Hacker News Reader

Hacker News

Comment by huangbong | Hacker News Reader

Full thread

huangbong

Hopefully AWS Lambda adds support for this latest LTS... soon... we need async await without Babel transpilation.

View on HN

I’ve long banished Babel thanks to Typescript. Still has a transpile step though much faster and no more plugin hell.

Mind sharing your process?

I have been having issues setting up my project structure with TypeScript

Here is my example with React + TypeScript + Webpack

https://github.com/styfle/react-server-example-tsx

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.

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.

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

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

You don't need babel to get HMR.

Browser support is literally the tip of the iceberg.

What literal iceberg would that be?

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.

Here's the problem: Your 20s build times aren't because of babel.

Ok, I'll bite. What's my problem?

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.

Should be noted that Typescript is slower for bigger apps if you're using Webpack.

The whole Typescript & Webpack situation is very sad.

I agree. I hope the Typescript team builds their own loader optimized for perf

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.

They are not different. They can both help developers write in confidence and integrity. Babel can do more.

Babel can't do type checking, right?

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.

>"I've replaced X build step with Y build step." I don't understand the argument.

Typescript does both X and Y steps, so what exactly don't you understand?

Reply on news.ycombinator.com