5 ms·

> Today's web isn't slow because of HTML's features, shortcomings, or other properties; it's slow because of excessive reliance on client-side scripting [...] T

> Today's web isn't slow because of HTML's features, shortcomings, or other properties; it's slow because of excessive reliance on client-side scripting [...] Turning off Javascript vastly improves pageloads Sure, disabling JavaScript will improve pageloads. However, are you suggesting clicking a link and waiting for an entirely new page to load is good UX? Good UX is instantaneous feedback, client-side code is a requirement... Unless you want some kind of enormous super-spec that is supposed to encompass anything anyone could ever wish to express in pure markup. In which case, good luck getting that supported and rendering quickly. The whole point of JavaScript (or any client side code, including mobile apps) is that it vastly improves UX.

Alphasite_ 10y ago
If it loads quickly, why not? My connection is a sub 3ms ping to the nearby datacenters, what exactly is the bottleneck? It's not to say there isn't a place for SPAs but I would argue many of these would be better suited to being full fledged desktop apps instead (better performance and snative integration).
- Benjamin_Dobell 10y ago
  Okay, for you there's no bottleneck, just woeful UI/UX. Seriously, seeing just one stateful element at a time, then pressing "Next". Wow, just wow. I fully expect that when I type the first few digits of my credit card number that the site knows precisely which card provider I'm supplying and updates the UI (highlight the card type) accordingly and immediately update the security code field to request my 3-digit MasterCard CCV vs. a 4-digit AMEX CID. To be clear, I'm not suggesting code needs to run on a client. One day when we all have fast enough connections (with minimal latency), including on mobile network, then perhaps all the code can run server-side and we just be streamed the output (video) - which again, updates in real-time! However, living in the real world as it stands today, client-side scripting is a fantastic solution to a real-world problem i.e. latency and bandwidth constraints, and real-time responsive UIs.
- tlrobinson 10y ago
  > My connection is a sub 3ms ping to the nearby datacenters, what exactly is the bottleneck? Heh, tell that to someone in, say, Australia.
