> 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.
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.
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.
> the C build ecosystem is quite a lot worse than the JS ecosystem
Other than module packaging (and that's admittedly a big "other than"), I don't agree. Esbuild is the first tool I used that's even close to e.g. Make in comprehensibility (~ ease of use x flexibility x ability to debug when something goes wrong). That's a pretty low bar, and I don't know how long esbuild will stay that way.
Agree to disagree I guess. I don't want to go to bat for JS, but I've done more than my share of C and C++ and Make, CMake, Autotools, etc are just fucking nuts, and that's ignoring the fact that they completely punt on package management. JS is painful by the standards of modern programming languages, but C and C++ are on the next level.
"Stockholm Syndrome" is the only way I can rationalize people vouching for C or C++ (or JS, to a significantly-lesser-but-still-not-negligible extent) build tooling.
I'm not trying to argue that it is harder, just different in some ways and ignoring that for the sake of "javascript bad" isn' going to change the point that there are challenges involved. Nevertheless I understand your pint a lot better now, thanks for the explanation.
I think we are both on the same page that the JS ecosystem overall is not in a good shape. But, you know, maybe THIS wave of new shiny tools is finally solving the issues once and for all (not holding my breath though...)
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.