No post body was provided.
Ask HN: If you targetting ES6 by default, how did you rationalize that choice?
1–10 of 62 posts
Re: Ask HN: If you targetting ES6 by default, how did you rationalize that choice?
#2Presumably you mean in the browser, rather than node.js? When you can compile and use polyfills with babel and webpack, then why not?
Re: Ask HN: If you targetting ES6 by default, how did you rationalize that choice?
#3How would you rationalize not using ES6?
Re: Ask HN: If you targetting ES6 by default, how did you rationalize that choice?
#4Chrome Extensions! Writing Chrome Extensions is a great way to use all the latest and greatest javascript for a practical project.
Re: Ask HN: If you targetting ES6 by default, how did you rationalize that choice?
#5IMO, 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 just cut out access to those users (that would be pretty bad customer service! that can totally ruin your reputation), so you also need to factor in the costs of educating your users about the upgrade, giving them enough time and/or providing an alternative means of using your app. (ex: an Electron-based app installer)
Considering how good the polyfills and transpilers currently are (assuming you already have those set up) the maintenance costs of supporting ES5 are very low. It makes very little financial sense to not support it for existing applications ATM.
If you're just starting with an app, that is going to launch in one year or more (assuming you're focused on a general audience , instead of a specialized market like corporate where browsers are updated more slowly) then I'd probably already start without worrying about ES5 at all.
Re: Ask HN: If you targetting ES6 by default, how did you rationalize that choice?
#6* It makes the language much easier to work with
* Most people familiar with JS will pick up on them very easily
* It makes "patterns" like immutable data and some straightforward async code MUCH easier (object spread, async/await, etc...)
* node.js supports it (with a slight speed penalty, however it hasn't bottlenecked us yet so we aren't worrying about it yet)
* Most modern browsers support many of the features, and those that don't the polyfills and compilation is pretty much "drop in" with the rest of our build system.
* Dead code elimination has completely changed how we architect our projects for the better
* const gives us less bugs by preventing overwriting and scope confusion
* One of the main applications we are using it on only supports newer browsers that support ES6 natively anyway (due to needing certain browser APIs), so using the full extent of those browsers doesn't seem like it's going to cause any issues.
and finally...
* There doesn't seem to be any downside. We are only using stuff which is already in the spec, or close enough to being finalized that we are comfortable. If performance is an issue we can just not use it in performance critical code, and it's just nicer to work with.
I will say that it's not all daisies and roses though. We are worried what will happen if the module loading spec goes in another direction than we think it will, not to mention that interfacing with external ES6 libraries is either done through transpiled common-js code (which loses most of the benefits of ES6), or through "hacky" solutions like a "nonstandard" field in the package.json which lets something like webpack load the ES6 version (which we have no idea what features they are using, might need transpiled, might need fixed, etc...).
Like anything, it's a bit of a gamble. But I'm confident that we will save more time and have less bugs by using the new features than we will lose to fixing modules to be inline with the spec or dealing with incompatibility problems.
Re: Ask HN: If you targetting ES6 by default, how did you rationalize that choice?
#7* It makes the language much easier to work with * Most people familiar with JS will pick up on them very easily * It makes "patterns" like immutable data and some straightforward async code MUCH easier (object spread, async/await, etc...) * node.js supports it (with a slight speed penalty, however it hasn't bottlenecked us yet so we aren't worrying about it yet) * Most modern browsers support many of the features, a…
One interesting counterpoint to what you're saying: async/await are not ES6.
Although I'm 100% on board with ES6 adoption, there's a slightly worrying element of everyone having a different definition of what it is.
Some NPM packages have a "jsnext:main" attribute allowing you to redirect the "main" JS file to load, but it requires you to only use ES6 modules + features currently supported by Node. So you end up transpiling two versions from the original source. It's messy.
Re: Ask HN: If you targetting ES6 by default, how did you rationalize that choice?
#8Hello! 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 the new methods on basic types. With old versions of EcmaScript, I needed to rely in third party libraries to add some functionalities to my project. With the new versions of ES, my code is more independent from external sources.
Also, Babel provides backward compatibility for old versions of the language. As I mentioned, we don't know the execution environment of our project, but the TC39, the committee behind the decisions of the new features, has thought in this. Adding backward compatibility is a requirement for new features in the language.
Re: Ask HN: If you targetting ES6 by default, how did you rationalize that choice?
#9* It makes the language much easier to work with * Most people familiar with JS will pick up on them very easily * It makes "patterns" like immutable data and some straightforward async code MUCH easier (object spread, async/await, etc...) * node.js supports it (with a slight speed penalty, however it hasn't bottlenecked us yet so we aren't worrying about it yet) * Most modern browsers support many of the features, a…
One interesting counterpoint to what you're saying: async/await are not ES6. Although I'm 100% on board with ES6 adoption, there's a slightly worrying element of everyone having a different definition of what it is. Some NPM packages have a "jsnext:main" attribute allowing you to redirect the "main" JS file to load, but it requires you to only use ES6 modules + features currently supported by Node. So you end up tran…
Neither is object spread, but yeah I've stopped worrying about those labels. For the most part people treat "ES6" as "all new JS features", and that's not going to go away soon.
Though when I see ES2015, I tend to take it literally.
But moving forward it's going to be important to see what version of the language people are using in their libraries. I can already see github badges for "ES2015 only" or "ES2016+" or something.
Or maybe a plugin which will scan the sources you import into your project and give you warnings if a library is using a feature you aren't supporting/transpiling...
Re: Ask HN: If you targetting ES6 by default, how did you rationalize that choice?
#10The code that I write will still be used in 5 years.
I can write ES6, stick babel.js on it and my code will be both present-proof and future-proof.