[lukevp]

It depends on how much data is centralized. If creating a new email round trips to the server to render in the next email list page, it may feel instant on a fast connection. With a SPA framework, it could add it to the local list of emails and push to the server in the background, so it would transition instantly regardless of connectivity. It would also work offline. If you are doing all business logic on the server side anyway, then yeah SPAs vs a server is not much different. But there is a whole class of problem that the server rendering cannot solve. Most email clients work offline and have an outbox. With a SPA you could have the web and mobile apps have the same exact code and support offline. With their setup, you have to build a native (or at least separate) app from the web app. This decision matters a lot when you’re making an app that should work everywhere, online and offline, with the exact same code.

[charukiewicz]

> With a SPA framework, it could add it to the local list of emails and push to the server in the background, so it would transition instantly regardless of connectivity.

With an SPA, it could be built to do this. But most SPAs aren't developed this way.

Take a look at the "RealWorld" example SPA showcase (it's like a TodoMVC for SPAs), which has 43k stars on GitHub: https://github.com/gothinkster/realworld

And go ahead and click on the demo site: https://demo.realworld.io/

In virtually every implementation, every time you change pages, the app re-downloads everything it needs for that route. Click on an article and then go back to the feed? Every time you will see a blank feed for about 500ms and only then do the articles stream in.

You can say "well it doesn't have to be this way" or "this is just an example". But the reality is that it usually is this way. This real world example is a good representation of how most SPAs are built, and they lack the type of functionality you're describing. They instead end up creating an experience that poorly emulates server side rendering, since now many page changes end up with a blank page or a loading indicator before the data arrives in a subsequent request.

I don't know about you, but I'd rather wait 250ms once and then have the page arrive fully rendered over a transition that takes 2ms and then 200-400ms of multiple requests finishing and the page popping into place. The latter is really annoying, yet it's the experience most SPAs give you.

[lukevp]

My post was not about what is probable but what is possible. Hey is an app, not a website, that has been built by an entire team of developers over 2+ years, with multiple millions of dollars, not a gatsby app on Netlify made in 30 minutes. They could have made this work fully offline in React in this time, if they wanted to.

[juandazapata]

Off-line support is trivial. https://twitter.com/javan/status/1274168003773566977

[JamesSwift]

Ummm, anyone claiming offline support is trivial has clearly never written offline support. I'll give you a clue: cache invalidation (and data reconciliation) is hard.

[charukiewicz]

In your post you made it sound like most SPA frameworks will take care of this for you.

> With a SPA framework, it could add it to the local list of emails and push to the server in the background, so it would transition instantly regardless of connectivity. It would also work offline.

None of this happens automatically with SPA frameworks, and it requires a custom implementation of offline functionality in the context of the business domain (what to store, what to send to the server when connection is reestablished, which data to re-synchronize). It's hard to do, which I think is why most SPAs don't do it.

Moreover, it's clear that DHH is not interested in even something like basic PWA support, and will instead spend his time attacking Apple for not approving their app on the app store.

[eitland]

> Moreover, it's clear that DHH is not interested in even something like basic PWA support, and will instead spend his time attacking Apple for not approving their app on the app store.

Let me paint a somewhat less strawman-y picture of DHH for the benefit of those who doesn't know him:

- He is the guy who built Rails and inspired a huge number of other frameworks from Symfony and Laravel to parts of modern JavaEE.

- "His" apps (obviously built together with others) were early examples of actually working Ajax.

- He has been preaching against the hunt for unicorns for a decade or so I think, talking about sanity and sustainability.

- I think the thing about PWA is less that he isn't interested in it and more that he wants things to just work across all browsers.

- The thing about Apple is less about attacking Apple and more about defending himself - and in the process a number of smaller devs - against abuse from Apple.

I have a lot of nice things to say about Apple, but for cases like this where you wonder if it was Apple or Oracle who called you to extort money then Apple deserves all the criticism rhey get (and then some more if you ask me). Just because one is mostly nice doesn't make it OK to run an extortion racket on the side.

(Apples platform, Apples riles one might say but as far as I have seen so far they didn't break any of the rules, so even by that rule Apple is in the wrong here until they change their rules to add something tvat allows them to do this.)

[akiselev]

I think that's holding SPAs to a higher standard than server side rendering. To compare apples to apples, you'd have to compare to the real world SSR app - think the average corporate intranet django monolith. Sure it's easier on client side network and CPU resources but the same engineers that create SPA monstrosities are the ones that create SSR monstrosities.

[Albert_Camus]

I don't think it's holding SPAs to a higher standard. It's holding SPAs to a reasonable expectation for SPAs. An SPA is significantly more complicated on the client side in exchange for some purported benefits, especially to the user (such as only downloading what you need). If everything is discarded on each "page" transition and re-downloaded again upon a return, and has the page-popping-into-place effect, that eliminates one of the foremost benefits of an SPA and diminishes the UX.

I encourage anyone developing an SPA to go talk to actual end users about this. Most will report that they don't like the experience, often citing a variety of issues, but one of the biggest ones is related to the immediate page transitions followed by blank boxes or loading spinners for a perceptible amount of time. You'll hear comments like "it feels too fast" or "it feels like nothing is happening". These are not good things, and developers shouldn't be clutching their React/Angular/Vue/whatever framework just because it's what they know how to develop in, at the cost of producing products that users don't like as much as normal server side rendered applications.

[mauflows]

> such as only downloading what you need

I think SPAs provide great benefits, but most users only visit a single page. So I would add that SPAs also tend to download more than you need (in JS) if it's something like a blog

[save_ferris]

You’re also still paying a performance penalty for interacting with the virtual DOM in react. It’s not like react is just more complex to develop on, it’s also a noticeably slower experience in some cases (looking at you, Reddit.)

I’m also not completely convinced that the one-codebase ethos actually results in that much more efficiency, particularly given that one codebase is JavaScript. I’m sure there is a gain, but I don’t know that it completely offsets the costs of being so tightly bound to the JS community, but that could just be my experience

[lukevp]

Vdom is a common point of premature optimization. React is very fast if you are rerendering components correctly. Turbo links is still having to diff just like react/vdom.

[welearnednothng]

Turbolinks merges the contents of <head>, but replaces the contents of <body> outright. No diffing on the body.

"During rendering, Turbolinks replaces the current <body> element outright and merges the contents of the <head> element. The JavaScript window and document objects, and the HTML <html> element, persist from one rendering to the next."

https://github.com/turbolinks/turbolinks#navigating-with-tur...

[tomlagier]

Not to be pedantic, but there is manual "diffing":

https://github.com/turbolinks/turbolinks#persisting-elements...

[welearnednothng]

Hey! I just saw this and thought I'd follow up for posterity's sake in case anyone else came across this.

This gets into how we want to define "diffing", but I would say no, no there's not any diffing on the body, manual or otherwise. Per the linked section:

"Before each render, Turbolinks matches all permanent elements by id and transfers them from the original page to the new page, preserving their data and event listeners."

So, at no point is it attempting to determine a difference between two pages. Instead, it simply queries for appropriately tagged elements (from the source code, 'this.bodyElement.querySelectorAll("[id][data-turbolinks-permanent]') and copies those over to the next page.

Thus, it's declarative rather than algorithmic and not what I would consider "diffing" at all. In this context, the parent to my comment stated it's "still having to diff just like react/vdom", which certainly isn't the case.

Cheers!