Live data from Hacker News

Some notes on using esbuild

jvns.ca

51–60 of 205 posts

Re: Some notes on using esbuild

#51
> “webpack” which I will not try to explain much because I don’t understand it, I think it’s a system with a million plugins that does a million things

Is webpack really considered such a difficult beast? I was an early adopter of TypeScript so I think I started with grunt, then gulp, then finally webpack 3, 4 and now 5.

I mean it's not my main job or anything, and I don't really enjoy configuring things but spending a handful of days reading the docs once a year or whatever is not really a problem. I have a couple of files, one for local one for production. About 50-70 lines each and considering it is compiling typescript, linting, minifying, scss, testing and so on... I find I get a lot of bang for my buck. It's not like the previous tooling was really any easier to deal with.

The production build takes about 50 seconds, and the local build takes about 3 seconds. It's honestly the least of my problems.

Re: Some notes on using esbuild

#52
post #7

Julia is one of my favorite examples of learning in public as a developer. Her technical chops are unquestioned so when she says things like "I have no idea what import does" it really drives home how much the JS community has to do to bring along the rest of the developer population who just wants to make web stuff occasionally without going to JS Build Tool University. I love this and maybe it would be great for so…

I don't understand why people are holding JS to a higher standard than other languages, is it just because it used to be easier? Knowing nothing about Java, I wouldn't expect to open a Java file and know what every line means. There's a million reasons to find modern web dev complicated but not taking the time to google "js import" is not one of them. Also I wouldn't expect to "just know" how to take a Java program a…

Import in JavaScript is significantly more varied and complex than import in any other language I know about.

There are multiple historical module systems, various official and unofficial syntaxes, and also the require keyword.

It is an absolute mess. I don't know anyone who understands all of the various flavors.

Re: Some notes on using esbuild

#53

I've recently being helping a friend who is starting with Node.js, and I strongly recommended him (and anyone else getting started now) to use all `import` instead of `require`. I would say it takes a bit more of work because the tutorials are normally written on commonJS (require), but otherwise it's just a different kind of work. Both of them have their peculiarities and issues, and CommonJS might also bite you big…

> CommonJS might also bite you big time

In which ways? I’ve always found CommonJS to be extremely unsurprising. What will bite you is the tooling built to interoperate with ESM.

Re: Some notes on using esbuild

#54
post #19
post #16

If you're going to have a build step at all, instead of hand rolling your build commands and configs, just use Vite[1] already. It uses esbuild for development and rollup for production (since esbuild is not featureful enough for a lot of production use cases), you get instantaneous startup, hot module replacement, static asset imports, etc. for free. It's from Evan You, the creator of Vue, but it also supports React…

Addressed in TFA: > But I stopped using those tools and went back to my old system because I don’t understand what those vue-cli-service and vite are doing and I didn’t feel confident that I could fix them when they break. So I’d rather stick to a setup that I actually understand.

She's doing things the right way here - applying the beginner's mindset, trying to understand things rather than cargo-culting by copy-pasting magical incantations from github. There's just so much incidental complexity in JS tooling, and her instinct to steer clear of that insanity by using Unix tools like esbuild is spot on.

Re: Some notes on using esbuild

#55
I found EsBuild via Snowpack was quite nice until it wasn't. I hit issues around package resolution and usage of libraries like Mobx, which was deeply displeasing. I have moved back to Webpack because 50ms vs 400ms refresh-after-save latency doesn't matter to me when once a month I have to spend a day fixing those things I have long since taken for granted

Re: Some notes on using esbuild

#57
post #52

Earlier quoted context omitted.

I don't understand why people are holding JS to a higher standard than other languages, is it just because it used to be easier? Knowing nothing about Java, I wouldn't expect to open a Java file and know what every line means. There's a million reasons to find modern web dev complicated but not taking the time to google "js import" is not one of them. Also I wouldn't expect to "just know" how to take a Java program a…

Import in JavaScript is significantly more varied and complex than import in any other language I know about. There are multiple historical module systems, various official and unofficial syntaxes, and also the require keyword. It is an absolute mess. I don't know anyone who understands all of the various flavors.

On top of this, a lot of the tooling is just shit. I don't just mean it makes design decisions I disagree with (which is also true of e.g. Maven, or Bundler) or that they're lacking in niceties (e.g. every C development workflow), I mean it's just absolutely poorly implemented CADT-except-they're-actually-25-and-overcapitalized trash.

Yarn blew NPM away on speed with more features and nicer developer workflow. Webpack is on major version 5 and still everyone just uses CRA rather than try to configure it by hand, but then nobody really knows how to debug CRA if something breaks. The entire babel stack is ridiculous. The dominant tools have just been so awful, for so long.

Re: Some notes on using esbuild

#58
Esbuild is great. That said, I find as its one major weakness the inability to alias/dedupe libraries at least in a pnpm monorepo. Even if it's the same version and I assume the same link, it will bundle it twice and you can get some pretty obscure errors when you run your app.

I did try various setups but none worked. With Vite at least I was able to alias libraries to same import thus avoiding importing them twice/x times.

But I'd kinda prefer using esbuild as Vite can get funky too, especially I've noticed if you build a local library with multiple chunks (eg just using tsc) the HMR will get out of hand. As I just tried, it basically seemed to go on indefinitely. Maybe there's a config for that but it's not nice, I can tell you that.

Re: Some notes on using esbuild

#59
post #49

Earlier quoted context omitted.

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.

Re: Some notes on using esbuild

#60
post #7

Julia is one of my favorite examples of learning in public as a developer. Her technical chops are unquestioned so when she says things like "I have no idea what import does" it really drives home how much the JS community has to do to bring along the rest of the developer population who just wants to make web stuff occasionally without going to JS Build Tool University. I love this and maybe it would be great for so…

I don't understand why people are holding JS to a higher standard than other languages, is it just because it used to be easier? Knowing nothing about Java, I wouldn't expect to open a Java file and know what every line means. There's a million reasons to find modern web dev complicated but not taking the time to google "js import" is not one of them. Also I wouldn't expect to "just know" how to take a Java program a…

It's holding JavaScript to its own higher standard: is dead simple, and trivial to understand and get working.

NPM, import, etc. seem mindbogglingly complex in comparison, with an enormous number of ways to do each thing, most of which require at least one build step just doesn't, and enormous numbers of third party dependencies, and if you go away for a few months and come back, there are good odds things will be different and broken.

Like Julia, I don't understand JS build systems and packaging etc., which no doubt contributes to the above experience, but I'm comparing to , whose simplicity is almost unbeatable.

Post reply on HN