3 ms·

jQuery really isn't a problem - it's just a light-ish wrapper around the native JS APIs. The problem is JS itself or rather the fact that it's used where it rea

by franga2000 6y ago

jQuery really isn't a problem - it's just a light-ish wrapper around the native JS APIs. The problem is JS itself or rather the fact that it's used where it really shouldn't be.

mjevans 6y ago
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.
wruza 6y ago
It’s understandable that keep it simple is a good technical rule. But it is also interesting for app developers who have to use some kind of inplace dom modifications. Personally, I don’t (yet) see how an in-browser html parser could be much faster than createElement from e.g. hyperscript driven by pojo. It is basically the same recursive process, with an exception that small updates generate small modifications in the latter.
- giantrobot 6y ago
  With jQuery (as an example) when you change elements it does so on the live DOM. This often causes the browser to re-layout, re-render, and re-draw content. If you create a thousand elements in a loop that's tons of extra work for the browser and blocks interactivity. You can do batch updates or non-display elements but it's not (or at least wasn't) built into jQuery. It's faster but more complicated. With React and the like they operate on a copy of the DOM and automatically batch updates to it. All of the changes are applied at once so there's fewer layout, render, and draw events. Part of the problem with jQuery is there's a cohort of web "developers" that grew up with it. Instead of learning the actual web stack they learned jQuery. Everything is put together (slowly) with jQuery. Even if they've been promoted out of junior positions they're not PMs or marketing drones requiring slow scripts because they're written in a style they understand.

jQuery really isn't a problem - it's just a light-ish wrapper around the native JS APIs. The problem is JS itself or rather the fact that it's used where it really shouldn't be.

mjevans 6y ago

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.

wruza 6y ago

It’s understandable that keep it simple is a good technical rule. But it is also interesting for app developers who have to use some kind of inplace dom modifications. Personally, I don’t (yet) see how an in-browser html parser could be much faster than createElement from e.g. hyperscript driven by pojo. It is basically the same recursive process, with an exception that small updates generate small modifications in the latter.

giantrobot 6y ago
With jQuery (as an example) when you change elements it does so on the live DOM. This often causes the browser to re-layout, re-render, and re-draw content. If you create a thousand elements in a loop that's tons of extra work for the browser and blocks interactivity. You can do batch updates or non-display elements but it's not (or at least wasn't) built into jQuery. It's faster but more complicated. With React and the like they operate on a copy of the DOM and automatically batch updates to it. All of the changes are applied at once so there's fewer layout, render, and draw events. Part of the problem with jQuery is there's a cohort of web "developers" that grew up with it. Instead of learning the actual web stack they learned jQuery. Everything is put together (slowly) with jQuery. Even if they've been promoted out of junior positions they're not PMs or marketing drones requiring slow scripts because they're written in a style they understand.