Not the reasons I expected
I don’t see Navigation as a main problem and it can be solved quite neatly, not that much more complex than a normal site. Was expecting something about bundle size etc.
SPAs Were a Mistake
261–270 of 637 posts
Re: SPAs Were a Mistake
#262REST API's (literally, "Representational State Transfer", ReST) are a very nice match with SPA's, because now the browser is the sole source of truth for application state (and the server only has to produce some JSON data instead of entire HTML pages).
Literally the entire point of REST is that you don't have to maintain server-side sessions, and you shouldn't. This also has benefits for scalable applications, in that you can transfer your running application to a cluster of servers on the other side of the world, and it'll still keep working.
The trust boundary between the front and back ends can be a huge boon to security as well, and some things are literally impossible to do with a multi-page app, and you can still maintain URL parity with new actions in your page.
That's why SPAs were, and are, great!
That doesn't mean everything should be an SPA! A photo, news, blog, or recipe website might be better laid out as a separate page for each individual item. However, there are tons of other types of real applications that can only be built as an SPA.
Are they unwieldy, sometimes hard-to-code and maintain, and sometimes result in a poorer experience? Yes, but that can also be true of a multi-page app, especially if you're trying to shoehorn an SPA experience into a multi-page app and want to maintain the same user experience as a user moves around within the app.
A multi-page "app" isn't really an app anymore; it's a server-side app that is producing multiple pages. A single page app literally is running in the browser and only sending a bit of data back and forth with each user interaction. It's just a completely different model.
Re: SPAs Were a Mistake
#263Earlier quoted context omitted.
Exactly, the best approach seems to be where the app is composed of traditional pages with server navigation between them, but each page is implemented as an SPA. This approach eliminates the need for a client-side router, keeps any centralized page state small, and improves the SEO and bookmarkability of the app. I have implemented this architecture in several projects, and it’s effective
The correct answer for this stuff, and it absolutely kills me saying this, is probably something like asp.net web forms.
Please, go learn about Remix (https://remix.run), it is the actual correct answer for this stuff.
Re: SPAs Were a Mistake
#264Earlier quoted context omitted.
> In my specific example, the navigation itself didn't happen through JS, but you need to hook into navigation APIs to handle backing into a partially-filled form after submitting to rebuild the UI to reflect the state before the user hit submit. I'm not sure I understand. The "conventional" solution to this is not to do it -- the reason browsers don't re-fill submitted forms is to prevent duplication. Give users the…
But browsers absolutely do keep the form filled unless your HTML or JS says otherwise. Pressing back after submitting on a vanilla HTML form keeps all values in place. As it should.
Not after a post. If you change the form method to get, I believe this is the behavior.
There are tons of good reasons to prefer this behavior, aside from just avoiding duplicates. Think of login forms.
Re: SPAs Were a Mistake
#265Earlier quoted context omitted.
Exactly. I've been in the position various times where I'm embedding a JS app on a page to help the user do something highly interactive, usually creating/editing content. And then as it's expanding to integrate with other things on the site, I start to wish more of the site was in the JS-app side of things. Sometimes I realize a SPA would have simply served the user better, and it doesn't necessarily take much to be…
Setting limits for future features to keep the code base clean and manageable is something developers could be more vocal about. Acquiescing to every demand product designers and management throw into the mix is what turns beautiful, easily-maintained codebases into nightmares. What people are talking about here is writing web apps as a series of small, tightly-coupled spas who manage state within very specific param…
The end goal of writing code isn't always a "clean and manageable" codebase.
Likewise the solution to SPAs isn't "say no to features".
Re: SPAs Were a Mistake
#266Earlier quoted context omitted.
Asp.net web forms absolutely sucked. They fundamentally misunderstood HTML and how the internet even worked. Modern Razor's pretty good (not Razor Pages, they also suck) which is probably what you mean. But it's not that much different from Rails, Laravel, Django, etc.
What’s wrong with razor pages? They’re fantastically simple and productive. And WebForms wasn't a misunderstanding. It was a deliberate and brilliant design that brought WinForm developers and their experience to the web and allowed them to build complex web apps two decades ago that still work to this day.
It's contextual. For me, WebForms fell down because it let the average web developer impose too many "costs" on internet-facing projects. A WinForms developer is a very specific kind of developer with a high focus on development of internal, or line-of-business (LOB) apps. WebForms also excelled at this, but brought more reach as people moved away from a preference for desktop apps.
The height of WebForms coincided with an embrace of web standards and accessibility which flows into the Web 2.0 era. You had to jump through a lot of hoops to achieve what was needed WebForms to get it to behave in a web-friendly way. The underlying .NET framework and base of ASP.NET (HttpHandler and HttpModule) was outstanding though.
(I still build/maintain WinForms, ASP.NET, and WPF apps.)
Re: SPAs Were a Mistake
#267Earlier quoted context omitted.
Hate to break it to you but Nextjs is for building SPAs.
I was going to say.... ironically NextJS is just an additional layer for creating static-rendered sites over an SPA framework. We have come full circle.
All of software engineering is a flat circle. All of it. On the backend side it's microservices vs. monoliths.
Re: SPAs Were a Mistake
#268Luckily we don't have to use them. Go ahead and do a full page reload when the user navigates to another page. Go ahead and implement interactive elements using jQuery. It all still works just as well as it did in 2012.
Re: SPAs Were a Mistake
#269Not the reasons I expected I don’t see Navigation as a main problem and it can be solved quite neatly, not that much more complex than a normal site. Was expecting something about bundle size etc.
Agreed. The blog doesn't seem like a very thought out examination, and I expect most of the HN replies are just debating the title.
For me, the biggest con of SPAs is lack of SEO.
Re: SPAs Were a Mistake
#270Earlier quoted context omitted.
The problem is the mixing and matching of state management. In a traditional web app all of the state is in the back end, in a SPA all of the state is in the front end. When we share state in between the two it's often messy. To me the answer feels like it should be "traditional web app for most things, components-as-first-intended for some things". The simplest React example is just one component that abstracts pres…
Agree, we just add React components here and there to server-side rendered HTML and it works great for us. The issue is most companies want separate teams for front-end and back-end and each team wants clear separation of boundaries and responsibilities between them.
Adding components here and there sounds like a simple app. Nothing wrong with that, if course.
Different teams exist for a reason. I've deeply regretted working in "we have real Devs that can do it all" environments.
It's not so much about boundaries as it is about competence. Or lack of it with