Hacker News Reader

Comment by STRiDEX | Hacker News Reader

Most of my projects now use babel indirectly and its been removed from all backend projects at work, sometimes replaced with typescript or vanilla es6.

Ex: anyone using facebook's jest, vue-cli, etc will get v7 whenever those packages upgrade.

The typescript support seems interesting for people with large babel pipelines, but I'm not sure what the other use cases are since it doesn't do any of the typechecking tsc does. Would be interested in hearing what people plan to use it for.

https://blogs.msdn.microsoft.com/typescript/2018/08/27/types...

View on HN

I recently evaluated using Typescript's compiler or Babel + TS plugin, and decided to use Babel. The main reason was keeping access to the Babel plugin ecosystem without needing to do tsc -> babel -> output, which would be a drag in development.

It seems to be more common now to see library-specific Babel plugins that optimize performance or improve developer ux. These plugins are usually optional, but I use them to enhance css-in-js and i18n performance/development.

With good editor support and ts-lint, the dev experience is solid and as-expected. Setting up an explicit tsc command as a pre-commit hook or CI task should provide that extra bit of confidence.

For myself, not being a TS purist, it feels like a good option.

One benefit of running babel in parallel with tsc is that your execution doesn't depend on your code compiling. Sometimes, for example, if I'm hacking something together, it's faster to just disable type checking all together so I can do what needs to be done and save the type checking until later. Having babel + tsc allows you to do just that instead of having to do all the typing as you go.

tsc in --watch mode still outputs even if there are type errors for precisely this reason. You can ignore the cli warnings and still have everything run in the browser or node while developing.

Typescript doesn't let me play with stage0-3 features of EcmaScript.

Replying to myself... looks like typescript now integrates with babel better. May actually convert my latest project next week.

I also haven't been using babel for most node projects; V8 has already implemented most of the major features I'm interested in.

I don't mind setting up a build tool and configuring everything if the project will be actively maintained or if there's a real need for it, but for smaller projects I think it's better to keep things as simple as possible. It's a huge drag when you later revisit a project and a bunch of dependencies are outdated or broken.

One of the holdouts which kept me coming back to babel was JSX, but eventually I learned to love preact and its hyperscript-inspired template function. The code ends up being a bit more verbose but you drastically cut down on dependencies.

Babel is still superb if you're targeting a broad range of browsers. Although during development I usually disable babel-loader from Webpack for the improved performance and debugging experience.

It allows you to add TypeScript to your Babel project like you'd add a linter, i.e. you can optionally run tsc to catch potential problems, but in your build pipeline just skip that and build it using the full Babel ecosystem.

Reply on news.ycombinator.com