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

51–60 of 152 posts

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

#51

Post by lucaluca1453 »

yogthos wrote: post #32

This seems really misinformed and written by somebody who has no idea how SPAs work. The SPAs approach results in much cleaner and simpler architecture in practice because you have clear separation between the client and the server. It also forces you to think about the API up front allowing you to create other clients, such as native mobile apps, later on. The SPA approach also helps with statefulness, because it al…

>>In an MPA, we can simply pass models to views and render attributes we need. This isn't the case in an SPA. We need to define data formats and implement serialization.

>Not really sure what that's about either. JSON exists, and I'm pretty sure nobody is inventing serialization formats in SPAs.

I think the author means serialization of models into JSON for your API, which is non-trivial in frameworks like Django - you have to pick which model fields to use, how to represent foreign keys, etc. In Django you can just pass that model object into a HTML template processor (view) in a MPA.

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

#52

Post by ishi »

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 agree, but using a front-end framework does not mean you must build your entire app as an SPA. You can still have separate pages, and UI components on each page get handled by your framework of choice. Also, there's a big difference between the state of a single form vs. keeping the state of your whole application in the frontend!

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

#53

Post by nicklasss »

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 why I love to use Vue to handle complex frontend states without building a full SPA

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

#54

Post by k_bx »

oever wrote: post #44
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/

Yesod is great, and would cover most of my app, but then you get things like "search field which filters as you type" and other UI elements (even as small as "like" button) and you get into a territory where you stop having a good time.

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

#56

Post by jhall1468 »

juandazapata wrote: post #14
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.

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

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

#57

Post by devwastaken »

Completely Disagree. SPA's are about making your 'site' like a GUI application. If you had to use Apache to navigate pages in visual .net or QT that'd be crazy.

SPA's also benefit from static caching and serving. You do not always need to have the pages being served from your origin, but can be served from a much cheaper source like Cloudflare or even a different origin.

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

#58

Post by thecatspaw »

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…

With SPA you usually dont add frontend state on top of backend state, you only have the frontend part, and a stateless API.

This makes it very easy to test and reason about.

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

#59

Post by MattyRad »

I will add that since the learning curve is substantially higher for SPAs, non-technically proficient front-end people (designers or folks who just do HTML/CSS) will constantly bastardize your app; creating 1000 line components, splicing in jQuery, inadvertently creating elements with duplicate IDs. It's been a headache for me at times, and I often feel like I'm the maid cleaning up after people.

It's understood that this can also happen in an MPA, but I think the blast radius is much smaller.

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

#60

Post by jhall1468 »

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.

> The experience was wonderful and highly recommended. I think it's perfect for small teams who are more productive with traditional/backend tech.

You presented the actual valid argument for the OP's position. If you are a small team of largely backend engineers, using tech you aren't familiar with is probably the wrong solution. Unfortunately, the blog post decided to take a more aggressive stance and made the author just look like a fool.

Post reply on HN