upvote

points

by epolanski6 hours ago |
comments
upvoteby ko276 hours ago|
next
[-]
> the average device and connection is insanely faster than 10-15 years ago

Using the same reasoning, I’d come to the opposite conclusion. Devices are much faster than they were 10-15 years ago, but network latency is still roughly the same because physics limits how much it can improve. So reducing network round trips matters more than ever, which favors SPAs over MPAs.

reply
upvoteby 5 hours ago|
parent|
next
[-]
deleted
reply
upvoteby bbg24016 hours ago|
parent|
prev|
[-]
I’m not sure I follow.

SPA’s tend to require more network round trips, sometimes significantly more based on the architecture.

reply
upvoteby Izkata6 hours ago|
parent|
next
[-]
But a lot of the time they can happen in the background where the user doesn't see them, or on a part of the page the user isn't currently interacting with, preventing it from being a stop-the-world interruption.
reply
upvoteby ko275 hours ago|
parent|
prev|
[-]
It’s in the name: an MPA requires a page roundtrip for every navigation, while SPA requires a single page roundtrip. Any subsequent requests are part of the application itself and can be handled without disrupting UX.
reply
upvoteby christophilus3 hours ago|
parent|
next
[-]
An MPA can make as many queries/service requests as it needs to to render the result. Most— the vast majority of SPAs I’ve ever written, maintained, or used— do that from the client, making many requests to render the new route.

The UX for an SPA can indeed be excellent, but the average SPA is worse than the average MPA, in my opinion. It’s just much easier to break things in many subtle ways in an SPA.

reply
upvoteby inigyou4 hours ago|
parent|
prev|
[-]
An SPA still requires roundtrips, just not to load the DOM root. Most of them do more than one roundtrip per navigation, making them worse than MPA. They also break loading screens.
reply
upvoteby Exoristos3 hours ago|
parent|
[-]
They don't have to be that way.
reply
upvoteby inigyou1 hours ago|
parent|
[-]
They still are
reply
upvoteby johsole6 hours ago|
prev|
next
[-]
One nice thing about using React even on the web is that it forces your Backend to be REST right from the start. Although I sincerely thing that is less important now with the explosion of LLMs. I've started thinking about everything as Display + MCP Server. Where a SPA front end is really just pre-defined display.
reply
upvoteby lunar_mycroft3 hours ago|
parent|
[-]
> One nice thing about using React even on the web is that it forces your Backend to be REST right from the start.

The creator of HTMX would disagree with you (as the person who described and coined the term REST)

https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...

reply
upvoteby shooly6 hours ago|
prev|
[-]
> React/Vue/etc solve a specific problem: single-page application

That's not true. They solve the problem of requiring separate code paths for interactive elements - one for initial render and another for updates.

Previously the server rendered the initial HTML and then client JS updated it after e.g. user clicks a button, but with React/Vue/etc., it's merged into one code path because HTML is derived from the current state.

> Even multi billion companies hiring leetcode ninjas can't get acceptable user experience

Modern UX is bad because many front-end programmers fundamentally just do not care about the UX, it's not about the specific tech they use.

reply
upvoteby austinthetaco2 hours ago|
parent|
next
[-]
> Modern UX is bad because many front-end programmers fundamentally just do not care about the UX, it's not about the specific tech they use.

This is untrue and is weird misunderstanding on your part. Most of modern UX and UI is designed to fit the needs of the customer for the frontend team/dev: the product or marketing or sales department. The user of the website is very rarely the customer for the dev.

reply
upvoteby recursive5 hours ago|
parent|
prev|
next
[-]
Only react "solves" that. In vue component setup only runs during mount. Update is not a thing in the way react has it.
reply
upvoteby shooly4 hours ago|
parent|
[-]
The point is that there's only one template and DOM is derived from that template. This concept is the same in both Vue, React and other popular component-based UI frameworks.
reply
upvoteby epolanski6 hours ago|
parent|
prev|
[-]
> A Single-Page Application (SPA) is a web application or website that loads a single HTML page and dynamically updates its content as users interact with it, rather than loading entire new pages from the server.

That's the definition, I didn't made it up.

And those libraries solve that.

Your other definition, can be fully implemented server side, Elixir's Phoenix does that. But it's not the only one.

reply
upvoteby robertlagrant6 hours ago|
parent|
next
[-]
> That's the definition, I didn't made it up.

Your prior claim was that they only solve one problem, not about a definition. They solve several problems:

- less data can move over the wire compared to sending a full page every time (this is in your definition, and is definitely not always true, as sometimes REST APIs can return far more data than what's needed to render the screen)

- the same REST/data API can serve your website and other consumers, e.g. any native mobile apps or third party API consumers

- you can write tests for your frontend, e.g. you can unit test components' behaviour and style in isolation

- the frontend can also work, or at least respond usefully to the user, when the network or the backend are not working

reply
upvoteby throwaway77833 hours ago|
parent|
[-]
That second point is almost never true " the same REST/data API can serve your website and other consumers, e.g. any native mobile apps or third party API consumers"

In a reasonably complex application, each interface ends up needing its own shape of optimized APIs. Otherwise the clients become very complex munging/reshaping data or making too many API calls, throwing away a lot of data etc.

reply
upvoteby shooly6 hours ago|
parent|
prev|
[-]
You said, that React/Vue/etc. solve a specific problem: SPAs - that's not accurate. That's not the problem they solve.

According to what you said, CSS also solves the problem of making an SPA because you could "switch pages" by changing CSS class names on `body`. But if someone asked what CSS is you're not gonna answer "you use CSS to make an SPA", even though _technically_ you can use it to make an SPA.

reply