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.
Your single-page app is now a polyfill
11–20 of 164 posts
Re: Your single-page app is now a polyfill
#12With service workers disabled on firefox the site just breaks, no graceful degradation/progressive enhancement. When clicking links in the header the url will change, but the page content doesn't.
The trouble is trailing slashes and inconsistent behaviour between the service worker and the web server.
https://instantmultipageapp.com/images/ loads from the server, and not the service worker. Observe how it lacks the Blog link in the header, which is missing in what the server is rendering—see /images/index.html in the repository.
https://instantmultipageapp.com/images loads from the service worker, and the server serves /index.html for it (which is very wrong) rather than /images/index.html.
This is purely a bug in the demo. Kind of a fundamental bug that leaves me unimpressed, but a simple bug nonetheless. If you were to actually run the service worker on the backend, it’d resolve this kind of problem, and also the inconsistency between what the two platforms render, as seen in the missing Blog link.
Re: Your single-page app is now a polyfill
#13You 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).
Re: Your single-page app is now a polyfill
#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. It is fine only as long as your app doesn't have any client state. The more state you put in your client (e.g. a text field with its contents) the harder it is to maintain the state across page reloads.
This is why now we design our applications with all the state in the frontend, closer to the user, and a stateless backend. SPAs are in fact enormously simpler than equivalent non-SPAs.
Re: Your single-page app is now a polyfill
#15off-topic: how/why is medium still around with their very aggressive techniques? They started as a minimalist blogging platform, and once they acquired the content, they started putting paywalls in front of their users' content.
I don't even know how to find articles on Medium. There used to be a whole bunch of articles listed on the front page. Now it just seems like one big advertisement.
Re: Your single-page app is now a polyfill
#16Please. 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.
There are many use cases for service workers you probably haven't heard of.
For example at my last job (at a YC startup) we built a service worker that used P2P to serve mp4 video over WebRTC.
It was the correct place to interop with the download - it was explicit and it would have been impossible without it.
----
I think the common use case (of much control over caching) is also quite reasonable. I agree the API and usage is too hard.
Re: Your single-page app is now a polyfill
#17I 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.
Re: Your single-page app is now a polyfill
#18Please. 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.
There are many use cases for service workers you probably haven't heard of. For example at my last job (at a YC startup) we built a service worker that used P2P to serve mp4 video over WebRTC. It was the correct place to interop with the download - it was explicit and it would have been impossible without it. ---- I think the common use case (of much control over caching) is also quite reasonable. I agree the API and…
"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
Re: Your single-page app is now a polyfill
#19I 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…
> 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
Re: Your single-page app is now a polyfill
#20This is impressive and would work really well in a lot of sites, especially ones with static content. However it misses two important reasons to use a single-page app: 1. SPAs allow for highly interactive interfaces with custom components, drag & drop, audio etc. 2. SPAs can cache UI state in the client. The alternative is to store it in a server side session specific to each client. This is possible, of course, but…
Regarding point #1, is there anything inherent to the single page application that makes something more interactive? I think this article touched on an alternative to the one factor of routing being necessary to eliminate transitions, but otherwise you still have the same interactive capabilities within a page.