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

41–50 of 152 posts

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

#41

Post by rocky1138 »

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?

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.

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

#42

Post by dagss »

thesimon wrote: post #25

>An MPA renders a 500 page upon error and that's it. However, an SPA needs to detect errors in the client code and then update the user interface accordingly. Again, busywork required to regain what MPAs offer out of the box. Is that supposed to be a downside? Just showing a 500 page isn't really a great UX, the SPA experience is probably a lot better (think preserving of unsaved data for example).

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 there isn't an easy "good enough" solution like you have for MPA, it is either good ux or nothing. (I don't know if that is true or if it is just that SPA devs will always insist in good ux even if it doesn't improve company's bottom line)

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

#43

Post by jordache »

bull crap.

The complexity of state management must exist within an app. Either it's stateful server side or stateful client side.

Going away from the SPA pattern doesn't save anything in this regard.

The only unique complexity SPA brings to the table is route management, which can get confusing, and a non-trivial learning curve.

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

#44

Post by oever »

k_bx wrote: post #37

I've just started implementing a website which would look like an ideal fit for a non-SPA (online library), but since I am using my own spare time on it, there's no way I will go back to the old non-SPA development. Most of the problems are solved by using Haskell+Elm+Generating the API types (sharing the code for their encoding/decoding). Testing the backend is way easier through API, and testing UI is better done w…

The routing and type safety from url to database that Yesod (Haskell) offers makes it simple to make MPA than an SPA. You can still add an API to test the backend.

https://www.yesodweb.com/

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

#45

Post by vetinari »

swiley wrote: post #29
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…

HTML has support for everything you listed without resorting to JavaScript. Maybe some sort of graphic editor for a special file type isn’t possible without JavaScript? But most things really have been thought of and incorporated into html.

HTML doesn't have support for autocomplete elements and conditional input elements. Even date pickers are spotty.

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

#46

Post by 3dfan »

rocky1138 wrote: post #41
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?

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

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

#47

Post by eropple »

toolz wrote: post #17
eropple wrote: post #12

Earlier quoted context omitted.

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…

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 HTML templating solution I've ever seen kinda sucks for composition beyond a very basic "insert blob here", whereas TSX--don't write plain JavaScript, kids--does a lot to address that. It's more that commingled views/controllers and the actual logic of the application causes separation-of-concerns issues (and yes, you can write better code, but people don't). And it's more that for any nontrivially successful thing I'm probably going to either need to provide an API or a mobile client--which are the same thing--and so I might as well get it out of the way to start.

In a way, it's the microservices argument. You don't make microservices because of performance, you make them because it forces less skilled developers to do (more of) the right thing and allows those less skilled developers to parallelize better. So it is with tooling like React in an SPA and an API-driven backend. But, and unlike microservice-all-the-things, I find myself able to crank out more involved features, faster, using React and talking to a backend API in something like Swagger than dealing with postbacks and string-manipulating my way to HTML output. So I think there are wins on both ends.

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

#48

Post by LaGrange »

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?

I was going to point out the mention of Turbolinks and other JS stuff (author isn't a fundamentalist if you read more than the headline), which would help, but in this case, to be honest, my opinion is "hopefully it wouldn't happen." It hurts my eyes.

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

#49

Post by SamBam »

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.

How does Stimulus compare to Angular? It seemed like a random plug in the article for a framework that appeared at first glance to basically be Angular.

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

#50

Post by ben_jones »

vetinari wrote: post #45
swiley wrote: post #29

Earlier quoted context omitted.

HTML has support for everything you listed without resorting to JavaScript. Maybe some sort of graphic editor for a special file type isn’t possible without JavaScript? But most things really have been thought of and incorporated into html.

HTML doesn't have support for autocomplete elements and conditional input elements. Even date pickers are spotty.

Datepickers, specifically datetime pickers, in pure html are vomit inducing.
Post reply on HN