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
My point is that for very interactive web apps, this is a significantly better architecture that a huge monolithic SPA
All of that said, I'm not opposed to approaches like Next/Nuxt/Aleph.
I'd be very interested to hear how you solve this, or if it's less of an issue than people might think.
I agree with this because you affirm my bias.
Also because I've also had success implementing this structure. This makes sure that state of each page doesn't leak everywhere, which simplifies the state management.
It also loads faster than a big SPA because you don't have to worry about bundle splitting!
For its time it was some cool tech.
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.
I'd love to watch people attempt to implement some of the stuff I pulled off with that back in the day now. Occasionally, very complex data driven page flows are required and you could nail that entire problem domain trivially with them.
There is a very large and well known company with a front-facing product used by millions of people which took 5 years pissing around with three different front end technologies to reimplement what we did in 3 months with that and it was slower and heavier and basically reimplemented web forms in python in the end.
It broke the the www intentionally because it sucked. And it still does.
If you don't understand continuations, then you'll struggle and invent all sorts of poor state management patterns. Web forms simplifies some of this because the continuation is captured in viewstate, but it captures too much state (there are other warts too of course).
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.
I'm working on one of those webforms projects right now, a legacy project that they need some fairly trivial tweaks to and it's an absolute nightmare of bad code. And I've done this before, it's become an accidental skill that I can still fix these awful messes.
One of the (many) reasons why webforms and the new Razor Pages are bad is because the code gets split up according to the UI instead of by function. So it gets scattered all over the place and is incredibly hard to do maintenance work on it.
The page-centric code layout that Webforms/Razor Pages/all the old PHP/Perl/etc. encourage is also extremely conducive in encouraging copy-and-pasta code for programmers trying to get stuff done asap.
So not only is it a nightmare to pick apart the code, you can often fine 2 or 3 copies of the same code that you only discover when one page is working as expected, but the same functionality is used somewhere else but someone just copied the page/control instead of actually splitting the page up into controls and re-using functionality.
I've seen this happen over and over and over. A single developer can avoid these pitfalls, a team cannot.
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.)
Who did; which "people"?
Corporations and "Web developers" maybe; users never asked for it AFAIK.
The problems started when you wanted to put together a REAL application. Because the entire paradigm of a web application programmed like a desktop application was flawed it resulted into an endless stream of headaches and workarounds, with bloated, complex and slow applications as a result.
In that sense ASP.NET MVC was a breath of fresh air.
It got better by ASP.Net 3, but MVC/Razor was much, much better imo.
My kneejerk rxn was "clearly you don't get it" -- but your critique and (mis)perception speak to their marketing / messaging, which, well, yeah, this is the world we live in. SPA has become the default, and Remix is pushing back on that, hard, and I'm stoked.
I've been doing webdev for a living since 1998, and Remix (like https://every-layout.dev 's "axiomatic css" - but I digress) is doing something profoundly powerful by leveraging the amazing power of the web platform on its terms, using the native APIs, and doing much, much more by being simpler and doing less. It's so refreshing.
I have a library I’ve been playing around with for 2 years now, I should package it up
Please do.
Of course eventually you need more people and I don't love anyone touch my code, but I'd rather have someone incompetent do entire stack that at least I can review than spend weeks upon weeks communicating basic assumptions.
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
It’s better to just write that as a component in React or Svelte or whatever. It’s more testable, easier to understand, can carry state and logic just fine. It does mean you have to communicate in JSON for a small part of your app, but that is reserved to a few well known endpoints and components like a complex form.
The penalty is loading React or some other lib just for that, but if used in this way the extra dependency isn’t really a big deal as it’s not your whole app. Just use React as a library for components the browser doesn’t already provide.
And by components here I should really clarify as “affordances”. A “primary” button isn’t an affordance, the browser already gives you a button element and CSS classes (or HTML attribute) for that. It doesn’t give you a “multi page wizard with immediate validation” affordance, however, so that’s a good candidate for a component.
a core aspect of REST was HATEOAS, which stands for Hypermedia As The Engine of Application State[2]
htmx goes about it in the same way as the original web
perhaps that is wrong, but the web was pretty successful overall
[1] - https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc... [2] - https://htmx.org/essays/hateoas/
Since HATEOAS is rarely implemented fully in practice, it would be simplistic to point to it as the reason the web is successful. The web allows an incredible variety of different architectures —- Some more closely aligned to HATEOAS and some less so. Perhaps this is the reason for the success of the web?
When it goes past the simplest examples it gets ugly real quick. Here's an example of client-side validation via HTMX: https://htmx.org/docs/#validation. That can't be the future.
htmx integrates with the existing HTML 5 validation API because, well, it's there, and that's what normal HTML does. I don't care much for the API, but that's the standard so we follow it. You can, of course, do client side validation however you'd like and integrate it with htmx using events, since events are the proper glue to tie things together in the DOM. I built a scripting language to help with this, and other stuff as well, called hyperscript: https://hyperscript.org
the "htmx" way for validation is the HTML/web 1.0/HATEOAS way: submit the form to the client side, validate and re-render. With htmx that can be inline, rather than a big clunky refresh-the-page action, which is why I say htmx extends and completes HTML as a hypermedia.
So long as you aren't willing to think about things in hypermedia terms, and htmx as an extension/completion of HTML as a hypermedia, you are going to miss the point. That's not to say that the hypermedia approach is always right, it isn't, but with htmx a lot more of the web application problem space is addressable with that approach.
And, as an aside, HATEOAS isn't great, outside the context of a hypermedia.
https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...
It is, rather, a fairly pointless category error, driven mainly by cargo-cult mentality from the early JSON API era.
Routing (history management) is also a big problem (I'm assuming you weren't including that in your definition of "state" here).
Some would say, "but React, etc. have solved the routing issues", and that's perhaps the case. But what's difficult is wiring these routers up outside of a full React app. That is, if you truly want routing "solved", you generally have to go all React (or whatever) or just let the browser handle it in the traditional request/response sense. Sprinkling in just a bit of dynamic interaction wherein you want the history managed is purgatory.
And, on mobile, things get even more interesting. Consider the simple case of popping a modal (especially a slide-out). Many users will hit "back" on a mobile device, which they would reasonably expect to simply close the modal. But, if your app/page doesn't intercede to manage the history, the previous page is loaded instead.
The problem is which source of truth we want to use. I find that I'll need to refer to routes as the source of truth to process information, meaning "almost" every react action become route-manipulation action and it's state is just derived from the route, which is very similar with what MPA already do.
And, I do think they're distinct problems (but related) when you're just adding a bit of interactivity to a page or two, as this sub-thread is discussing.
In a full SPA, it's largely coupled and more inline with what you say: let the route drive the action. But, sometimes you have an MPA with a dynamic stateful feature embedded at a particular URL, but which may or may not need a sub-route of its own. In those cases, weird stuff can happen if the history is not managed correctly.
This. But IMHO the right solution is to make the back-end stateless and manage all client state on the client. Each request authenticates itself, and (if you're ReSTful about it) the back-end is simply a database connector/augmenter.
In this paradigm, the SPA is basically a desktop app that retrieves data from a server, built to run within a framework, which happens to be a web browser.
In case you're jumping to conclusions, know that I'm a late-comer to the SPA party, having resisted from its inception until about a year ago, for all the obvious reasons, including those bemoaned by the OP.
Why did I relent? SPA frameworks like React now handle pretty much all the heavy lifting for you. OP, you should check out React Router, which can render this post's examples irrelevant. I'm surprised that in 2022, someone writing to the web UI layer would bother to create code to manage the address bar when there are a thousand ways to not have to.
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 presentation and logic. The only state is its own. It does not handle an entire web app as a SPA, no Redux, prop drilling, it's just the idea of a reusable component as an HTML tag. Same with VueJS and all. If we restrict ourselves to that we're in the good path.
If there was already an HTML tag for your own specific problem, wouldn't you just use it in your traditional server-rendered app? A `<photo-upload url="/photos">` tag that does exactly what you want. Or a `<wizard pages=5 logic="com.domain">` tag. We should create just those components, either in React/VueJS/Whatever or in vanilla JS Web Components, and live with the rest as we used to.
We're basically saying that some parts of our apps are too difficult to mix and match state management, and we should offload all of the state to one of the two sides. In some rare apps indeed all of the state should be on the front end, but the use cases for that are just not as big as they're made out to be.