19 ms·

Your single-page app is now a polyfill

164 points by mhoad 6y ago

obilgic 6y ago
off-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.
- jelling 6y ago
  I don’t subscribe to Medium yet but I started using Apple News because the ad-driven model has led to publisher pages that are near unreadable / terrible UX. So I won’t be surprised if Medium is successful.
- lukestevens 6y ago
  For better or worse, Medium is not just around, it’s growth is (apparently) accelerating: https://blog.medium.com/whats-around-the-corner-for-medium-b79e8764c9cd https://blog.medium.com/whats-around-the-corner-for-medium-b...
  - cblconfederate 6y ago
    not so sure about that. alexa stats and every other stat show them on a downward trend
- kecupochren 6y ago
  use incognito mode
- AA-BA-94-2A-56 6y ago
  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.
- redwall_hp 6y ago
  Because it pays out well for popular posts and doesn't involve ads. I made a few hundred dollars off one that I published there over the summer.
vnglst 6y ago
This is a really cool idea, but I did notice a full page refresh on mobile Safari. It’s not the app-like experience you get with SPA’s
- deleted 6y ago
  [deleted]
- Geee 6y ago
  On desktop Safari as well.
PudgePacket 6y ago
With 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.
- chrismorgan 6y ago
  The trouble is trailing slashes and inconsistent behaviour between the service worker and the web server. https://instantmultipageapp.com/images/ 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 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.
  - the_gipsy 6y ago
    This is just one bug you found. There are more edge cases for sure, serviceworkers intercepting requests and caching is a nightmare.
    - chrismorgan 6y ago
      I think it’s better characterised in this way: service workers are dangerous because you can break things; so it’s very important that the foundations of your service worker are sound. If the foundations are sound (which takes effort), there’s nothing wrong with them. But ad hoc service workers, like this, are extremely dangerous.
  - dannymoerkerke 6y ago
    Thanks for reporting. There were some problems on the backend but this has now all been solved.
jpnelson 6y ago
This is a good use case for service workers and is mentioned in this post from 2016: https://developers.google.com/web/updates/2016/06/sw-readablestreams https://developers.google.com/web/updates/2016/06/sw-readabl... It covers some pros and cos, the main advantages of using an app shell are > whether your web app is best modeled as a single-page application (advantage: App Shell); and on whether you need a model that's currently supported across multiple browsers' stable releases (advantage: App Shell) I think it's reasonable to argue that lots of sites that are SPA's don't need to be, if they can do this instead.
jakecopp 6y ago
> Server-side rendering on the client JavaScript has gone too far :D
- mad182 6y ago
  What does it even mean?
sambeau 6y ago
This 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 it will either be lost every time the server is restarted, or it will need to stored in the database. Sending UI state back and forth to the database is another increase in load on the database and network. There is also the more general point about SPAs exchanging less data with the server so putting less stress on the network but that is touched upon in the post.
- brailsafe 6y ago
  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.
- Scarbutt 6y ago
  2. SPAs can cache UI state in the client. The alternative is to store it in a server side session specific to each client. Non-SPA doesn't mean 0% JS.
- pier25 6y ago
  > SPAs allow for highly interactive interfaces with custom components, drag & drop, audio etc. None of the features you listed require an SPA. Other than page transitions you can have any UI sophistication on an MPA. > This is possible, of course, but it will either be lost every time the server is restarted, or it will need to stored in the database. Which is why there are caching databases like Redis to solve this.
  - maxthegeek1 6y ago
    Serverside caching with e.g. doesn't help with network latency.
mdoms 6y ago
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.
- aitchnyu 6y ago
  Clearing browser cache used to be our "have you turned it off and on again?" Looks like we need a "restore website to factory settings" which clears cache, cookies, service workers, offline storage, JIT of the code etc.
- inglor 6y ago
  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.
  - fxtentacle 6y ago
    "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
    - SirHound 6y ago
      Better = higher barrier to entry?
      - fxtentacle 6y ago
        Less behavior that users are surprised by in a negative way.
