3 ms·

> Am I missing something Yes. - navigating to a new page triggers a page reload - a page reload tears down the page context - the new page must be loaded fr

> Am I missing something Yes. - navigating to a new page triggers a page reload - a page reload tears down the page context - the new page must be loaded from scratch, a new context set up, JavaScript started from scratch, and the page parsed and executed Even if the resources between the two pages are shared and those shared resources properly cached, time is lost relative to the more instantaneous process of making partial edits to an already loaded page and only loading the JavaScript necessary to pull in features that weren't on the page navigated away from. I recommend popping the browser inspector open when using AWS console or Google Cloud console and look at what's going over the wire. As the user navigates around, these web apps are only loading the chunks of the interface necessary, not the Chrome or the sidebar or any of those other already-loaded components. Those components are already live in the JavaScript context and don't need to be rebuilt from scratch because they weren't destroyed, since no page navigation occurred. You can make the case that those consoles are over complicated and could be replaced with a handful of web forms (not by comparing them to hacker news, the relative complexity of the pages are apples to oranges... If I were to make the case, I would make it by saying that the Google app engine console that predated Google Cloud console was perfectly serviceable, clunky and slow as it was). But given that they are what they are, the dynamic loading is much faster than tearing down and building new pages as a user navigates around the panels in the console. And given the way they work, the user expects the back button to go to the previous panel, not to navigate completely out of the web app because they happened to enter the experience from a specific URL.

Dylan16807 4y ago
And it can be as simple as clicking on an image to expand it, like on twitter. It's nice to be able to hit back to close it, especially on phone browsers. And it's also nice to stay on the same page context the entire time, so it can respond much faster and doesn't screw up the scrolling.
ysavir 4y ago
> Even if the resources between the two pages are shared and those shared resources properly cached, time is lost relative to the more instantaneous process of making partial edits to an already loaded page and only loading the JavaScript necessary to pull in features that weren't on the page navigated away from Technically, yes. Whether it's significant difference is reflective of the engineering, and sometimes, on the product design. And the beauty of not using JS navigation is that you don't need to draw the page using JS templates. The dynamic data, sure, but the rest can load pretty instantaneously. Out of curiosity, when's the last time you built a web app that doesn't rely on JS navigation, and architected it with that in mind? What was that experience like, and how does it compare to your JS experiences?
- shadowgovt 4y ago
  It was Ruby on Rails, it was forms-based, and it was hell. To personal taste these days, I much prefer writing a heavyweight client and a thin server that emits raw data and does very little HTML rendering or HTML pre-processing to the alternatives I tried before. But even if the server is doing a lot of heavy lifting, the end user experience can benefit both in performance and bandwidth from minimizing page reloads. There's some pretty spiffy client and server template technologies now that let you get pretty close to write once, render on either the client or the server depending on which is cheaper. And there are other applications for which manipulating history is a better fit. Otherwise, how would you mail history into a web experience that doesn't match very well to page navigation at all, like a WebVR walk where you want to be able to return to a location via URL, or a music player where you want the history to go back and forth between the songs you played?

Dylan16807 4y ago

And it can be as simple as clicking on an image to expand it, like on twitter. It's nice to be able to hit back to close it, especially on phone browsers. And it's also nice to stay on the same page context the entire time, so it can respond much faster and doesn't screw up the scrolling.

ysavir 4y ago

> Even if the resources between the two pages are shared and those shared resources properly cached, time is lost relative to the more instantaneous process of making partial edits to an already loaded page and only loading the JavaScript necessary to pull in features that weren't on the page navigated away from Technically, yes. Whether it's significant difference is reflective of the engineering, and sometimes, on the product design. And the beauty of not using JS navigation is that you don't need to draw the page using JS templates. The dynamic data, sure, but the rest can load pretty instantaneously. Out of curiosity, when's the last time you built a web app that doesn't rely on JS navigation, and architected it with that in mind? What was that experience like, and how does it compare to your JS experiences?

shadowgovt 4y ago
It was Ruby on Rails, it was forms-based, and it was hell. To personal taste these days, I much prefer writing a heavyweight client and a thin server that emits raw data and does very little HTML rendering or HTML pre-processing to the alternatives I tried before. But even if the server is doing a lot of heavy lifting, the end user experience can benefit both in performance and bandwidth from minimizing page reloads. There's some pretty spiffy client and server template technologies now that let you get pretty close to write once, render on either the client or the server depending on which is cheaper. And there are other applications for which manipulating history is a better fit. Otherwise, how would you mail history into a web experience that doesn't match very well to page navigation at all, like a WebVR walk where you want to be able to return to a location via URL, or a music player where you want the history to go back and forth between the songs you played?