It doesn't make sense to require a backend tool for frontend technologies. That's just me though. So that's why I'm asking. Couldn't they just create a package system that's not based on some backend tech?
If you're writing a tool that's written in Javascript, you need an implementation of Javascript to make it work. Node, while focused on being "Javascript on the server", is also a really convenient way to get going with a Javascript runtime.
So yeah, in theory, you could create a whole 'nother binding to a runtime just for front-end tooling. Nobody's found node lacking enough to do that.
I guess I don't understand. How would you fetch/build/etc frontend JS files without some sort of backend technology?
(Also don't forget that frontend JS has to target dozens of subtly different browsers, so we unfortunately need to "build" JS files to account for backwards compatibility, etc)
We have that and it's called `bower`. We moved away from it because having two package managers to manage javascript (one for front-end and one for back-end) is more insane than the issue you described.
So yeah, in theory, you could create a whole 'nother binding to a runtime just for front-end tooling. Nobody's found node lacking enough to do that.