jiofih 6y ago
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).
- recursivedoubts 6y ago
  Absolutely. The initial motivation for building intercooler.js (and then htmx) was because I found that slamming a large html table rendered on the server into the DOM directly was orders of magnitude faster than running the JSON equivalent through a local template engine.
  - nawgz 6y ago
    Sure, but what's your use case? Strict data table where everything is a string or number? Great. Full fledged application where your table rows are actually selectable items that modify app state and cause rerenders elsewhere? Surely a slight performance hit in the table is worth the smoothness of an application. For example, I have a workflow execution tool. You have a Table serving as a left column, and when you select a workflow (by clicking its table row), it populates the right column with the graph of that workflow. I often feel as if arguments against SPA are constructed against the worst examples of the thing, when the UIs it enables are smooth, performant, and best-of-all not requiring user installs.
    - recursivedoubts 6y ago
      > For example, I have a workflow execution tool. You have a Table serving as a left column, and when you select a workflow (by clicking its table row), it populates the right column with the graph of that workflow. That is trivially implementable in pure HTML interactions. If you were making a 3D game or something, sure... but that's just normal web navigation.
      - 6y ago
Udik 6y ago
> 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.
- brailsafe 6y ago
  I think those are definitely some key advantages to SPAs, but my impression when they started becoming adopted, especially to the consumers (users) was one seamless thing with no new pages etc.. certainly development is more manageable with client only state, but I don't see that as the first big sell.
- Cthulhu_ 6y ago
  > it all started with the desire to eliminate blank screens in between pages and reduce payload sizes That isn't even a thing anymore, except in SPA's or Internet Explorer; Chrome (seems to?) wait until some content is loaded before it switches to the clicked page, there is no blank screen. Payload sizes is not really a problem either given that content is not that much data. Images and media take up the brunt of bandwidth; the payload size is not the issue.
- imtringued 6y ago
  >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.
  - 6y ago
fxtentacle 6y ago
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.
PinguTS 6y ago
Maybe I am missing the point. When the problem is speed and the solutions seems single page app with bloated javascript or the thing the poster suggest. Why isn't the solution just simple classical HTML without any bloated Javascript, which also needs to be executed. The CSS is cached, so it doesn't need to be reloaded and the next possible pages are prefetched via the correct META tags.
- manigandham 6y ago
  That is the best solution, just not trendy. Ironic since that's what HN uses and why it's so fast, and why all the SPA HN clones are terrible.
divbzero 6y ago
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.
- pier25 6y ago
  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.
  - mdoms 6y ago
    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.
    - pier25 6y ago
      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.
    - qu4z-2 6y ago
      I'm seconding this. I'm in New Zealand and Hacker News is easily one of the most responsive sites on the web, in my experience.
      - pier25 6y ago
        How long do you wait for TTFB from HN on average?
- playpause 6y ago
  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.
shusson 6y ago
> 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?
- milankragujevic 6y ago
  For me, SPA is either chosen due to "fancy factor" or because the app is too complex to easily implement as a traditional (SSR) web page. That could be a complex search+filter with autocomplete, or a social network-like UI with infinite scroll and dynamic widgets.
  - shusson 6y ago
    Yes in practice this is what I see as well. I would also add, "developer likes framework x tooling". The other use case that SPA frameworks sell, is develop for all platforms For web, mobile and desktop. It sounds nice on paper, but I have no experience with it.
    - imtringued 6y ago
      That sounds about it. People use SPAs to make webapps that are as complicated as regular desktop or phone apps.
      - mrlala 6y ago
        For sure. I have a complicated SPA app that is as complex as any desktop application; but with the flexibility of it being a simple web app. I never, ever, ever could have managed to pull this off before SPA. Especially as a non-primary web developer, angular basically does all the grunt work for me and allows me to keep a very structured application. Looking forward to attempting a blazor experiment as some point; as I still hate having to define the same object on the front-end vs back-end and I use dynamic data little too much.. but the current state of being able to use an SPA blows the options before out of the water. In my mind, you had to be a 100% javascript/web developer to create any type of usable complicated equivalent SPA.. but now I can do a structured (mostly) typed front-end.
