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

#101

Post by illiac_1962 » Tue, Oct 30, 2018, 5: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…

Queue up a huge debate that essentially results in qualifying web development as the train wreck dumpster fire school shooting that it is. Painful in many ways all at once.

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

#102

Post by koolba » Tue, Oct 30, 2018, 5: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…

Or just have multiple pages with the complicated ones rendered with something like React. Nothing stops you from having more than one app bundle and with proper packaging it’s not even particularly slower to download or parse.

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

#103

Post by jrochkind1 » Tue, Oct 30, 2018, 5:25 PM UTC

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…

> I can add, remove, and edit rows from an HTML table without javascript or server side state

I may be being dense, but can you provide me with a hint as to how? I guess the answer is "css", but it's not obvious to me how you would do this.

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

#104

Post by illiac_1962 » Tue, Oct 30, 2018, 5:26 PM UTC

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…

I am particularly amused that the author confused architecture with project structure and frameworks. If your core business logic changes to meet any part of the UI you should be horse whipped and dropped off at a daycare.

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

#105

Post by jrochkind1 » Tue, Oct 30, 2018, 5:27 PM UTC

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…

> I envision a Smalltalk-ish environment where, in my application running in a browser, I send a message to an object telling it to save itself.

It sounds to me like "what if Javascript had SOAP", heh.

We can envision lots of things. The beauty of software engineering/architecture is you can envision almost anything.

The trick is that the more complex the thing is, the harder it is to pull of _well_, and the easier it is to end up with a monster.

The complicated things take more expertise/skill/experience to design, and _also_ take more development time to produce -- and on an ongoing basis to maintain. And it's not always clear where development resources come from on 'shared commons' like platforms (unless they are proprietary and only available for a fee). The current front-end JS environment is already _pretty darn complex_ of course. How well it's pulling it off, well, is a matter of debate central to the OP.

On, and then there's getting different actors to coordinate in thing that require that (like browser's supporting something).

I can envision it too. But I wouldn't wager much on it happening in a way that actually results in an improved development environment (instead of a monster).

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

#106

Post by Zooper » Tue, Oct 30, 2018, 5:28 PM UTC

Alternate title: the front-end sucks now because we have too many options for doing generally the same thing, and they all aren't compatible with each other, but my way, the way I first learned, is best, and something about functional programming even though UIs arbitrarily necessitate or do not necessitate state.

I, personally, place blame on WC3 for this state of affairs, as Web components should have solved the UI interoperability problem, observed objects were dropped which regardless of what one thinks of them (I think a trie is better) would have unified state management clearly (replaced by Proxy? yeah, I see everyone using that string-only thing for state), and various other specs should have solved most of these issues, but I guess they were too busy making people leave their org over DRM, rather than making a useful, consistent, easily-produced internet. Who needs standards when all of the for-profit board members have their own un-interoperable libraries?

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

#107

Post by casper345 » Tue, Oct 30, 2018, 5:28 PM UTC

> For instance, if you’re building a chat box then there’s really no need to implement your login page in React.

Wrestling with this idea. Been using create react app for most of my projects that arguably do not need it. But the development is so much faster and easier to manage than traditonal html/css webpack

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

#108

Post by TopWaltz » Tue, Oct 30, 2018, 5:29 PM UTC

PurpleBoxDragon wrote: post #83

paulie_a wrote: post #18

Earlier quoted context omitted.

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.

> I once worked with a guy who built an app with everything done server side in web forms, including a datetime picker

ASP.NET Webforms? I have good memories of being able to do that easily, with zero (or almost zero) JavaScript.

It's not the best user experience ever (the whole page has to reload after each click, and the state is persisted by serializing structs in fields), but I had a pleasant experience when I developed with it.

ASP.NET Webforms components were the best thing until we finally had React/Vue!

The only problem was that it was way too easy to make a mess in your backend code.

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

#109

Post by dagss » Tue, Oct 30, 2018, 5:30 PM UTC

jhall1468 wrote: post #61

dagss wrote: post #42

Earlier quoted context omitted.

Then you go back to the point made in the beginning of the article: Is the better UX during 5xx worth the extra investment? Does it directly drive more revenue than what it costs in developer time? I would argue that in most situations the business is better off using 10 hours of engineer time working on some source of 5xx, than 10 hours making sure the error has good UX. Problem with SPA made here is simply that the…

User Experience is not just about bottom line, and approaching it from that position is just terrible. People that have to interact with terrible UX don't like those interactions. A 500 error with a bolded text saying "an error occurred" is going to make me never return to your site, because a reasonable user experience for that page doesn't require 10 hours of work.

Users never returning has an effect on bottom line. So you can make the argument from that position.

Whether users return, and how that hurts your business, depends very much on your site and your users.

I will disagree about UX not being about bottom line though (in the usual context of a for-profit company of course). In a common setting, whoever pays developers and designers are doing so as an investment that they think will be profitable. If you can cut costs without hurting (long term) revenue by cheaping out on UX then of course you should (!). But often the idea is good UX will drive revenue...

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

#110

Post by nathan_f77 » Tue, Oct 30, 2018, 5:36 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 was wondering if I might be able to ask you some questions about those healthcare forms? (I wanted to send a private message but couldn't find any contact information.)

I'm working on a product that can fill out very complex PDF forms, as well as automatically generating web-based forms for people to fill in, so I would be very interested in hearing some more details.