Ask HN: What are some concrete examples of good SPA's? | Hacker News Reader

Ask HN: What are some concrete examples of good SPA's?

4 pointsbestinterest5 comments

Hi all,

One of the arguments I keep hearing being said on Twitter and Hackernews is you should use React/Angular/Svelte when you have an more 'appy' website but I can never figure out what is meant by that.

Can we have some examples of concrete sites that are actually benefiting from SPA frameworks and would be infeasible in a typical Rails/Django/Laravel setup.

Anyone know of any resources taking a reference point of a more complex user interface and implementing it in both React and templating with Rails?

Turbolinks for me has fixed the white page refresh issue and Hotwire seems to have unlocked a few more interactivity tricks CRUD things, see https://twitter.com/noelrap/status/1341520142258348035.

But I'd like to know what interactivity I'm missing out on.

View on HN

> But I'd like to know what interactivity I'm missing out on.

The appropriate level of interactivity is merely a product design concern.

There's a point not very far down the meter where rendering HTML on the server and then implementing interactivity on top of it with Javascript is more complex and/or harder to work with than just implementing the entire client in Javascript (like how you build any other). So that's another way to look at SPAs than just "SPA = web app" which you say is hard to make sense of.

Not quite sure what kind of examples you're asking for.

The Discourse forum (https://meta.discourse.org/, used as Blizzard's official forums for example) is a large Ember Javascript app with a Rails server. Something noteworthy about it here is that instead of traditional pagination, it has a sort of scrubber in the topic view, and topics behave as an endless scroll with UI to tell you where you are in the topic.

So, deciding to build a forum as a SPA isn't because "forum = web app" (most people here wouldn't even make that connection) but rather they targeted a level of interactive UX for what they thought would make a compelling forum, and building most of the UI in Javascript was a sensible way to implement it.

Great comment, but what type of interactions do you have in mind are just easier to do with SPA and would not be possible or would be on the spaghetti side to implement with JavaScript sprinkles?

Basically at what point down the line (with some possible examples) would you say that we are at a stage where there is too much complexity to handle the page with 'manual' dom manipulation?

I think it depends on the kind of app/interactivity that you want. Hotwire/BC/HEY shows that it's possible to build apps, but the downside is at the latency for the interactions (the DOM response time depends on server location). This also applies for Phoenix LiveView/Intercooler/HTMX/etc.

With the current state of that stack, I feel it's not strictly about interactivity anymore. It's more of the feature set. Do you need the app to still be interactive/functional when offline or on spotty connections? Do you already have an extensive codebase with REST API?

Of course the interactivity level can be a consideration, but the limit of HTML responses on that side gets bumped up.

Yes latency can be a killer but I have see a few tricks with sending the request for pages on hover which seem like a really smart idea but not bulletproof compared to dealing with it client side.

With offline point I believe the complexity in offline apps must be crazy if you have a SPA, you now have 3 states to manage. The backend, the frontend and now also the frontend's IndexedDB. It doesn't help when I've not seen any great example of offline first apps work that well.

And I'll be selfish from a business point of view that the development effort and technical complexity may not be worth the cost for 90% of cases.

But agreed on if you have an existing REST API, I think another advantage of it is that is can help separate concerns and allow for front end devs and backend devs to be separate. But I really think that it is a crazy amount of complexity if you are not a huge corp.

Interactivity levels is where I'm missing the piece of the puzzle, show me a picture of a user interface that would fall apart with SSR + the new Hotwire is going to be the only way I can truly appreciate when to use SPA frameworks.

Yeah. The trick to managing the offline states is to have it as cache. So updating and solely relying on the server, and only serve when offline.

On the interactivity side, I feel that a lot of tools that I use daily justifies the use of SPA/PWA. Definitely can be passable with HTML SSR, but there's not much examples of it yet.

Todoist: No hassle offline handling. It will sync on it's own.

Twitter: They do intercept everything and handle/queue requests when the client is offline. It's not perfect though.

Roam: Again. Offline syncing, mainly offline search/document creation. This is a bit unique though as I think the server basically is just a sync logic.

I feel that the SPA stage is definitely a growing phase instead of a destination to be. There's a lot of problems that are not solved elegantly yet, and it's and the boundaries. But I feel that SPA and all of it's learnings will be an example of how the next step will be like. And with .wasm coming, there's a lot of possibility of different architectures/how to build apps.

Some talks that refers to why/how SPA makes sense for some problems/usecases:

Offline first PWA/Web App, with CRDT for syncing: https://www.youtube.com/watch?v=DEcwa68f-jY (James Long's CRDT For Mortals talk)

State management framework oriented for offline/PWA use: https://read.reduxbook.com/

Reply on news.ycombinator.com