Great question, a lot of people ask that. The server can keep track of what are common bahaviors users do on site and than can add a pre-fetch command to sart downloading (but not executing) the JS before you need it based on what the user is most likely to interact with.
That implies, if some users do the uncommon behaviors (something not predicted by the server), then such users would experience the website to be slower. Am I right?
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
Sounds like an interesting way to account for this, I obviously only grasp the concept at the moment so maybe I haven't quite got it based on just a simple todo list but what happens with a complex application?
If you preload say 50+ tiny JS snippets that is just going to clog even a preload strategy up?
Also look forward to seeing what a server considers "most likely" to be interacted with as that feels like something that is prone to issues.
On that line of thought one last question is if I interact with something and the script hasn't arrived yet for whatever reason, does it remember the command I entered ready for when the script is available or is that action just lost?
Prime example would be a spotty connection, I scroll the page to a contact form, start filling my name in but the validation is still lost in the ether, then I move to the next field and the validation finally loads in, will it suddenly validate the field I have just left? Would the developer have to account for this in the way they develop code (by not using .blur() etc.)
Like I said it is a really interesting concept (and the fact it focuses on HTML first is a big plus in my book) but I am just trying to understand how the "streaming JS" side of it works (for want of a better term for it!).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great question, a lot of people ask that. The server can keep track of what are common bahaviors users do on site and than can add a pre-fetch command to sart downloading (but not executing) the JS before you need it based on what the user is most likely to interact with.
That implies, if some users do the uncommon behaviors (something not predicted by the server), then such users would experience the website to be slower. Am I right?
Sounds like an interesting way to account for this, I obviously only grasp the concept at the moment so maybe I haven't quite got it based on just a simple todo list but what happens with a complex application?
If you preload say 50+ tiny JS snippets that is just going to clog even a preload strategy up?
Also look forward to seeing what a server considers "most likely" to be interacted with as that feels like something that is prone to issues.
On that line of thought one last question is if I interact with something and the script hasn't arrived yet for whatever reason, does it remember the command I entered ready for when the script is available or is that action just lost?
Prime example would be a spotty connection, I scroll the page to a contact form, start filling my name in but the validation is still lost in the ether, then I move to the next field and the validation finally loads in, will it suddenly validate the field I have just left? Would the developer have to account for this in the way they develop code (by not using
.blur()etc.)Like I said it is a really interesting concept (and the fact it focuses on HTML first is a big plus in my book) but I am just trying to understand how the "streaming JS" side of it works (for want of a better term for it!).