A single-page app is almost always worse than a multi-page app • Hacker News Board

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

#81

Post by PurpleBoxDragon » Tue, Oct 30, 2018, 4:23 PM UTC

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…

You do still have state, but with a MPA you have a cleaner break between each page and thus far less ability for state to persist and cause problems (though there are plenty of technologies to shoot yourself in the foot if you so desire). I wonder if the most optimal solution is to have a MPA but using some SPA technology. This reduces the overall state of every page, but still gives you decent technology to work with the state of the page that you just cannot do away with.

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

#82

Post by arendtio » Tue, Oct 30, 2018, 4:26 PM UTC

> There are cases where an SPA makes sense but this is a topic for another article.

Without that second part, this is just a trite rant against SPAs.

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

#83

Post by PurpleBoxDragon » Tue, Oct 30, 2018, 4:26 PM UTC

paulie_a wrote: post #18

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).

Honestly no it wouldn't suck and from a end user perspective for a calendar. It is actually far superior. Granted this is only my personal opinion. There seems to be this desire to overcomplicate the front end when simple solutions work quite well. Granted they don't have all the catchy buzzwords. But they make for a better less bug filled solution.

I once worked with a guy who built an app with everything done server side in web forms, including a datetime picker. It stands out in my memory as one of the worst pieces of software I've ever seen produced.

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

#84

Post by toolz » Tue, Oct 30, 2018, 4:29 PM UTC

eropple wrote: post #47

toolz wrote: post #17

Earlier quoted context omitted.

> I do, however, think they generally scale (developer-scale, not performance-scale) better than any multi-page system I've ever worked on. I've never understood this opinion. To me it seems like you're forcing such complexity that you _need_ focused developers. That by definition scales far worse than having all cross functional team of developers that can work on the view layer and the data layer (by virtue of the…

I'm both of these developers, and I don't think either part is complex or all that difficult. I have no problem bouncing from backend to frontend in the course of implementing a feature and I don't find my mental stack getting smashed in the process. If your developers aren't cross-functional in exactly the way you describe, I think you probably hired insufficiently skilled developers. ;) To me, it's more that every…

I don't think there's a production application out there not using an entire toolchain for their client side code. I'm not saying it's _too_ hard for people to be cross functional. I'm saying it's hard enough that companies often times make an artificial separation.

I don't agree with the microservice comparison because the separation of view/data layers could more easily exist with a back-end rendered application. It only exists more readily with front-end rendering because the complexity is so much higher that you find specialists in that field who can only work with that stack. The separation is purely artificial and driven by increased complexity.

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

#85

Post by PurpleBoxDragon » Tue, Oct 30, 2018, 4:30 PM UTC

jhall1468 wrote: post #56

juandazapata wrote: post #14

Earlier quoted context omitted.

From the blog post > Third, if you’re implementing a very complicated component then you can use React just for that component.

LOL. So avoid complexity by writing in VanillaJS, but feel free to load an enormous frontend library for a single component. Makes sense.

I'd assume it is to have a enormous front end library to handle all your complicated components and the author would be horrified by the prospect of every component written with a different front end library. It does present an issue if you literally have a single component that needs it, but I think this advice was aimed at cases where there are many such complicated components.

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

#86

Post by BlackFly » Tue, Oct 30, 2018, 4:33 PM UTC

reaperducer wrote: post #72

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…

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 one.

I believe that you compared different UI's because otherwise you wouldn't need user testing: you could just measure the latency and code complexity.

The person you are responding to is saying, for a fixed user interface design, the necessary state management will be the same and your only choice is how to implement it. You say you believe this to be false but it doesn't seem like you are responding to the point.

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

#87

Post by wstuartcl » Tue, Oct 30, 2018, 4:34 PM UTC

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…

shrug

That feels like a straw man, you can obviously also use modern js and a decent framework (vue react whatever) to make the portions of the page that need state, transitions and complex interactions very user friendly and easy to reason about without pulling the entire site or section of site up into an SPA. I have seen far too many implementations pull whole sites or large sections of sites up to SPA to mitigate one complex form or stateful interaction area. There is obviously a range of implementations that can be done from SPA|--------------------------|Page-Level and none of the areas on that spectrum require you to do anything in a"jquery tangle" let alone with any jquery include at all.

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

#88

Post by bunderbunder » Tue, Oct 30, 2018, 4:36 PM UTC

rovek wrote: post #77

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…

If you didn't use JS for date pickers, you didn't have very inclusive browser support - especially for something like a healthcare website. [1] Were the designs and layout of these SPA and HTML5/CSS3 website also identical? [1] https://caniuse.com/#search=input%20date

If it's public facing, that's a huge concern.

If it's intended for business users, particularly if on an intranet site, it's often very easy to limit the number of browsers and versions you need to support to just a handful.

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

#89

Post by bunderbunder » Tue, Oct 30, 2018, 4:41 PM UTC

okal wrote: post #80

At my current workplace - as a deliberate design choice - and last one - organically "discovered", but deliberately maintained - we've tended towards building user facing products as collections of smaller apps sharing a backend, rather than typical SPA (Single Page Application) architecture What that means in practice is that: 1. Routing is always handled server side. The less frontend state (IMO/IME) the better. Th…

Another potential benefit is reduced toolkit lock-in. Migrating a bunch of smaller pages one at a time is pretty doable. Migrating a large SPA without disrupting business could be like trying to pass a camel through the eye of a needle.

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

#90

Post by richardwhiuk » Tue, Oct 30, 2018, 4:42 PM UTC

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?

If it stopped the developer doing some ridiculous animation and providing me with a list of products like every ecommerce website on the net, then, sure. Also, why do you need the submit button? Just let me click on a link which filters by 32 GB and be done with it.