Jimp: Moving to es2015

[houd1ni]

Hi! I'm making a module https://github.com/oliver-moran/jimp/issues/183
and just faced with a little problem: I'd better make it using modern techniques or CoffeeScript.

The library is already written in es5 and cs isn't widely popular.
So, how about es2015 with smth. like babel for deploying into old browsers?

The code is a bit obscure due to following old standards comparing to modern.
Maybe a little rewrite of the syntax?

[davidfekke]

es5 syntax is backwards compatible with es201* syntax. I just wrote a module called jimp-appicon that uses jimp and was written in es2015 syntax. I did not have any issues using jimp even though I used es2015

[houd1ni]

@davidfekke yes, of course, but I'm talking about core jimp rewriting for best isomorphic design.
And your module seems to be a special case tool: it's can be written even in some native add-on 😸
And to have a chance to be merged, I have to discuss it with repo owner, do I?
By the way, how do you look at this core /change/?

[aurium]

Caution on moving to ES6!
For a lib like jimp, performance is more important than code beauty.
ES6 implementation still slower than ES5 for most cases.

I like CoffeeScript, however i'm not sure if it will be easy to translate all jimp code to coffee.

[thisconnect]

Today ES6/ES2015 performance vary. It will be required to be transpiled through babel or buble. This is for some reason already done for the browser build:
https://github.com/oliver-moran/jimp/blob/7d5157d36dc2cbcf6f16cdd75a19ac9d11248e36/browser/browserify-build.sh#L12
https://github.com/oliver-moran/jimp/blob/52d9f6e9d2f989b0d987b922620bbdb2087b8e3c/package.json#L43-L46

The major benefit of having the jimp sources written in es-modules is, the ability to tree shake your application and end up with a bundle containing only the functions you really use. d3, three, lodash moved to es modules and use rollup/buble to bundle/transpile see http://rollupjs.org/

[abritinthebay]

Got to agree that this is a good, medium term, plan for many reasons but should be undertaken with care and after a full regression & benchmark suite is built.

[aditya2272sharma]

Opinion: Transpiling will only slow the project down. If something is not there in Node v6.x directly, and if we've to use a transpiler to get around it, then IMO, it won't be as productive as it has been so far. Debugging is quicker when you don't have additionally TAT.

[abritinthebay]

Speaking as someone who writes and debugs ES6 production code daily practically - that's simply not true.

It may slow deployment of a new version down (because it'll build a distribution version before publish) but day-to-day development is no slower and, when features are supported natively (in Node 6/7/8 as most are) they can be faster (not always, but they will get faster). The worst case speed wise is using the ES5 version form... which this library already does!

If anything the only slow down would be the time taken to create in the initial setup/build chain, but that's not that long.

That being said - it's not a small thing so should be done with caution.

[hipstersmoothie]

closed via #473