ES6 introduces lots of interesting features that could help us reduce the amount of code we are using and the potential errors.
Though, not all the browser support it which means we would be obliged to use a transpiler that would complexify development.
That is I really think we should start to move towards ES6 asap.
What do you all think about this?
Note: This discussion was imported from Loomio. Click here to view the original discussion.
I donāt want to use any build-tools to create the javascript-files we use in developmentā¦ just edit and reload.
If there was browser support of all major desktop and mobile browsers AND you want to create a new feature, using ES6 specific features would be acceptable. But if you have too much time, donāt rewrite existing stuff in ES6, there are much more things to do. 
Apparently one could integrate https://github.com/browserify-rails/browserify-rails with https://github.com/thlorenz/es6ify or some similar solution that does the compilation inside the asset pipeline. But yeah, not sure itās worth all that since it increases compile time, makes the code less transparent (= harder to debug) and increases the inconsistencies again since we wouldnāt want to port all existing code.
But yeah, not sure itās worth all that since it increases compile time
I hadnāt though about that.
increases the inconsistencies again since we wouldnāt want to port all existing code.
Couldnāt be done step by step, like we did with the port of SASS to SCSS or Blueprint to BS2 ?
Porting everything sounds like a shitload of work for little benefit. We still didnāt even manage to port everything to Backbone.
FWIW, sprockets-es6 ships babeljs in Rails.
But, as Jonne said, I see no purpose in rewriting everything. What are you even talking about, Augier? Fat arrows?
Really guys. Diaspora suffers from performance and bloat problems. I think there are better things to fine tune fron-end code 
What are you even talking about, Augier? Fat arrows?
Among other things, yes. There are also template strings. These are really the two main features that could have lighten the code a lot.
But indeed, it is not certain it worth the effort.
@denschub years laterā¦
While submitting a PR, I changed some varās to letās - as suggested by my coding-tool, and just slipped into the problem that in
config/envirommnents/production.rb
the Line
config.assets.js_compressor = Uglifier.new(harmony: true)
should have set. (instead of config.assets.js_compressor = :uglifier)
Is this just what it means to āenable ES6ā ?
Tell your IDE not to do that - and/or revert it. Changing a lot of lines just for the sake of it isnāt worth - it creates a lot of diff noise with no benefit at all.
Also, no, this is not what āenabling ES6 meansā. 
There already is āsupportā for āes6ā, but only in JS files with the .es6 extension, like app/assets/javascripts/helpers/profile_photo_uploader.es6 for example. Again, use that if you need to, not because your IDE claims itās better to use let instead of var.
Edit: I want to highlight that even this approach is kinda weird. Itās 2021, there is no reason to transpile, at all. In hindsight, diaspora/diaspora#7569 should have been pursued and pushed, because that would not only remove the need for hacky asset gems, but also make changes to the frontend pipeline less painful. Oh well.
Will the āterseā PR change this?
So, did I understand it right - modern browser support ES6 syntax, then the ES6 suffix will not be needed? And minimizing with ES6 syntax will be supported with terse?
Sorry, Iām not the right person to answer your questions, I fear. I have never heard of āterseā - and given Iām focusing on other things these days, I have not even looked at the PR you are referring to.
But in general, yes, if the asset build chain does not explode with untranspiled ES6+ in the source, then thatās the way to go, probably. Itās fairly unreasonable to expect any modern project to support browsers stuck in the past century, imho.