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

Some notes on using esbuild

jvns.ca

Post reply on HN
Print view View original

71–80 of 205 posts

Re: Some notes on using esbuild

#71

Post by BiteCode_dev »

3np wrote: post #48
BiteCode_dev wrote: post #31

Earlier quoted context omitted.

The purpose of vite is not to be fast for build, but to be a live reload instant dev platform. So you almost never run build. You code with vite's server, and it let you see the result instantly in the browser. You can use modules, modern js, and transpiled languages transparently. Then when you put in prod, you build once. 30s once a day doesn't matter.

It does matter in a CI environment. Using a different build procedure there is not optimal.

Optimal != Best for most people.

Re: Some notes on using esbuild

#72

Post by tgv »

loevborg wrote: post #54
cuu508 wrote: post #19

Earlier quoted context omitted.

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.

Seems right to me, too, but perhaps it's not the beginner's mindset. My colleague, who is an actual beginner, started the frontend part of a project, read up to the vue-cli scaffolding incantation, copy-pasted it into his terminal and checked in the result. The consequence was that I have to fix the unavoidable breaks and other npm and webpack issues, because he has no clue.

Apart from that, debugging the builds is a bad experience.

Re: Some notes on using esbuild

#73

Post by KptMarchewa »

smt88 wrote: post #52
betageek wrote: post #45

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.

Python?

Re: Some notes on using esbuild

#74

Post by maccolgan »

smt88 wrote: post #52
betageek wrote: post #45

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.

You're saying Java & Maven/Gradle are simpler than even Nodejs or ESM workflows?

Re: Some notes on using esbuild

#75

Post by madeofpalk »

mkl wrote: post #60
betageek wrote: post #45

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…

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 di…

still works. Feel free to keep using it.

Re: Some notes on using esbuild

#77

Post by kqr »

seumars wrote: post #76

As long as your code doesn't need transpiling, there's also the possibility of importing modules using the type attribute in script tags: – which is very well supported: https://caniuse.com/es6-module

The drawback of this, IIRC, is that if you want any sort of third-party library using this approach, you'll trigger a million HTTP requests, one for each part of the transitive closure of dependencies. Maybe things have improved.

Re: Some notes on using esbuild

#78

Post by hsn915 »

oefrha wrote: post #23
hsn915 wrote: post #20

Earlier quoted context omitted.

I don't understand the point of vite. I tried using it and the "build" took over 30 seconds. esbuilds takes less than 1 second for the same project. > esbuild is not featureful enough for a lot of production use cases What makes you say that? I keep hearing people say this, but I haven't run into any problem that make esbuild not ready for production.

> I tried using it and the "build" took over 30 seconds. It hardly matters because it's very rare that you need to run build during development. Use dev. > I keep hearing people say this, but I haven't run into any problem that make esbuild not ready for production. https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuil...

> It hardly matters

For the hundredth time: it does matter.

Stop wasting people's time with slow tools and telling them it doesn't matter. That's not a way to treat your users.

Your fancy hot module reloading is not what I want. What I want is to reload the page and see my changes.

I've never seen a "hot reload" that works properly. The one some of co workers are using right now works like this:

- You edit a file

- You wait 5 seconds for the "instant" rebuild

- The browser reloads the page 5 times

- After a total of over 10 seconds, you can finally see the effects of your changes.

Maybe vite's HMR is better, I will never know because I don't care.

The link you sent has the following to answer why not esbuild:

> some of the important features needed for bundling applications are still work in progress - in particular code-splitting and CSS handling.

But this is not true. It handles css and does code splitting. Now, you have to be very explicit about code splitting: you have to define other entry points that share the same libraries as the main program so that it forces those shared libraries into separate chunks. To have more chunks you have more entry points where each entry point uses just one or two libraries. Yes, it's not perfect, but it's not a blocker for getting to production.

Where as the 30 seconds build is a total blocker for development iteration.

Re: Some notes on using esbuild

#79

Post by hsn915 »

loevborg wrote: post #54
cuu508 wrote: post #19

Earlier quoted context omitted.

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.

> the beginner's mindset

It's actually the experienced mindset.

With experience you learn to distrust complicated setups.

A beginner would just trust the tutorials and follow them to the letter without bothering to try to understand everything.

Re: Some notes on using esbuild

#80

Post by hsn915 »

Bellend wrote: post #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…

The problem with webpack, beside being very slow, is it's based on config files.

Config files are brittle and very hard to understand.

Spending several days sifting through the webpack docs and maintaining 70 lines of config files sounds like a nightmare.

Now, for esbuild, I have more lines than that for the build script, but the thing is, it's just code. The configuration part is about 10 lines. The other stuff is just programming logic.

Navigating documentation to understand what parameters something accepts is ok.

Spending time editing code is ok. It's what I do most of the time anyway.

It's tractable.

A web of configuration files is not tractable.

Post reply on HN