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

131–140 of 152 posts

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

#131

Post by mekoka »

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?

In a traditional MPA yes. The user would have to choose and hit submit and wait.

Regardless, I think this is a superior experience. It does require some getting use to because of the screen/price chart, but just because it's different than anything everybody has done in the past, doesn't mean it's worse. I think someone getting used to this reactive approach might find it a bit hard to go back to a more traditional click/wait cycle.

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

#132

Post by jolmg »

jolmg wrote: post #123
TimJYoung wrote: post #94

Earlier quoted context omitted.

Legitimate question: if you have multiple pages, are you still actually creating an SPA ? That may be the problem that you're encountering, and I can sympathize. Nobody wants to transfer state across page loads, it's a mess...

The reason we chose to make an SPA for the big project is that we wanted the back-end to work for multiple different types of front-ends, some potentially adding automations from the client side via the API. Who knows, were it not for that, we may have chosen a simpler HTML+jQuery design.

You know, TimJYoung, I think I may have misunderstood what you were asking. It's still one page that loads the initial HTML layout, javascript files, and HTML templates. What I meant by "page" in my original post were front-end "pages" that just modify the content of the main container tag in the actual page. I don't need to transfer state because it's already there. Clicking a link causes the framework to destroy the content in a tag, run some javascript functions that probably make some requests to the back-end and fill the tag with the "page" of the new front-end route. The problem is that because of front-end framework supposedly-helpful automagic, unexpected things happen due to keeping state from previous front-end routes.

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

#133

Post by CosmicShadow »

SPAs: reinventing the browser in the browser, and you get the bonus of doing it all in JavaScript!

I hate SPAs, so much more complexity and work. In MPAs you can still use JS and AJAX for a better experience, but SPAs just have so much needless extra work and are harder to maintain. They are also frustrating to use. They can be better to use when done well, but you don't often see that unless it's from someone quite big.

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

#134

Post by lotyrin »

madmaniak wrote: post #23

SPA done properly is much simpler than classical, well known and established ways of making web applications. The only issue is in misleading "best practices".

What I don't get is why these conversations try to pretend that "best practice" is a single point, making huge implicit assumptions about the skill level and practices of the host organizations... Things which almost always have larger force multipliers than the wider space of "what options for this (theoretically) exist in wider industry".

If I have a team of apes slapping keyboards that know Perl and don't understand finer points of OS/servers/state-management very much and see JS as form of evil, then yeah... I'm going to have an MPA where everything complicated happens in a CGI Perl backend that gets wiped clean between every request and probably hand-roll a little bit of turbolinks for them so they don't have to in the spots that will benefit from that.

If I have a team consisting of a single perfect crystalline entity that exists out of time and can pluck the correct solution out of the set of all possible solutions and just start banging out source files in alphabetical order, but BA is staffed by two-headed barbarian ettins that change their mind mid-sentence and can't produce static documentation then we're going to have to account for that least common denominator when it comes to our project management style -- super-iterative... maybe kanban, crystal boy banging out a set of feature branches and staging environments for them with big demos meetings of "so.. kinda like this?"

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

#135

Post by merb »

aldoushuxley001 wrote: post #128
reaperducer wrote: post #72

Earlier quoted context omitted.

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…

Were you able to stop page refresh after form submit without JS? That's something I've been looking for, for a long time.

yeah that's also what I'm curious about, unless he adds a confirm page for some actions (which is actually more work) than just confirm('Text');

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

#136

Post by marcosdumay »

throwaway2016a wrote: post #116
marcosdumay wrote: post #91

Earlier quoted context omitted.

> stateless API Does it not access any data?

It is generally accepted that when someone uses the phase "stateless API" they mean session state not data persistence.

Yes, and this does nothing to help with the problem of state coherence between the backend and frontend.

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

#137

Post by nostrademons »

rovek wrote: post #77
reaperducer wrote: post #72

Earlier quoted context omitted.

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…

If you didn't use JS for date pickers, you didn't have very inclusive browser support - especially for something like a healthcare website. [1] Were the designs and layout of these SPA and HTML5/CSS3 website also identical? [1] https://caniuse.com/#search=input%20date

86% isn't bad, particularly considering you can easily polyfill a date-picker in the missing browsers and attach it to input[type=date] elements.

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

#138

Post by da02 »

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.

Did he ever have trouble finding employers or paying clients?

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

#139

Post by dapreja »

> Error HandlingAn 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.

I'm no gilded dev, but 5 years back when PHP wasn't avoided like the black plague we would still need to update user interface handling these internal server errors. It's judt good design practice.

I more or less agreed/understood with the writer up to that point. Everything else past this just sounded like a argument for argument's sake.

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

#140

Post by systematical »

ravenstine wrote: post #97

I don't really agree with the author that SPA's are almost always worse. Although sometimes they're gratuitous, as was the case with a lot of early Angular apps where it was pretty clear that the developers thought they were being cool by making way too many things behave "dynamicky" for the sake of having their work appear more like an app than a site. On the other hand, there are plenty of times where a multi-page…

>The vast majority of users don't even perceive things like page reloading, etc. Build something useful, whatever the means are.

This is the correct response, but among developers you will have zealotry on this topic. I personally find MPAs easier, but that is based on my work experience and my perception of the learning curved involved in things like React and Angular (I found VueJS to be far easier to learn). I do like the idea of thinking about an API from the get-go with an SPA, but do all applications need an API? Nope. The amount of applications in the business world that will require both a web implementation and an iphone/android app is actually quite small, isn't it?

Post reply on HN