Hacker News Reader

Comment by ko27 | Hacker News Reader

It's funny that you, and probably a lot of HN folk, consider MPA simpler than SPA. It's opposite in my experience. The name itself is actually telling you that it has more complexity (multi page vs single page).

In practice, you can make both as complicated as you want, but SPA seems like a simpler starting point.

View on HN

The earliest web apps I worked on were multi-page apps, with pages generated by Perl CGIs, later PHP. There was almost nothing going on on the client side except form submissions and a bit of JS-based form validation. I can tell you with 100% certainty this was simpler to build than most anything I see today with React SPAs and REST APIs. Even a simple form submission can be a PITA with modern tools.

> Even a simple form submission can be a PITA with modern tools.

SPA excel in complex interactions if you need only very simple forms it will be PITA

I think the argument is generally that most applications' "complex interactions" are artificial contrivances and are unnecessary. I certainly think so.

SPA definitely have their place. However, when I see them be used for content-oriented sites with minimal user interaction (few forms, etc.) I wonder what guided the decision.

It can definitely seem this way if you only consider the front end. But a challenge that many SPA apps run into is that for the vast majority of SPA apps you end up in a situation where the front end and back end need to share business logic, and this can be a very complex thing to model and maintain, with either duplicated effort (and the potential of drift) or complicated solutions to keep them in sync, particularly if your front end and back end technologies aren't identical.

Most MPA apps treat the browser and front end as dumb clients basically - strictly responsible for putting stuff on a screen

The complications are not coming from the M or S part of the acronym, it comes from the words “Page” and “App” being intertwined. Or in other words 18 years of trying to hammer the web browser (conceived for “pages”) into an app platform.

It is the spectrum of interactivity. If you are a CPP/AI/Go dev who needs a static blog with simple form, you'll believe server rendered MPA are way to go. If your site has interactivity and dynamic status/notifications, you'll believe SPA makes sense. Unfortunately like in everything now days people assume other side is idiot and pick up pitchfork.

How is SPA a simpler starting point? It requires more code and more abstractions in the client from the onset. One might argue that that complexity would just exist in the backend in an MPA, but that's not true: there is some additional backend complexity, but not nearly as much as required to support the multitude of clients that exist for the baseline in an MPA.

Because in most web apps you still need to have client-side logic anyways, like form validation and such, so familiarizing yourself with a SPA framework is simpler than learning to implement this in addition to the MPA framework you'll probably end up using anyway.

Reply on news.ycombinator.com