detaro 10y ago
For many pages, loading an entirely new page is perfectly fine UX, and way better UX if the alternative is dynamic loading and all kind of performance-eating ad scripts, scroll hijackers, ... If your site is a traditional content-heavy website, you need to load a full page of content with both ways, it doesn't matter that much if you are loading the skeleton around it or not, and there is way less chance of accidentally breaking something. I don't need instantaneous feedback that you have begun to squeeze content through the pipe (if I'm on mobile the content will take time to load anyways, on a wired connection you can deliver a full page quickly enough) Sure, real "apps" are a different thing, but they are not the ones people typically complain about being overloaded with scripts.
- zyxley 10y ago
  I have to wonder what it would be like if, instead of reinventing the page load process using Javascript frameworks, the web had gone in the direction of increasingly refined frameset functionality.
  - flukus 10y ago
    HTML5 sections are very similar to how frames were used. The biggest problems with frames were individual scrolling and opening in anew tab would lose context, both of which are solvable.
pjmlp 10y ago
On my case I wanted it to have stayed as plain interactive documents. I contribute to this goal by only allowing native applications on my devices, unless I don't have any good alternative to switch to.
niftich 10y ago
You raise some good points. Within the same website, loading a different server-generated full page will typically load many of the same assets like CSS, and header images, which will remain cached by the client for subsequent loads. It's true that some markup framing the content is duplicated; incidentally in the olden days we used <frame> tags to separate a site-global navigation from the page-specific content, but that went out of style -- it had URL addressability drawbacks and no convention ever developed to fix it. But ultimately the client needs to render the View, while the server (at some point presumably) originates the Model. Somehow you have to turn the M into the V, and there have been hundreds of different takes over the last couple decades on how exactly to accomplish this. Classically, every HTML page was the complete view, but then the DOM API was introduced to allow this view to be mutated imperatively after the View has been rendered. The main innovation of client-side scripting was Ajax, which was explicitly about lazy- and/or continuous loading of small snippets of innercontent, like a single Tweet or a couple Google Maps tiles. This emboldened some to push more and more state onto the client, and now we have entire frameworks that do MVC or MVVM in (client-side) Javascript. If we had a way besides the DOM API to morph one state of the View to another; say, a declarative HTML-diff, or, something like XSLT or JSON-patch, I'm sure people would take it. If this sounds a lot like Virtual DOM, it's because they solve the same problem.
catdog 10y ago
> Sure, disabling JavaScript will improve pageloads. However, are you suggesting clicking a link and waiting for an entirely new page to load is good UX? If done right there is not much wasted and there is not much to wait for as most of the things which are not new already are cached. Most of the time such slowness results from unnecessary bloat or slow code on the server side. > The whole point of JavaScript (or any client side code, including mobile apps) is that it vastly improves UX. In practice it worsens UX more often than not.
ksk 10y ago
> However, are you suggesting clicking a link and waiting for an entirely new page to load is good UX? Maybe they aren't saying that, but sure I'll bite. Why wouldn't it be good UX? I would challenge anyone to argue that non-JS/static UIs are anything but simple, intuitive and easily teachable. I have had the displeasure of repeatedly having to explain to family/relatives, how to use these "modern" UIs to the point where I'm fairly convinced that none of them have any utility, as far as UX is concerned.

Alphasite_ 10y ago

If it loads quickly, why not? My connection is a sub 3ms ping to the nearby datacenters, what exactly is the bottleneck? It's not to say there isn't a place for SPAs but I would argue many of these would be better suited to being full fledged desktop apps instead (better performance and snative integration).

Benjamin_Dobell 10y ago
Okay, for you there's no bottleneck, just woeful UI/UX. Seriously, seeing just one stateful element at a time, then pressing "Next". Wow, just wow. I fully expect that when I type the first few digits of my credit card number that the site knows precisely which card provider I'm supplying and updates the UI (highlight the card type) accordingly and immediately update the security code field to request my 3-digit MasterCard CCV vs. a 4-digit AMEX CID. To be clear, I'm not suggesting code needs to run on a client. One day when we all have fast enough connections (with minimal latency), including on mobile network, then perhaps all the code can run server-side and we just be streamed the output (video) - which again, updates in real-time! However, living in the real world as it stands today, client-side scripting is a fantastic solution to a real-world problem i.e. latency and bandwidth constraints, and real-time responsive UIs.
tlrobinson 10y ago
> My connection is a sub 3ms ping to the nearby datacenters, what exactly is the bottleneck? Heh, tell that to someone in, say, Australia.

detaro 10y ago

For many pages, loading an entirely new page is perfectly fine UX, and way better UX if the alternative is dynamic loading and all kind of performance-eating ad scripts, scroll hijackers, ... If your site is a traditional content-heavy website, you need to load a full page of content with both ways, it doesn't matter that much if you are loading the skeleton around it or not, and there is way less chance of accidentally breaking something. I don't need instantaneous feedback that you have begun to squeeze content through the pipe (if I'm on mobile the content will take time to load anyways, on a wired connection you can deliver a full page quickly enough) Sure, real "apps" are a different thing, but they are not the ones people typically complain about being overloaded with scripts.

zyxley 10y ago
I have to wonder what it would be like if, instead of reinventing the page load process using Javascript frameworks, the web had gone in the direction of increasingly refined frameset functionality.
- flukus 10y ago
  HTML5 sections are very similar to how frames were used. The biggest problems with frames were individual scrolling and opening in anew tab would lose context, both of which are solvable.

pjmlp 10y ago

On my case I wanted it to have stayed as plain interactive documents. I contribute to this goal by only allowing native applications on my devices, unless I don't have any good alternative to switch to.

niftich 10y ago

You raise some good points. Within the same website, loading a different server-generated full page will typically load many of the same assets like CSS, and header images, which will remain cached by the client for subsequent loads. It's true that some markup framing the content is duplicated; incidentally in the olden days we used <frame> tags to separate a site-global navigation from the page-specific content, but that went out of style -- it had URL addressability drawbacks and no convention ever developed to fix it. But ultimately the client needs to render the View, while the server (at some point presumably) originates the Model. Somehow you have to turn the M into the V, and there have been hundreds of different takes over the last couple decades on how exactly to accomplish this. Classically, every HTML page was the complete view, but then the DOM API was introduced to allow this view to be mutated imperatively after the View has been rendered. The main innovation of client-side scripting was Ajax, which was explicitly about lazy- and/or continuous loading of small snippets of innercontent, like a single Tweet or a couple Google Maps tiles. This emboldened some to push more and more state onto the client, and now we have entire frameworks that do MVC or MVVM in (client-side) Javascript. If we had a way besides the DOM API to morph one state of the View to another; say, a declarative HTML-diff, or, something like XSLT or JSON-patch, I'm sure people would take it. If this sounds a lot like Virtual DOM, it's because they solve the same problem.

catdog 10y ago

> Sure, disabling JavaScript will improve pageloads. However, are you suggesting clicking a link and waiting for an entirely new page to load is good UX? If done right there is not much wasted and there is not much to wait for as most of the things which are not new already are cached. Most of the time such slowness results from unnecessary bloat or slow code on the server side. > The whole point of JavaScript (or any client side code, including mobile apps) is that it vastly improves UX. In practice it worsens UX more often than not.

ksk 10y ago

> However, are you suggesting clicking a link and waiting for an entirely new page to load is good UX? Maybe they aren't saying that, but sure I'll bite. Why wouldn't it be good UX? I would challenge anyone to argue that non-JS/static UIs are anything but simple, intuitive and easily teachable. I have had the displeasure of repeatedly having to explain to family/relatives, how to use these "modern" UIs to the point where I'm fairly convinced that none of them have any utility, as far as UX is concerned.