←back to thread

Skeptical of rewriting JavaScript tools in "faster" languages

(nolanlawson.com)
160 points todsacerdoti | 1 comments | 20 Oct 24 21:25 UTC | HN request time: 0.195s | source
Show context
paulddraper ◴[20 Oct 24 22:06 UTC] No.41898871[source]▶
The biggest reason to be skeptical is that these tools are not open to extension in the same way that JavaScript is.

Webpack has an enormous community of third-party plugins, it would be very hard to do something similar with e.g. Go or Zig.

replies(2): >>41898951 #>>41899005 #
klabb3 ◴[20 Oct 24 22:17 UTC] No.41898951[source]▶
Right, because tooling is standardized in eg Go. There’s no custom build pipeline, transpilation hell, or experimental language features that are selectively enabled randomly. I’m not even against JS, like at all, and I think the majority of perf issues can be resolved. However, JS tooling is the prime example of where things get truly nightmarish from a software development perspective. Webpack being a perfect example of this horror.
replies(2): >>41899009 #>>41899976 #
postalrat ◴[20 Oct 24 22:27 UTC] No.41899009[source]▶
It's also a breeding ground where the best ideas often end becoming a sort of standard not only for javascript devs but for other langauges as well.
replies(1): >>41899197 #
1. FridgeSeal ◴[20 Oct 24 23:01 UTC] No.41899197[source]▶
Well curious as to what some of these ideas might be.

NPM has done a pretty great job of showing everyone else what to avoid doing.

The mere mention of “web pack” sends most of the FE devs I’ve met into borderline trauma flashbacks.

There’s seemingly half a dozen package managements tools, some of which also seem to be compilers? There’s also bundlers, but again some of these seem integrated. Half of the frameworks seem to ship their own tools?