4 ms·

I feel like the whole article misses the point. Yes, the rendering delay caused by a non-streaming HTML parser exists, but unless you screw things up elsewhere

I feel like the whole article misses the point. Yes, the rendering delay caused by a non-streaming HTML parser exists, but unless you screw things up elsewhere, that's going to be less than 1ms of delay. Yes, bloated frameworks are annoying, but not due to their computational overhead per se, but because they increase download size and because Javascript is slower then native code in general. I find it very telling that this article doesn't mention network latency even once. Those 50ms to 100ms round-trip time between the user and the server, that's what is causing most of the visible delays. Ship your users an app including a copy of the data ahead of time, and you have no visible delays. It's as easy as that :) And before you criticise that this won't work for every use case, consider that IMAP is basically an offline-capable newsfeed. Also, I can buy a DVD with a directory of all US businesses. The only reason why Facebook and Yelp work the way they do is because otherwise they would have to give up on some of the tracking. Because for some reason, people are more tolerant towards privacy invasive tracking if it's a "web app" instead of a native app.

gabipurcaru 6y ago
> Ship your users an app including a copy of the data ahead of time I did exactly that with a hobby project (https://www.acceleratul.ro/ https://www.acceleratul.ro/). The funny thing is that I had to add a short (~50ms) artificial delay with a spinner before showing search results, because people completely missed the fact that the page had refreshed
- modeless 6y ago
  Yeah, I did the same with https://james.darpinian.com/decoder/ https://james.darpinian.com/decoder/. It's an underused technique for sure. It's enraging when I have to repeatedly wait multiple seconds to load a bloated results page containing 10 additional rows from a database query (e.g. paginated product listings) when I could have easily downloaded the complete query results or even the entire database in less time.
- tartoran 6y ago
  Nice helpful project, I think I may have used it once while in Romania. Yeah, for small static data it absolutely makes sense to embed it in the app itself. But imagine your app was world wide or it needed to account for dynamic data, not sure it would make sense to ship a few dozen MBs all at once.
- victor106 6y ago
  This is cool. What techniques did you use to include a copy of the data?
  - gabipurcaru 6y ago
    it's just a bunch of JSON bundled inside the rest of the JS assets with webpack
  - nexuist 6y ago
    I believe this entire technique is known as SSR - Server-Side Rendering. It's built in to Vue and React and you can find examples on their respective sites.
    - asddubs 6y ago
      that's confusing, I've only ever heard SSR/server side rendering to mean actually rendering html and serving that, as opposed to SPAs
      - nexuist 6y ago
        Well, the idea is that you render the first pass of the SPA and serve that HTML to the client. Rather than just injecting the data into the SPA source code, you inject the data and render the page, and then serve that page. Then whatever changes the user makes to the page after that initial load gets handled by the SPA. This way the user avoids having to wait for the SPA and all its dependencies to load before the page can even appear, and the developer doesn't have to differentiate between what happens on the client side and server side (remember using PHP to inject variables into JS source code?) because they can just bake it into their SPA.
        asddubs 6y ago
        that's pretty neat, I didn't know that react could do that. Shame no one ever seems to make use of it
nyanpasu64 6y ago
In single-page apps, navigating between pages is hard to get right. https://vector-of-bool.github.io/ https://vector-of-bool.github.io/ implements its own JavaScript-powered page turning. However if you press End on a long page, then navigate to a short page and back to the long page, the browser's scroll position gets truncated. In the "Instant Multi-Page App", navigating between pages "just works".
simonw 6y ago
"unless you screw things up elsewhere, that's going to be less than 1ms of delay" Are you using an iPhone? In my experience SPA performance falls apart on cheaper Android devices, which are far more common among regular users but tend not to be in the pockets of developers, who spend way more money on their devices.
- nexuist 6y ago
  I think the question is whether developers actually care if users with cheap devices can't use their SPAs. If you're trying to sell them something, you probably want customers with deep enough pockets to afford a somewhat modern phone. If you don't want to sell them something and you just want to provide information (e.g. restaurant website, digital flyer, event RSVP, etc) you could serve a simple static page, or forego the website entirely and post your information on social media which can then be consumed by optimized native apps. If you don't want to sell them something and you don't want to tell them something, why are you building a complex SPA at all?
  - rob74 6y ago
    > forego the website entirely and post your information on social media which can then be consumed by optimized native apps ...and force the user to install the "optimized native app" for the social media site du jour? Or simply let them put up with Facebook's "yes-this-is-a-public-page-but-I'm-still-going-to-ask-you-to-log-in-or-sign-up-just-because-I-can" shenanigans? Great UX, that!
    - auggierose 6y ago
      Cheap phone, cheap UX?
    - nexuist 6y ago
      Are we really going to assume that your average user doesn't already have FB installed and already signed in? They have over one billion users, you know. It's not exactly rare to find Facebook on any arbitrary person's device.
lhorie 6y ago
> that's going to be less than 1ms of delay That doesn't jive with my experience. If you are using something like React to do client-only rendering, you're gonna be waiting a lot for blocking critical path JS to run, as well as the actual paint time (which alone can easily be in the hundreds of milliseconds). > Ship your users an app including a copy of the data ahead of time That's not really feasible though, is it? Most SPAs in the wild fetch data on demand, so you still get the network latency no matter what (on top of the delay due to no streaming each time). This is why you get those skeleton placeholders on sites like Facebook.
- nawgz 6y ago
  >which alone can easily be in the hundreds of milliseconds This actual paint time is surely not any different than if you rendered the exact same application from pre-hydrated HTML though. Plus, if your application is so complex that paints are on the order of magnitude of network latency, it's probably very important to have a framework to handle interactivity, else everything will end up as some kind of a mess if you try to re-load the whole HTML page to change some small DOM subtree. Overall, I don't really see the situation where an SPA is performing worse than a server-rendered application, given that some in-browser interactivity is required.
  - lhorie 6y ago
    > This actual paint time is surely not any different than if you rendered the exact same application from pre-hydrated HTML though. Well, it's different in different ways, depending on which goalpost you're standing on. If by that you mean do SSR, then run React on top, then you've just incurred the same TTFP as plain HTML, plus the cost of React hydration, plus potentially a second repaint (or even third and fourth repaints, depending on how your data trickles in). In the wild, this pattern gets particularly egregious when people decide that it's ok to have loading icons and widgets pushing each other down as data comes in. If you mean to compare to client-side rendering without SSR, then you're still looking at the cost of at least two repaints (the initial TTFP repaint, plus any repaints from data fetching after that).
deleted 6y ago
[deleted]
qpiox 6y ago
Misses the point on so many levels. Fastest experience will always be without a special framework. Fastest will always be if there is nothing except the content served in a single minimal request/response. So, this means no JS (excepct issuing requests), no browser framework, pure content. Browser sends the simplest request and receives simplest content. User reads it or looks at it. Fast as hell. It can't be faster than that because JPG can not be compressed further, gzipped HTML can not be compressed further. With later HTTP implementations, the connection can already be open and re-used. To explain this with an analogy. Bloatware comes when you decide that your true content is not enough to be appreciated as is, and needs to be beautified, made interactive, .... Just like make-up. Without make-up you only need to show your face. When you decide to use make-up to cover the true content (your true face), you need huge ammount of overhead - you need to buy the make-up, you need to learn how to apply the make-up, clean the make-up, re-apply the make-up. You need robust make-up. You need waterproof make-up. Then you need special cleaner because water will not be able to clean it. Then you start needing a make-up framework, to help you clean, apply and re-apply the make-up consistently and easily. So reinventing make-up frameworks will do nothing in alleviating overhead. Dropping the framework is the best way to go. I hope this analogy makes things clear what I meant.

gabipurcaru 6y ago

> Ship your users an app including a copy of the data ahead of time I did exactly that with a hobby project (https://www.acceleratul.ro/ https://www.acceleratul.ro/). The funny thing is that I had to add a short (~50ms) artificial delay with a spinner before showing search results, because people completely missed the fact that the page had refreshed

modeless 6y ago
Yeah, I did the same with https://james.darpinian.com/decoder/ https://james.darpinian.com/decoder/. It's an underused technique for sure. It's enraging when I have to repeatedly wait multiple seconds to load a bloated results page containing 10 additional rows from a database query (e.g. paginated product listings) when I could have easily downloaded the complete query results or even the entire database in less time.
tartoran 6y ago
Nice helpful project, I think I may have used it once while in Romania. Yeah, for small static data it absolutely makes sense to embed it in the app itself. But imagine your app was world wide or it needed to account for dynamic data, not sure it would make sense to ship a few dozen MBs all at once.
victor106 6y ago
This is cool. What techniques did you use to include a copy of the data?
- gabipurcaru 6y ago
  it's just a bunch of JSON bundled inside the rest of the JS assets with webpack
- nexuist 6y ago
  I believe this entire technique is known as SSR - Server-Side Rendering. It's built in to Vue and React and you can find examples on their respective sites.
  - asddubs 6y ago
    that's confusing, I've only ever heard SSR/server side rendering to mean actually rendering html and serving that, as opposed to SPAs
    - nexuist 6y ago
      Well, the idea is that you render the first pass of the SPA and serve that HTML to the client. Rather than just injecting the data into the SPA source code, you inject the data and render the page, and then serve that page. Then whatever changes the user makes to the page after that initial load gets handled by the SPA. This way the user avoids having to wait for the SPA and all its dependencies to load before the page can even appear, and the developer doesn't have to differentiate between what happens on the client side and server side (remember using PHP to inject variables into JS source code?) because they can just bake it into their SPA.
      - asddubs 6y ago
        that's pretty neat, I didn't know that react could do that. Shame no one ever seems to make use of it

nyanpasu64 6y ago

In single-page apps, navigating between pages is hard to get right. https://vector-of-bool.github.io/ https://vector-of-bool.github.io/ implements its own JavaScript-powered page turning. However if you press End on a long page, then navigate to a short page and back to the long page, the browser's scroll position gets truncated. In the "Instant Multi-Page App", navigating between pages "just works".

simonw 6y ago

"unless you screw things up elsewhere, that's going to be less than 1ms of delay" Are you using an iPhone? In my experience SPA performance falls apart on cheaper Android devices, which are far more common among regular users but tend not to be in the pockets of developers, who spend way more money on their devices.

nexuist 6y ago
I think the question is whether developers actually care if users with cheap devices can't use their SPAs. If you're trying to sell them something, you probably want customers with deep enough pockets to afford a somewhat modern phone. If you don't want to sell them something and you just want to provide information (e.g. restaurant website, digital flyer, event RSVP, etc) you could serve a simple static page, or forego the website entirely and post your information on social media which can then be consumed by optimized native apps. If you don't want to sell them something and you don't want to tell them something, why are you building a complex SPA at all?
- rob74 6y ago
  > forego the website entirely and post your information on social media which can then be consumed by optimized native apps ...and force the user to install the "optimized native app" for the social media site du jour? Or simply let them put up with Facebook's "yes-this-is-a-public-page-but-I'm-still-going-to-ask-you-to-log-in-or-sign-up-just-because-I-can" shenanigans? Great UX, that!
  - auggierose 6y ago
    Cheap phone, cheap UX?
  - nexuist 6y ago
    Are we really going to assume that your average user doesn't already have FB installed and already signed in? They have over one billion users, you know. It's not exactly rare to find Facebook on any arbitrary person's device.

lhorie 6y ago

> that's going to be less than 1ms of delay That doesn't jive with my experience. If you are using something like React to do client-only rendering, you're gonna be waiting a lot for blocking critical path JS to run, as well as the actual paint time (which alone can easily be in the hundreds of milliseconds). > Ship your users an app including a copy of the data ahead of time That's not really feasible though, is it? Most SPAs in the wild fetch data on demand, so you still get the network latency no matter what (on top of the delay due to no streaming each time). This is why you get those skeleton placeholders on sites like Facebook.

nawgz 6y ago
>which alone can easily be in the hundreds of milliseconds This actual paint time is surely not any different than if you rendered the exact same application from pre-hydrated HTML though. Plus, if your application is so complex that paints are on the order of magnitude of network latency, it's probably very important to have a framework to handle interactivity, else everything will end up as some kind of a mess if you try to re-load the whole HTML page to change some small DOM subtree. Overall, I don't really see the situation where an SPA is performing worse than a server-rendered application, given that some in-browser interactivity is required.
- lhorie 6y ago
  > This actual paint time is surely not any different than if you rendered the exact same application from pre-hydrated HTML though. Well, it's different in different ways, depending on which goalpost you're standing on. If by that you mean do SSR, then run React on top, then you've just incurred the same TTFP as plain HTML, plus the cost of React hydration, plus potentially a second repaint (or even third and fourth repaints, depending on how your data trickles in). In the wild, this pattern gets particularly egregious when people decide that it's ok to have loading icons and widgets pushing each other down as data comes in. If you mean to compare to client-side rendering without SSR, then you're still looking at the cost of at least two repaints (the initial TTFP repaint, plus any repaints from data fetching after that).

deleted 6y ago

[deleted]

qpiox 6y ago

Misses the point on so many levels. Fastest experience will always be without a special framework. Fastest will always be if there is nothing except the content served in a single minimal request/response. So, this means no JS (excepct issuing requests), no browser framework, pure content. Browser sends the simplest request and receives simplest content. User reads it or looks at it. Fast as hell. It can't be faster than that because JPG can not be compressed further, gzipped HTML can not be compressed further. With later HTTP implementations, the connection can already be open and re-used. To explain this with an analogy. Bloatware comes when you decide that your true content is not enough to be appreciated as is, and needs to be beautified, made interactive, .... Just like make-up. Without make-up you only need to show your face. When you decide to use make-up to cover the true content (your true face), you need huge ammount of overhead - you need to buy the make-up, you need to learn how to apply the make-up, clean the make-up, re-apply the make-up. You need robust make-up. You need waterproof make-up. Then you need special cleaner because water will not be able to clean it. Then you start needing a make-up framework, to help you clean, apply and re-apply the make-up consistently and easily. So reinventing make-up frameworks will do nothing in alleviating overhead. Dropping the framework is the best way to go. I hope this analogy makes things clear what I meant.