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.
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.
"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.
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.
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.
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.
In the version they released yesterday they have an improved watch mode, and they started they're working on providing an API to make loaders, among others, benefit from those optimisations.
"I've replaced X build step with Y build step." I don't understand the argument.
What I would love is for TypeScript to do one thing and that is it: static type checking. The fact that it does more than that to me is feature creep. I really wish something like Flow had the community support that TypeScript has because of its single responsibility.
TypeScript is never mean to be a replacement of Babel.
The spirit of TypeScript is code integrity. Imagine that you are working on a project which change often. In this case, refactoring and maintaining breaking changes are headache. How would you identify potential issues before pushing to CI and being punished by errors with no clue?
Babel and TypeScript are different. Babel is a transpiler which enable us to write modern syntax which are not widely supported, while TypeScript is a transpiler which help us to write in confidence and integrity.
It absolutely can! That said, the way it currently works is that babel-preset-flow and babel-preset-typescript both remove type annotations for the final build, essentially enabling flow or typescript to work without having to also be build engines.
You're just mimicking babel with `babel-preset-typescript` + `babel-transform-object-rest-spread`, but without support for:
I don't get why people think that they're doing something special by not using babel. Pre-babel life sucked.