This is the answer IMO. The number of targets and noise would be a lot less if JS had a decent stdlib or if we had access to a better language in the browser.

I have no hope of this ever happening and am abandoning the web as a platform for interactive applications in my own projects. I’d rather build native applications using SDL3 or anything else.

▲

mrguyorama 4 days ago | parent | next [-]

But this can't be the whole story. In the Java world, it's pretty common to import a couple huge libraries full of utility functions, but those are each one import, that you can track and version and pay attention to.

Apache Commons helper libraries don't import sub libraries for every little thing, they collect a large toolbox into a single library/jar.

Why instead do people in the javascript ecosystem insist on separating every function into it's own library that STILL has to import helper libraries? Why do they insist on making imports fractally complex for zero gain?

	▲	crabmusket 4 days ago \| parent \| next [-]
		Bundle size optimisation. See my comment upthread for more detailed explanation. Bundle size is one of the historical factors that makes JS ecosystem a unique culture, and I'd argue uniquely paranoid.
	▲	xd1936 4 days ago \| parent \| prev \| next [-]
		I didn't used to be. It's just become less trendy to import a big giant Lodash, Underscore, Sugar, or even jQuery.
	▲	flomo 4 days ago \| parent \| prev [-]
		Originally I think it was to avoid the applet experience of downloading a large util.jar or etc. (Not that most js devs really care.) However, I suspect the motivation is often social status on GitHub & their resume.

▲

imiric 4 days ago | parent | prev [-]

To be fair, this is not a problem with the web itself, but with the Node ecosystem.

It's perfectly possible to build web apps without relying on npm at all, or by being very selective and conservative about the packages you choose as your direct and transitive dependencies. If not by reviewing every line of code, then certainly by vendoring them.

Yes, this is more inconvenient and labor intensive, but the alternative is far riskier and worse for users.

The problem is with web developers themselves, who are often lazy, and prioritize their own development experience over their users'.

▲

palmfacehn 4 days ago | parent [-]

I'm often surprised at the number of JS experts who struggle with the basics of the browser API. Instead of reasoning through the problem, many will reach for a framework or library.

	▲	PeterisP 4 days ago \| parent \| next [-]
		At least historically it used to be the case that you don't ever want to use the browser API directly for compatibility reasons but always through some library that will be a do-nothing-wrapper in some cases but do a bunch of weird stuff for older browsers. And traditions are sticky.
	▲	skydhash 4 days ago \| parent \| prev [-]
		Especially with the MDN, an amazing resource.