Live data from Hacker News

Your single-page app is now a polyfill

itnext.io

81–90 of 164 posts

Re: Your single-page app is now a polyfill

#81
post #69

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 t…

"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.

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?

Re: Your single-page app is now a polyfill

#82

Earlier quoted context omitted.

> 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/ ). 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

This is cool. What techniques did you use to include a copy of the data?

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.

Re: Your single-page app is now a polyfill

#84
post #14

> it all started with the desire to eliminate blank screens in between pages and reduce payload sizes Hell, no. The "two main reasons" for single page app given at the beginning (faster app, reduced network traffic) are actually not the main one. The main one is that the browser loses its state at each page reload, and that the state on the server, if any, needs to be reconciled every time with that on the browser. I…

>The main one is that the browser loses its state at each page reload, and that the state on the server, if any, needs to be reconciled every time with that on the browser. Yes, I also noticed this flaw. There is no good way of dealing with this other than saving state into localStorage which is less than ideal.

Traditionally you'd save it in the session on the server

Re: Your single-page app is now a polyfill

#85

Earlier quoted context omitted.

Yeah this is the point right here that seems to be so easily forgotten. You lost every non-programmer at “okay download this binary and run it from the terminal with these flags”

Not really. Non-programmers have also been using computers ever since the PC revolution and are quite used to downloading, installing and running programs, provided it has a usable GUI. After all, web apps are very recent. Even now, most programs are installed, and the rest are websites.

Web apps are relatively recent, sure. But the web is three decades old at this point. The majority of people using computers today grew up with web apps being a thing.

It's difficult to verify, but my guess is your stats are backward: most programs are websites, and the rest are installed.

Re: Your single-page app is now a polyfill

#86
post #69

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 t…

"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.

A few years ago while working on a big redesign of a high traffic web app used by people on a variety of devices–where maintaining conversion rates was critical to the project–I bought my team a handful of the cheapest current-gen Android devices I could find on Amazon to test with.

It's definitely a worthwhile exercise if your audience isn't just tech company employees with brand new flagship devices.

Re: Your single-page app is now a polyfill

#87
post #81
post #69

Earlier quoted context omitted.

"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.

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 for…

> 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!

Re: Your single-page app is now a polyfill

#88
post #58

This is seriously nifty but you really don’t need SPAs or client-side request interception for page loads to feel “instant”. All you need is server-side rendering without a zillion third-party scripts. Clicking around Hacker News provides case in point.

Also probably because you're close to the server. I doubt someone in say New Zealand would have instant page loads on HN. The solution of course is having distributed data and logic which is becoming much easier and cheaper these days.

I'm in New Zealand. HN page loads are about as instant as you can get on the web. Certainly faster than the vast majority of SPA interactions and their requisite API calls.

Re: Your single-page app is now a polyfill

#89

This is seriously nifty but you really don’t need SPAs or client-side request interception for page loads to feel “instant”. All you need is server-side rendering without a zillion third-party scripts. Clicking around Hacker News provides case in point.

We have different definitions for “feeling instant”. Most clicks on HN take well over 2s for me on a 4g connection, and often about half a second even on fast broadband. Sure that feels snappy compared to most websites, but it is still a completely different experience to using an app, or indeed a website that has been designed to eliminate perceptible delays as opposed to making them shorter. These are separate (and…

If the delay you are experiencing is caused by your connection, having the data served via a JS worker will not be faster. The additional overhead compared to a pure HTML page will hurt even more.

Re: Your single-page app is now a polyfill

#90
post #88
post #58

Earlier quoted context omitted.

Also probably because you're close to the server. I doubt someone in say New Zealand would have instant page loads on HN. The solution of course is having distributed data and logic which is becoming much easier and cheaper these days.

I'm in New Zealand. HN page loads are about as instant as you can get on the web. Certainly faster than the vast majority of SPA interactions and their requisite API calls.

Oh wow. How long do you wait for TTFB on HN requests?

Edit:

I'm in Mexico and the home page loads between 100ms and 1000ms.

Post reply on HN