Hacker News Reader

Comment by jayceedenton | Hacker News Reader

This is motte-and-bailey argumentation in my opinion.

The motte: SPAs are a good way to write highly complex applications in the browser, like Photoshop and Figma, to compete with desktop apps.

The bailey: SPAs are a good way to write most web applications.

If you attack the bailey, proponents retreat to the motte, which is hard to disagree with. With the motte successfully defended, proponents return to the bailey, beneficial for those enthusiastic about SPAs but much harder to defend.

The only way to tease this issue apart is to stick to specifics and avoid casting SPAs or MPAs as universally good or bad. Show me the use-case and we can decide which route is best.

View on HN

Or even avoid discussing SPAs or MPAs entirely.

At the end of the day, we're talking about whether a specific interaction (or a set of interactions) can be handled over the network or not.

If you need the interaction to fully resolve (as in the state is updated and the success or failure of the interaction is visible to the user) within 800ms or so, then it shouldn't be performed over the network.

For interactive editors like Figma, you often have interactions based on key repeats, which usually fire at 50-200ms intervals. So client-side rendering is really the only feasible option.

> If you need the interaction to fully resolve (as in the state is updated and the success or failure of the interaction is visible to the user) within 800ms or so, then it shouldn't be performed over the network.

Most real-world SPA sites perform a lot more roundtrips over the network than the MPA equivalent, not less. And every roundtrip adds yet another 800ms to your update latency, plus the risk that some random network failure will break the SPA state update and force you to reload it from scratch.

Those who do not remember Lotus Notes are doomed to reinvent it.

Strangely enough, this dichotomy seems to exist only for the web platform.

Everywhere else (desktop, mobile etc) the model is SPAs.

The only reason people distinguish it for web is because of legacy: html + DOM, i.e. Documents.

Documents don't generally require programmers even if using lateX.

Both models can coexist. I believe that SPAs somewhat supersede MPAs and that an MPA can be a simplification sometimes for a specific kind of apps, a website being simply an app that has been broken apart and is sent piece by piece.

Oh my, may I remind folks about SDI vs MDI https://en.m.wikipedia.org/wiki/Multiple-document_interface

Or the window-is-application/process (Windows, Linux DEs) vs window-is-document-and-application-is-independent (MacOS) models

Or spatial navigation vs file browser.

> Strangely enough, this dichotomy seems to exist only for the web platform.

> Everywhere else (desktop, mobile etc) the model is SPAs.

It exists for CLIs too, where some projects provide a collection of single-purpose programs (e.g. imagemagick) and others provide a single program which can do many things (e.g. git)

git is a facade and "git add" actually calls "git-add". On Windows this means separate exes, git-add.exe, git-commit.exe, git-update.exe, etc. But all these exes are actually identical. So git is multiple copies of a single program which can do many things!

No not really.

Yes there are two approaches, but you can switch between the two with 98% of the code intact.

and you have identified the problem. web dev tooling, despite the extreme churn, is still absolutely poo-poo to use the technical term.

of course, mostly because very few oh-new-shiny-woah-such-modern tools doesn't even attempt to solve the problem of backend-frontend state sync. sure, maybe you get a piece of the puzzle (eg. a library that conveniently rerenders on state change, React, or one that you can wire up with all the fancy observables, Angular, or one that's super simple, sleek, even has magical runes that help with only rerendering the things affected by the state change, Svelte ... and maybe on top of these you get a state manager library, and then you still end up writing a thousand mutator/reducer in Redux by hand).

So we are still nowhere near a nice end-to-end full-stack tool that helps model both backend and frontend changes and then helps to design and implement an efficient API between them. (Because, obviously, it seems that this is not obvious to most people. Hence we get solutions like expose your DB as REST API and ship your DB via WASM sqlite, and so on.) That said, even those might be better than one more frontend-only state management lib.

I think you're discounting (1) the fact that there is only one front end runtime, and any number of backend runtimes (2) the application is distributed across a network.

Those are the reasons why SPA and MPA are so different

> Everywhere else (desktop, mobile etc) the model is SPAs.

> The only reason people distinguish it for web is because of legacy: html + DOM, i.e. Documents.

There’s another key difference: the other model has preinstalled software and most functionality is on trusted clients. If I email you a Word document, you don’t have to download Word from the Office servers to open it, which creates very different trade offs. There’s also a big difference in trust: I don’t need to ask whether I want each web page I open to have access to the data on my computer.

The web’s big selling point was the immediacy of being able open anything quickly and not needing to trust the remote server to run native code on your system (even in the 90s we knew that was a bad idea), so it’s not surprising that there’s so much gravity to its core model. The addition of more app-like abilities is really useful but it’s lead to a certain amount of app-envy where people often pick the cool technical challenge without asking whether they’re working on an app which needs it.

To me, the core of this entire issue is complexity and where it belongs.

My view is that you should perform as much processing as possible in the backend. This allows you to send as little data as possible over the network and allows your application code to make more sense because all your domain logic is centered in one self-contained app.

Now this self-contained app is just a software library, it doesn't do anything on it's own. But you can throw a CLI on top of it and use it through the terminal. You put a web api on top of it and use it from an SPA. You can use it as a backend for a server side rendered app.

The ideal, in my eyes, is that th frontend only concerns itself with actually displaying things. It doesn't get a big list of data, filter and transform the data, then display it. It asks the backend for exactly what it needs and the backend provides exactly what it needs and it displays it and that's the end of it.

Now you can have a website and a mobile app that are both trivial to develop and both use the same backend - if you fix a bug in the backend you've fixed it on both frontends.

I realize this may not always be possible or practical, but I think it is both of those things more often than not.

> beneficial for those enthusiastic about SPAs

It's almost as if some developers choose technologies based on "what'll look good on my CV"

Oh, here we go.

When we start to even think about debate fallacies when comparing engineering methodologies, it's completely clear we already lost the game. In fact, we also lost the meta game, and probably some 2 or 3 outer meta layers of it.

So yes, we should design software for the specifics of the function it will provide. Do not let people evade their competency by talking in generalities.

A fun metaphor. A SPA-inclined team/consultancy/department will retreat to their motte when necessary. They'll live to fight another day. Given a chance, they'll return to the bailey, advocating for SPAs under a relaxed standard.

Using this metaphor can imply significant disingenuity: a lack of honesty about one's true belief.

> Using this metaphor can imply significant disingenuity: a lack of honesty about one's true belief.

I actually disagree. I think this is the natural state of people, and they come by it honestly. We make decisions emotionally and then justify them rationally. It's just the way we are.

You could maybe say it's a lack of honesty about one's true belief to themselves. But even then it's hard to fault somebody for lack of awareness for something that is very subtle.

Honestly I think pointing out this human tendency and calling it out with examples like this is the best way to combat it. Once people become aware of it, they are more likely to fight it internally.

Two things. First, yes, people can deceive themselves. To the extent this is true, I take your point; it isn’t a matter of honesty in the usual sense; it is perhaps better stated in terms of self inconsistency; i.e. having internal contradictions in one’s beliefs.

Second, people do can and do lie about this kind of thing. I’m talking about conscious deception. Motives vary; they range from “I’ll pick my battles” to “this is good for my income stream” to “these other people don’t know it yet, but I’m right, and they’ll thank me later” and others.

> … I think pointing out this human tendency and calling it out with examples like this is the best way to combat it. Once people become aware of it, they are more likely to fight it internally.

Sometimes that works. Sometimes it just causes people to dig in deeper.

Reply on news.ycombinator.com