
The cost of transpiling ES2015 in 2016 - AlexMuir
https://github.com/samccone/The-cost-of-transpiling-es2015-in-2016
======
ThePhysicist
Personally 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).

~~~
mbrock
I agree, and I think ES5 even has a benefit as a language: it's extremely
simple. The trajectory of ES2015 seems to be, basically: add as much cool
stuff as possible. Thus increasing the syntactic surface area, and the amount
of stuff to learn.

With a slightly more clever and more concise definition of `createElement`, I
also have no need for JSX.

    
    
        tag("div.widget.fancy", {}, [
          tag("h1#title", {}, "Hello, world!")
        ])
    

I'm fine with that. My editor understands the indentation.

And... such an enormous benefit... there is no compilation step.

Right now at work, our code base takes 20 seconds to compile with Babel.
Enough said.

The feeling, after being used to all this transpilation business, of writing
code that's just already ready to serve, is very nice. I can even work on it
with nothing but a text editor and a web browser.

Unfortunately everyone thinks I am crazy for preferring this.

~~~
bhauer
That looks a lot like the element builder function that Fastmail put together
back in 2012.

[https://blog.fastmail.com/2012/02/20/building-the-new-
ajax-m...](https://blog.fastmail.com/2012/02/20/building-the-new-ajax-mail-ui-
part-2-better-than-templates-building-highly-dynamic-web-pages/)

I too am fond of that approach.

~~~
mbrock
Yeah, same idea.

The dream that designers, being comfortable with HTML, would be able to mess
around with JSX is, as far as I can tell, unrealistic anyway, because it's
always full of React-specific weird stuff that the designer doesn't understand
and doesn't want to mess with.

~~~
WickyNilliams
You should separate your Presentational and Container components [0].
Presentational components can be pure and stateless, containing no/minimal
_React-specific weird stuff_ \- that should go into the Containers.

[0] [https://medium.com/@dan_abramov/smart-and-dumb-
components-7c...](https://medium.com/@dan_abramov/smart-and-dumb-
components-7ca2f9a7c7d0)

------
kenOfYugen
The 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/vani...](https://github.com/tastejs/todomvc/tree/master/examples/vanilla-
es6)

------
bretthopper
Not 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
Yah... I'm confused as well. :/

But I did work with Sam on this project and I think it's quite worthwhile!

~~~
niftylettuce
what happened to tambourines lol

------
lobster_johnson
We'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
If 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
We'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.

------
cdnsteve
Transpiling 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
Browsers will always lag behind specifications.

~~~
gburnett
Yes, I'm not sure why transpiling will ever go away. Not sure either why it
would be limited to specifications.

~~~
MrPatan
Transpiling 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
Because:

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.

------
SeanAnderson
It'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
JSPM 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
Easier 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
The 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.

------
JDDunn9
Related: Performance of ES6 features relative to the ES5 baseline operations
per second. - [http://kpdecker.github.io/six-
speed/](http://kpdecker.github.io/six-speed/)

------
dustingetz
I think one could transpile to javascript compatible with the Google Closure
compiler which does dead code elimination. Someone's probably already on it.

~~~
emidln
Google 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/

~~~
dustingetz
Have 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.

~~~
lobster_johnson
Can you explain by what you mean by "requires"? We're using Closure to minify
our code, and it works fine. We know that it's not able to do all the
optimizations it can (it was made to follow Google's specific conventions,
after all), but it still produces smaller code than minifiers such as Uglify,
so it is useful.

~~~
bpicolo
The Closure compiler is definitely at it's best when you have all
optimizations and are JSDoccing like they intend. While you get some out of
the box, it's not the full power of it.

------
wrong_variable
wait.

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
This 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
There 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
I 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.

------
Dirlewanger
Wait what?? I thought ES2015 was just another name for ES6?? This is too
much...

~~~
eloisant
Yes, what used to be called ES6 has been renamed ES2015.

What's the problem?

~~~
Dirlewanger
Knee-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
> 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).

------
vladimir-y
Nowadays 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.

------
minionslave
Javascript 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
I assume your comment is sarcastic, because Javascript is obviously the only
language which you can just write and immediately run.

~~~
coldtea
...if you don't work in any company with a convoluted build process that
includes transpiling (which is nearly all of them).

------
jtwebman
I would love to see Elm added to the list.

~~~
omaranto
Just try using the Elm compiler to translate an ES2015 program to ES5 and
you'll quickly figure out why it's not on the list.

------
cromwellian
I 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)

------
draw_down
It'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
Not sure what you mean. Can you elaborate?

------
harel
What is holding up the major browsers from implementing es6 natively?

~~~
TranquilMarmot
Nothing 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
But 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
Browsers 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
Yes, 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.

~~~
harel
Actually, I firmly believe that this applies to big apps as well. From my
experience, if there is an app a user needs and it requires the user to
upgrade their browser? They will upgrade their browser. Most don't upgrade
because nobody asks them to. If a need arises in a corp environment to use an
app with the simple requirement of a modern browser - they will upgrade it. If
the apps always "allow" sub par browser support and bend over backwards for it
- there will never be a reason for people to upgrade.

------
wldcordeiro
Maybe this should link to the upstream? [https://github.com/samccone/The-cost-
of-transpiling-es2015-i...](https://github.com/samccone/The-cost-of-
transpiling-es2015-in-2016)

~~~
dang
Good catch. Url changed from [https://github.com/paulirish/The-cost-of-
transpiling-es2015-...](https://github.com/paulirish/The-cost-of-transpiling-
es2015-in-2016).

------
cdnsteve
The 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
The language is spelled "Clojure" if I'm remembering correctly

~~~
cdnsteve
yep correct, my mistake!

------
planetmcd
samccone works hard at this stuff, link to the original repo.

~~~
dang
Done, 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.

------
simonebrunozzi
I 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).