petilon 6y ago
> Most times, a frontend framework is added as well to handle the rendering of these pages, increasing complexity further. This is true, but it doesn’t need to be this way at all! Here’s a single page app written without a bloated framework: https://github.com/rajeev-k/eureka https://github.com/rajeev-k/eureka And here’s the client-side router, which is all of 500 lines: https://github.com/Rajeev-K/mvc-router https://github.com/Rajeev-K/mvc-router React + Redux + ReactRouter is way too complicated and it is getting more complicated every passing day, with things like react hooks and so on. But 90% of web apps don’t need that complexity.
cblconfederate 6y ago
the idea that the DOM based browser can be used as a GUI toolkit was wrong to begin with. It has been stretched to absurd proportions over the years. Maybe we need to go back to java applets?
- imtringued 6y ago
  I disagree. The only problem is that people insist to use it for desktop apps. Webapps are their own thing. They should stay in the browser instead of leaking and spilling everywhere.
f311a 6y ago
> 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 engineered.
- dspillett 6y ago
  > 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 feel more "janky". This is something some people cite as why they don't like e-ink devices. > some SPAs are much harder to navigate because they are over engineered This is definitely true, but also holds for many non SPA sites too. > > blank screens This part of the parent post is significant IMO. If the previous page vanishes I find I'm less patient waiting for the new information. This is worse if there has been a delay before that happens too. Though likewise if nothing changes I might think something is amiss: did my click even register? Some extra indication of action (the click target changing colour is sufficient) helps here, when the background request doesn't show in the browsers built-in activity indicators.
  - pier25 6y ago
    > 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.
fravelgue 6y ago
Is this something similar to Turbolinks of Basecamp?
codeulike 6y ago
What does the article mean by "polyfill"? Edit: from Wikipedia In web development, a polyfill is code that implements a feature on web browsers that do not support the feature. Most often, it refers to a JavaScript library that implements an HTML5 web standard
princekolt 6y ago
> So we build single-page apps, where only the content that changes in the page is replaced, avoiding a full page reload, so navigating to another page feels instant. HTTP caches and the absence of overcomplicated JS frameworks will do this better than any developer (simply because there's less to be done). This article is basically a web dev admitting native apps are better but refusing to behave accordingly, choosing instead to make their own lives harder. Edit: Also, makes this whole statement then publishes their article on medium...
k4roshi 6y ago
Isn't this what turbolinks already does?
- jdauriemma 6y ago
  Convergent evolution. Turbolinks has a similar use case but does not implement the same abstractions as OP's approach.
Justsignedup 6y ago
My reasons for SPAs has always been complex behaviors on the app and state persistence is a PITA if you don't end up with a nice MVVC on the front-end. Not saying not possible to make complex pages without SPAs, but there are some things that are harder, and some that are easier. Personally I love writing SPAs, I find that I end up making less complex code which ends up being easier to maintain. Not counting by the number of lines of code, but counting by how easy developers find it to change the logic without breaking everything in a complex codebase. So idk, maybe I'm doing it wrong.
- Quarrelsome 6y ago
  The sort of garbage we ended up doing prior to SPAs justify SPAs. Writing a server to dynamically create a HTML page that also includes first pass content as well as potentially dynamic javascript to make the page interactive in "later passes" is just an ugly mix of client side execution and server side execution in one spot. The application just feels a lot more consistent when the client is just pulling data instead of being thrown away and recreated in the middle of a request made by a browser for a particular URL that is just one of a very long series of requests.
  - Justsignedup 6y ago
    There are techniques for controlling complexity there, and often you can make a single-page react page which will encapsulate complex behaviors. Often a mix of the two helps. But you end up having one set of code managing the static page, and another for the api-based interactions. and then once you have api-based stuff product asks to add on a feature and a feature until you have mutliple SPAs. :P Code reuse is a big reason too, why write 10 different SPAs for one site, when you can write 1 SPA with a ton of code/tool re-use. I always end up taking 1 SPA and make 2-4 different SPAs out of it, each facing a different set of users, with different security/look requirements, but all underpinned by the exact same technology. So much headaches saved. Just to make it clear: - I agree that SPAs didn't come out of developers being idiots, but rather because the shit we had to do before SPAs was craaaaaaaaaaazy. Jesus I remember the old jquery things. And before jquery... shiver... - I think SPAs are definitely not a one-tool-for-all-problems kind of thing. - Interestingly enough, SPAs can be a one-tool-for-all-problems kind of thing with SSR, that's what linkedin does. LI is an SPA with the ability to behave like a non-SPA via isomorphism.
pier25 6y ago
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).
- deleted 6y ago
  [deleted]
