6 ms·
On the web browser side, I don't recommend using ES6 yet, without any kind of fallback. Internet Explorer 11 is still used, as are devices on older iOS versions
by my123 10y ago
On the web browser side, I don't recommend using ES6 yet, without any kind of fallback. Internet Explorer 11 is still used, as are devices on older iOS versions.
(without counting people using the default browser on pre-Lollipop Android)
- jaquers 10y agoIndeed. Are there any 'good' strategies for this (loading ES6 for supported browsers)? I imagine you'd have to do UA sniffing on the server side, and I suppose it's kind of a moot point if you're using React/JSX.
- Tankenstein 10y agoThere's no need unless you need runtime-only concepts, like new string methods. Use https://babeljs.io/ https://babeljs.io/ to turn nice es6 into es5. (I imagine you already know this, if you're using react/jsx)
- megous 10y agoJust try to eval a sample of ES6 syntax you use, and if it throws error, load ES5 code. You'd need to feature check all the features that you use, to cover the browser versions with incomplete ES6 support.
- hzoo 10y agoWorking on https://github.com/babel/babel-preset-env https://github.com/babel/babel-preset-env right now which should help with this
- Tankenstein 10y agoFor anyone who wants to use ES6 in production, https://babeljs.io/ https://babeljs.io/ is amazing.
- treve 10y agoIt's both amazing, and 600MB worth of dependencies. We use it for server-side code. It's high quality, and we only have a few issues with it, but I can't wait to be able to ditch is (pretty much when async/await lands in a stable node).
- fryan 10y agobuble is a good alternative - small and fast. Doesn't support all of ES2015, but it does support the examples in the article. https://buble.surge.sh/guide/ https://buble.surge.sh/guide/
- pitaj 10y ago600MB worth of development dependencies, which don't effect the code being sent to the client. Just wanted to clarify.
- treve 10y agoI'm using it server-side, so yea, you're not wrong.
- tlrobinson 10y ago600MB is a huge exaggeration. Looks like about 34MB for babel-cli, babel-preset-es2015, and babel-preset-stage-0.
- vcarl 10y agoDoing du -ch ./babel* from my `node_modules` directory yields 3.2M total so I'm gonna need a citation on that 600MB claim.
- deleted 10y ago[deleted]
- baristaGeek 10y agoHave used it in production and it's amazing. Have you tried Minify(Babili) by the way?
- fenomas 10y agoAlso - for anyone writing code where performance matters, the question isn't when browsers support the syntax, it's when each JS engine's optimizations support it. E.g.: until some months ago just putting "let foo" into a function would cause V8 to bailout (meaning the whole function gets executed slowly, even if the actual let statement gets removed as dead code). Unfortunately I've never found any good references on the optimizability of ES5+ features, so I've been avoiding them so far.
- acdha 10y agoThis is a real concern, but it definitely carries the usual caveats about premature optimization and needing to measure regularly to confirm that it is a real concern and that the performance landscape hasn't shifted since the last time you measured it. The best suite I've seen is https://kpdecker.github.io/six-speed/ https://kpdecker.github.io/six-speed/ which measures node and the various modern browsers which Sauce Labs supports and appears to be run semi-regularly.
- fenomas 10y agoThat is a great reference, but in general I don't find myself caring much about the raw performance of individual statements that way. My concern is that this or that new syntax will prevent a function from getting inlined, or prevent the engine from guessing type information it otherwise would have guessed, or whatever - just because those bits of the optimizing compiler are newer and less robust.
- acdha 10y agoI'd assume the author would be receptive to pull requests for things like the `let` deoptimization.
- fenomas 10y ago`let` doesn't deoptimize anymore - actually V8 has made great strides here, and a lot of new syntax will go through the optimizer. More generally though, I wouldn't think the stuff I'm worrying about would show up in microbenchmarks.
- TheAceOfHearts 10y agoYou should be using babel to serve all your target browsers. But you can still use ES2015 during development; it's an absolute joy.
- baristaGeek 10y agoIf you're developing a desktop-only app (or you're making a native app for the mobile frontend) ES6 works pretty well. At least I haven't received any complaint yet, and if you can optimize early on without any short-term cost then it's the best thing you can do. Thank god Chrome and Firefox dominate the market.
- neurostimulant 10y agoFor developing browser extensions I think ES6 is currently can be used safely (at least for Chrome).