4 ms·

> When on a 1Mbit/s WiFi connection in Greece, my vanilla app loaded in 4 seconds and started rendering after ~2 seconds, while the React/Redux app took 50 seco

> When on a 1Mbit/s WiFi connection in Greece, my vanilla app loaded in 4 seconds and started rendering after ~2 seconds, while the React/Redux app took 50 seconds to first render! This is the thing that baffles me about the SPA/framework trend, regardless of connection speed. The whole pitch for React/Vue/etc. is that they're supposed to make for more responsive interfaces. And yet, whenever I actually use an app written in React/Vue/etc., I find myself marveling at how slow it feels. Even on a desktop PC with a fast connection, I spend so much time staring at progress bars and loading spinners as all the various bits and bobs of the interface get pulled down and rendered. I don't know whether pages that are rendered server-side are empirically faster, but they sure feel faster, because after a brief (usually < 1s) wait the whole page just, you know, appears, fully rendered and ready to go. As another developer who's old enough to remember the CENTER tag, I'm open to the idea that this is just incipient old-fogeydom on my part. But whenever I hear people start talking about how much more responsive SPAs are, it sounds a lot like the old gag: "who are you going to believe, me or your lying eyes?"

pkaye 8y ago
Doesn't responsive UI just mean it works on different screen sizes and devices?
- smacktoward 8y ago
  That's something slightly different: reponsive design (see https://en.wikipedia.org/wiki/Responsive_web_design https://en.wikipedia.org/wiki/Responsive_web_design).
maccio92 8y ago
I think Progressive Web Apps should help with this. The architecture there designates that you have an app shell that's only downloaded once - this should be your SPA framework and all the layout bits and blobs. Those get cached at the service worker layer. Everything else (i.e. the actual data that gets displayed) can be cached as needed or retrieved as needed, without having to redownload all the "app shell" bits.
deleted 8y ago
[deleted]
jerf 8y ago
I think it's fair to say the browser has a ton of potential performance pitfalls in it, regardless of framework or lack thereof, and it's really easy to make a slow thing no matter what you do. There's definitely a ton of people who take relatively fast frameworks and do slow things with them.
fredley 8y ago
I've started using Vue for some projects, and while it has some fantastic upsides, I find it very hard to optimise. With native code you can easily profile and work out where you need to speed things up or leverage cacheing. With (e.g.) Vue, because you write so little code comparatively, it leaves you very little to do if the 'magic' that's making stuff happen under the hood is very slow. I work with a largely native Javascript SPA (main dependency is d3) and find that Javascript can be pretty damn fast if you need it to be.
bouncing 8y ago
> Even on a desktop PC with a fast connection, I spend so much time staring at progress bars and loading spinners as all the various bits and bobs of the interface get pulled down and rendered. A lot of that is likely because of the way most REST APIs are laid out. Suppose you're looking at a page that displays an invoice for an accounting system. With a traditional non-SPA app, you'd do a bunch of SQL queries and build a page from an HTML template. With a REST API, you're doing one HTTP call per entity, at least, and then subsequent HTTP calls for aggregate entities. When I've made SPAs before, I've often eschewed REST and just made a single Ajax call for "everything I need to display X to the user," not just out of efficiency, but also out of laziness -- it's easy to build. As long as you internally use your API only and don't publish keys for third parties, it's easy to maintain too. There are some solutions to address the whole problem on a grander scale (GraphQL comes to mind), but overall, that's the cause of slow SPAs in my experience.
- smacktoward 8y ago
  Yes, this has been my suspicion too. Calls out across a network like the Internet are always going to perform variably, and each new call you make represents a new roll of the dice on how fast you're going to get a response back. So passing the whole page over the wire in one call feels faster than breaking it up into X calls and then assembling the results of them all on the client end, with the page seeming slower as the value of X gets bigger.
- Svenskunganka 8y ago
  If that's the case, shouldn't HTTP/2 have solved that issue? HTTP/2 is multiplexed, so if you make something like 10 HTTP calls, only a single TCP connection would be established. Additionally, according to section 9.1 of the HTTP/2 spec[0], connections are persistent so unless the server closed the connection, an already established connection will be available from when you first loaded the page. [0]: https://httpwg.org/specs/rfc7540.html#rfc.section.9.1 https://httpwg.org/specs/rfc7540.html#rfc.section.9.1
  - bouncing 8y ago
    Well, no. For one, the most major http client library (Axios) doesn't have support for that kind of pipelining. But also, you don't necessarily know what to pipeline until you get the first request through. Most web apps will make a REST request, look at the contents of the response, then make another REST request. Maybe you could keep the socket open through that, or you could even use websockets to bypass HTTP altogether and use jsonrpc, but still, you don't know what you need to fetch in the second round until you finish the first one, so either way you're looking at a waterfall of requests, one after another. Pipelining them would scarcely help. What would help is having one API request that basically says, "here's who I am and here's the page the user wants. Give me everything for it." Then you're moving the controller back to the server, and leaving only the view on the client.
notus 8y ago
Time to first render isn't as important anymore. The expectation is more that people will open the app and leave it open for web applications and there is data to back this up. For informational sites the time to render is more important. That being said, there are also a lot of bad developers who basically invalidate any optimizations that the library makes due to their own ignorance.
- TeMPOraL 8y ago
  > The expectation is more that people will open the app and leave it open for web applications and there is data to back this up. I'm suspicious about this data. This sounds way too much like the same misguided thinking that makes people ignore performance, because obviously your app is so special it'll be the only thing user will have open on their computer. I can buy this expectation for work SaaS, in front of which you sit for 8 hours straight. Most of those used by genpop? Opened briefly and rarely.
