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

141–150 of 152 posts

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

#141

Post by systematical »

cpeterso wrote: post #98
3dfan wrote: post #46

Earlier quoted context omitted.

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.

As a developer I appreciate it more, perhaps users might find it slicker. However, I go back to something another user posted "The vast majority of users don't even perceive things like page reloading, etc. Build something useful, whatever the means are." And that is the correct answer here. As the other poster stated, there are tons of applications that don't need to be an SPA. Think of damn near every admin section of a companies intranet or whatever. That thing just needs do the job, run fast enough, be easy to scale and develop on and hopefully not look like an eye sore.

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

#143

Post by whatpadk »

BlackFly wrote: post #86
reaperducer wrote: post #72

Earlier quoted context omitted.

But the thing is, almost as soon as you have any kind of significant user input to handle (multipart forms, date pickers, autocomplete elements, conditional input elements) you are instantly dealing with complex frontend state. And then your choice is not "SPA vs plain HTML forms," it becomes "SPA vs (ad hoc jQuery tangle + ad hoc server side endpoints that know to speak to random jQuery UI libraries)." In my experie…

I can believe that in your user testing people would score a non-spa higher, but that isn't relevant to the question of whether an spa had more complex state management hidden from the user than a mpa. What I imagine happened in your tests is, you didn't compare two different implementations of the same UI, you implemented the form via two different UI's and the users preferred the experience of new one to the old on…

Isn't it unuseful to be pedantic to the point of completely missing the point of the post you're replying to?

That person had something to contribute that was worthwhile. Sorry it wasn't a double-blind placebo controlled clinical trial, but it was still useful info and very much related to the topic replied to.

You must've missed the "vs plain HTML forms" part.

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

#144

Post by ernsheong »

ehayes wrote: post #8

Over the past year we replaced an Angular front-end with the author's recommendations: Turbolinks and Stimulus.js. With the pair, our app mostly feels like an SPA, but has the developer benefit of leaning on server-side rendering. The experience was wonderful and highly recommended. I think it's perfect for small teams who are more productive with traditional/backend tech.

Unfortunately, there are too many weird corner cases with Turbolinks. And it doesn't work with certain ad scripts (which ad publishers aren't interested to support Turbolinks).

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

#145

Post by BlackFly »

whatpadk wrote: post #143
BlackFly wrote: post #86

Earlier quoted context omitted.

I can believe that in your user testing people would score a non-spa higher, but that isn't relevant to the question of whether an spa had more complex state management hidden from the user than a mpa. What I imagine happened in your tests is, you didn't compare two different implementations of the same UI, you implemented the form via two different UI's and the users preferred the experience of new one to the old on…

Isn't it unuseful to be pedantic to the point of completely missing the point of the post you're replying to? That person had something to contribute that was worthwhile. Sorry it wasn't a double-blind placebo controlled clinical trial, but it was still useful info and very much related to the topic replied to. You must've missed the "vs plain HTML forms" part.

As a top level comment, it is valuable to point out that many executions of SPAs are lack lustre and will not deliver a superior user experience. If it was a top level comment and didn't lead with contradiction of the prior comment, I would have affirmed and probably not have posted anything. That is why I started by telling the commenter that I believed he actually produced better implementations, because he has a point but not a point that is meaningful to back up his disagreement.

The point of the comment chain in question is that a given UI has a need for a given amount of state. That is the point that was "[believed] false" and the point I was reiterating. User feedback is not useful at all for determining whether SPA's will require more state than multiple "plain HTML form"s. Moreover, the key assertion of the article is that this is necessarily the case, a point which is asserted without evidence and used as the foundation of the entire article. If you remove that assertion, the whole article collapses.

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

#146

Post by [deleted] »

simooooo wrote: post #127
esaym wrote: post #121

Earlier quoted context omitted.

>In the last two years I've built five very complex forms for the healthcare industry that not only had crazy looking flow-charts... Can you maybe elaborate a little bit more? I've had to do some pages for configuring industrial machinery, some having over 100 parameters, many of which would affect what other parameters could then be used or selected. Used Vue.js which worked pretty good, but I'm curious of other way…

