Live data from Hacker News

Ask HN: If you targetting ES6 by default, how did you rationalize that choice?

news.ycombinator.com

31–40 of 62 posts

Re: Ask HN: If you targetting ES6 by default, how did you rationalize that choice?

#31

I think the word "target" in the question is unclear, or at least has been misinterpreted. Many of the answers here seem to be about why you would write your source code in ES6, but at least to me, the "target" code is the code that actually ends up executing (whether on the server or in the user's browser or whatever). I think it all depends on your context and use case. If you're running code on the server, there's…

> If you're running code on the server, there's no reason to compile down to ES5

Actually, ES6 is not running at full speed in Node yet. So there are still some performance benefits on transpiling.

Re: Ask HN: If you targetting ES6 by default, how did you rationalize that choice?

#32
post #8

Hello! I assume you are talking about we development. As a developer, the new versions of EcmaScript include good features that make easier the development of our applications. Also, ES6 is not a beta, it's a new version of the language. We are talking about frontend, so the execution environment of our application is unknown. However, the benefits of using the new features are big. For me, the most important one is…

"With the new versions of ES, my code is more independent from external sources."

What about all of those external sources brought in to support building\transpiling\source map generation\whatever?

Re: Ask HN: If you targetting ES6 by default, how did you rationalize that choice?

#33

I think the word "target" in the question is unclear, or at least has been misinterpreted. Many of the answers here seem to be about why you would write your source code in ES6, but at least to me, the "target" code is the code that actually ends up executing (whether on the server or in the user's browser or whatever). I think it all depends on your context and use case. If you're running code on the server, there's…

> If you're running code on the server, there's no reason to compile down to ES5 Actually, ES6 is not running at full speed in Node yet. So there are still some performance benefits on transpiling.

The runtime performance lost using ES6 features is minuscule compared to the runtime performance lost by using Node.js in the first place. If the difference in performance for the ES6 features actually matters then you have made a grave mistake using Node in the first place.

Re: Ask HN: If you targetting ES6 by default, how did you rationalize that choice?

#34
post #33

Earlier quoted context omitted.

> If you're running code on the server, there's no reason to compile down to ES5 Actually, ES6 is not running at full speed in Node yet. So there are still some performance benefits on transpiling.

The runtime performance lost using ES6 features is minuscule compared to the runtime performance lost by using Node.js in the first place. If the difference in performance for the ES6 features actually matters then you have made a grave mistake using Node in the first place.

Are you comparing node to C or Go or something else?

It's funny, my big a-ha moment on performance happened when I was working at a bank and could only code in vba (i.e. excel). All of a sudden -- even on small data sets -- O(n^2) was unacceptable and I needed to think about algorithms to get to O(nlgn).

Re: Ask HN: If you targetting ES6 by default, how did you rationalize that choice?

#35
post #5

IMO, you should set up an analytics funnel to measure landing page conversion or (for web apps) usage metrics based on browser version. Whenever the cost of supporting old, ES5-only browsers (measured by the amount of time spent debugging/adapting code * dev hourly rate) surpasses the income brought in by users on those browsers, it's probably time to make the switch. For the web app case, you obviously don't want to…

This is the best comment. Thanks k you for making it about the customer and the user instead of "code beauty".

Re: Ask HN: If you targetting ES6 by default, how did you rationalize that choice?

#36
I limit myself to ES6 features supported by Node LTS on the server-side.

I limit myself to ES5 code on the client side for now and probably at least next year too.

By writing code that is compatible with the platform it runs on I'm able to avoid having a slow, lengthy or complex build process to reach that state.

Re: Ask HN: If you targetting ES6 by default, how did you rationalize that choice?

#37
Might be a good chance to suggest using our new preset: https://github.com/babel/babel-preset-env/.

TL;DR - automate your Babel config options based on targets.

babel-preset-env: A Babel preset that can automatically determine the Babel plugins and polyfills you need based on your supported environments.

It takes the data from compat-table [1] to generate a mapping [2] between a Babel plugin and the first version that a browser/env supports. We calculate the least common denominator of your targeted envs to determine the final set of plugins to compile with.

(Feel free to ask questions, I help maintain Babel and the preset). Just released a 1.0 a few weeks ago and looking for more help and usage! Looking into more help with removing unnecessary polyfills, and determining plugins based on performance via benchmarks of native/compiled.

And yes there is a lot of work that goes into making this work correctly (and in the foreseeable future with ES2015+). Would appreciate any help moving forward. And maybe we should just replace/recommend this preset instead of anything else to fight the fatigue..

[1]: https://kangax.github.io/compat-table/es6/ [2]: https://github.com/babel/babel-preset-env/blob/master/data/p...

Re: Ask HN: If you targetting ES6 by default, how did you rationalize that choice?

#39
post #5

IMO, you should set up an analytics funnel to measure landing page conversion or (for web apps) usage metrics based on browser version. Whenever the cost of supporting old, ES5-only browsers (measured by the amount of time spent debugging/adapting code * dev hourly rate) surpasses the income brought in by users on those browsers, it's probably time to make the switch. For the web app case, you obviously don't want to…

This is the best comment. Thanks k you for making it about the customer and the user instead of "code beauty".

I think people are making it about code beauty because ES6 is code, not a user concern. Right now you're pretty much transpiling down to ES5 for anything user facing.
Post reply on HN