Refactor client to ES6

Wondering what people’s opinions are on this. Currently, the primus.js file in the root of this repository is still written in ES5. Would it make sense for a maintenance point of view to transform this to ES6 as well and just have babelify it during the browserify process so we end up with ES5 again?

Obvious downside would be a slight increase in file size due to extra babel helpers and other sorts of polyfills that would be added but it might make more sense to have a unified code base here where everything is written in ES6 classes, const, fat arrows.

The only biggest hurdle we would need to tackle is Node.js support, because we re-use the same client code base from the browser for the Node.js client.

[3rd-Eden]

The main reason would be to have a consistent code base. As the rest of the code is already in ES6.

[joepie91]

It’s important to keep in mind that ES6 does not replace ES5. It merely adds a number of new features to the language that can help in the cases where they are appropriate (ie. where they fit the requirements well).

Rewriting code to “use ES6 features as much as possible, for the sake of using ES6” is therefore a bad idea. This particularly applies to remarks like:

a unified code base here where everything is written in ES6 classes, const, fat arrows

… which isn’t really what you’d want. The value of ES6 classes is dubious in and of itself, const is not necessarily universally applicable (eg. when you need to reassign things you’ll want to use let), and arrow functions are not functionally equivalent to regular functions; they have different semantics, so they can’t wholesale replace regular functions.

I’m not at all saying it’s a bad idea to start using ES6 features, provided that the transpilation concerns are addressed, but trying to maximize ES6 feature usage makes no sense and will just lead to a bigger maintenance burden.

(On a loosely related note, while ‘consistency’ can be a beneficial factor to readability and maintainability in some cases, it can also work against it; consistency in and of itself should really never be a design goal of any codebase.)