3 ms·

"You don't have to download all the content again" is also true if you version your assets and use a CDN with far-future expiry headers. If you need an HTTP co

"You don't have to download all the content again" is also true if you version your assets and use a CDN with far-future expiry headers. If you need an HTTP connection to download a section of HTML for a new part of an SPA it won't be that much different from a full page of HTML, presuming you compress the transfer as you should. "Of course shitty implementations exist" is true of a non-SPA setup too.

daxterspeed 7y ago
While it's true that the browser won't have to download the content again, it will have to re-instantiate various resources (eg execute all JavaScript over again..., restart gifs). If implemented correctly, JavaScript navigation should seamlessly appear like normal navigation. Not supporting streamed requests is a serious drawback. Of course browsers have actually gotten pretty good at AJAX-like loading instead of completely re-rendering the page. These systems tend to rely on heuristics though, and I don't think there's any documentation for these, but even when these fail the browser tend to be more competent than even the best JavaScript solutions.
- frereubu 7y ago
  I think there are good use-cases for SPAs (Google Maps, for example), but the majority of cases that I've seen aren't good ones, and the extra complexity involved in managing state etc. far outweighs any marginal gains in not re-instantiating JS.
- zonidjan 7y ago
  > While it's true that the browser won't have to download the content again, it will have to re-instantiate various resources (eg execute all JavaScript over again..., restart gifs). Your JavaScript shouldn't be blocking page load anyway. Defer, defer, defer.
- manigandham 7y ago
  JS is cached in its compiled state in modern browsers. There is no download or parsing step for repeated loads.
  - bryanrasmussen 7y ago
    without a unique key in the js name/path, or any server action to enable it? If so I would like to read about this particular development - can you point me to an article on how they're doing it?
    - manigandham 7y ago
      Yes, Chrome uses V8 which has Isolates (also used by some FaaS platforms like Cloudflare Workers), and adds more optimizations on top like disk-based caching to share across processes. The script is keyed from a hash of its contents. https://v8.dev/blog/code-caching-for-devs https://v8.dev/blog/code-caching-for-devs
      - bryanrasmussen 7y ago
        Thanks! I guess will have to see if FF and Safari support same thing. Perhaps in another year can remove cache busting from builds.
        manigandham 7y ago
        They do, it's linked in the blog: https://blog.mozilla.org/javascript/2017/12/12/javascript-startup-bytecode-cache/ https://blog.mozilla.org/javascript/2017/12/12/javascript-st... https://bugs.webkit.org/show_bug.cgi?id=192782 https://bugs.webkit.org/show_bug.cgi?id=192782 Also did you mean http caching? Not sure why would want to remove that. It's still important for the browser to get the latest script content before the bytecode caching happens.
      - gray_-_wolf 7y ago
        How can the download step be skipped then if you are using the hash of the content as a key??
        manigandham 7y ago
        That's what HTTP caching is. Browsers use headers and heuristics.
kowdermeister 7y ago
What if there's no content to download? The client could have the same algorithm that the server could render. For example create a melody with seed: 4564342 The client can render it and if you access it from the server the server does the rendering with the same seed. Caches also exists, now with PWA-s offline modes would benefit from the History API.

daxterspeed 7y ago

While it's true that the browser won't have to download the content again, it will have to re-instantiate various resources (eg execute all JavaScript over again..., restart gifs). If implemented correctly, JavaScript navigation should seamlessly appear like normal navigation. Not supporting streamed requests is a serious drawback. Of course browsers have actually gotten pretty good at AJAX-like loading instead of completely re-rendering the page. These systems tend to rely on heuristics though, and I don't think there's any documentation for these, but even when these fail the browser tend to be more competent than even the best JavaScript solutions.

frereubu 7y ago
I think there are good use-cases for SPAs (Google Maps, for example), but the majority of cases that I've seen aren't good ones, and the extra complexity involved in managing state etc. far outweighs any marginal gains in not re-instantiating JS.
zonidjan 7y ago
> While it's true that the browser won't have to download the content again, it will have to re-instantiate various resources (eg execute all JavaScript over again..., restart gifs). Your JavaScript shouldn't be blocking page load anyway. Defer, defer, defer.
manigandham 7y ago
JS is cached in its compiled state in modern browsers. There is no download or parsing step for repeated loads.
- bryanrasmussen 7y ago
  without a unique key in the js name/path, or any server action to enable it? If so I would like to read about this particular development - can you point me to an article on how they're doing it?
  - manigandham 7y ago
    Yes, Chrome uses V8 which has Isolates (also used by some FaaS platforms like Cloudflare Workers), and adds more optimizations on top like disk-based caching to share across processes. The script is keyed from a hash of its contents. https://v8.dev/blog/code-caching-for-devs https://v8.dev/blog/code-caching-for-devs
    - bryanrasmussen 7y ago
      Thanks! I guess will have to see if FF and Safari support same thing. Perhaps in another year can remove cache busting from builds.
      - manigandham 7y ago
        They do, it's linked in the blog: https://blog.mozilla.org/javascript/2017/12/12/javascript-startup-bytecode-cache/ https://blog.mozilla.org/javascript/2017/12/12/javascript-st... https://bugs.webkit.org/show_bug.cgi?id=192782 https://bugs.webkit.org/show_bug.cgi?id=192782 Also did you mean http caching? Not sure why would want to remove that. It's still important for the browser to get the latest script content before the bytecode caching happens.
    - gray_-_wolf 7y ago
      How can the download step be skipped then if you are using the hash of the content as a key??
      - manigandham 7y ago
        That's what HTTP caching is. Browsers use headers and heuristics.

kowdermeister 7y ago

What if there's no content to download? The client could have the same algorithm that the server could render. For example create a melody with seed: 4564342 The client can render it and if you access it from the server the server does the rendering with the same seed. Caches also exists, now with PWA-s offline modes would benefit from the History API.