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

11–20 of 152 posts

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

#11

Post by crazygringo »

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 tradeoff as literally every other business decision: will the resulting benefits be greater than the costs they incur?

My dentist doesn't need a single-page app for their site. Anything complex enough to intuitively be called an "app"... there's a good chance it does.

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

#12

Post by eropple »

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…

You still have to test a non-SPA app and you still have to manage state--it's just on the other end of the wire.

TBH, given the state of modern tooling I'm not sure that SPAs really do require more development (once you have actually bought into the process of using them, which is nontrivial). I do, however, think they generally scale (developer-scale, not performance-scale) better than any multi-page system I've ever worked on.

I like your division of "site" and "app", and it's the same one I use. The boundaries are definitely fuzzy, but if you're working on it--I think you know.

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

#13

Post by alexmuro »

tldr; I've invested a lot of time becoming very good at rails and I don't want to learn a new appraoch to solving a problem I am already very good at solving.

The quality of an end product doesn't have as much to do with tools as people would like to believe.

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

#14

Post by juandazapata »

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…

From the blog post

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

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

#15

Post by basch »

bauerd wrote: post #9
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…

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)

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

#16

Post by poisonborz »

While there are some valid concerns in the article, it mostly is just a rant against SPAs, which seem to be unfamiliar and subjectively disliked by the author.

As with stacks, this is highly team-dependent. I for one do not crave for the time of constant back and forth between backend-frontend mindsets and stack lock-in because of rigid query/rendering requirements. This may not work for the author's team of mostly "backend-mindend" devs who wish for more control over output, but is much preferred for a more diverse set of members (or especially departments).

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

#17

Post by toolz »

eropple wrote: post #12
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…

You still have to test a non-SPA app and you still have to manage state--it's just on the other end of the wire. TBH, given the state of modern tooling I'm not sure that SPAs really do require more development (once you have actually bought into the process of using them, which is nontrivial). I do, however, think they generally scale (developer-scale, not performance-scale) better than any multi-page system I've eve…

> 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 view layer being easy enough all developers can understand it).

It's touted quite frequently ime that it's better to have front-end engineers and back-end engineers and that to me just feels flat on its face wrong.

I'm not claiming there are no benefits to SPAs, of course. I'm just saying I don't understand the opinion that claims it scales better with development cycles.

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

#18

Post by paulie_a »

bauerd wrote: post #9
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…

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.

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

#20

Post by toolz »

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…

There are some interesting implementations out there taking advantage of persistent connections to allow the server to handle the rendering while having targeted fragment updates come from the server.

Here's a thread I posted about some FOSS I've been working on that relies entirely on the server for rendering and using VDOM diff/patching on the server for updates. I'm definitely biased, but in my opinion this approach is vastly more user friendly because it enables realtime data updates as easily as request/response style updates.

here's the thread https://news.ycombinator.com/item?id=18318415

if you need some click bait, here's a gif of me in seattle over cell phone internet interacting with a SSR realtime app with the server in cali. https://imgur.com/z8pKt8t - all operations going round trip, with no application level JS written

Post reply on HN