[cxr]

That's a start at improving something. But it won't rid itself of the Playskool/Fisher-Price gimmick factor or have any lasting effect until we can convince JS developers to write their own tools in a standards-compliant dialect and use standardized APIs so that contributors can use the runtime they already have installed instead of being cajoled and browbeaten into installing NodeJS or Bun or Deno or whatever to do what the browser runtime is perfectly capable of: opening a project directory, executing the code comprising the build script, and outputting the build artifacts when it's done.

[nl]

> do what the browser runtime is perfectly capable of: opening a project directory, executing the code comprising the build script, and outputting the build artifacts when it's done

Unfortunately Firefox doesn't support the FileSystem API so to do this you need to resort to uploading the entire source code directory each time you change a source file.

I understand Firefox's privacy and security first thinking on this, but I think it is misguided. It's led to the webplatform being eclipsed by other, propriety options, or people forced to ship "Chrome-based only" features.

[cxr]

> Unfortunately Firefox doesn't support the FileSystem API so to do this you need to resort to uploading the entire source code directory each time you change a source file.

Right, it's so much less onerous to have people download and set up an entirely separate fickle toolchain—and needing to trust that the install triggers in the package.json of some transitive dependency won't exfiltrate your personal data or install some nefarious ineradicable background service onto your system, versus the two extra clicks you'd have to subject yourself to if you wanted to re-run the build.*

Wait, no.

> people [are] forced to ship "Chrome-based only" features

No they're not. By your own admission they could make their build scripts work with the standardized HTML5 APIs that are well-supported in all major browsers. They choose not to.

And you're not really responding to the substance, anyway—which is that JS programmers (frequently writing for browser runtimes, even) require that you install NodeJS, Bun, or Deno (because they hardcode the build scripts internals against one of those runtime's APIs). If programmers really were writing build scripts that you could run in Chrome but unfortunately not Firefox, then even that would be an improvement over the status quo. But that's not what we're talking about, because that's not happening.

* most of which are destined to be one-shot executions, anyway

[nl]

You seem very angry and I clearly don't understand what you are talking about.

> And you're not really responding to the substance of the comment anyway, which is that JS programmers—frequently writing for browser runtimes, even—are demanding that you install NodeJS, Bun, or Deno (because they hardcode the build scripts against those runtimes' APIs).

Do you mean things like the Typescript + Webpack/whatever toolchain? Because broadly speaking that seems orthogonal to the target browser.

Using tools outside the browser to build something for the browser is mostly an optimization, for both the developer and the end user.

If someone has a web app with maybe 100 NPM packages, doing things like tree-shaking offline before shipping to a browser is important.

> And you're not really responding to the substance of the comment anyway, which is that JS programmers—frequently writing for browser runtimes, even—are demanding that you install NodeJS, Bun, or Deno (because they hardcode the build scripts against those runtimes' APIs).

If they are targeting Web APIs and using runtimes to build for those APIs what is the problem?

There are plenty of tools that need version X.XX+ of GCC to build and won't build using MSVC or something. It's a bit annoying but hardly outrageous.

[cxr]

> You seem very angry and I clearly don't understand what you are talking about.

Luckily you managed to frame it so that the failure comes across like something that I got wrong and messed up and am responsible for, and that's the most important thing.

[arikrahman]

This is why I use Clojure/ClojureScript to sidestep the issue entirely, while still being able to use the ecosystem if I have to.