Hacker News Reader

Comment by dclowd9901 | Hacker News Reader

But it isn't. There's no aspect of it that would be extra trouble. It's just mechanical transforms. That's like saying true refactoring is "trouble".

View on HN

Until one found the code failed on some version on browsers, or worst - mobile browsers...

Then you need to debugger your code, compiled code, sourcemap files, compiler, compiler options, the layer and layers of configuration JSON scripts and mobile browser.

I've been working with es6 for two years now and never even heard of this happening to someone. Given the huge number of people who use babeljs, if there were to be a bug in it, it'd be reported and fixed rather quickly.

Yes, transpiling es6 -> es5 is adding another layer of complexity to your codebase, another thing that could potentially go wrong, but the reality is that the development gains we get from being able to use es6 are far more important than a small chance of a problem. It works well enough that you don't even think about it after leaving webpack in watch mode.

Really curious about the tangible gains of using ES6 over ES5.

Especially since ES6 is being converted to ES5 at the end of the day.

It adds some extra nice language features to JS. It really is a good productivity improvement, especially with JSX which enables HTML literals: pretty much essential when working with a complex React front-end in my opinion.

My team has been using it for most of this year now and we've had no problems so far.

Block scoping (using const/let instead of var which is scoped to the function) alone is really nice, but I also make heavy use of destructuring, arrow functions, template literals, export/import syntax and promises. Es6 makes javascript more pleasant to code with, and can greatly improve readability.

es6 has become pretty well supported by modern browsers, so maybe after a year or so, we'll just be calling it "javascript" and running it without babel. I expect everyone to continue to transpile, though, to get newer features as they come, as the plan for ES is to release new language updates on a yearly basis.

> Then you need to debugger your code, compiled code, sourcemap files, compiler, compiler options, the layer and layers of configuration JSON scripts and mobile browser.

This seems like you're deliberately trying to make things sound way more complicated than they actually are. If there is a bug in the code on a certain platform, you examine the bug on that platform and add the appropriate feature detection code to fix it. There is no need to debug the compiler and every other tool in your stack, it all compiles to javascript at the end of the day and assuming you're not running a minifier in development, 99% of platform specific bugs are readily apparent and almost certainly the developer's fault (i.e. not the tool's fault)

Have you tried add OAuth support to your web app?

After with, do your team do automated regressive tests the oauth support and all other functionalities on all the regular browsers and mobile browsers?

+ Older version browsers?

+ Older browsers in older version of Linux, Mac, Windows?

+ Browsers with plugins such umatix, unblock origin, noscript that blocks scripts from your own domains + other domains?

I'm not really sure what your point is. If OAuth integration is a requirement for your project then its your responsibility to test it across the platforms you intend to support and that's a universal truth no matter what development stack you're working with.

Dealing with sourcemaps absolutely causes extra trouble. Transpiler errors and bugs can also pop up at the worst times. Any time you add more steps to your compilation and deployment process, you're adding risk and potential trouble. That's just a fact of life. I'm not saying not to use es6 because I do and it's awesome, but I am not under the illusion that it's all sunshine and rainbows.

Reply on news.ycombinator.com