Hacker News Reader

Comment by cdnsteve | Hacker News Reader

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.

View on HN

Transpilers are here to stay. The plan of a new version every year for ES20xx means that browser javascript support and what devs actually write has to be decoupled, and once everyone is on that workflow, it's hard to see any reason why we'd go back unless javascript stagnates.

Unless we're working in React (or similar) that depends on compilation to JS.

Plus uglification/minification is a thing that reduces production js file sizes, therefore bandwidth. So we'll probably keep doing that.

I think we should probably stop calling it transpiling and just accept that javascript is a compiled language now.

Agreed!

Unfortunately as long as any of your target browsers don't support all of the transpiled features, you need to transpile for everyone.

Unless you start serving up different builds based on user agent...

Not necessarily. You could build multiple targets and dynamically serve one over the other. Not as hard as it sounds.

Isn't that what the parent said?

Didn't when I posted it

What tools do you use to make it happen?

Still working it through. The steps as I see it:

Figure out which browsers to support on which features: https://kangax.github.io/compat-table/es6/

Have an alternate .babelrc with a transpile blacklist that points to a separate dest

Build a regex to match those browsers in your CDN (I use Fastly). Vary on the value you create.

Point said browsers asking for the normal JS payload to the alternate dest.

Transpiling is here to stay... there is no acceptable ROI for 'move fast and break things'. It's for organizational and economic reasons, not technical ones. Even if the browsers catch up, it can still take a year or more for roll-out updated software in many companies. It doesn't seem like you're aware of the fact that in an enterprise, 99% of users aren't allowed to install and update software on their own.

>It doesn't seem like you're aware of the fact that in an enterprise, 99% of users aren't allowed to install and update software on their own.

Tons of startups and services target the consumer and could not care less about enterprise users.

Perhaps, but I run an entertainment site targeted towards consumers. You'd think that we'd never need to support IE8 or even IE9, right?

Well no, about 10% of our traffic is from people sitting on those two browsers at work. Some of those people are even still running Windows XP, forcing us to use SAN instead of SNI certs.

There's a few traffic spikes in the day. Pre-8am, when people check the site before work. 12pm when people are fiddling around at work, then post 5pm when people are home from work, then 10pm before people sleep.

We even have a web app, but nope, people prefer to use the desktop version even at work.

>Well no, about 10% of our traffic is from people sitting on those two browsers at work. Some of those people are even still running Windows XP, forcing us to use SAN instead of SNI certs.

This depends on many things. If your 90% brings enough profit, then this 10% perhaps could be dismissed, as it might not be worth the developers costs and time to keep support them (that needs an "opportunity cost" calculation).

There's also the fact that that 10% is only gonna go down, never up again.

Browsers will always lag behind specifications.

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

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!

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.

Why is that not cool? It's not like they are forcing anyone to anything (like you could argue was the case in the 90's).

I don't use it but I appreciate that the JS is being explored and expanded by projects like it and many others.

Because JScript was an MS-only implementation, while TS always has and always will compile to JS. There's quite a difference.

Also, could you elaborate "web breaking" w.r.t. compile-to-JS languages?

"Transpiling" may never go away, but it will cease to be the first thing everyone reaches for when web assembly comes out and reaches the point you can use it. It's the first thing right now since it's pretty much the only thing. Web assembly will pick up a lot of the use cases. Something like Coffeescript will probably still target JS by design, something like Emscripten will tend to target web assembly, and where the in between will end up is anybody's guess.

Not necessarily - specs could come out as standardization of existing behaviour.

More importantly the things ES6 solves are kind of rudimentary (modules, classes, => syntax, actual collections), stuff after that is nice to have but provide diminishing value

Transpiling is here to stay. Old browsers and new language features are not going anywhere.

Even if the browsers fully support ES6, you'll still want to use optimizing compilers to statically dead-strip unused code and remove the need for separate module loading.

No, transpiling is forever :) All that changes is the target you're transpiling for.

Reply on news.ycombinator.com