Hacker News Reader

Comment by ricardobeat | Hacker News Reader

ESBuild doesn't transpile your code down to ES5.

If you're using any ES6 features - default params, template literals, arrow functions, let/const, spread, etc, your cut-off for browser support will be ~2017 (= no support for IE 11).

swc (https://swc.rs) does transpilation and it's as fast as esbuild. Setup is slightly more complex. I'm hoping esbuild will add ES5 transforms at some point, would much rather have a Go tool underneath.

View on HN

I love swc, it's close to a drop-in replacement for babel, but with a native executable and doesn't download half of the internet in JavaScript dependencies. You can use your existing build system, but get substantial speedups over using babel.

[1] https://parceljs.org/

Plain esbuild is perfect for adding typescript support to node.js projects. We literally just run ’esbuild && node dist/run.js’

How is this different from `tsc && node dist/run.js`?

1. It’s much faster. 2. It won’t catch type errors.

Regarding #2, I assume that things are set up so that type errors are caught in some other way, such as in CI or in a precommit hook.

What I do is run esbuild and tsc (with no emit) in parallel in watch mode. That way, I get fast rebuilds and iterations, but still eventually see the errors spit out.

My code editor catches 90% of the errors, but it’s definitely nice to have tsc catch the rest earlier than the CI process.

> My code editor catches 90% of the errors

With or without strict mode enabled?

It's a lot faster (runs in 0.1 seconds) so it doesn't affect our iteration speed at all.

What about web projects, though? Isn’t that what the discussion is about (script tags and all)? Node projects aren’t too bad because you don’t need anything beyond local fs module resolution.

IE (all versions) seems to have 1-2% market share, so I'm not sure it's worth jumping through hoops for.

IE usage could be 50% in your industry, or your company may guarantee IE support for one reason or another. Global stats aren't always representative of your business.

Sure, but if legacy support is your business, you know it. I don't think there's any reason to default to supporting ancient browsers any more.

Sadly it's a lot more than old IE versions, there are a lot of mobile devices with surprisingly old/buggy browsers around. Of course this is highly dependent on the target audience but at my last job we did some runtime feature detection (basic stuff like arrow functions, let/const...) and shipped a modern build or a legacy build. And something like 10% of users got the legacy build, most of them on mobile browsers.

Reply on news.ycombinator.com