Some of our forms have 150+ fields with a rule engine that hides/shows various sections of the forms or hides items from particular drop downs, even auto populating fields with custom data via 60+ rules. All using jQuery, and it's impossible to work on.

[deleted]

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

#147

Post by icebraining »

basch wrote: post #15
bauerd wrote: post #9

Earlier quoted context omitted.

This is true, the author seems to imply that it's somehow possible to always avoid complex UI state. Might be true for some UIs, but definitely not for all (e.g. a calendar UI would suck big time when rendered exclusively on the server-side).

is that true? googles auto-suggestions are rendered server side, as you type in the field they update. (unless I am mistake, but I thought that was the case)

That's not really "rendered" server side; the data is fetched from the server by JavaScript in JSON form, then dynamically inserted into the DOM.

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

#148

Post by icebraining »

rpeden wrote: post #63
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'm not sure stateful vs stateless is even the right way to frame it. With no JavaScript at all, your application is still stateful. Even if an individual HTTP request is stateless, your app as a whole still has state. The state just lives in the database in that case, and each request you make either gives you a view of part or all of its current state or provides data to transition the application from one valid st…

https://pouchdb.com/ works more or less like that. You just save objects, and then it'll report back when it's synced with the server.

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

#149

Post by TimJYoung »

jolmg wrote: post #132
jolmg wrote: post #123

Earlier quoted context omitted.

The reason we chose to make an SPA for the big project is that we wanted the back-end to work for multiple different types of front-ends, some potentially adding automations from the client side via the API. Who knows, were it not for that, we may have chosen a simpler HTML+jQuery design.

You know, TimJYoung, I think I may have misunderstood what you were asking. It's still one page that loads the initial HTML layout, javascript files, and HTML templates. What I meant by "page" in my original post were front-end "pages" that just modify the content of the main container tag in the actual page. I don't need to transfer state because it's already there. Clicking a link causes the framework to destroy th…

Ahhh, yes, in that case it seems like you might possibly be better off (and happier ! :-) ) with just using a page-oriented architecture. It seems like the client-side state is just getting in your way, as opposed to being helpful in any way.

The way that I look at it is this: if you're going to do an SPA, then do it like you're writing a desktop client application: all content is manipulated on the client, the only requests to the back-end are for data (JSON/XML), and the client typically will maintain quite a bit of state. Complex applications that are ports of desktop applications and sit behind authentication dialogs are ideal candidates for SPAs. Here's an example case study of such an application from our company web site:

https://www.elevatesoft.com/articles?action=view&category=ew...

The one exception to this would possibly be something like an online manual/help browser application, in which you might be able to make an exception and have the content driven by an SPA, thus allowing for more control over advanced content navigation via a tree view or vertical menu.

In general, though, if you find yourself needing to do a lot of history/page management, then that is a good indication that you might be trying to shoehorn a traditional, page-oriented architecture into an SPA.

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

#150

Post by davvolun »

whatpadk wrote: post #143
BlackFly wrote: post #86

Earlier quoted context omitted.

I can believe that in your user testing people would score a non-spa higher, but that isn't relevant to the question of whether an spa had more complex state management hidden from the user than a mpa. What I imagine happened in your tests is, you didn't compare two different implementations of the same UI, you implemented the form via two different UI's and the users preferred the experience of new one to the old on…

Isn't it unuseful to be pedantic to the point of completely missing the point of the post you're replying to? That person had something to contribute that was worthwhile. Sorry it wasn't a double-blind placebo controlled clinical trial, but it was still useful info and very much related to the topic replied to. You must've missed the "vs plain HTML forms" part.

The comparison doesn't make sense though. There's absolutely no reason you can't build an interface using single-page that functions to the end-user identically to any multi-page form. You can't necessarily do the reverse (multi-page to emulate single page), but that is also irrelevant to the top level -- if the SPA has 10 times the complexity to build an identical UI, then it's probably going to be harder to maintain for no value to the end user (which isn't to say no value).

What I got is that they built different UIs and found one of those UIs was better than the others; that says nothing about single-page vs multi-page. Maybe it was easier for them to build the "winning" UI as a multi-page app, but I didn't see that being said.

Post reply on HN