←back to thread

Skeptical of rewriting JavaScript tools in "faster" languages

(nolanlawson.com)
160 points todsacerdoti | 2 comments | 20 Oct 24 21:25 UTC | HN request time: 0.414s | 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 #
1. paulddraper ◴[21 Oct 24 01:40 UTC] No.41899976[source]▶
You can ship a 20MB Go program and no one blinks.

Go programs start at 20MB. The Go AWS Terraform provider is something like 300MB.

A massive amount of the complexity/difficulty in webdev build tools space has to with optimizing delivery sizes on the web platform.

Node.js tooling is straightforward comparatively.

replies(1): >>41906596 #
2. paulddraper ◴[21 Oct 24 17:56 UTC] No.41906596[source]▶
To be clear: Server-side Node.js tooling is relatively simple. It the web tooling (Webpack, etc) that is complicated.