5 ms·

It's faster because it's doing much less. You're just mimicking babel with `babel-preset-typescript` + `babel-transform-object-rest-spread`, but without suppor

It's faster because it's doing much less. You're just mimicking babel with `babel-preset-typescript` + `babel-transform-object-rest-spread`, but without support for: - babel-preset-env - babel-minification - or any of the other dozen or so plugins that make development easier - any bug fixes or polyfills I don't get why people think that they're doing something special by not using babel. Pre-babel life sucked.

roblabla 9y ago
For a side-project of mine, I decided to not use babel (or typescript or any transpilation at all), and I've got to say, post-babel life is awesome. Sure, you're limited in browser support. But it makes life so much easier, iteration time so much quicker, and we've got most of the es2015 goodies in browsers nowadays. Being able to do the same on the backend side would be nice.
- qudat 9y ago
  "But it makes life so much easier." Is this because you don't have to install a plugin for every thing you want? I found both babel and typescript to have a learning curve and a configuration step that required dev cycles being spent on getting it to work properly. It really wasn't much of a difference in terms of getting things up and running. Typescript has plenty of weird nuances and configuration settings that are required to get things working properly, just like babel.
- joshuahutt 9y ago
  If you're not using HMR and you're worried about iteration time, you're missing the biggest win. The time it takes to transpile a function is negligible. http://matthewlehner.net/react-hot-module-replacement-with-webpack/ http://matthewlehner.net/react-hot-module-replacement-with-w...
  - roblabla 9y ago
    You don't need babel to get HMR.
  - deleted 9y ago
    [deleted]
- krainboltgreene 9y ago
  Browser support is literally the tip of the iceberg.
  - amake 9y ago
    What literal iceberg would that be?
prophesi 9y ago
It might be doing much less, but for most people it does plenty. You've still got your classes, arrow functions, modules, and whatnot. If your build iterations are averaging ~20 seconds on a device because of babel, I fail to see the problem with switching it out with Typescript.
- krainboltgreene 9y ago
  Here's the problem: Your 20s build times aren't because of babel.
  - prophesi 9y ago
    Ok, I'll bite. What's my problem?
    - krainboltgreene 9y ago
      I can't possibly know the actual problem. It could be a multitude of issues, hell it could even be one unofficial babel plugin, but it is absolutely not babel taking 20s. Babel is essentially `cp` but with a slight twist: AST -> AST conversion. That doesn't take a huge amount of time.
      - prophesi 9y ago
        This is purely anecdotal, and we could very well have done something wrong with our configuration, but I had my build iteration times cut in more than half after switching our project to CommonJS + ES6 Typescript from es2015-preset Babel. I think we were using Gulp without any hot module replacement, so there are other ways we could have sped up our build time, but Typescript was good enough.

roblabla 9y ago

For a side-project of mine, I decided to not use babel (or typescript or any transpilation at all), and I've got to say, post-babel life is awesome. Sure, you're limited in browser support. But it makes life so much easier, iteration time so much quicker, and we've got most of the es2015 goodies in browsers nowadays. Being able to do the same on the backend side would be nice.

qudat 9y ago
"But it makes life so much easier." Is this because you don't have to install a plugin for every thing you want? I found both babel and typescript to have a learning curve and a configuration step that required dev cycles being spent on getting it to work properly. It really wasn't much of a difference in terms of getting things up and running. Typescript has plenty of weird nuances and configuration settings that are required to get things working properly, just like babel.
joshuahutt 9y ago
If you're not using HMR and you're worried about iteration time, you're missing the biggest win. The time it takes to transpile a function is negligible. http://matthewlehner.net/react-hot-module-replacement-with-webpack/ http://matthewlehner.net/react-hot-module-replacement-with-w...
- roblabla 9y ago
  You don't need babel to get HMR.
- deleted 9y ago
  [deleted]
krainboltgreene 9y ago
Browser support is literally the tip of the iceberg.
- amake 9y ago
  What literal iceberg would that be?

prophesi 9y ago

It might be doing much less, but for most people it does plenty. You've still got your classes, arrow functions, modules, and whatnot. If your build iterations are averaging ~20 seconds on a device because of babel, I fail to see the problem with switching it out with Typescript.

krainboltgreene 9y ago
Here's the problem: Your 20s build times aren't because of babel.
- prophesi 9y ago
  Ok, I'll bite. What's my problem?
  - krainboltgreene 9y ago
    I can't possibly know the actual problem. It could be a multitude of issues, hell it could even be one unofficial babel plugin, but it is absolutely not babel taking 20s. Babel is essentially `cp` but with a slight twist: AST -> AST conversion. That doesn't take a huge amount of time.
    - prophesi 9y ago
      This is purely anecdotal, and we could very well have done something wrong with our configuration, but I had my build iteration times cut in more than half after switching our project to CommonJS + ES6 Typescript from es2015-preset Babel. I think we were using Gulp without any hot module replacement, so there are other ways we could have sped up our build time, but Typescript was good enough.