Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Your single-page app is now a polyfill

itnext.io

Post reply on HN
Print view View original

61–70 of 164 posts

Re: Your single-page app is now a polyfill

#61

Post by playpause »

divbzero wrote: post #22

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 sometimes even conflicting) design goals.

Re: Your single-page app is now a polyfill

#62

Post by pier25 »

shusson wrote: post #26

> Why do we build single-page apps?... > We want our web apps to feel “instant”... > Blank screens make for a bad user-experience... In my experience if you really need fast page loads, SPAs are off the table. So the premise of the article makes no sense to me. In fact, what do people on HN think the main reason to choose an SPA is these days?

There are two valid reasons IMO:

1) A use case that requires some form of persistence like Gmail or Spotify.

2) The added complexity of working on an SPA is worth it to decouple back/front end teams.

Re: Your single-page app is now a polyfill

#63

Post by pier25 »

dspillett wrote: post #38
f311a wrote: post #35

> Blank screens make for a bad user-experience. Users don’t want to wait for content to arrive from a server when they click a link or a button. They expect websites to be fast like native apps. Why would users expect that? Most of websites use multiple pages and users are used to that. We change pages when reading paper books too. It’s not instant. In fact, some SPAs are much harder to navigate because they are over…

> Why would users expect that? People are impatient and expect everything on three computer to be as fast as the faster things on it. Anything slow can feel like there is something wrong. They don't expect things to be instant, but your page turning example is relevant: if losing a new page take the time of a physical page turn or two then it is probably fine and feels smooth. More than a few hundred ms and things fe…

> People are impatient and expect everything on three computer to be as fast as the faster things on it. Anything slow can feel like there is something wrong.

True, but an SPA doesn't really solve that either. You still have to make a request to the API and wait for it just like you have to wait for some HTML. The only difference is with an SPA you can show a spinner to the user.

Also, on an SPA, the initial hit of JS can be alleviated with code-splitting (if your main chunk is small enough) but when you switch pages you still need to download and parse a new chunk of JS.

Re: Your single-page app is now a polyfill

#64

Post by pier25 »

FpUser wrote: post #56

Frankly I do not experience any problems mentioned by the author in my single page apps. Maybe because I avoid giant frameworks and my app does not drag down megatons of dependencies. Instead they feel nice and respond instantly. Customers love it.

I agree. I wrote an SPA with Mithril a couple of months ago and the entire app fit in 38kB gzip.

For me the biggest drawback of an SPA is that it's a lot more work.

Re: Your single-page app is now a polyfill

#66

Post by dntrkv »

the_gipsy wrote: post #29
mdoms wrote: post #11

Please. Please don't do this. Service workers cause so many problems, I have never seen an implementation that didn't completely explode at some time or another, and as far as I can tell the only fix is to open the dev tools and delete service workers. They're a bad solution to a non-problem.

Twitter's implementation just exploded on me the other day on my phone. Since then I cannot open ANY links to twitter anymore. I just get a page from the browser that says "Cannot complete request". It's on my phone so I can't just clear a single site's data, and I cannot be bothered to clear everything and relog everywhere.

Hook up your iPhone to your Mac via lightning cable. Open Twitter on your iPhone and then on your Mac open Safari, enable develop mode, and then go to Develop > Your iPhone > Twitter tab. This will open up inspector on your Mac allowing you access to the local Twitter data on your iPhone.

I think that should work.

Re: Your single-page app is now a polyfill

#67

Post by vorpalhex »

redwall_hp wrote: post #51
jiofih wrote: post #13

You know what also uses the streaming parser? Standard server-rendered pages. The idea that SPAs are faster because “they just download the content” is rarely true, HTML compresses well and the content will take the same space in either. The real bottlenecks are in re-executing huge amounts of JS per page (don’t have huge amounts of JS?) and page transitions (being worked on).

If the majority of users only view the one page they land on, throwing a load of JS at them to make subsequent page loads faster is only slowing down their experience. It's also pointless for users who aren't the lowest common denominator, since opening links in new tabs also defeats the whole premise. That's how I'm browsing HN right now: middle-clicking several links on the front page, so I don't lose my place, ope…

> since opening links in new tabs also defeats the whole premise

You should still have assets cached and not have to refetch them, but on most SPAs you are still having to get that pages content dynamically so in theory you're reducing load time.

Of course, you could just reduce the entire bundle size to be reasonable, statically render everything and save a whole bunch of complexity, but that wouldn't be very Web 4.0 of us.

Re: Your single-page app is now a polyfill

#68

Post by Scarbutt »

pier25 wrote: post #54

Is there any evidence that users really prefer SPAs? There are plenty of examples of super successful websites that are not SPAs (Amazon, Github, StackOverflow, Wikipedia, etc).

Those websites may not be SPAs but they still contain big JS payloads.

Not sure about the others, but my guess is that if Github were created today, most of it would probably be an SPA.

Re: Your single-page app is now a polyfill

#69

Post by simonw »

fxtentacle wrote: post #17

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.

Re: Your single-page app is now a polyfill

#70

Post by corytheboyd »

jakelazaroff wrote: post #53
fxtentacle wrote: post #18

Earlier quoted context omitted.

"it would have been impossible without it" C++ desktop app It'll even have 2x the throughput at the same CPU level. Plus users can choose when they want to run your app, as opposed to you accidentally draining their battery because they left an old tab open. Boom, possible and better :p

"Better" is subjective. Web apps sacrifice performance, but you get an app that you don't have to install, that can't do anything malicious to your system without your consent, that's (at least in theory) easily shareable and deep linkable. Maybe that tradeoff isn't worth it for you, but it is for a lot of people!

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”

Post reply on HN