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

161–170 of 205 posts

Re: Some notes on using esbuild

#161

Post by akitzmiller »

modeless wrote: post #139
akitzmiller wrote: post #118

I know it's just piling on at this point, but I've been doing a lot of software builds and deployment over the last 20 years, mostly in a scientific computing context. Nothing I've dealt with is as bad as JavaScript. I've generated and hacked dozens of autotools builds and written m4 macros of my own; I've hacked CMake builds; written RPM spec files; fixed Rcpp package installs; written and modified innumerable Makef…

You really prefer autotools or CMake to esbuild just because they are older and don't change as much? I will take esbuild over CMake every day of the week and twice on Sunday. C++ build tools are an abject disaster. (And CMake does change anyway)

I think CMake is a real pain and Autotools is an older pain. But I can figure them out and things I learned two blue moons ago are still basically true. The churn in JS makes it really hard for me to accumulate knowledge and solutions.

Re: Some notes on using esbuild

#162

Post by bredren »

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

> It's not like the previous tooling was really any easier to deal with. If you really understood the previous tooling, that probably explains why you have the mental models in place to understand what webpacker is doing with increasing automation. Say, if you were using babel without webpacker already. For people who skipped that or came to JS in webpacker era (myself included), it's hard to understand what is going…

> But webpacker isn't just insane, it is what it is for a reason, involving solving specific problems that were in existence in previous ways of doing things. If you had those problems personally... it's a lot easier to make sense of it.

I think this a big issue for non-js / frontend people, particularly in the python webdev community.

People don't know the story of front end and the user demand for refined interfaces. The demand has been high even though browsers just recently offered consistent support for modern js / css features.

I suspect this will come back to bite backend people, to some extent because the dust is settling on frontend. So the anti-everything on frontend attitude might blind people to the rapid advance of JS and node.

Re: Some notes on using esbuild

#163

Post by akitzmiller »

jashper wrote: post #143
akitzmiller wrote: post #118

I know it's just piling on at this point, but I've been doing a lot of software builds and deployment over the last 20 years, mostly in a scientific computing context. Nothing I've dealt with is as bad as JavaScript. I've generated and hacked dozens of autotools builds and written m4 macros of my own; I've hacked CMake builds; written RPM spec files; fixed Rcpp package installs; written and modified innumerable Makef…

Hey now, let's leave Richard Stallman alone :D

Indeed

Re: Some notes on using esbuild

#164

Post by akitzmiller »

colejohnson66 wrote: post #142
akitzmiller wrote: post #118

I know it's just piling on at this point, but I've been doing a lot of software builds and deployment over the last 20 years, mostly in a scientific computing context. Nothing I've dealt with is as bad as JavaScript. I've generated and hacked dozens of autotools builds and written m4 macros of my own; I've hacked CMake builds; written RPM spec files; fixed Rcpp package installs; written and modified innumerable Makef…

You'd really take autotools and M4 over some other build system? This honestly reads like a "get off my lawn. The old days were better" post.

You're not totally wrong; I'm getting into that age range.

It's not that I prefer those tools; they are really obtuse. It's just that I can't handle the moving target of JavaScript. I'm sure I can figure out esbuild just fine, but in a year or two it could be abandoned in favor of swc or Vite or a Vite-esbuild-swc uber package.

Re: Some notes on using esbuild

#165

Post by throwaway894345 »

elevader wrote: post #122
throwaway894345 wrote: post #99

Earlier quoted context omitted.

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…

Most languages also don't really have to worry about shipping dozens of plaintext source code files over the wire that then might get executed in an environment you have no control over that doesn't actually support the code you wrote (There are still people running old IE versions and loosing 1% of customers might be really costly at scale). I'm not saying that the current ecosystem isn't an overly complex mess but…

I empathize with the unique difficulties of the web and I don't doubt that the complexity solves for real problems (e.g., old IE versions); however, I take issue with treating all problems as equal irrespective of how niche those problems are. The C and C++ folks make the same kind of argument to justify their abusive build systems--if the build systems made sane assumptions, then it would exclude certain niche use cases. Of course, we all agree that sane tooling excludes niche use cases, but we disagree about whether excluding ~1% of use cases for a dramatically improved experience for the ~99% is worthwhile (and we may even disagree about some of the qualifiers I used in this sentence).

Re: Some notes on using esbuild

#166

Post by [deleted] »

akitzmiller wrote: post #118

I know it's just piling on at this point, but I've been doing a lot of software builds and deployment over the last 20 years, mostly in a scientific computing context. Nothing I've dealt with is as bad as JavaScript. I've generated and hacked dozens of autotools builds and written m4 macros of my own; I've hacked CMake builds; written RPM spec files; fixed Rcpp package installs; written and modified innumerable Makef…

[deleted]

Re: Some notes on using esbuild

#167

Post by throwaway894345 »

morelisp wrote: post #150
elevader wrote: post #145

Earlier quoted context omitted.

> There is no problem JS transpilers+bundlers tackled that earlier compiler writers had not tackled, better, before. I'm not sure what I am supposed to do with that statement/answer? It's obviously very easy to just assume that every js developer must be an idiot but that is hardly a fruitful discussion to have. > What does "plaintext source code" or "over the wire" do to distinguish this from "compiling a binary tar…

> I can ship it and the binary will work In this scenario, the binary is your ES3 or ES5 or what have you. Compiling Go to an x86 ABI, Rust to the same x86 ABI, C to the same x86 ABI, etc. is an analogous problem to "shipping dozens of plaintext source code files over the wire that then might get executed in an environment you have no control over". It's harder , by order of magnitude and on every axis, than compilin…

I tend to agree with the overall thrust of your argument and the conclusion you're driving toward, but it's at least interesting to note that the distribution model of the web puts unique pressure on tools to ship dramatically smaller payloads. In Go or Rust, we ship debug symbols in production builds by default (or whatever it is which give us stack traces on panic), but in JS sourcemaps typically aren't shipped in production builds because they are too bulky. Similarly, there are a litany of caching concerns which apply in the browser world but not natively.

I also think that invoking "C compilers did X" weakens your argument because the C build ecosystem is quite a lot worse than the JS ecosystem and without any good excuses (its ecosystem is not rapidly evolving, there is no distribution model putting comparable pressure on latency, etc).

But in general, I agree that there is a lot the JS world could learn from the native world.

Re: Some notes on using esbuild

#168

Post by colejohnson66 »

akitzmiller wrote: post #164
colejohnson66 wrote: post #142

Earlier quoted context omitted.

You'd really take autotools and M4 over some other build system? This honestly reads like a "get off my lawn. The old days were better" post.

You're not totally wrong; I'm getting into that age range. It's not that I prefer those tools; they are really obtuse. It's just that I can't handle the moving target of JavaScript. I'm sure I can figure out esbuild just fine, but in a year or two it could be abandoned in favor of swc or Vite or a Vite-esbuild-swc uber package.

That is a very valid concern

Re: Some notes on using esbuild

#169

Post by mpolichette »

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

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…

This ^

I feel like JS gets thrown under the bus in discussions, but no body talks about arcane file structures in Java or implicit pathing lookups which have the same kind of "historical path dependence" to why they exist as JS has for require/import.

All languages have their warts and 99% of the time they're all doing the same thing just in slightly different ways.

Re: Some notes on using esbuild

#170

Post by swyx »

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…

fwiw here's my piece on why JS Build Tools are so churny: https://www.swyx.io/jobs-of-js-build-tools
Post reply on HN