- Scarbutt 6y ago
  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.
  - pier25 6y ago
    > Those websites may not be SPAs but they still contain big JS payloads. Probably, although my question was not about the bloat but the claim on the article that users prefers the UX of SPAs. > my guess is that if Github were created today, most of it would probably be an SPA Why is that?
    - Scarbutt 6y ago
      Probably, although my question was not about the bloat but the claim on the article that users prefers the UX of SPAs. Should rephrase that, they have big JS payloads to make the website feel close to an SPA as possible. > my guess is that if Github were created today, most of it would probably be an SPA Github.com today has many components that are pure JS(most new features), writing it today from scratch my guess would be they would have go almost all client-side JS.
      - pier25 6y ago
        > they have big JS payloads to make the website feel close to an SPA as possible Can you give an example? I know Github uses Turbolinks, but that doesn't really contribute much to its bloat. > Github.com today has many components that are pure JS(most new features) What you're saying is that because some of their features on some of their pages are JS heavy then it would make more sense to make an SPA?
FpUser 6y ago
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.
- pier25 6y ago
  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.
  - orthecreedence 6y ago
    I've found SPAs to be less work. Instead of having two templating systems (server-side and client-side) there's just one on the client side. Now I don't have to share code between client and server, but more than that, the two are logically separated. The client can just be a client, rather than a strange half-extension, half-app of the server. Secondly, if you also want to expose an API, do you put it in the server that does the rendering, or do you have a third component that the server talks to? With an SPA, there's only the app and only the API and the two are separated out by their respective duties quite cleanly. Once I started building out SPAs for data-driven applications, I never looked back to the old model of generating HTML server-side. It seems barbaric to me. The only hesitation I would have is if the SPA needs to be SEO optimized, in which case you can go either isomorphic (again, not a fan) or scrape pages via a headless browser as .html into a directory that your webserver serves up.
    - pier25 6y ago
      I agree having two templating systems is a problem (more on this later) but by going SPA your front end now becomes massively more complex than sprinkling some JS here and there. For example you now need to manage application state which is not a trivial problem on large projects. You also need to replicate native browser UX if you're serious about making a good SPA (eg: your forms are filled when going back, the content and scroll position are preserved when going back, etc). As for the duplicate template problem, this is easily solved by doing SSR + hydration. I concede this is generally complex to set up (unless using something like Next.js) but it's worth it IMO. It's really the best of both worlds (MPA vs SPA). You are still creating components and having a sophisticated interactive UI just like in the SPA world, but front end development is greatly simplified since you're only dealing with one page at a time. Also, in many cases, you might not even need an API. How many times have you create an API only to feed your SPA? It's a lot of overhead. Also these days I don't think the decoupling argument is so strong unless you're working on a complex project with multiple teams.
fareesh 6y ago
I wonder if Turbolinks will evolve to this approach. They currently do a regular XHR and replace everything in the <body> from what I understand.
pgcj_poster 6y ago
"In conversations with web performance advocates, I sometimes feel like a hippie talking to SUV owners about fuel economy. They have all kinds of weirdly specific tricks to improve mileage. Deflate the front left tire a little bit. Put a magnet on the gas cap. Fold in the side mirrors. Most of the talk about web performance is similarly technical, involving compression, asynchronous loading, sequencing assets, batching HTTP requests, pipelining, and minification. All of it obscures a simpler solution. If you're only going to the corner store, ride a bicycle. If you're only displaying five sentences of text, use vanilla HTML. Hell, serve a textfile! Then you won't need compression hacks, integral signs, or elaborate Gantt charts of what assets load in what order. Browsers are really, really good at rendering vanilla HTML. We have the technology." https://idlewords.com/talks/website_obesity.htm https://idlewords.com/talks/website_obesity.htm
stuaxo 6y ago
There's the benefit of being able to continue playing media as the user navigates the site, like soundcloud.
ilaksh 6y ago
I thought this article was going to be about HTTP 2 Server Push which allows the server to deliver pages ahead of time before you click them and thus allows for the instant transition between preloaded pages. It's strange to me that people do not appreciate that technology or discuss it more. I think it's just something that hasn't caught on.
qpiox 6y ago
Fail! The demo site does not work. Failed to register/update a ServiceWorker for scope ‘https://instantmultipageapp.com/’ https://instantmultipageapp.com/’: Storage access is restricted in this context due to user settings or private browsing mode. The article does not even try to mention this.

