4 ms·

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 whe

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 11y ago
Browsers will always lag behind specifications.
- gburnett 11y ago
  Yes, I'm not sure why transpiling will ever go away. Not sure either why it would be limited to specifications.
  - MrPatan 11y ago
    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 11y ago
      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.
    - kristiandupont 11y ago
      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.
    - deleted 11y ago
      [deleted]
    - izym 11y ago
      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?
  - jerf 11y ago
    "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.
- moonchrome 11y ago
  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
randallsquared 11y ago
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.
marcus_holmes 11y ago
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.
- cdnsteve 11y ago
  Agreed!
matwood 11y ago
Transpiling is here to stay. Old browsers and new language features are not going anywhere.
netghost 11y ago
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...
- brokentone 11y ago
  Not necessarily. You could build multiple targets and dynamically serve one over the other. Not as hard as it sounds.
  - frandroid 11y ago
    Isn't that what the parent said?
    - brokentone 11y ago
      Didn't when I posted it
  - Kiro 11y ago
    What tools do you use to make it happen?
    - brokentone 11y ago
      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/ 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.
officialchicken 11y ago
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.
- coldtea 11y ago
  >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.
  - true_religion 11y ago
    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.
    - coldtea 11y ago
      >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.
cromwellian 11y ago
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.
draw_down 11y ago
No, transpiling is forever :) All that changes is the target you're transpiling for.

kmkemp 11y ago

Browsers will always lag behind specifications.

gburnett 11y ago
Yes, I'm not sure why transpiling will ever go away. Not sure either why it would be limited to specifications.
- MrPatan 11y ago
  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 11y ago
    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.
  - kristiandupont 11y ago
    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.
  - deleted 11y ago
    [deleted]
  - izym 11y ago
    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?
- jerf 11y ago
  "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.
moonchrome 11y ago
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

randallsquared 11y ago

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.

marcus_holmes 11y ago

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.

cdnsteve 11y ago
Agreed!

matwood 11y ago

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

netghost 11y ago

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...

brokentone 11y ago
Not necessarily. You could build multiple targets and dynamically serve one over the other. Not as hard as it sounds.
- frandroid 11y ago
  Isn't that what the parent said?
  - brokentone 11y ago
    Didn't when I posted it
- Kiro 11y ago
  What tools do you use to make it happen?
  - brokentone 11y ago
    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/ 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.

officialchicken 11y ago

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.

coldtea 11y ago
>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.
- true_religion 11y ago
  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.
  - coldtea 11y ago
    >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.

cromwellian 11y ago

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.

draw_down 11y ago

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