4 ms·
We absolutely, most certainly, should NOT ship libraries with browsers. This is a horrible idea. Browser vendors would then have too much influence on developme
by JustSomeNobody 11y ago
We absolutely, most certainly, should NOT ship libraries with browsers. This is a horrible idea. Browser vendors would then have too much influence on development libraries.
- mod 11y agoIt could be a 'use the default or link your own' situation, which then wouldn't influence a whole lot. But I agree, overall.
- LeoNatan25 11y agoIn this case, very very little would change. People would still link their own, as they do now.
- JustSomeNobody 11y agoOr worse, people would use the buggy, out of date default.
- delan 11y ago“We absolutely, most certainly, should NOT ship libraries with operating systems.”
- ArkyBeagle 11y agoThere used to be a distinction between browsers and operating systems.
- JustSomeNobody 11y agoPretty sure there still is.
- mindcrime 11y agoIt's getting pretty hard to tell.
- JustSomeNobody 11y agoAll the major browsers ship with JavaScript. If JS, absolutely needed JQuery in order to, say, select an element the way C needs a library to output to the console, then sure, you may have an argument here. But, no.
- morgante 11y agoAnd why do you think web development has become the dominant form of development?
- pikzen 11y agoBecause literally any child can start developing, and then grows up and pulls every library under the sun because the language they use is a piece of crap, without a single thought about the consequences? Thankfully node.js is bringing this clusterfuck to the desktop too.
- dinkumthinkum 11y agoIt's more about deployment and dependency problems. The dependencies we are talking about are transparent to the user, save only for some download performance issues which are pretty minimal, if not overstated in many cases, compared to the former issues faced by native applications.
- notahacker 11y agoI think the direction of the influence would mostly works the other way round. If there's an attribute on the HTML link tag that some browsers recognise as calling the browser's client-side version of that library (with local/CDN fallback for browsers that don't) then users are going to notice that browser X seems to load a lot of websites more quickly than browser Y, which puts pressure on the vendor of browser Y to make sure it also supports these frequently-used js libraries (especially if they're large frequently-used libraries with multiple minor version numbers and no widely-accepted-as-canonical CDN source) This is still a shame if you're maintaining a heavyweight alternative to jQuery or React which is far too obscure to be a consideration for browser vendors, but it's a big boon for users, especially users on slow or metered connections that download several different version numbers of jQuery from several different CDNs every day.
- dinkumthinkum 11y agoI'm not sure that is true. No one is saying external libraries cannot be loaded. It is actually a good idea to be able to rely on certain popular libraries already on the client; this makes a lot of sense. You can still have the existing mechanism so I don't think browser vendor are going to hold everyone hostage. If you like, there could be mutually agreed upon standard repository that browser vendors routinely update from. Sure, your less popular experimental library won't be in the list, that's what "<script src=..." is for. It probably won't happen but it is hard to defend the position that it is a bad idea, I think.