164 points by mhoad 6y ago

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

jelling 6y ago
I don’t subscribe to Medium yet but I started using Apple News because the ad-driven model has led to publisher pages that are near unreadable / terrible UX. So I won’t be surprised if Medium is successful.
lukestevens 6y ago
For better or worse, Medium is not just around, it’s growth is (apparently) accelerating: https://blog.medium.com/whats-around-the-corner-for-medium-b79e8764c9cd https://blog.medium.com/whats-around-the-corner-for-medium-b...
- cblconfederate 6y ago
  not so sure about that. alexa stats and every other stat show them on a downward trend
kecupochren 6y ago
use incognito mode
AA-BA-94-2A-56 6y ago
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.
redwall_hp 6y ago
Because it pays out well for popular posts and doesn't involve ads. I made a few hundred dollars off one that I published there over the summer.

vnglst 6y ago

This is a really cool idea, but I did notice a full page refresh on mobile Safari. It’s not the app-like experience you get with SPA’s

deleted 6y ago
[deleted]
Geee 6y ago
On desktop Safari as well.

PudgePacket 6y ago

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

chrismorgan 6y ago
The trouble is trailing slashes and inconsistent behaviour between the service worker and the web server. https://instantmultipageapp.com/images/ 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 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.
- the_gipsy 6y ago
  This is just one bug you found. There are more edge cases for sure, serviceworkers intercepting requests and caching is a nightmare.
  - chrismorgan 6y ago
    I think it’s better characterised in this way: service workers are dangerous because you can break things; so it’s very important that the foundations of your service worker are sound. If the foundations are sound (which takes effort), there’s nothing wrong with them. But ad hoc service workers, like this, are extremely dangerous.
- dannymoerkerke 6y ago
  Thanks for reporting. There were some problems on the backend but this has now all been solved.

jpnelson 6y ago

This is a good use case for service workers and is mentioned in this post from 2016: https://developers.google.com/web/updates/2016/06/sw-readablestreams https://developers.google.com/web/updates/2016/06/sw-readabl... It covers some pros and cos, the main advantages of using an app shell are > whether your web app is best modeled as a single-page application (advantage: App Shell); and on whether you need a model that's currently supported across multiple browsers' stable releases (advantage: App Shell) I think it's reasonable to argue that lots of sites that are SPA's don't need to be, if they can do this instead.

jakecopp 6y ago

> Server-side rendering on the client JavaScript has gone too far :D

mad182 6y ago
What does it even mean?

sambeau 6y ago

This 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 it will either be lost every time the server is restarted, or it will need to stored in the database. Sending UI state back and forth to the database is another increase in load on the database and network. There is also the more general point about SPAs exchanging less data with the server so putting less stress on the network but that is touched upon in the post.

brailsafe 6y ago
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.
Scarbutt 6y ago
2. SPAs can cache UI state in the client. The alternative is to store it in a server side session specific to each client. Non-SPA doesn't mean 0% JS.
pier25 6y ago
> SPAs allow for highly interactive interfaces with custom components, drag & drop, audio etc. None of the features you listed require an SPA. Other than page transitions you can have any UI sophistication on an MPA. > This is possible, of course, but it will either be lost every time the server is restarted, or it will need to stored in the database. Which is why there are caching databases like Redis to solve this.
- maxthegeek1 6y ago
  Serverside caching with e.g. doesn't help with network latency.

mdoms 6y ago

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.

aitchnyu 6y ago
Clearing browser cache used to be our "have you turned it off and on again?" Looks like we need a "restore website to factory settings" which clears cache, cookies, service workers, offline storage, JIT of the code etc.
inglor 6y ago
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.
- fxtentacle 6y ago
  "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
  - SirHound 6y ago
    Better = higher barrier to entry?
    - fxtentacle 6y ago
      Less behavior that users are surprised by in a negative way.

jiofih 6y ago

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

