Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Esbuild – An extremely fast JavaScript bundler

esbuild.github.io

Post reply on HN
Print view View original

91–100 of 288 posts

Re: Esbuild – An extremely fast JavaScript bundler

#91

Post by eloff »

CodeIsTheEnd wrote: post #41

Work on esbuild started at the start of 2020. It is primarily authored and maintained by Evan Wallace, who, in addition to making this tremendous contribution to the JavaScript ecosystem, is the CTO and co-founder of Figma . Incredible output.

I came here too say this. The man authored in the neighborhood of 100k LOC in a year, just on this. There's a living 10x dev, it's not a myth. What is ridiculous is to think someone can 10x a normal developer, it's more like the difference between the top few percent and the bottom 10-20%. Evan Wallace is a beast, no doubt.

Re: Esbuild – An extremely fast JavaScript bundler

#92

Post by kryptiskt »

TekMol wrote: post #4

Isn't the browser also an extremely fast Javscript bundler? How many scripts does a site need to make it feel faster when bundled? When I visit websites that are rendered serverside, they usually feel instant to me. Even when they load a dozen scripts or so.

I like Snowpack (https://www.snowpack.dev) because it doesn't actually do any bundling, it just makes sure that the files are in the right place to be loaded (it does compile Typescript files). Because the only thing I actually care about during development is that all the inter-package dependencies are resolved. I don't actually need a fat heap of JS that needs to be rebuilt every time I change something.

Re: Esbuild – An extremely fast JavaScript bundler

#93

Post by simlevesque »

EugeneOZ wrote: post #75
kitd wrote: post #60

Earlier quoted context omitted.

Practically, it isn't an issue if you use VSCode which has the Typescript language server built in to catch type errors for you. If you want, your build script can include `tsc -noEmit` to type check before the build.

Only if a project is pretty small. Change in one place, especially if it's a reusable code, might ruin code in multiple different places and IDE will not recompile the whole project on every change, it will only watch your currently opened files and, maybe, some files in opened folders.

Did you reply to the wrong comment ? The --noEmit does not have the issue you talk about.

Re: Esbuild – An extremely fast JavaScript bundler

#94

Post by Ginden »

leeman2016 wrote: post #40
Kiro wrote: post #12

How is it possible to be so fast?

It also doesn't include type checking for typescript. It just transpiles sources to javascript

> It also doesn't include type checking for typescript.

If you use `@aws/sdk`, you are going to have bad time with Typescript. Resolving its types can easily take >50% of compilation time for small projects.

Re: Esbuild – An extremely fast JavaScript bundler

#95

Post by nsonha »

tiew9Vii wrote: post #45
phillu wrote: post #26

I'm using this to compile typescript lambda functions for AWS with great success. Combined with cdk and its NodeJsFunction you can even deploy/compile without local docker.

I looked at using ESbuild and I use Typescript. It was all looking good until reading the docs and it said ESbuild doesn't typecheck Typescript and to rely on your IDE to flag errors. Is that correct and how is that working for you practically if it is? The whole point for Typescript for me is to have a compiler typecheck my code and block errors at compile time. ESbuild not typechecking seemed like a major contradic…

By "supporting typescript" it parses typescript code and won't fail. That is what a bundler promises. Bundler doesn't have to do the typechecking. It is actually conventional to set it up that way for any bundler. In my job we have webpack bundling typescript with babel in the "build" step. We could've use ts-loader but we want hot reload to be fast. Then in the "check" step we have ts, linter, unit tests. Those run on CI.

Re: Esbuild – An extremely fast JavaScript bundler

#96

Post by johnnypangs »

qeternity wrote: post #79

What’s the catch? Do they really have a secret sauce or are there limitations in esbuild to achieve these speed ups?

The catch is that they focus on modern builds (I.e. not IE) it also doesn’t do type definitions, so if you want type defs you’ll need to compile with typescript anyway.

Re: Esbuild – An extremely fast JavaScript bundler

#97

Post by hit8run »

albertgoeswoof wrote: post #54
hit8run wrote: post #21

What do you think of the importmap approach propagated by dhh on rails 7?

the only problem with this is that it's an option. As a rails dev, I want one, strong opinion on what the default/best approach is. I don't want to configure anything

No importmaps are the new default in Rails 7. The menu is still omakase. In case you have different requirements you can use options.

Re: Esbuild – An extremely fast JavaScript bundler

#98

Post by sanderdlm »

dom111 wrote: post #65

We recently switched on a few of our project from Webpack and the difference is incredible. Running a watch using this is practically instantaneous compared to our previous setup. I've been recommending it to all my colleagues and we're replacing Webpack slowly but surely. The main draw for me is the simplicity of the config too. Webpack config (even using things like Symfony's Encore) is pretty convoluted and confus…

Do you have a public example of a PHP/Symfony project that you've ported from Webpack to esbuild?

Re: Esbuild – An extremely fast JavaScript bundler

#99

Post by gyosko »

petethepig wrote: post #47

Great job on the landing page — that simple animation tells an incredibly simple and compelling story all in 800x200 pixels. I wish more products had landing pages that looked like that.

It is very easy to be misleading though: https://github.com/evanw/esbuild/issues/669

Re: Esbuild – An extremely fast JavaScript bundler

#100

Post by enjikaka »

baybal2 wrote: post #78
dom111 wrote: post #65

We recently switched on a few of our project from Webpack and the difference is incredible. Running a watch using this is practically instantaneous compared to our previous setup. I've been recommending it to all my colleagues and we're replacing Webpack slowly but surely. The main draw for me is the simplicity of the config too. Webpack config (even using things like Symfony's Encore) is pretty convoluted and confus…

Webpack is a bane of webdev existence. Having junior team encounter a webpack breakage === them spending as much time on tooling, as coding itself

I cannot count the days I've spend on webpack config breakage during the last years at work. It's never really been good at all either. The gulp setup we had before worked faster, better and didn't break once a month. Webpack really only is a pet project of the idiocratic React-community. Facebook not only screws your personal data over, also your dev workflow!
Post reply on HN