Your single-page app is now a polyfill

https://itnext.io/your-single-page-app-is-now-a-polyfill-7881fb01694e

by mhoad • 6 years ago

164 158 6 years ago

obilgic• 6 years 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.

lukestevens• 6 years 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-b...

cblconfederate2• 6 years ago

not so sure about that. alexa stats and every other stat show them on a downward trend

kecupochren• 6 years ago

use incognito mode

AA-BA-94-2A-56• 6 years 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_hp2• 6 years 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.

jelling• 6 years 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.

vnglst• 6 years 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

Geee• 6 years ago

On desktop Safari as well.

PudgePacket• 6 years 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.

chrismorgan2• 6 years ago

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.

the_gipsy4• 6 years ago

This is just one bug you found. There are more edge cases for sure, serviceworkers intercepting requests and caching is a nightmare.

dannymoerkerke2• 6 years ago

Thanks for reporting. There were some problems on the backend but this has now all been solved.

Deukhoofd• 6 years ago

Which in turn means that sites using this technique will not work in private browsing mode.

dannymoerkerke2• 6 years ago

That is not correct. There were some issues on the backend but these have now been solved.

jpnelson• 6 years 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-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• 6 years ago

Server-side rendering on the client

JavaScript has gone too far :D

mad182• 6 years ago

What does it even mean?

sambeau• 6 years 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.

brailsafe2• 6 years 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.

Scarbutt3• 6 years 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.

pier2513• 6 years 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• 6 years ago

Serverside caching with e.g. doesn't help with network latency.

mdoms2• 6 years 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.

inglor• 6 years 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.

fxtentacle3• 6 years 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

the_gipsy4• 6 years ago

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.

dntrkv• 6 years ago

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.

cjstadler• 6 years ago

Are you on Firefox? This resolved it for me: https://support.mozilla.org/en-US/kb/twitter-isnt-working-fi...

kreetx• 6 years ago

The problem might be that it's just not well understood yet, it definitely has it's use cases.

That said, I recently tried Twitter's PWA and it went into an infinite page refresh loop right after login. So yeah, not easy to get it right.

jupp0r• 6 years ago

Have you used the internet lately? Service Workers are ubiquitous. Google.com is using them. Amazon.com is using them. Your uncles blog is probably using them too.

Sure they can be tricky, but don't dismiss their success.

tziki• 6 years ago

First, I think service workers are essential if we don't want all future apps to live and die by arbitrary app store restrictions. Service workers provide a lot of functionality that make web pages competitive (feature-wise) with apps. Second, I'm sure you've seen plenty of implementations that were just fine, you just didn't notice. Angular comes with a default implementation that does caching and plenty of sites use it.

haywirez• 6 years ago

You can send a Clear-Site-Data header[1] for forcing a full refresh.

[1] https://w3c.github.io/webappsec-clear-site-data/#header

aitchnyu• 6 years 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.

jiofih3• 6 years 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).

recursivedoubts4• 6 years 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.

nawgz13• 6 years 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.

redwall_hp2• 6 years ago

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, opening the links and then comment pages in new tabs.

vorpalhex• 6 years ago

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.

Udik• 6 years 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.

brailsafe2• 6 years 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_• 6 years 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.

imtringued3• 6 years 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.

astura• 6 years ago

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

fxtentacle3• 6 years 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.

gabipurcaru2• 6 years 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/). 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• 6 years ago

Yeah, I did the same with 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• 6 years 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.

victor106• 6 years ago

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

nyanpasu64• 6 years ago

In single-page apps, navigating between pages is hard to get right. https://vector-of-bool.github.io/ implements its own JavaScript-powered page turning. However if you press End on a long page, then navigate to a short page and back to the long page, the browser's scroll position gets truncated.

In the "Instant Multi-Page App", navigating between pages "just works".

simonw• 6 years ago

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

nexuist5• 6 years ago

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?

macNchz• 6 years ago

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.

lhorie2• 6 years ago

that's going to be less than 1ms of delay

That doesn't jive with my experience. If you are using something like React to do client-only rendering, you're gonna be waiting a lot for blocking critical path JS to run, as well as the actual paint time (which alone can easily be in the hundreds of milliseconds).

Ship your users an app including a copy of the data ahead of time

That's not really feasible though, is it? Most SPAs in the wild fetch data on demand, so you still get the network latency no matter what (on top of the delay due to no streaming each time). This is why you get those skeleton placeholders on sites like Facebook.

nawgz13• 6 years ago

which alone can easily be in the hundreds of milliseconds

This actual paint time is surely not any different than if you rendered the exact same application from pre-hydrated HTML though.

Plus, if your application is so complex that paints are on the order of magnitude of network latency, it's probably very important to have a framework to handle interactivity, else everything will end up as some kind of a mess if you try to re-load the whole HTML page to change some small DOM subtree.

Overall, I don't really see the situation where an SPA is performing worse than a server-rendered application, given that some in-browser interactivity is required.

