4 ms·
Right, because tooling is standardized in eg Go. There’s no custom build pipeline, transpilation hell, or experimental language features that are selectively en
by klabb3 2y ago
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.
- postalrat 2y agoIt'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.
- FridgeSeal 2y agoWell 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?
- paulddraper 2y agoYou 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.
- paulddraper 2y agoTo be clear: Server-side Node.js tooling is relatively simple. It the web tooling (Webpack, etc) that is complicated.