"I’m saying that what runs in the browser is NOT the same code that runs on the server."

But it can be, for real. The exactly same code.

"To get that server-targetted code, that’s often written in a bleeding-edge version of ECMAscript, to run in a browser you need transpilers and bundlers."

It's not mandatory. It depends on the one who are building the module. I will give an example from my own experience. I have some modules that are built to run on both sides, and with that, i mean that you could use require , import or just call the module from a file using the <script> tag without the need of any transpiler or bundler. Without any need of doing anything to have it working. Just require or call it through a file on a browser.

The last one that i built i had it written using ES6, and once i finished it, i rewrote it, to replace ES6 features with the "old" ones that has a wider support from our current browsers. I did that just to have an ease of use for both sides. To avoid the need of a transpiler for those who just want to use it as a file using the <script> tag. I can give you a link for those examples, if you are interested.

That's why i said that it depends on the developer. People are choosing to write things with the dependency of a transpiler, when it could be done differently.

Maybe the problem that people sees today comes from what you said about people writing Front End using import / require, hence, creating a direct dependency of a transpiler.

About your last paragraph, i can't agree because you say:

"saying it’s not javascript that’s a mess, but front-end development, that’s disingenuous"

Which could be a statement around JavaScript, but then you write next:

"It’s only a mess in browsers because the ecosystem is no longer designed for the browser run-time"

Which is not a statement around JavaScript. The ecosystem is what we (developers) are creating around JS.