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

141–150 of 205 posts

Re: Some notes on using esbuild

#141

Post by morelisp »

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…

There is no problem JS transpilers+bundlers tackled that earlier compiler writers had not tackled, better, before.

> 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

What does "plaintext source code" or "over the wire" do to distinguish this from "compiling a binary targeting a minimum supported ABI"? Bundled JavaScript doesn't even have to deal with dynamic linking!

Re: Some notes on using esbuild

#142

Post by colejohnson66 »

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.

Re: Some notes on using esbuild

#143

Post by jashper »

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

Re: Some notes on using esbuild

#144

Post by cxr »

smt88 wrote: post #117
cxr wrote: post #108

Earlier quoted context omitted.

> Within the actual language, there isn't a universal syntax just to use a package. There is. The issue is one of mindset. You recognize Maven and Gradle as belonging to a sort of "parastandard" set of technology, offering proprietary (albeit free/open source) glimpses of how one could conceivably solve the set of problems that they're meant to be used for, but when it comes to JS, you're elevating the parastandard s…

I think you're misunderstanding what I'm saying. You're still talking about package managers and build systems. I'm talking only about syntax. TypeScript, NPM, esbuild, Gradle, and Maven are completely separate from what I'm talking about.

I'm not misunderstanding. (The difference between parastandard tech like package managers vs base-level stuff in e.g. the language itself was actually the point of my message, so I understand the distinction.) You're saying that unlike Java, JS at the language level doesn't have imports, but what you're saying is untrue.

It's entirely possible that the projects you're most familiar with aren't using them, but the JavaScript language has native modules, including standardized syntax and semantics for import statements.

Re: Some notes on using esbuild

#145

Post by elevader »

morelisp wrote: post #141
elevader wrote: post #122

Earlier quoted context omitted.

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…

There is no problem JS transpilers+bundlers tackled that earlier compiler writers had not tackled, better, before. > 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 What does "plaintext source code" or "over the wire" do to distinguish this from "compiling a binary targeting a minimum…

> 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 targeting a minimum supported ABI"? Bundled JavaScript doesn't even have to deal with dynamic linking!

Correct me if I'm wrong on that but it doesn't really matter if something is written in Go, Rust 2015, Rust 2018, Rust 2021, Zig, D or whatever else comes to mind, assuming static linking of course. I can compile it, I can ship it and the binary will work. I can't just ship typescript out, browsers don't understand it. I can't just ship modern js out as I have no idea if the users browser understands the code. Bundled javascript doesn't have to deal with dynamic linking because it is, in essence, static linking. The whole dynamic linking thing was sort of tried with CDNs shipping js libraries, didn't really work out all that well in practice, relying on some different service to be available for your dependencies is only a good idea until that service has downtime.

Re: Some notes on using esbuild

#146

Post by mynegation »

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)

Not your parent commenter. I worked both with CMake/autotools and Java build tools (not esbuild specifically) and the point (which I agree with) is - yes - C/C++ build tools are complicated, but once you set it up it just runs most of the time without any problem. With things like webpack you are always one upgrade away from things breaking down in spectacular fashion, and the troubleshooting involves hunting github issues, blogs, and sometimes looking through the source code to figure out why this combination of npm package versions gives you the trouble.

Re: Some notes on using esbuild

#147

Post by 3np »

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

Earlier quoted context omitted.

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

Optimal != Best for most people.

Best for most people != Best for everyone

I mean, notepad.exe is arguably a better text editor for most people compared to anything else most of us are using.

I'll happily take some minor overhead in build configuration over adding 30s+ to every automated build if it's not a personal or small-scale community project.

Re: Some notes on using esbuild

#148

Post by handrous »

morelisp wrote: post #57
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.

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 . Webpa…

> Yarn blew NPM away on speed with more features and nicer developer workflow.

I dunno if it's still true, but for years into people saying "LOL use yarn, it's a better replacement for NPM" it was still really easy to find packages that broke under Yarn because it lacked some feature or other, or was skipping some obviously-a-good-idea sanity check that NPM did and so crashed rather than proceeding after adjusting its approach, or to venture slightly off the happy path of doing "yarn install" and running into features that yarn didn't support, but NPM did. A venture into the issue tracker in that time period was enlightening, and I don't just mean the sheer count, but digging into some of the issues and why they were happening.

[EDIT] in fact, in the agency I was at at the time, a kind of joke developed that a project wasn't fully underway until you'd been forced to replace Yarn with NPM.

Re: Some notes on using esbuild

#149

Post by lhorie »

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.

I mean, there is a certain amount of buy-in into cargo culting. She could've used something like mithril.js and that would've worked with a script tag only setup without having to worry about template language compilers or anything of the sort. The tutorial even walks you through how to do exactly that.

Esbuild is a fantastic tool, but the nature of the problem domain is indeed inherently complex. "I don't know what import does" may sound like admitting ignorance, but it is also borderline clairvoyant. Resolving a module involves the incredibly convoluted node resolution algorithm, semantics of doppelganger packages, semantics of peer dependencies, architecture-specific optional dependencies, other ad-hoc standards and spin-offs such as package.json `browser` fields and import maps, esm vs cjs vs umd woes... any of those could break and the error messages are impenetrable when they do.

Re: Some notes on using esbuild

#150

Post by morelisp »

elevader wrote: post #145
morelisp wrote: post #141

Earlier quoted context omitted.

There is no problem JS transpilers+bundlers tackled that earlier compiler writers had not tackled, better, before. > 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 What does "plaintext source code" or "over the wire" do to distinguish this from "compiling a binary targeting a minimum…

> 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 compiling TS, ES2015, whatever, all down to some lesser ES version. And yet these compilers are faster, more effective, and easier to use.

You've missed my point about static vs. dynamic linking entirely. The point is that C compilers did "bundling" for years while supporting dynamic linking, and now you're trying to say JavaScript is tackling some way more difficult problem when it has a much simpler language-to-"ABI" translation process and doesn't even need to support that?

As you say, this maybe isn't a fruitful discussion - but it's a true one. JS tooling developers got seriously deluded about the novelty of their problems and quality of solution at some point ca. 2014, and we will be dealing with the results for another decade or more. At the very least let's start being honest about it.

Post reply on HN