recursivedoubts 6y ago
Absolutely. The initial motivation for building intercooler.js (and then htmx) was because I found that slamming a large html table rendered on the server into the DOM directly was orders of magnitude faster than running the JSON equivalent through a local template engine.
- nawgz 6y ago
  Sure, but what's your use case? Strict data table where everything is a string or number? Great. Full fledged application where your table rows are actually selectable items that modify app state and cause rerenders elsewhere? Surely a slight performance hit in the table is worth the smoothness of an application. For example, I have a workflow execution tool. You have a Table serving as a left column, and when you select a workflow (by clicking its table row), it populates the right column with the graph of that workflow. I often feel as if arguments against SPA are constructed against the worst examples of the thing, when the UIs it enables are smooth, performant, and best-of-all not requiring user installs.
  - recursivedoubts 6y ago
    > For example, I have a workflow execution tool. You have a Table serving as a left column, and when you select a workflow (by clicking its table row), it populates the right column with the graph of that workflow. That is trivially implementable in pure HTML interactions. If you were making a 3D game or something, sure... but that's just normal web navigation.
    - 6y ago

Udik 6y ago

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

brailsafe 6y ago
I think those are definitely some key advantages to SPAs, but my impression when they started becoming adopted, especially to the consumers (users) was one seamless thing with no new pages etc.. certainly development is more manageable with client only state, but I don't see that as the first big sell.
Cthulhu_ 6y ago
> it all started with the desire to eliminate blank screens in between pages and reduce payload sizes That isn't even a thing anymore, except in SPA's or Internet Explorer; Chrome (seems to?) wait until some content is loaded before it switches to the clicked page, there is no blank screen. Payload sizes is not really a problem either given that content is not that much data. Images and media take up the brunt of bandwidth; the payload size is not the issue.
imtringued 6y ago
>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.
- 6y ago

fxtentacle 6y ago

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.

PinguTS 6y ago

Maybe I am missing the point. When the problem is speed and the solutions seems single page app with bloated javascript or the thing the poster suggest. Why isn't the solution just simple classical HTML without any bloated Javascript, which also needs to be executed. The CSS is cached, so it doesn't need to be reloaded and the next possible pages are prefetched via the correct META tags.

manigandham 6y ago
That is the best solution, just not trendy. Ironic since that's what HN uses and why it's so fast, and why all the SPA HN clones are terrible.

divbzero 6y ago

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.

pier25 6y ago
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.
- mdoms 6y ago
  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.
  - pier25 6y ago
    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.
  - qu4z-2 6y ago
    I'm seconding this. I'm in New Zealand and Hacker News is easily one of the most responsive sites on the web, in my experience.
    - pier25 6y ago
      How long do you wait for TTFB from HN on average?
playpause 6y ago
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.

shusson 6y ago

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

milankragujevic 6y ago
For me, SPA is either chosen due to "fancy factor" or because the app is too complex to easily implement as a traditional (SSR) web page. That could be a complex search+filter with autocomplete, or a social network-like UI with infinite scroll and dynamic widgets.
- shusson 6y ago
  Yes in practice this is what I see as well. I would also add, "developer likes framework x tooling". The other use case that SPA frameworks sell, is develop for all platforms For web, mobile and desktop. It sounds nice on paper, but I have no experience with it.
  - imtringued 6y ago
    That sounds about it. People use SPAs to make webapps that are as complicated as regular desktop or phone apps.
    - mrlala 6y ago
      For sure. I have a complicated SPA app that is as complex as any desktop application; but with the flexibility of it being a simple web app. I never, ever, ever could have managed to pull this off before SPA. Especially as a non-primary web developer, angular basically does all the grunt work for me and allows me to keep a very structured application. Looking forward to attempting a blazor experiment as some point; as I still hate having to define the same object on the front-end vs back-end and I use dynamic data little too much.. but the current state of being able to use an SPA blows the options before out of the water. In my mind, you had to be a 100% javascript/web developer to create any type of usable complicated equivalent SPA.. but now I can do a structured (mostly) typed front-end.

petilon 6y ago

> Most times, a frontend framework is added as well to handle the rendering of these pages, increasing complexity further. This is true, but it doesn’t need to be this way at all! Here’s a single page app written without a bloated framework: https://github.com/rajeev-k/eureka https://github.com/rajeev-k/eureka And here’s the client-side router, which is all of 500 lines: https://github.com/Rajeev-K/mvc-router https://github.com/Rajeev-K/mvc-router React + Redux + ReactRouter is way too complicated and it is getting more complicated every passing day, with things like react hooks and so on. But 90% of web apps don’t need that complexity.

