4 ms·
Everyone in JS-land seems to have an opinion about how tooling should work, and because the platform (well, Node at least) provides no opinions of its own, ever
by deergomoo 2y ago
Everyone in JS-land seems to have an opinion about how tooling should work, and because the platform (well, Node at least) provides no opinions of its own, everyone goes ahead and implements it. So you end up with a thousand-and-one competing bundlers, linters, formatters, test runners, etc, with all the associated churn and cost in learning it all and getting a new project up and running.
Compare that to something like Go which includes all of that stuff out of the box—by and large everyone has just said "yep that seems to work" and stuck with the defaults.
I think the second problem is the browser still fundamentally wants to be a displayer of documents. Yes there has been continued additions of new APIs over the years that have made the SPA pattern much easier to work with, the fact of the matter is you can still save yourself about an order of magnitude of complexity if you can get away with your app being an "old school" multi-page affair.
- mirekrusin 2y agoYet I wouldn't call gui ecosystem in go a success like js'es is.
- jpk 2y agoIs that a fair critique given that GUI applications aren't really Go's target market?
- zdragnar 2y agoIt just demonstrates that there is a lot more natural complexity in writing UI than CRUD endpoints or small services. Sure, the browser environment (DOM etc) introduce plenty of problems, but it's going to be more complex than slapping together CRUD endpoints regardless.
- jpk 2y agoIt doesn't. The original comparison to Go here was in terms of opinionated defaults with respect to tooling. Go became a popular language for distributed systems, backend web, CLI tools, etc, in part because of the batteries-included tooling. Starting or getting acquainted with a project in Go is pretty straightforward because of this. The opposite is true of JS projects, in part because of the lack of standardized tooling. To point at Go's lack of usage for GUI applications in the context of is a non sequitur. To phrase the comparison a different way: Would the JS ecosystem be better if there was one set of tools everyone agreed on, similar to Go? (The answer is yes.)
- kaba0 2y agoWell, if it doesn't handle a notoriously hard area basically at all, then frankly it's a pretty bad data point to bring up.
- jpk 2y agoAgain, the comparison made was about tooling around Go/JS. What Go, the language, is or isn't typically used for is utterly irrelevant to that comparison.
- mirekrusin 2y agoComplexity handled by tooling is absolutely relevant.
- jpk 2y agoSuch as... :)
- bsimpson 2y agoThis feels like less of a problem in recent years, with Vite having won the bundler space in the same way that VHS/Blu-ray won home video. There might be future evolution of course, but it feels like Vite is the default for new/retrofitted projects these days.
- jakjak123 2y agoWell, Go bundles its own runtime with the executable. JS has to work on probably millions of different combinations of versioned runtimes.