qpiox2• 6 years ago

Misses the point on so many levels.

Fastest experience will always be without a special framework. Fastest will always be if there is nothing except the content served in a single minimal request/response. So, this means no JS (excepct issuing requests), no browser framework, pure content. Browser sends the simplest request and receives simplest content. User reads it or looks at it. Fast as hell. It can't be faster than that because JPG can not be compressed further, gzipped HTML can not be compressed further. With later HTTP implementations, the connection can already be open and re-used.

To explain this with an analogy. Bloatware comes when you decide that your true content is not enough to be appreciated as is, and needs to be beautified, made interactive, .... Just like make-up. Without make-up you only need to show your face. When you decide to use make-up to cover the true content (your true face), you need huge ammount of overhead - you need to buy the make-up, you need to learn how to apply the make-up, clean the make-up, re-apply the make-up. You need robust make-up. You need waterproof make-up. Then you need special cleaner because water will not be able to clean it. Then you start needing a make-up framework, to help you clean, apply and re-apply the make-up consistently and easily. So reinventing make-up frameworks will do nothing in alleviating overhead. Dropping the framework is the best way to go.

I hope this analogy makes things clear what I meant.

PinguTS• 6 years 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.

manigandham5• 6 years 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• 6 years 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.

pier2513• 6 years 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.

mdoms2• 6 years 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.

playpause• 6 years 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.

onli2• 6 years ago

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.

scsilver3• 6 years ago

Yeah it took over a second to get to this comment page. A lightweight js app could have popped up a modal, I put in my comment, click send, and hide the modal and show a spinner on the bottom right changing to a checkmark when the comment goes through. That's feeling instant, not waiting for the back and forth to a server. The other stories could be lazy loaded in the background as I scroll.

shusson2• 6 years 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• 6 years 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.

shusson2• 6 years 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.

pier2513• 6 years ago

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.

robertlagrant• 6 years ago

SPAs also can scale better - CSS, JS and HTML all just static files, not rendered by a server.

tpxl• 6 years ago

In fact, what do people on HN think the main reason to choose an SPA is these days?

The only reason to choose a SPA is when you need an _application_.

A blog has no reason to be a SPA. A news site has no reason to be a SPA. HN has no reason to be a SPA.

An internal support tool has a reason to be a SPA. A messaging app has a reason to be a SPA (slack et. al). A music player has a reason to be a SPA (spotify).

petilon• 6 years 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

And here’s the client-side router, which is all of 500 lines:

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.

cblconfederate2• 6 years 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?

imtringued3• 6 years 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• 6 years 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.

dspillett2• 6 years 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.

pier2513• 6 years 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.

blueblisters• 6 years ago

Why would users expect that? Most of websites use multiple pages and users are used to that.

I concur with this sentiment. Most SPAs I have interacted with end up being a bad experience because when a page change action does not result in a page refresh, I expect the content to be delivered with native-like performance. Obviously, mobile and desktop browsers don't deliver that just yet. I doubt they ever will until mobile platforms figure out a way to charge a cut of any transactions happening on these apps.

fravelgue• 6 years ago

Is this something similar to Turbolinks of Basecamp?

codeulike• 6 years 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• 6 years 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• 6 years ago

Isn't this what turbolinks already does?

jdauriemma• 6 years ago

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

pier2513• 6 years 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).

Scarbutt3• 6 years 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.

pier2513• 6 years 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?

Justsignedup3• 6 years 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• 6 years 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.

Justsignedup3• 6 years 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.

WillPostForFood• 6 years ago

These are good reasons, but notice they are all about improving the experience for the developer, not the user.

debaserab2• 6 years ago

If you have a messy codebase with logic mimicked on both the back and front end its not just the developer experience that suffers - the user experience will eventually suffer too.

Justsignedup3• 6 years ago

I mean isn't that what ruby on rails is? RoR's minimum response time is WAY slower than most other frameworks. Getting a ruby on rails page rendering in under 100ms is work, while other frameworks getting it under 50ms isn't much effort at all.

Tradeoffs everywhere. If I needed to serve my pages to an area where downloading 1mb would take a minute and that was my core demographic, I will be making very different choices in tech than what most people have to write for.

dougmany• 6 years ago

I am curious what tools you are using. I am trying to upgrade Angular 1.4 to 1.7 and it is a nightmare. Has your method had any sort of time test for upgradability?

nawgz13• 6 years ago

Angular 1 is ancient and terrible.

I've been developing React for the last 5 years, times change and "best practices" change with them, but my 3 year old model / graph editor seamlessly upgrades across React versions, even if my eyes don't love the code like they once might've.

FpUser• 6 years 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.

pier2513• 6 years 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• 6 years 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.

fareesh• 6 years 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• 6 years 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

stuaxo• 6 years ago

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

ilaksh• 6 years 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.

qpiox2• 6 years ago

Fail! The demo site does not work. Failed to register/update a ServiceWorker for scope ‘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.

Your single-page app is now a polyfill

Related Stories