Switch to ES6

[oparoz]

From @oparoz on June 20, 2015 21:18

Now that ES 6 is official, we can begin to think about switching to it, but none of the browsers or transpilers support all the features, so it's probably a task for 2016.

https://kangax.github.io/compat-table/es6/

We currently support ES5 in strict mode.

It would be a great opportunity to add testing (#344) as we go along

Sponsorship

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Copied from original issue: owncloud/gallery#173

[oparoz]

From @Siddharth11 on March 2, 2016 12:12

Hi @oparoz!
How should we proceed with this task. I was thinking to make a new folder and transpiling (using grunt and babel) all files in js folder one by one.

[oparoz]

I think you're on the right path. We would keep all source files in /js and have generated files in /js/dist perhaps?
The project has to be divided in several sub-projects, aiming to convert individual classes or group of classes, maing it easier to test for regressions.

Also, it would be a great opportunity to add testing (owncloud/gallery#344) as we go along

[oparoz]

From @Siddharth11 on March 2, 2016 17:24

@oparoz that sounds great!
Also, are we planning to implement all ES6 features? Honestly, I'm not a big fan of ES6 classes, it's like we're trying to make javascript into something else just for the ease of developers coming from different community. I still prefer normal prototypal inheritance (for efficiency) + a bit of functional programming approach (for readability) as seen in this tiny JS library I recently made using ES6.

Ultimately it's your call :)

[oparoz]

Also, are we planning to implement all ES6 features?

I don't think that's necessary. I simply would like for the code to be more robust, easier to understand and testable.

Regarding ES6 classes, I'd like to hear what @BernhardPosselt, @icewind1991 and maybe @PVince81 have to say about it.

When reading es6 code, I find import/export statements useful per example.

[oparoz]

From @BernhardPosselt on March 3, 2016 8:43

I'm unsure if this is a well defined GSOC task (mechanical turk work :D) and if its a benefit to do this right now. FYI Modules are not implemented in any browser yet and you also dont see them listed on kangax' es6 table which means that you will have to transpile no matter what.

The transpiling experience itself is quite horrible IMHO, there are too many choices (typescript, es6, coffeescript) too many tools (gulp, webpack, browserify) and too much configuration and headaches (karma). I've given up and will gradually enhance newer code so I won't have to transpile.

[oparoz]

From @BernhardPosselt on March 3, 2016 12:33

Another addition to ES6 modules: the current wrapper logic (in whatever module loader) is vastly different from the actual spec, so this has potential to break when you don't use the wrapper anymore.

[oparoz]

Thank you for your valuable input @BernhardPosselt .

I created the issue last year as a long term goal to modernize and better organize the app. That's the reason I wanted to focus on classes and modules first and didn't mind having to transpile everything. Having said that, there will probably be an issue with debugging, because the end result in the browser will not match what we wrote. This makes it even harder for people not familiar with the project.

If we drop transpiling then it becomes, as you've mentioned, only about migrating methods and I doubt students will find this project interesting.

What do you think @Siddharth11? Have you looked at the code in Gallery and do you see some opportunities to improve the overall architecture? Have you worked on projects of similar size using ES6 + transpiling?
Don't forget that you can come up with your own projects, so don't hesitate to come up with new ideas.

[jaller94]

It seems to me that some bundled apps moved to ES6 with webpack and Vue.js.
The debugging of transpiled code is possible by generating source maps.

Example:

• https://github.com/nextcloud/server/tree/master/apps/oauth2
• https://github.com/nextcloud/server/tree/master/apps/accessibility
  The transpiled JavaScripts and source maps can be found in js. The source files can be found in src.

The folder structure, code and templating of HTML is much more readable to newcomers. I think a structure like this would greatly benefit the contributability of the gallery app.