cblconfederate 6y ago

the idea that the DOM based browser can be used as a GUI toolkit was wrong to begin with. It has been stretched to absurd proportions over the years. Maybe we need to go back to java applets?

imtringued 6y ago
I disagree. The only problem is that people insist to use it for desktop apps. Webapps are their own thing. They should stay in the browser instead of leaking and spilling everywhere.

f311a 6y ago

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

dspillett 6y ago
> 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 feel more "janky". This is something some people cite as why they don't like e-ink devices. > some SPAs are much harder to navigate because they are over engineered This is definitely true, but also holds for many non SPA sites too. > > blank screens This part of the parent post is significant IMO. If the previous page vanishes I find I'm less patient waiting for the new information. This is worse if there has been a delay before that happens too. Though likewise if nothing changes I might think something is amiss: did my click even register? Some extra indication of action (the click target changing colour is sufficient) helps here, when the background request doesn't show in the browsers built-in activity indicators.
- pier25 6y ago
  > 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.

fravelgue 6y ago

Is this something similar to Turbolinks of Basecamp?

codeulike 6y ago

What does the article mean by "polyfill"? Edit: from Wikipedia In web development, a polyfill is code that implements a feature on web browsers that do not support the feature. Most often, it refers to a JavaScript library that implements an HTML5 web standard

princekolt 6y ago

