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

91–100 of 205 posts

Re: Some notes on using esbuild

#91

Post by dmitriid »

maccolgan wrote: post #74
smt88 wrote: post #52

Earlier quoted context omitted.

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?

Maven and Gradle have been around for years, and they are pretty much understood.

Moreover, you can skip them entirely and roll your own in a couple of hours [1]

Meanwhile in JS world? Build tools now change faster than frameworks, and not a single person is concerned with upgrade paths, or working in tandem with other tools.

And yes, import story is a mess.

[1] https://tonsky.me/blog/python-build/

Re: Some notes on using esbuild

#92

Post by eitland »

badthingfactory wrote: post #84
swyx wrote: 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…

My primary frustration with frontend development is that I have gone to JS Build Tool University... Roughly 10 times now. I'm not sure I've ever set up two separate frontends the same way. Even when I avoid the shiny new tools and stick with crusty slow webpack, there's a new version that behaves entirely different than the previous version. I'm enjoying the speed and simplicity of ESBuild.

I've been poking fun at JS for a long time (friendly though, I'm consistently amazed at what those people manage to do with little more than straws and duct tape ;-)

Just be glad Gradle hasn't entered the JS scene yet:

With JS there is at least some standards now: both Angular and React at least has some systems for getting things running in a standard way and keeping it somewhat aligned.

With Gradle however I haven't seen two similar setups so far. Edit: I might have seen two similar setups.

Re: Some notes on using esbuild

#93

Post by Bellend »

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

> Is webpack really considered such a difficult beast For whatever it's worth, I'm the sort of person who writes makefiles for fun, and I regularly work with the build systems of go, C, rust, java, ruby, python, and javascript. webpack is easily the most complicated, slow, frightening build system I have ever encountered and I will go far out of my way to avoid it.

TIL as it's not really something I can say I am an expert on although I am really surprised by the bar height being set by others. Hopefully I will be pleasantly surprised when I try some new tooling in the future!

Re: Some notes on using esbuild

#94

Post by oefrha »

hsn915 wrote: post #78
oefrha wrote: post #23

Earlier quoted context omitted.

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

> What I want is to reload the page and see my changes.

And what other people want is to not having to reload everything, lose all state on the page and make API requests all over when they add a 2px margin.

> I've never seen a "hot reload" that works properly.

Yeah, you've never seen a hot reload that works properly means someone else can't develop something new that works. And whatever crappy workflow that you enjoy must be great for everyone else.

Anyway, talking to close minded individuals is pointless, so this is it.

Re: Some notes on using esbuild

#95

Post by DrammBA »

hsn915 wrote: post #78
oefrha wrote: post #23

Earlier quoted context omitted.

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

Sample size of 1 here: My vite project hot reloads in a few milliseconds, keeps state, and shows me all recent changes with no issues. Sounds like your co-workers are using webpack-based hmr, that can become slow very fast.

Re: Some notes on using esbuild

#96

Post by llimllib »

Bellend wrote: post #93
llimllib wrote: post #89

Earlier quoted context omitted.

> Is webpack really considered such a difficult beast For whatever it's worth, I'm the sort of person who writes makefiles for fun, and I regularly work with the build systems of go, C, rust, java, ruby, python, and javascript. webpack is easily the most complicated, slow, frightening build system I have ever encountered and I will go far out of my way to avoid it.

TIL as it's not really something I can say I am an expert on although I am really surprised by the bar height being set by others. Hopefully I will be pleasantly surprised when I try some new tooling in the future!

It's also completely possible that I had my brain warped in weird ways by old software, and you'll have your brain warped in your own weird ways that work better in the future. Anyway, I know I'm always glad to have somebody who knows their way around webpack on the team :)

Re: Some notes on using esbuild

#97

Post by oefrha »

dmitriid wrote: post #88
oefrha wrote: post #44

Earlier quoted context omitted.

If you can roll your own esbuild commands to build your codebase without change, good for you. Once you’ve done that, good luck figuring out a dev server with HMR, since esbuild certainly doesn’t offer that.

> Once you’ve done that, good luck figuring out a dev server with HMR, since esbuild certainly doesn’t offer that. Because vite does, and "just go with vite", right?

Because when it actually works it's a very refreshing development experience, once you get used to it you never want to return to the crappy "let me refresh this page to see my changes" workflow.

But hey, tons of people swear by the simple setup they claim to understand; good for them. As someone who don't work on frontend stuff professionally, I wouldn't pretend I "understand" esbuild and can always fix it when it breaks. Ironically, TFA presents an issue with this simple setup that the author could not figure out without help from experts:

> I was really baffled by this, but I was eventually able to figure it out with some help from people who understood Javascript.

Re: Some notes on using esbuild

#98

Post by hsn915 »

Bellend wrote: post #90
hsn915 wrote: post #80

Earlier quoted context omitted.

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

The reason I moved away from gulp (v3?) at the time was because I considered configuration (especially an intellisense configuration) really simple as opposed to the god awful pipable javascript files gulp went for. Not sure how much that plays to my strengths though because everything I have ever used has json file configurations or object file configurations. Anyway I am definitely going to kick some tires on ESBui…

I never understood the point of gulp and other libraries that claim to help you write "commands". I just never used them and instead just wrote the code directly.

Back in the day I was using amd.js and they had a scriptable command line utility so I just wrote a javascript file that collected all the required inputs for it and then built up the build command. (or something like that .. I don't remember the details).

Re: Some notes on using esbuild

#99

Post by throwaway894345 »

hobofan wrote: post #65
mkl wrote: post #60

Earlier quoted context omitted.

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…

> It's holding JavaScript to its own higher standard: is dead simple, and trivial to understand and get working. The most simple example is almost never a representative example that can be used as a standard to hold the whole language to. In the same vein, one could say: "See how easy it is to build a C program with `gcc main.c`? Why should I have to figure out how to use make?". And the answer is simple: Most proje…

C also lacks a sane build system, so if you’re trying to make the point that JS isn’t so bad, comparing it with C isn’t the way to go. Consider that no other language needs a bundler with all of the weird stuff it supports. You might argue that it’s good that JS supports all of these things and that’s fine, but what you’re really saying is complexity is good which is also fine but incompatible with the “JS is no more complex than other languages” position.

Re: Some notes on using esbuild

#100

Post by merrywhether »

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.

On the flip-side this approach sounds kind of like premature optimization. You don’t have to understand the entire path from pressing buttons on a keyboard to a program causing photons to exit your monitor. You instead trust that large parts of that chain just work.

If what you’re doing works via script tag, the odds of Vite/CRA/etc not working for you are extremely low, so why worry about problems you might have before you ever have them. It’s perfectly fine to opaquely trust your tools while focusing on the details you actually care about.

In another context, no Java course ever starts off with explaining “public static void main(String[] args) {…}” and students just “cargo-cult” it for a while until through other exposures to various bits of functionality through natural use they build a context through which to eventually circle back and easily understand what that crucial bit of code actually means. And that’s long before someone would consider trying to get a deeper understanding of what the compiler is doing! “Welcome to CS101, we’re going to start off talking about byte-code and intermediate representations” would have a success rate of literally 0%.

Post reply on HN