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

21–30 of 152 posts

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

#21

Post by sbr464 »

I’m curious if anyone has done any analysis and seen any patterns emerge around days of the week >> certain popular HN topics (controversial/rants/per category)? Kind of similar to the analysis you find around best times to post etc. I feel like I see type system related posts closer to Fri/Sat.

I think we could make a nice color coded calendar or almanac to celebrate these more. Maybe even create more formal holidays. I’m inspired by the Giant Man radio interview[0] I heard on NPR this last weekend. Highly recommend it, by Hillary Frank.

[0]https://www.thisamericanlife.org/351/return-to-childhood/act...

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

#22

Post by bauerd »

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.

Calendar UIs commonly demand stuff like auto-refreshing, datetime selects, drag-dropping items around, resizing those, list goes on. Please elaborate how you'd build a "simple solution" that does not resort to client-side rendering.

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

#24

Post by the_gastropod »

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…

Hear hear! I don't think the assertion that SPA's are faster to build / more scalable holds up to much scrutiny.

1. SPA's still require some back end to render the initial page / payload.

2. SPA's cannot be trusted, so you need to duplicate things like validations.

2a. "But you can just do an ajax call to validate records on the back end, and get a json response!" — how's that any more performant than just doing a traditional page load? With pjax or turbolinks, the performance difference between these options is even closer.

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

#25

Post by thesimon »

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

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

#26

Post by [deleted] »

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…

[deleted]

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

#28

Post by sj3k »

toolz wrote: post #20
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 approa…

Is this kinda how next.js works? I have not used it myself but I think it looks neat.

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

#29

Post by swiley »

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.

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

#30

Post by detaro »

daliusd wrote: post #27

JWT is encoding standard for tokens. Bearer tokens can be JWT tokens (and usually are). Has anyone idea what author had in mind with bearer tokens?

From the context, any bearer token that's tied to a session with backend state, in contrast to having no backend state, securing state through the JWT validation, with the listed downside of having no way of revoking it.
Post reply on HN