> So we build single-page apps, where only the content that changes in the page is replaced, avoiding a full page reload, so navigating to another page feels instant. HTTP caches and the absence of overcomplicated JS frameworks will do this better than any developer (simply because there's less to be done). This article is basically a web dev admitting native apps are better but refusing to behave accordingly, choosing instead to make their own lives harder. Edit: Also, makes this whole statement then publishes their article on medium...

k4roshi 6y ago

Isn't this what turbolinks already does?

jdauriemma 6y ago
Convergent evolution. Turbolinks has a similar use case but does not implement the same abstractions as OP's approach.

Justsignedup 6y ago

My reasons for SPAs has always been complex behaviors on the app and state persistence is a PITA if you don't end up with a nice MVVC on the front-end. Not saying not possible to make complex pages without SPAs, but there are some things that are harder, and some that are easier. Personally I love writing SPAs, I find that I end up making less complex code which ends up being easier to maintain. Not counting by the number of lines of code, but counting by how easy developers find it to change the logic without breaking everything in a complex codebase. So idk, maybe I'm doing it wrong.

Quarrelsome 6y ago
The sort of garbage we ended up doing prior to SPAs justify SPAs. Writing a server to dynamically create a HTML page that also includes first pass content as well as potentially dynamic javascript to make the page interactive in "later passes" is just an ugly mix of client side execution and server side execution in one spot. The application just feels a lot more consistent when the client is just pulling data instead of being thrown away and recreated in the middle of a request made by a browser for a particular URL that is just one of a very long series of requests.
- Justsignedup 6y ago
  There are techniques for controlling complexity there, and often you can make a single-page react page which will encapsulate complex behaviors. Often a mix of the two helps. But you end up having one set of code managing the static page, and another for the api-based interactions. and then once you have api-based stuff product asks to add on a feature and a feature until you have mutliple SPAs. :P Code reuse is a big reason too, why write 10 different SPAs for one site, when you can write 1 SPA with a ton of code/tool re-use. I always end up taking 1 SPA and make 2-4 different SPAs out of it, each facing a different set of users, with different security/look requirements, but all underpinned by the exact same technology. So much headaches saved. Just to make it clear: - I agree that SPAs didn't come out of developers being idiots, but rather because the shit we had to do before SPAs was craaaaaaaaaaazy. Jesus I remember the old jquery things. And before jquery... shiver... - I think SPAs are definitely not a one-tool-for-all-problems kind of thing. - Interestingly enough, SPAs can be a one-tool-for-all-problems kind of thing with SSR, that's what linkedin does. LI is an SPA with the ability to behave like a non-SPA via isomorphism.

pier25 6y ago

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

deleted 6y ago
[deleted]
Scarbutt 6y ago
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.
- pier25 6y ago
  > Those websites may not be SPAs but they still contain big JS payloads. Probably, although my question was not about the bloat but the claim on the article that users prefers the UX of SPAs. > my guess is that if Github were created today, most of it would probably be an SPA Why is that?
  - Scarbutt 6y ago
    Probably, although my question was not about the bloat but the claim on the article that users prefers the UX of SPAs. Should rephrase that, they have big JS payloads to make the website feel close to an SPA as possible. > my guess is that if Github were created today, most of it would probably be an SPA Github.com today has many components that are pure JS(most new features), writing it today from scratch my guess would be they would have go almost all client-side JS.
    - pier25 6y ago
      > they have big JS payloads to make the website feel close to an SPA as possible Can you give an example? I know Github uses Turbolinks, but that doesn't really contribute much to its bloat. > Github.com today has many components that are pure JS(most new features) What you're saying is that because some of their features on some of their pages are JS heavy then it would make more sense to make an SPA?

FpUser 6y ago

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.

pier25 6y ago
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.
- orthecreedence 6y ago
  I've found SPAs to be less work. Instead of having two templating systems (server-side and client-side) there's just one on the client side. Now I don't have to share code between client and server, but more than that, the two are logically separated. The client can just be a client, rather than a strange half-extension, half-app of the server. Secondly, if you also want to expose an API, do you put it in the server that does the rendering, or do you have a third component that the server talks to? With an SPA, there's only the app and only the API and the two are separated out by their respective duties quite cleanly. Once I started building out SPAs for data-driven applications, I never looked back to the old model of generating HTML server-side. It seems barbaric to me. The only hesitation I would have is if the SPA needs to be SEO optimized, in which case you can go either isomorphic (again, not a fan) or scrape pages via a headless browser as .html into a directory that your webserver serves up.
  - pier25 6y ago
    I agree having two templating systems is a problem (more on this later) but by going SPA your front end now becomes massively more complex than sprinkling some JS here and there. For example you now need to manage application state which is not a trivial problem on large projects. You also need to replicate native browser UX if you're serious about making a good SPA (eg: your forms are filled when going back, the content and scroll position are preserved when going back, etc). As for the duplicate template problem, this is easily solved by doing SSR + hydration. I concede this is generally complex to set up (unless using something like Next.js) but it's worth it IMO. It's really the best of both worlds (MPA vs SPA). You are still creating components and having a sophisticated interactive UI just like in the SPA world, but front end development is greatly simplified since you're only dealing with one page at a time. Also, in many cases, you might not even need an API. How many times have you create an API only to feed your SPA? It's a lot of overhead. Also these days I don't think the decoupling argument is so strong unless you're working on a complex project with multiple teams.

fareesh 6y ago

I wonder if Turbolinks will evolve to this approach. They currently do a regular XHR and replace everything in the <body> from what I understand.

pgcj_poster 6y ago

"In conversations with web performance advocates, I sometimes feel like a hippie talking to SUV owners about fuel economy. They have all kinds of weirdly specific tricks to improve mileage. Deflate the front left tire a little bit. Put a magnet on the gas cap. Fold in the side mirrors. Most of the talk about web performance is similarly technical, involving compression, asynchronous loading, sequencing assets, batching HTTP requests, pipelining, and minification. All of it obscures a simpler solution. If you're only going to the corner store, ride a bicycle. If you're only displaying five sentences of text, use vanilla HTML. Hell, serve a textfile! Then you won't need compression hacks, integral signs, or elaborate Gantt charts of what assets load in what order. Browsers are really, really good at rendering vanilla HTML. We have the technology." https://idlewords.com/talks/website_obesity.htm https://idlewords.com/talks/website_obesity.htm

stuaxo 6y ago

There's the benefit of being able to continue playing media as the user navigates the site, like soundcloud.

ilaksh 6y ago

I thought this article was going to be about HTTP 2 Server Push which allows the server to deliver pages ahead of time before you click them and thus allows for the instant transition between preloaded pages. It's strange to me that people do not appreciate that technology or discuss it more. I think it's just something that hasn't caught on.

qpiox 6y ago

Fail! The demo site does not work. Failed to register/update a ServiceWorker for scope ‘https://instantmultipageapp.com/’ https://instantmultipageapp.com/’: Storage access is restricted in this context due to user settings or private browsing mode. The article does not even try to mention this.