Could not disagree more with the article. In my experience, well designed SPAs are almost always better and lighter than multi page apps. The fact that a lot of SPAs are implemented quite poorly is a different story. In actual fact, whether a web app is single or multi page is merely an implementation detail; in both cases we're just passing information back and forth between client and server. With multi page apps, you transmit and parse full markup each time. With SPAs, you do it once and then mutate as needed. In that sense it's more efficient and I can't see why that's a bad thing.
A single-page app is almost always worse than a multi-page app
71–80 of 152 posts
Re: A single-page app is almost always worse than a multi-page app
#72So, 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…
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 experience, this is false.
In the last two years I've built five very complex forms for the healthcare industry that not only had crazy looking flow-charts, but had to be multi-lingual, predictive, mobile-friendly, and fully accessible.
They use all those little bits that you talk about - multi-part forms, date pickers, autocomplete, and conditional input.
The only JS is for the autocomplete. The rest is all HTML5/CSS3.
We did user testing on three of them (100 people from our target group, selected randomly at two of our facilities, with generally low levels of technology literacy), and the paginated HTML5/CSS3 versions all scored higher than the previous Javascript SPA mess the preceded them.
Re: A single-page app is almost always worse than a multi-page app
#73Earlier quoted context omitted.
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…
having worked with JSF, I can safely say that me and server side rendering with peristent client connection to push updates are ... not friends. You have multiple scopes in the same document. You have the jsp scopes which gets rendered once, when the client requests the page, and the jsf scope which lives longer. Initially when rendering these scopes seem to share variables, but after the request is rendered, the jsp…
I promise you that your complains are with the abstractions chosen and implementation and not the concept. Texas doesn't have any of the issues you're talking about. You don't even worry about the data that populates the view. You simply write view code like any other templating engine that knows how to render itself and when data changes you send a small message to a process that handles updating the client and texas handles all the logic for efficiently updating its client.
Re: A single-page app is almost always worse than a multi-page app
#74Earlier quoted context omitted.
> 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 tr…
I remember a decade ago, when there was a management demand to get rid of the "page load", and our quick and (very) dirty solution was to simply load the next page with ajax as HTML and simply replace most of the body with the body of the loaded page. It was hardly any faster (we measured), but everyone insisted it was suddenly blazing fast. The psychological effect of avoiding the visual artefacts of a page load was large enough that it was mostly sufficient.
We eventually did some minor optimisations - returning smaller parts of the page, and replacing more precise sub-parts of the DOM. We had some other small pieces of JS on the pages too, but for the most part just having the server render everything replacing large chunks was good enough.
Re: A single-page app is almost always worse than a multi-page app
#75Earlier 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.
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.
Yeah, even a "Select All" button that checks all checkboxes requires Javascript.
Aside: I don't understand the premise of this thread that suggests it's a "SPA" just to, say, use React on a single page of an application. The whole basis of the "SP" in "SPA" is that the Javascript (state) spans multiple pages.
Re: A single-page app is almost always worse than a multi-page app
#76So, 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…
You don't have to use jQuery... https://news.ycombinator.com/item?id=18336429
Re: A single-page app is almost always worse than a multi-page app
#77So, 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…
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?
Re: A single-page app is almost always worse than a multi-page app
#78Earlier quoted context omitted.
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.
Eh, let's avoid eye-rolling hysterics on this forum and stay practical.
There are components that are complex enough to warrant a view library, embedded in an application that's not. In fact, it doesn't take much complexity at all, in my experience. At which point loading a view library a la carte is your only real option.
What doesn't make sense about that?
Re: A single-page app is almost always worse than a multi-page app
#79Most of the issues listed are either issues with MPA's as well or optional for SPA's.
There are plenty of MPA's with slow first time loads for instance.
Re: A single-page app is almost always worse than a multi-page app
#80At my current workplace - as a deliberate design choice - and last one - organically "discovered", but deliberately maintained - we've tended towards building user facing products as collections of smaller apps sharing a backend, rather than typical SPA (Single Page Application) architecture
What that means in practice is that:
1. Routing is always handled server side. The less frontend state (IMO/IME) the better. There will be the odd bit of pushState where appropriate, but no actual full-on routes.
2. Whether to render content server or client side is determined on a case by case basis. It's often easier to build HTML using whatever templating system your backend tooling provides than build a REST/GraphQL endpoint for a component to consume.
3. You can introduce React/React-style programming piecemeal to a team with varying levels of experience. Everyone on a team (with varying degrees of frontend skill/experience) can be productive from day one.
Does anyone else do this?