ng12 8y ago
> Even on a desktop PC with a fast connection, I spend so much time staring at progress bars and loading spinners as all the various bits and bobs of the interface get pulled down and rendered. This means whoever wrote the app wrote it slow. React rendering performance is fantastic but that doesn't stop devs from abusing AJAX.

pkaye 8y ago

Doesn't responsive UI just mean it works on different screen sizes and devices?

smacktoward 8y ago
That's something slightly different: reponsive design (see https://en.wikipedia.org/wiki/Responsive_web_design https://en.wikipedia.org/wiki/Responsive_web_design).

maccio92 8y ago

I think Progressive Web Apps should help with this. The architecture there designates that you have an app shell that's only downloaded once - this should be your SPA framework and all the layout bits and blobs. Those get cached at the service worker layer. Everything else (i.e. the actual data that gets displayed) can be cached as needed or retrieved as needed, without having to redownload all the "app shell" bits.

deleted 8y ago

[deleted]

jerf 8y ago

I think it's fair to say the browser has a ton of potential performance pitfalls in it, regardless of framework or lack thereof, and it's really easy to make a slow thing no matter what you do. There's definitely a ton of people who take relatively fast frameworks and do slow things with them.

fredley 8y ago

I've started using Vue for some projects, and while it has some fantastic upsides, I find it very hard to optimise. With native code you can easily profile and work out where you need to speed things up or leverage cacheing. With (e.g.) Vue, because you write so little code comparatively, it leaves you very little to do if the 'magic' that's making stuff happen under the hood is very slow. I work with a largely native Javascript SPA (main dependency is d3) and find that Javascript can be pretty damn fast if you need it to be.

bouncing 8y ago

> Even on a desktop PC with a fast connection, I spend so much time staring at progress bars and loading spinners as all the various bits and bobs of the interface get pulled down and rendered. A lot of that is likely because of the way most REST APIs are laid out. Suppose you're looking at a page that displays an invoice for an accounting system. With a traditional non-SPA app, you'd do a bunch of SQL queries and build a page from an HTML template. With a REST API, you're doing one HTTP call per entity, at least, and then subsequent HTTP calls for aggregate entities. When I've made SPAs before, I've often eschewed REST and just made a single Ajax call for "everything I need to display X to the user," not just out of efficiency, but also out of laziness -- it's easy to build. As long as you internally use your API only and don't publish keys for third parties, it's easy to maintain too. There are some solutions to address the whole problem on a grander scale (GraphQL comes to mind), but overall, that's the cause of slow SPAs in my experience.

smacktoward 8y ago
Yes, this has been my suspicion too. Calls out across a network like the Internet are always going to perform variably, and each new call you make represents a new roll of the dice on how fast you're going to get a response back. So passing the whole page over the wire in one call feels faster than breaking it up into X calls and then assembling the results of them all on the client end, with the page seeming slower as the value of X gets bigger.
Svenskunganka 8y ago
If that's the case, shouldn't HTTP/2 have solved that issue? HTTP/2 is multiplexed, so if you make something like 10 HTTP calls, only a single TCP connection would be established. Additionally, according to section 9.1 of the HTTP/2 spec[0], connections are persistent so unless the server closed the connection, an already established connection will be available from when you first loaded the page. [0]: https://httpwg.org/specs/rfc7540.html#rfc.section.9.1 https://httpwg.org/specs/rfc7540.html#rfc.section.9.1
- bouncing 8y ago
  Well, no. For one, the most major http client library (Axios) doesn't have support for that kind of pipelining. But also, you don't necessarily know what to pipeline until you get the first request through. Most web apps will make a REST request, look at the contents of the response, then make another REST request. Maybe you could keep the socket open through that, or you could even use websockets to bypass HTTP altogether and use jsonrpc, but still, you don't know what you need to fetch in the second round until you finish the first one, so either way you're looking at a waterfall of requests, one after another. Pipelining them would scarcely help. What would help is having one API request that basically says, "here's who I am and here's the page the user wants. Give me everything for it." Then you're moving the controller back to the server, and leaving only the view on the client.

notus 8y ago

Time to first render isn't as important anymore. The expectation is more that people will open the app and leave it open for web applications and there is data to back this up. For informational sites the time to render is more important. That being said, there are also a lot of bad developers who basically invalidate any optimizations that the library makes due to their own ignorance.

TeMPOraL 8y ago
> The expectation is more that people will open the app and leave it open for web applications and there is data to back this up. I'm suspicious about this data. This sounds way too much like the same misguided thinking that makes people ignore performance, because obviously your app is so special it'll be the only thing user will have open on their computer. I can buy this expectation for work SaaS, in front of which you sit for 8 hours straight. Most of those used by genpop? Opened briefly and rarely.

ng12 8y ago

> Even on a desktop PC with a fast connection, I spend so much time staring at progress bars and loading spinners as all the various bits and bobs of the interface get pulled down and rendered. This means whoever wrote the app wrote it slow. React rendering performance is fantastic but that doesn't stop devs from abusing AJAX.