4 ms·

When I did web development, I specifically loaded JS lazily so first you got a pure HTML page with just a few lines of code. Those lines of code are normal (not

by iopq 4y ago

When I did web development, I specifically loaded JS lazily so first you got a pure HTML page with just a few lines of code. Those lines of code are normal (not jQuery) JS that loads the rest of the JS lazily in a progressive enhancement. This means the page can start being rendered before the jQuery code loads. But in fact, jQuery is largely not needed since Internet Explorer lost market share and there's less of a need to have lots of workarounds for it.

3np 4y ago
If done properly this can be nice but a common grief is when interactive elements (input fields/buttons/links, including in flowing text) move around after first becoming visible. The worst is input fields that get cleared or grabbing focus (this is way too common; not stellar to have to password reset due to typing half a password in an auto-complete search field) as part of this process after the user has already started inputting data.
- 867-5309 4y ago
  it also negatively affects anchor links, e.g. example.com/#contact will not always jump to the contact section with lazy loading
- marcus_holmes 4y ago
  this is so infuriating when it happens and I click the wrong thing because between the time I saw the button and pushed the button, the button moved away and another button moved under my finger/cursor. I would massively prefer to have a blank page, or a page with no buttons, and wait a few seconds for the buttons to appear in their final locations, than this.
wildrhythms 4y ago
You have to really do some extra work to make this happen "nicely". Swapping out parts of the page without jerking the user around is a difficult problem, especially if you aren't working with fixed sizes of elements. And creating a "skeleton" system of placeholders during loading is a whole other set of state you have to build out and maintain. I find most sites using this kind of progressive loading are completely useless during the loading phase... What's the point of showing the user a page full of skeleton/loading placeholders? You might as well have just server-rendered the whole thing and made the user wait an extra second or two.
- Dalewyn 4y ago
  I remember how it was good practice to assign width and height to <img> tags. The idea being the browser would know how to render the things around the picture without needing to download the picture first, preventing the page from jumping around as the quicker and lighter HTML was downloaded and rendered first.
  - chrisweekly 4y ago
    That still is a best practice. That "jumping around" is now referred to as "CLS" -- Cumulative Layout Shift -- one of the "Core Web Vitals" metrics used to quantify performance-related UX.
    - teknopaul 4y ago
      I sometmes like CLS, it makes it look like things are happening instead of feeling like a wait time. I recently used a simple templating mechanism elem = jquery.clone() ... elem.slideDown() And this renders bits of the page moving them as it does it; slideDown() is in jquery core. It used to be popular before that biz of rendering grey squares first got invented
      - tryfinally 4y ago
        Layout shift feels fairly terrible when you're navigating to an element that is at the bottom of the page (via #id) or simply refreshing the page. There is literally nothing more annoying than clicking the wrong link because the layout shifted under the cursor at just the wrong moment. CLS is also known as "jank" for a reason.
  - christophilus 4y ago
    I use aspect ratio for this now that it's supported in CSS. It might be my favorite CSS feature since flex.
- Banana699 4y ago
  GP was talking about loading JS, adding JS to a webpage doesn't affect its rendering (unless the loaded JS is DOM-manipulating) does it ?
wraptile 4y ago
> jQuery is largely not needed since Internet Explorer lost market share and there's less of a need to have lots of workarounds for it. As someone who's late to the webdev party I feel that jQuery is pretty awesome (all I ever heard is people poopoo it). The vanilla API for the DOM manipulation is just plainly awful and borderline nonsensical so I'd say jQuery is still very much needed.
- djitz 4y ago
  jQuery and the many plug-ins people wrote for it were amazing. What was not amazing was the manner in which many projects utilized them.
- NohatCoder 4y ago
  This is probably the biggest hole in vanilla js. In particular building a large DOM structure requires so many method calls. jQuery lets one use an innerHTML-ish style, but it is supposedly guarding against injection attacks in some way. I don't like the hand-wavy way it claims to guard against injections, as basically it has no way to tell what part of a string was meant to be text, and what was meant to be elements. So I ended up coding my own library. No conversion of strings to elements, so naturally no injections. Very small and simple. But saves a ton of typing when generating DOM structures in JavaScript: https://github.com/NoHatCoder/DOM_Maker https://github.com/NoHatCoder/DOM_Maker
- dspillett 4y ago
  If you are mainly using jquery for its DOM manipulation¹ rather than for browser compatibility² or things that didn't exist consistently in older browsers³ then there are much smaller libraries that do that job which may be worth looking into. https://github.com/fabiospampinato/cash https://github.com/fabiospampinato/cash or https://github.com/franciscop/umbrella https://github.com/franciscop/umbrella to give a couple of examples. Some explicitly support IE11 so you are not dropping as much support for legacy browsers as you might otherwise. Though if jQuery works for you and isn't a performance issue, then by all means keep with it. It may not be ideal, but good enough and does the job. Let the naysayers spend their time debating whether you should or not, and just get on with making things! --- [1] selection engine, chained selections, chained modifications, … [2] not the issue it once was, if you can abandon IE and old Android browsers from your supported UAs or can deal with any issues that crop up individually [3] again, if you can afford to drop support for legacy UAs

by iopq 4y ago

3np 4y ago

If done properly this can be nice but a common grief is when interactive elements (input fields/buttons/links, including in flowing text) move around after first becoming visible. The worst is input fields that get cleared or grabbing focus (this is way too common; not stellar to have to password reset due to typing half a password in an auto-complete search field) as part of this process after the user has already started inputting data.

867-5309 4y ago
it also negatively affects anchor links, e.g. example.com/#contact will not always jump to the contact section with lazy loading
marcus_holmes 4y ago
this is so infuriating when it happens and I click the wrong thing because between the time I saw the button and pushed the button, the button moved away and another button moved under my finger/cursor. I would massively prefer to have a blank page, or a page with no buttons, and wait a few seconds for the buttons to appear in their final locations, than this.

wildrhythms 4y ago

You have to really do some extra work to make this happen "nicely". Swapping out parts of the page without jerking the user around is a difficult problem, especially if you aren't working with fixed sizes of elements. And creating a "skeleton" system of placeholders during loading is a whole other set of state you have to build out and maintain. I find most sites using this kind of progressive loading are completely useless during the loading phase... What's the point of showing the user a page full of skeleton/loading placeholders? You might as well have just server-rendered the whole thing and made the user wait an extra second or two.

Dalewyn 4y ago
I remember how it was good practice to assign width and height to <img> tags. The idea being the browser would know how to render the things around the picture without needing to download the picture first, preventing the page from jumping around as the quicker and lighter HTML was downloaded and rendered first.
- chrisweekly 4y ago
  That still is a best practice. That "jumping around" is now referred to as "CLS" -- Cumulative Layout Shift -- one of the "Core Web Vitals" metrics used to quantify performance-related UX.
  - teknopaul 4y ago
    I sometmes like CLS, it makes it look like things are happening instead of feeling like a wait time. I recently used a simple templating mechanism elem = jquery.clone() ... elem.slideDown() And this renders bits of the page moving them as it does it; slideDown() is in jquery core. It used to be popular before that biz of rendering grey squares first got invented
    - tryfinally 4y ago
      Layout shift feels fairly terrible when you're navigating to an element that is at the bottom of the page (via #id) or simply refreshing the page. There is literally nothing more annoying than clicking the wrong link because the layout shifted under the cursor at just the wrong moment. CLS is also known as "jank" for a reason.
- christophilus 4y ago
  I use aspect ratio for this now that it's supported in CSS. It might be my favorite CSS feature since flex.
Banana699 4y ago
GP was talking about loading JS, adding JS to a webpage doesn't affect its rendering (unless the loaded JS is DOM-manipulating) does it ?

wraptile 4y ago

> jQuery is largely not needed since Internet Explorer lost market share and there's less of a need to have lots of workarounds for it. As someone who's late to the webdev party I feel that jQuery is pretty awesome (all I ever heard is people poopoo it). The vanilla API for the DOM manipulation is just plainly awful and borderline nonsensical so I'd say jQuery is still very much needed.

djitz 4y ago
jQuery and the many plug-ins people wrote for it were amazing. What was not amazing was the manner in which many projects utilized them.
NohatCoder 4y ago
This is probably the biggest hole in vanilla js. In particular building a large DOM structure requires so many method calls. jQuery lets one use an innerHTML-ish style, but it is supposedly guarding against injection attacks in some way. I don't like the hand-wavy way it claims to guard against injections, as basically it has no way to tell what part of a string was meant to be text, and what was meant to be elements. So I ended up coding my own library. No conversion of strings to elements, so naturally no injections. Very small and simple. But saves a ton of typing when generating DOM structures in JavaScript: https://github.com/NoHatCoder/DOM_Maker https://github.com/NoHatCoder/DOM_Maker
dspillett 4y ago
If you are mainly using jquery for its DOM manipulation¹ rather than for browser compatibility² or things that didn't exist consistently in older browsers³ then there are much smaller libraries that do that job which may be worth looking into. https://github.com/fabiospampinato/cash https://github.com/fabiospampinato/cash or https://github.com/franciscop/umbrella https://github.com/franciscop/umbrella to give a couple of examples. Some explicitly support IE11 so you are not dropping as much support for legacy browsers as you might otherwise. Though if jQuery works for you and isn't a performance issue, then by all means keep with it. It may not be ideal, but good enough and does the job. Let the naysayers spend their time debating whether you should or not, and just get on with making things! --- [1] selection engine, chained selections, chained modifications, … [2] not the issue it once was, if you can abandon IE and old Android browsers from your supported UAs or can deal with any issues that crop up individually [3] again, if you can afford to drop support for legacy UAs