I've been working on some scripts for automated testing of the Umbraco Back Office at the minute and I've been writing them in javascript ES6 syntax out of habit.
I'm wanting to see if thats a wise choice to use ES6 syntax but I'm not sure if its something "the community" would be comfy/happy doing.
There is a clear win to keeping it vanilla, everyone "knows it" right now. But moving forward that is likely to stop being the case. Newer dev's are going to start picking up and expecting ES6. It would be like coding in .net 1.1 still. The newer language features make you faster, safe and cleaner.
React JS went all in for ES6 with their logic being that "its the future" but it caused some headaches. ES6 is now mostly supported by the leading browsers with a bit of poly fill needed here and there for the others. As a result you have to run it through a transpiler like Babel. Now the trouble here was you now had to understand ES6, React AND Babel which caused some head scratching and one of the main reasons I think some devs run away from React (that shit looks too hard!). The barrier to entry in the early days was too high.
But in Umbraco land the config for the transpiling and poly fills would all be done for you already so you don't have to worry about that. But you would still need to learn ES6 if its a new thing to you but...learning is good right? Would this be a good thing to start moving the back office over to I wonder? This can be done bit by bit as each area is touched, it doesn't need to be a single big hit.
I'm not sure which way to go with it so wanted to open it up for discussion here.
THIS IS NOT a HQ endorsed idea btw, just me thinking out loud. I don't even know if they would want to go for it. But it effects me with my tests as I want to open source them.
Babel btw recompiles your code down to ES5 syntax (or not if you don't wnat it to, ie you know what browsers you are supporting) so under the hood it is "vanilla js". ES6 is for our benefit as developers and to future proof ourselves as our code won't age and we get to use the goodies of ES6 now rather than wait.
Thats good to know. And no I don't agree it should be a requirement, no need for it to be. But it changes the nature of contributing and understanding so worth having a chat about it.
PR's to Core could start asking that the changes are in ES6 for instance and rejecting those that aren't. Users will have to see two different flavours of JS for a while etc.
Package devs and custom property types etc. can all be done however you like. Its not a requirement more a design choice for those that want to.
PR's to Core could start asking that the changes are in ES6 for
instance and rejecting those that aren't. Users will have to see two
different flavours of JS for a while etc.
This will be the difficult part. You will end up with js files partially being ES6 and partially with vanilla js.
I definitely think it's a good idea. Babel is pretty inobtrusive, and plugins can stay as vanilla JS or babelified modules at the developers whim.
The roadmap however can be a bit bumpy. As @edparry mentioned on Twitter, it should probably be put in gradually as things are worked on. Which means contributors won't have the ability to look at "any other component" for inspiration / learning. Some "in your face" guidelines would be needed in order to prevent a growing tail of snippets to upgrade. (As I see @dawoe is concerned about as well.)
Let's say I take it upon me to convert a service to ES6 and this get's merged...then all PR's that make changes to the same file become unmergeable. So the PR creator needs to do extra work.
They other way around as well. If PR's get merged in changing the service I'm converting at that moment..will need to be merged in first in my PR...giving me extra work.
Maybe V8 will be a good place to start doing this.
In the very least, I think it should be allowed. Not so sure about required for PR's.
Could be a nice way to encourage some people to contribute (fancy new stuff can be appealing to some).
And worth keeping in mind, ES6 IS vanilla JavaScript. It's just a new version of it. It's not like we're porting everything over to TypeScript.
It's also worth nothing the sorts of things that are new to ES6, which people can see here: http://es6-features.org/
Some things of note:
Block-scoped variables (e.g., let i = 0;).
Expression bodied functions (e.g., x => x + 1;).
String interpolation (e.g., message = 'Hello, ${person.Name}.';). Note that the apostrophes should be backticks, but I can't figure out how to escape them.
Export/import for modules (e.g., import {pi} from 'lib/math';).
Classes (e.g., class Animal { grow() {this.height += 1;} }).
Promises (e.g., new Promise(function (resolve, reject) {resolve(5);}).then(function (val) {console.log(val);})).
And much more.
I can see some weird edge cases to avoid though. For example, exposing promises to public functions (i.e., ones expected to be consumed outside of the Umbraco core). Would want to avoid that, as I imagine callbacks are typically used currently.
Great point of discussion Pete. I'm all for ES6 and have been using it for a while now. As others have already said, at the moment II think it should be used alongside Babel or another workflow for compile down to ES5. We can't forget that our clients won't always have the latest and greatest browser, and a broken backoffice is a broken CMS.
Should our javascript start moving towards ES6?
I've been working on some scripts for automated testing of the Umbraco Back Office at the minute and I've been writing them in javascript ES6 syntax out of habit.
I'm wanting to see if thats a wise choice to use ES6 syntax but I'm not sure if its something "the community" would be comfy/happy doing.
There is a clear win to keeping it vanilla, everyone "knows it" right now. But moving forward that is likely to stop being the case. Newer dev's are going to start picking up and expecting ES6. It would be like coding in .net 1.1 still. The newer language features make you faster, safe and cleaner.
React JS went all in for ES6 with their logic being that "its the future" but it caused some headaches. ES6 is now mostly supported by the leading browsers with a bit of poly fill needed here and there for the others. As a result you have to run it through a transpiler like Babel. Now the trouble here was you now had to understand ES6, React AND Babel which caused some head scratching and one of the main reasons I think some devs run away from React (that shit looks too hard!). The barrier to entry in the early days was too high.
But in Umbraco land the config for the transpiling and poly fills would all be done for you already so you don't have to worry about that. But you would still need to learn ES6 if its a new thing to you but...learning is good right? Would this be a good thing to start moving the back office over to I wonder? This can be done bit by bit as each area is touched, it doesn't need to be a single big hit.
I'm not sure which way to go with it so wanted to open it up for discussion here.
THIS IS NOT a HQ endorsed idea btw, just me thinking out loud. I don't even know if they would want to go for it. But it effects me with my tests as I want to open source them.
I posted up a poll too btw:
https://twitter.com/peteduncanson/status/1011546617525219329
Thoughts please.
Babel btw recompiles your code down to ES5 syntax (or not if you don't wnat it to, ie you know what browsers you are supporting) so under the hood it is "vanilla js". ES6 is for our benefit as developers and to future proof ourselves as our code won't age and we get to use the goodies of ES6 now rather than wait.
Hi Pete,
Core moving to ES6 : yes...yesterday.
But it should not be requirement for extending the backoffice...just an option.
Dave
Thats good to know. And no I don't agree it should be a requirement, no need for it to be. But it changes the nature of contributing and understanding so worth having a chat about it.
PR's to Core could start asking that the changes are in ES6 for instance and rejecting those that aren't. Users will have to see two different flavours of JS for a while etc.
Package devs and custom property types etc. can all be done however you like. Its not a requirement more a design choice for those that want to.
This will be the difficult part. You will end up with js files partially being ES6 and partially with vanilla js.
Dave
I definitely think it's a good idea. Babel is pretty inobtrusive, and plugins can stay as vanilla JS or babelified modules at the developers whim.
The roadmap however can be a bit bumpy. As @edparry mentioned on Twitter, it should probably be put in gradually as things are worked on. Which means contributors won't have the ability to look at "any other component" for inspiration / learning. Some "in your face" guidelines would be needed in order to prevent a growing tail of snippets to upgrade. (As I see @dawoe is concerned about as well.)
My biggest concern is the PR process.
We still have a lot of old PR's open for v7.
Let's say I take it upon me to convert a service to ES6 and this get's merged...then all PR's that make changes to the same file become unmergeable. So the PR creator needs to do extra work.
They other way around as well. If PR's get merged in changing the service I'm converting at that moment..will need to be merged in first in my PR...giving me extra work.
Maybe V8 will be a good place to start doing this.
Dave
Any PR to V7 with new functionality would need to be ported to V8 as well. ><
And there is a big (unknown to me) bundling process in there today.
Then again, if you never start...
In the very least, I think it should be allowed. Not so sure about required for PR's.
Could be a nice way to encourage some people to contribute (fancy new stuff can be appealing to some).
And worth keeping in mind, ES6 IS vanilla JavaScript. It's just a new version of it. It's not like we're porting everything over to TypeScript.
It's also worth nothing the sorts of things that are new to ES6, which people can see here: http://es6-features.org/
Some things of note:
let i = 0;).x => x + 1;).message = 'Hello, ${person.Name}.';). Note that the apostrophes should be backticks, but I can't figure out how to escape them.thing = { ['index_' + index]: index * index};).import {pi} from 'lib/math';).class Animal { grow() {this.height += 1;} }).new Promise(function (resolve, reject) {resolve(5);}).then(function (val) {console.log(val);})).And much more.
I can see some weird edge cases to avoid though. For example, exposing promises to public functions (i.e., ones expected to be consumed outside of the Umbraco core). Would want to avoid that, as I imagine callbacks are typically used currently.
Great point of discussion Pete. I'm all for ES6 and have been using it for a while now. As others have already said, at the moment II think it should be used alongside Babel or another workflow for compile down to ES5. We can't forget that our clients won't always have the latest and greatest browser, and a broken backoffice is a broken CMS.
is working on a reply...