13 ms·
The cost of transpiling ES2015 in 2016
- bretthopper 11y agoNot sure why this is linking to a fork of the original repo. It was discussed recently here: https://news.ycombinator.com/item?id=11021271 https://news.ycombinator.com/item?id=11021271
- paulirish 11y agoYah... I'm confused as well. :/ But I did work with Sam on this project and I think it's quite worthwhile!
- niftylettuce 11y agowhat happened to tambourines lol
- AlexMuir 11y agoApologies, I didn't notice it was a fork.
- reimertz 11y agoI was confused at first as well, but I guess it doesn't hurt if this generates some more discussion (with the help of paul irish and his fame :D). Fun fact, I was just about to migrate all of my js to es6.. Might have to investigate further what transpiler to chose instead of blindly do what the mass seems to do.
- wrong_variable 11y agowait. Browserify is for package-management. For people who want to do node.js style requires in their browser. Closure Compiler is for optimization, it is to get rid of dead code. Browserify is not optimized for performance. Why is this post surprising ?
- fenomas 11y agoThis confused me as well. The point of browserify is that it groks npm versions and wrangles your dependencies. Whether you want to transpile or uglify etc. is orthogonal to whether you need browserify/webpack, isn't it?
- draw_down 11y agoThere wouldn't be a bundle for Babel to transpile if the code wasn't Browserified first. I don't know much about Closure compiler but apparently it handles both the transpilation step and the bundling step.
- fenomas 11y agoI think that closure and other transpilers do "bundle", but only in the sense that they resolve explicit ES6 imports. They don't attempt to grok versions or dependencies the way browserify/webpack do.
- nailer 11y agoDoes closure compiler tree shake commonjs? If not, I'd rather stick with browserify than lose access to all of npm.
- cdnsteve 11y agoTranspiling is temporary. Soon browsers will catch up and many of these tools will no longer be needed. Unless, of course, everyone wants to start using ES7 when browsers actually support ES6. JavaScript is maturing, this is good news. We are lucky so many tools have become available.
- kmkemp 11y agoBrowsers will always lag behind specifications.
- gburnett 11y agoYes, I'm not sure why transpiling will ever go away. Not sure either why it would be limited to specifications.
- MrPatan 11y agoTranspiling will go away when people stop trying to push their own web-breaking language. It wasn't cool for Microsoft to push JScript in the 90s, why is it cool now for it to push TypeScript? And allied with Google, no less!
- spion 11y agoBecause: 1. JScript added conditional compilation directly in the browser which was IE-only (extend, extinguish). TypeScript compiles to cross-browser JavaScript (which does none of the above) 2. TC39 is supposed to be working in a "pave the cowpaths" (1) mode. Before new features get integrated into EcmaScript, TC39 looks into what the community is already doing (existing cowpaths), then integrates that into the language. Not only that but TC39 can learn from the mistakes of TS and Flowtype when they add type system support in EcmaScript. We are in dire need of one - and thanks to Microsoft's and Facebook's explorations, we now know what kind of type system would work for JS. (1) For example, we got arrow functions in ES2015 thanks to CoffeeScript.
- kristiandupont 11y ago
- dustingetz 11y agoI think one could transpile to javascript compatible with the Google Closure compiler which does dead code elimination. Someone's probably already on it.
- emidln 11y agoGoogle Closure compiler seems to already support this out of the box: https://github.com/google/closure-compiler/wiki/ECMAScript6 https://github.com/google/closure-compiler/wiki/ECMAScript6 Edit: s/good/support/
- eatonphil 11y agoThat page says there are a number of features they aren't interested in supporting. Is there an actual list somewhere? I don't want to start using this then discover things I wanted to use just aren't supported.
- dustingetz 11y agoHave they figured out a solution to the string/property access problem preventing us from passing all js through Closure compiler? (To those who aren't aware, Closure compiler is already an excellent compiler stack, but it requires you write a specific subset of javascript[1], so real-world js written without specifically targetting Closure are generally not compatible. Closure compiler is not currently useful to a javascript developer who depends on the npm ecosystem) [1] e.g. write foo.bar instead of foo['bar'], so Closure compiler can do name mangling and dead code elimination. edit since i currently sit at zero points: my point being that you can't dead-code eliminate your dependencies, which is the whole point of using closure compiler instead of whatever other toolchain.
- Scarbutt 11y agoyou can use external libs but you have to write an extern file, the extern file only needs to reference the parts of the lib you use.
- lobster_johnson 11y ago
- minionslave 11y agoJavascript is kinda messy. So many things needed to get stuff working right. Uglyfy, browserify, babel. Will there ever be an alternative language that can allow me to just: write, compile, run in browser?
- morgante 11y agoI assume your comment is sarcastic, because Javascript is obviously the only language which you can just write and immediately run.
- coldtea 11y ago...if you don't work in any company with a convoluted build process that includes transpiling (which is nearly all of them).
- Raphmedia 11y agoUnlikely. Unless we were to discard support for all old browsers and all new browsers update automatically and support the same features across devices and OS.
- ZenoArrow 11y agohttps://medium.com/javascript-scene/what-is-webassembly-the-dawn-of-a-new-era-61256ec5a8f6#.ba84xpc0f https://medium.com/javascript-scene/what-is-webassembly-the-...
- krapp 11y agoThose things aren't needed to get javascript to work properly, most such "hacks" are necessary because of the DOM, proprietary standards and the ridiculous variety of devices web content needs to be displayed on. Even if you had an alternative language, those problems would still remain.
- trimbo 11y agoHere ya go: http://grail.sourceforge.net/ http://grail.sourceforge.net/
- planetmcd 11y agosamccone works hard at this stuff, link to the original repo.
- dang 11y agoDone, but in the future please include a URL the way https://news.ycombinator.com/item?id=11059143 https://news.ycombinator.com/item?id=11059143 did, and then we can act on your suggestion.
- ThePhysicist 11y agoPersonally I find the advantage of using ES2015 over ES5 marginal for most use cases, so I actually went back to writing "traditional" ES5 JS with require.js imports and only use a JSX->JS transpiler for the React part of my code. This helps me a lot to stay "closer" to my code and reduce the complexity of my build chain. Many things that ES2015 provides are nice of course and the code looks a bit cleaner, but apart from a few real innovations most changes seem to be syntactic sugar. Also, I found that each step in my build chain made it more complicated to build and maintain my code, especially for other developers. I eventually even abandoned Gulp (which in my opinion tries to reinvent Unix pipes but does it all wrong) in favor of a simple Makefile that chains a few build commands and uses inotifywait to watch the filesystem for changes in order to automatically rebuild the code during development. Another thing I do which may shock many JS people is to actually check in the build directory of my setup into version control, because this makes deployment much easier and ensures that I will always have a working version of the code in the repository, even if some external dependencies should change in the future. This also eliminates installing extensive tooling on my production servers, which itself is a large burden and creates many security issues (for a simple setup consisting of rabel, react, require.js and a few support libraries, node.js downloads about 350 MB of source files onto the machine).
- xbryanx 11y agoYes, I am a big fan of checking in the build directory. We work on lots of little one-off apps that need to last for 5-8 years. Having the build dir in the version control makes it so much easier to fix things and update content years down the road. It insures us from things like npm (insert your package manager here) going away. Which I know sounds ridiculous, but try to re-download some essential Flash/Actionscript library from 2009, in 2016.
- n0us 11y agoI honestly assumed this was common practice and everyone did it this way. It also makes it easy for someone to clone the repo and run the app without having to download a bunch of npm stuff and figure out how to get the build tool working.
- cdnsteve 11y agoThe name "closure" is confusing since it's actually Google's Closure Compiler here and not the Clojure language https://developers.google.com/closure/compiler/ https://developers.google.com/closure/compiler/
- purplerabbit 11y agoThe language is spelled "Clojure" if I'm remembering correctly
- cdnsteve 11y agoyep correct, my mistake!
- carsie 11y agoI'm not sure you meant to say Closure language. Do you mean Clojure language? Or the Google Closure JavaScript library perhaps? Either way I can relate to the confusion!
- bpicolo 11y agoThough ClojureScript does use the closure compiler under the hood
- lobster_johnson 11y agoWe've been using Closure to minify our code for years. It's extremely slow (I think it takes a minute or so on our codebase), so we only do it for deploys. It produces smaller code than minifiers such as Uglify, even though we're not using its coding conventions (Closure is designed to optimize code written in a certain way that allows it to eliminate dead code paths).
- rafael-rinaldi 11y agoIf I was you I would give Rollup a try: http://rollupjs.org http://rollupjs.org I used to minify with Closure as well (through r.js) and it would take forever.
- lobster_johnson 11y agoWe're using Browserify — can you use Rollup with it? Closure's slowness isn't really a problem for us since we only use it for deploys, not while deveoping. Edit: I see, Rollup is a competitor to Browserify. Looks nice, if somewhat immature. Maybe we'll be able to use it.
- JDDunn9 11y agoRelated: Performance of ES6 features relative to the ES5 baseline operations per second. - http://kpdecker.github.io/six-speed/ http://kpdecker.github.io/six-speed/
- SeanAnderson 11y agoIt's worth mentioning that I spoke to Guy Bedford (author of JSPM) after Sam put out this article. He thinks he can get JSPM's times down pretty easily and he's putting some effort into it this week. I wouldn't let anyone interested in trying out JSPM be jaded by these numbers just yet. JSPM v0.17beta-6 hasn't reached fully stable yet and that's what's being used to generate these #s
- EvanPlaice 11y agoJSPM is slow to build but I don't see much utility in building during development when on-the-fly transpilation can be used instead. In terms of using JSPM to create builds for production, it seems significantly easier to setup than the equivalent using gulp, browserify, webpack.
- girvo 11y agoEasier than Webpack? I dunno about that. I have major gripes about webpack, but being difficult to set up is not one of them.
- rafael-rinaldi 11y agoThe problem with Webpack IMO is that it kinda feels like Grunt sometimes where you find yourself editing a giant nested config. But it is by far the most flexible tool for the job and setting it up without all the fancy stuff is pretty straightforward.
- Dirlewanger 11y agoWait what?? I thought ES2015 was just another name for ES6?? This is too much...
- eloisant 11y agoYes, what used to be called ES6 has been renamed ES2015. What's the problem?
- Dirlewanger 11y agoKnee-jerk reaction comment when I read "There are a lot of tools to compile es2015 to es5", I had to take a second to realize what was being said. Getting all the Lego pieces of JS webdev scattered on the floor straight in one's head is sometimes a pain when one's job only has one venturing into the front end every couple months, thus having to relearn all the acronyms and such.
- pluma 11y ago> when one's job only has one venturing into the front end every couple months, thus having to relearn all the acronyms and such. To be fair, in my experience that holds true for any technology you only touch once every couple months (especially when you then quickly move on to other things again).
- acjohnson55 11y agoES2015 is the title of the standard that defines ECMAScript Language, version 6. They're essentially the same thing.
- leppr 11y agoIt is
- ferbivore 11y agoNo, you probably fell asleep and missed the last 2008 versions. Fortunately, not much has changed.
- deleted 11y ago[deleted]
- wldcordeiro 11y agoMaybe this should link to the upstream? https://github.com/samccone/The-cost-of-transpiling-es2015-in-2016 https://github.com/samccone/The-cost-of-transpiling-es2015-i...
- dang 11y agoGood catch. Url changed from https://github.com/paulirish/The-cost-of-transpiling-es2015-in-2016 https://github.com/paulirish/The-cost-of-transpiling-es2015-....
- kenOfYugen 11y agoThe cost of transpiling es2015 isn't very visible here, because the "vanilla es6 TodoMVC" example used [1] doesn't rely heavily on ES6 only features, such as generator functions etc., that aren't just sugar on top of ES5. Such features are expected to decrease the performance of the generated code significantly and should be taken into account when a transpilation step is involved. [1] https://github.com/tastejs/todomvc/tree/master/examples/vanilla-es6 https://github.com/tastejs/todomvc/tree/master/examples/vani...
- draw_down 11y agoIt's interesting how these tools pretty much ignore the issue of source maps. If you want your code minified and tree-shaken no problem, but if you want to the source maps split into an external map and still have your debugger actually work, well, good luck.
- rafael-rinaldi 11y agoNot sure what you mean. Can you elaborate?
- jtwebman 11y agoI would love to see Elm added to the list.
- simonebrunozzi 11y agoI hate when people avoid clarity in titles and such. For mere mortals, ES2015 (or ES6) is the latest version of https://en.wikipedia.org/wiki/ECMAScript https://en.wikipedia.org/wiki/ECMAScript, a Javascript specification. (now I am expecting a lot of down flags, just because of my tone. Perhaps deserved. You judge).
- harel 11y agoWhat is holding up the major browsers from implementing es6 natively?
- TranquilMarmot 11y agoNothing really, but a lot of users may be stuck on older browsers. With government agencies or banks or the like, they tend to not upgrade until the last day that their current setup is supported. The cost of upgrading infrastructure is far too great to be justified by non-tech savvy higher ups who fail to understand security risks of not regularly upgrading systems. So, developers are stuck programming for some ancient godawful version of Internet Explorer that barely even supports ES5.
- harel 11y agoBut that's them. I want to develop ES6 in my browser natively and offer my app to people with modern browsers. I don't care about those stuck in the past. Why don't the browsers support it? Browsers support WebGL today where i can run advanced 3D graphics in my browsers. Government workers on Netscape 4.7 won't be able to run but still the browsers have that. Why not ES6? Surely webgl is more complex to implement...
- dchesterton 11y agoBrowsers are adding support now: https://kangax.github.io/compat-table/es6/ https://kangax.github.io/compat-table/es6/. Upcoming Chrome releases will have 90%+ compatibility if you only care about bleeding edge browsers.
- TranquilMarmot 11y agoYes, and as a corollary to my comment above I do have my own apps that I write that are entirely in ES2015 (aka ES6) and haven't found any features that I really want to use that aren't implemented by the big browsers (Chrome, Firefox, Safari, Edge). No transpiling needed; it seems like transpiling is only really needed if you want to support legacy versions of Internet Explorer. Only Internet Explorer lags behind, but I'm not opposed to putting a warning when somebody visits with Internet Explorer when its my own little app.
- vladimir-y 11y agoNowadays any a bit complex JS application needs to transcompile. If so then why not do that with TypeScript since it supports ES6 stuff, but in along with that provides unique features such as optional typing which might be very helpful for a large projects and large/distributed teams (due to static typing) and generally for building a maintainable code structure.
- cromwellian 11y agoI just wanted to the point out that the actual overhead of transpiling the module in Closure is zero. Here's a link where you can see the module boilerplate "compile away" http://goo.gl/fR3BjQ http://goo.gl/fR3BjQ (Choose Advanced Mode)