Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A single-page app is almost always worse than a multi-page app

gregnavis.com

Post reply on HN
Print view View original

91–100 of 152 posts

Re: A single-page app is almost always worse than a multi-page app

#91

Post by marcosdumay »

thecatspaw wrote: post #58
decasia wrote: post #6

So, the OP argues that SPAs introduce unnecessary frontend state: "I think this is a very underappreciated aspect of SPAs. Stateful software is always more difficult to work with than stateless. The frontend state is added on top of the already-existing backed state. This requires more development time, increases the risk of bugs, and makes troubleshooting more difficult." But the thing is, almost as soon as you have…

With SPA you usually dont add frontend state on top of backend state, you only have the frontend part, and a stateless API. This makes it very easy to test and reason about.

> stateless API

Does it not access any data?

Re: A single-page app is almost always worse than a multi-page app

#92

Post by marcosdumay »

3dfan wrote: post #39

How would something like this work as a non-single-page-app: https://www.productchart.com/laptops/ Would the user have to chose "32 GB Ram", hit a submit button and wait for the page to reload with the matching laptops?

That's basically how every other product comparison site works. And, honestly, this is one of the worst ones I've seen.

Re: A single-page app is almost always worse than a multi-page app

#93

Post by TimJYoung »

decasia wrote: post #6

So, the OP argues that SPAs introduce unnecessary frontend state: "I think this is a very underappreciated aspect of SPAs. Stateful software is always more difficult to work with than stateless. The frontend state is added on top of the already-existing backed state. This requires more development time, increases the risk of bugs, and makes troubleshooting more difficult." But the thing is, almost as soon as you have…

My problem with the idea that SPAs, as an idea, are inherently more difficult to develop is that this doesn't translate to desktop/mobile applications, which are, conceptually, very similar in architecture (fat UI client, app server on the back-end). What may be more true is that the way in which we develop SPAs is so flawed that it causes serious issues with quality/development effort. IOW, perhaps the issue is with JS and its limitations with large, complex client applications, not the SPA architecture.

Disclaimer: my company sells a web development product that creates SPAs that work like desktop applications.

Re: A single-page app is almost always worse than a multi-page app

#94

Post by TimJYoung »

jolmg wrote: post #69
decasia wrote: post #6

So, the OP argues that SPAs introduce unnecessary frontend state: "I think this is a very underappreciated aspect of SPAs. Stateful software is always more difficult to work with than stateless. The frontend state is added on top of the already-existing backed state. This requires more development time, increases the risk of bugs, and makes troubleshooting more difficult." But the thing is, almost as soon as you have…

That's like saying that if you have to kill a fly, why opt for swatter when you can use a bazooka? After spending some years building an SPA webapp, I'm really missing the simplicity of stateless HTML. The front-end framework my colleagues picked really likes to carry state around, like between pages, which has caused numerous hard-to-find bugs. These bugs are triggered when you do certain sequence of actions across…

Legitimate question: if you have multiple pages, are you still actually creating an SPA ? That may be the problem that you're encountering, and I can sympathize. Nobody wants to transfer state across page loads, it's a mess...

Re: A single-page app is almost always worse than a multi-page app

#95

Post by TimJYoung »

marcosdumay wrote: post #91
thecatspaw wrote: post #58

Earlier quoted context omitted.

With SPA you usually dont add frontend state on top of backend state, you only have the frontend part, and a stateless API. This makes it very easy to test and reason about.

> stateless API Does it not access any data?

Most JSON/data APIs for SPAs are similar to SQL database servers: maintaining a persistent connection is useful for performance reasons, but there's nothing about the API that dictates that it's required. The only state that is required across API calls is an authenticated session, and that is maintained on the server side.

Re: A single-page app is almost always worse than a multi-page app

#97

Post by ravenstine »

I don't really agree with the author that SPA's are almost always worse. Although sometimes they're gratuitous, as was the case with a lot of early Angular apps where it was pretty clear that the developers thought they were being cool by making way too many things behave "dynamicky" for the sake of having their work appear more like an app than a site.

On the other hand, there are plenty of times where a multi-page app is just fine. If that's the tool that works best for you, then by all means use it. The vast majority of users don't even perceive things like page reloading, etc. Build something useful, whatever the means are.

Re: A single-page app is almost always worse than a multi-page app

#98

Post by cpeterso »

3dfan wrote: post #46
rocky1138 wrote: post #41

Earlier quoted context omitted.

I can't decide whether you're joking or not. That's how the web has worked since its inception until just a few years ago when SPAs appeared on the scene. I don't think SPAs are always a bad idea, but they sometimes are. For instance, I've gone back to HTML Gmail and I love how fast it is compared to the JavaScript mess the main product has become.

Not joking. It was a rhetorical question. What I mean: This is an example where a single-page approach is better. I agree that there are many single-page sites that would be better if they were multipage. But I'm not sure the "almost always" is justified. The title of the article is even stronger "The Architecture No One Needs". But you and I clearly can bring up examples where it's an architecture that does make sen…

Why is this product chart SPA better than a simple MPA? The zoom animations do not add any value to the user experience.

Also, with this SPA, you can't bookmark or a share a URL to a particular hardware search, so information and usability is lost. The URLs could be fixed, but the SPA has to explicitly manage the page history. An MFA gets that for free.

Re: A single-page app is almost always worse than a multi-page app

#99

Post by dzwillia »

ishi wrote: post #52
decasia wrote: post #6

So, the OP argues that SPAs introduce unnecessary frontend state: "I think this is a very underappreciated aspect of SPAs. Stateful software is always more difficult to work with than stateless. The frontend state is added on top of the already-existing backed state. This requires more development time, increases the risk of bugs, and makes troubleshooting more difficult." But the thing is, almost as soon as you have…

I agree, but using a front-end framework does not mean you must build your entire app as an SPA. You can still have separate pages, and UI components on each page get handled by your framework of choice. Also, there's a big difference between the state of a single form vs. keeping the state of your whole application in the frontend!

...and this is really what it comes down to. State management should come down to what the front end has to manage in order to be well-organized and structured. By creating a multi-page app, all you are doing is forcing yourself to organize your state by page. This is something that can be done simply enough by using modules in your state manager of choice. With a SPA, you have the option, with MPA, the decision of overall organization has already been made.

Re: A single-page app is almost always worse than a multi-page app

#100

Post by BlackFly »

crazygringo wrote: post #11

Sorry, but this is just silly and looks at the problem from the wrong end. Of course single-page apps generally require far more development than multi-page. Of course they require more state, more testing, are slower to load, etc. But they also do a million things multipage "apps" can't and, and therefore have the potential to provide a vastly better user experience at the end of the day. In the end it's same tradeo…

It is not at all obvious to me that a single page application requires more state than a multiple page application.

Consider a choose your own adventure book.

Both a single page application and a multiple page application can implement this entirely through the url and I don't see how I have any state other than the url.

If that is too facile, there were choose your own adventure books where you had hit points and could fight monsters. So now I store hit points in the session or in the url or in the single page application's state.

Single page application doesn't mean single url. I don't exactly understand what additional state would be required to implement any particular user experience via a single page application or multiple page application. The only difference I see in either case is where the state gets managed and mutated.

Post reply on HN