2 ms·

jQuery isn't the problem as much as jQuery "needing" to exist is the problem. Developers still have to make webpages that work with customers that are stuck on

jQuery isn't the problem as much as jQuery "needing" to exist is the problem. Developers still have to make webpages that work with customers that are stuck on old phones which will never see another firmware update, corporate desktops that have some forsaken frozen copy of IE6 that gets used for some legacy corporate platform (and then end users either don't or actually aren't allowed by IT/security to use any other browser), people with PCs that 'still work' (and if you're lucky have Windows XP with whatever it came with)... etc. Generally we can't have nice things because that legacy cruft is going to be around until all of that legacy falls over and dies so hard that even laypeople consider it laughable to assume it still works. It's got to be like those old blenders or fans... wait they still work; we're cursed forever. Want the Internet to be fast? jQuery is a defacto standard that needs to be made native in browsers and then when called for not loaded as script but already existing as native code and management models.

franga2000 6y ago
Are those legacy-supporting sites really the slow ones though? Targeting old software usually also means targeting old hardware, so those sites tend to perform reasonably well (and in general, old browsers didn't give developers many options to slow things down). The problem really starts once developers can start ignoring old platforms and (ab)using the full power of a modern browser. The problem isn't any specific library, but the mindset developers use to develop web sites/apps. Bundling 20 dependencies and 10k lines of "compiled" JSX into one giant 5MB uncachable blob that needs to get parsed in its entirety, then shoot some requests off then need to complete, be parsed, then compile some HTML and CSS that then need to again get parsed by the browser and then finally, the the browser's rendering engine gets to start laying things out and drawing the first pixels - that is the problem. The browser is a document viewer, not an application runtime, so you should be giving it documents, not programs. Yes, JavaScript is necessary, but just like you shouldn't be using HTML for layout and CSS for content and graphics (although CSS-only art is impressive!), you shouldn't be using JavaScript for content and styling.

franga2000 6y ago

Are those legacy-supporting sites really the slow ones though? Targeting old software usually also means targeting old hardware, so those sites tend to perform reasonably well (and in general, old browsers didn't give developers many options to slow things down). The problem really starts once developers can start ignoring old platforms and (ab)using the full power of a modern browser. The problem isn't any specific library, but the mindset developers use to develop web sites/apps. Bundling 20 dependencies and 10k lines of "compiled" JSX into one giant 5MB uncachable blob that needs to get parsed in its entirety, then shoot some requests off then need to complete, be parsed, then compile some HTML and CSS that then need to again get parsed by the browser and then finally, the the browser's rendering engine gets to start laying things out and drawing the first pixels - that is the problem. The browser is a document viewer, not an application runtime, so you should be giving it documents, not programs. Yes, JavaScript is necessary, but just like you shouldn't be using HTML for layout and CSS for content and graphics (although CSS-only art is impressive!), you shouldn't be using JavaScript for content and styling.