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.
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.
Sometimes I realize a SPA would have simply served the user better, and it doesn't necessarily take much to be in that predicament.
Too many people hate on SPAs by, presumably, just imagining static read-only content like blogs and news. Though I'm also a bit tired of "SPAs suck amirite, HN?"
Put the user first, consider the trade-offs that work towards that goal, and see what shakes out.
The browser <-> multiple pages paradigm is pretty much how the web evolved, so SPA's just end up being one giant hack to get everything working.
UWP/WPF/any other desktop app framework demonstrates how easy developing a 'single page application' can be without all the cruft you have to add to make a SPA work because it's actually a sort-of-massive-workaround.
It's certainly true that you don't get to lean on built-in features like history support, but that's why you can now drive history with Javascript. And all sorts of other things. And if you're smart, you're using a solution that handles these things for you.
Rich client development is always hard—on any platform—, and you always make concessions for the platform you're on. I certainly have to when I'm building iOS apps. But I see no reason for this to dissuade you if you can push a better UX to the user.
As tried-and-true as server-rendered architecture might be, there are all sorts of things it will never be able to do no matter how much of a hack you think web client development might be. Software is a hack. And at the end of the day, your users may remain unconvinced when you preach about what the browser was "meant to do" when they begin coveting a richer experience.
That's something that's often left by the wayside when we discuss these things. We talk about technical superiority and become prescriptive about what we think technology is for. While fun thought exercises as craftspeople, we too seldom talk about delivering value. If leaning into the historical nature of the browser supporting HTML pages over the wire helps you build a better experience, that's great. But that's not the only option you have today.
I think the difference is how much you as a developer have to "fight" the platform. Having to implement history management yourself very much qualifies as "fighting" to some extent in my eyes… continuing with native platforms as an example, that sort of thing just isn't necessary in most cases – like with iOS, 99% of your "history" management comes for free with some combination of UINavigationController and view controller presentation, assuming the use of UIKit.
While bad SPAs do this badly just like bad iOS clients do things badly (like incessant spinners, zero caching, and unselectable text), it's a small concesión to make in the scheme of client-side development.
On the other hand, have you ever wrestled with CoreData on iOS? It's like using the worst ORM with the worst Active Record abstraction, easy to get wrong, yet that's the tool you're given. And you're choosing between that built-in solution or going off the rails with another solution with its own trade-offs, and both paths feel like you're wrestling with the platform.
It just comes with the space of client-development, you just tend to get used to wrestling with the platform you have the most experience with, and it's easy to forget that when you judge the concessions that must be made on other platforms.
Additionally HTML5 wasn't really 'made for' SPAs, it added features to HTML which could help support SPA's but it's main design decision was to be 100% backwards compatible with the older HTML spec. HTML5 is made for SPAs the same way that a stretched limo is made for commuting.
Here and now, WPF is much worse. Even Microsoft itself now invests into React Native.
Microsoft invests in React Native as they want to bring applications built in React Native for iOS and Android to Windows.
The fact they are investing in React Native doesn't necessarily mean much more than the fact that they want developers to compile their React Native apps to Windows as well as the mobile platforms.
But OP's point still stands - it is much less hacky than anything in the web ecosystem even so.
The hard idea from the programmer’s point of view is automatic layout, not grids; my impression was that Tk originated it (it certainly brought it to light), but now that I’m looking I’m not sure it wasn’t already in Motif to some extent, so the roots of the idea might go down into the primordial soup of Project Athena and similar places.
If you ignore those things in your SPA, much of the "cruft" is negligible.
As for bookmarks, that's semi-right, but the web platform conflates the back button with bookmark-ability in ways that are quite confusing. If you want the back button to get the user out of your settings screen, then you must push a new URL onto the history stack using JavaScript, but then if the user bookmarks your site they'll bookmark the settings screen specifically even though that's very unlikely to be what they wanted. Non-web apps that have enough content to need something like bookmarks often implement a similar mechanism that's more predictable, albeit less general.
The OPs article is really a common lament amongst web developers - they're (ab)using a tool that was never meant for what they're using it for. It's a real and very serious problem in our industry.
The whole SPA vs multi-page dichotomy really emerges because the web doesn't have sufficiently rich, modular or low level APIs. If you look at non-web frameworks like iOS or Java then you get a huge number of APIs (usually classes) tackling the low levels of a problem, then more classes building on the lower levels to give you higher level solutions. Those classes can usually be customized in many different ways, so the amount of control a developer has is enormous. If you start with a high level helper class and find you can't customize it to meet your needs, you can reimplement it using the lower level building blocks.
The web isn't like this. Web APIs are an absolute pigs ear of very high level function calls and classes designed in more or less random ways to quickly hack together a solution to whatever need a browser maker had at the time. HTML5 supports peer-to-peer video streaming and augmented reality but not a virtualized table view. In many cases it's obvious that little or no thought went into the APIs, e.g. XMLHTTPRequest has nothing to do with XML, you can open a URL for a custom URL handler but not detect if that URL will work ahead of time, nor even if opening that URL worked once you try it, and so on. Instead of starting with low level APIs and composing them into high level APIs, browsers start with high level APIs and then introduce entirely orthogonal low level APIs decades later, or never.
These sorts of problems just don't occur when writing desktop apps with professionally designed frameworks - even in the rare cases that you hit some limit of the framework, you can (these days) just patch it directly and ship a fixed version with your app. If you hit a problem in the browser you're just SOL and have to hack around it.
Our industry needs to reinvigorate desktop apps. Attempting to convert browsers into Qt/Java/.NET competitors has:
a. Made HTML5 unimplementable, even by Microsoft. It's not so much a spec anymore as a guide to whatever Chrome happens to do on the day you read it (hopefully).
b. Created tons of security holes.
c. Yielded an atrocious and steadily decaying developer experience.
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 parameters. And that's a great way to build software. Until someone comes in and asks you to draw in the state from one section into two other sections. You have the choice to say a) no and explain why, to b) create a clever "glue" that will be hard to maintain and difficult to explain, or to c) take the time to refactor the code into something more general and complex to allow for the feature on a more abstract level.
Guess which one almost always gets chosen.
The upshot is this: The solution to front-end complexity may not be a technical one, it may not require a new framework or library. It may be a shift in what we expect out of the web. We could always temper our expectations in order to keep our code clean.
Likewise the solution to SPAs isn't "say no to features".
A start would be devs communicating to product & design what the technical limits are to the current approach so that it informs their decisions.
In my experience, every single team I've been part of that was building an SPA was because they put the developer experience and desires first, even if in the mid/long term the dev experience ends up being worse as the project grows.
This is why React is such a popular JavaScript framework of libraries.
Believe me, I get it.
I dealt with building these kinds of features for a full decade before SPAs became fashionable.
Now I'm stuck here watching in frustration as people go all-in on SPAs because they didn't know how to solve these problems without them.
I completely understand the historic reasons for wanting to keep JS to a minimum and stay within ERB/Ruby, but the JS component-driven UI pattern feels like the correct front end architecture for most commercial projects these days, especially now with better JS tools like Svelte, which feels like rails for the front end to me.
I started playing around with InertiaJS recently and I absolutely fell in love with it. I was surprised to see how niche it still is because it's pretty much what I've dreamed what writing JS with Rails could be for the last 5 years.
https://github.com/seanhess/juniper
It's an implementation of Elm (imagine React if you're a JS dev), but all logic is executed on the server. State is passed back to the server whenever you choose to listen to an event. The view is then re-rendered and virtual dom diffed on the client. Non-interactive pages are just views. If you want them to be interactive, you add a Message an update function.
I used it on a client project and it was pretty delightful.
It probably isn't documented well enough yet to make total sense, but I think it's a step in the right direction.
Where in this process did you need to start adding navigation via JS? Did that functionality really require JS, or was it implemented that way just because other parts are JS, and the trend was continued? Could you have used Stimulus controllers to manage functionality on the page itself, but when it came time to navigate to a new page, just done a basic browser redirect?
Saying that SPAs is a mistake doesn't mean that a strong dependence on JS or frameworks in a mistake. It just means that trying to make an entire site fit into a single page load introduces more costs than savings. You can still have pages controlled via React or Vue or Stimulus, but forgoing the router functionality.
In my own apps, I use Vue and VueX to control page behaviors, but each URL is its own Rails page. For example, I have a search page that uses Vue and VueX to asynchronously load, filter, and display search results. Clicking on a result is a basic browser redirect, taking you to the result's page, doing a full Rails page load, and again using Vue and VueX to manage any dynamic state (any static content is rendered via ERB files).
This has created a very clear and simple structure that allows each page to have any dynamic functionality it needs, but no complications from having to maintain navigation or browser history via JS. The browser already does that natively, and I get to spend my time working only on actual features--not recreating the browser's built-in functionality, or debugging my own take on it.
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. To make things even more fun, Turbo/Stimulus (sometimes?) breaks bfcache in Safari & Firefox so they behave different from Chrome.
Personally, I detest the vast majority of SPAs, especially the ones from Google, Facebook and Linkedin. Not even sure what they do to make them so horribly slow to use.
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 ability to post-backclick-repost and your DB will rapidly fill up with duplicate rows.
If you do need to back-navigate to a page that has been submitted (say, to edit the submission w/o requiring an edit-specific URL), you have the server re-render the form with the filled values.
If that isn't sufficient, you can always push your form state on the history stack using the history API, so even though this is a bad idea (IMO), you can still do it pretty easily without needing to resort to re-writing nav.
I hate to say it, but I feel like a lot of this stuff had server-side solutions that worked fine circa 2010, but have been almost completely forgotten.
There are tons of good reasons to prefer this behavior, aside from just avoiding duplicates. Think of login forms.
In fact, browsers even have re-submit built-in: Just press F5 on a page that was retrieved using POST. That’s why so many sites use a redirect after POST.
https://www.theserverside.com/news/1365146/Redirect-After-Po...
It sounds like this warn-on-double-submit behavior is convention and not required, so maybe it has become more common for browsers to stop doing it.
> Why not try it, right here, on Hacker News.
OK, I did. HN does a 302 redirect on comment POST to the comment GET. When you back nav, you are seeing the response to a GET request to /reply?id=X
(In other words, the form is re-rendered.)
Edit: oddly, however, submitting on form rendered by GET /reply?id=X ends up creating a new comment, so that's just weird server logic. It might explain why you occasionally see duplicate comments on HN.
Edit 2: on backnav to a comment edit, the redirect is to GET /edit?id=X, which is a re-render of the edit form, the process I described in my OP. Not sure what's going on with the back-after-post...maybe a bug?
With the text you previously entered, which the browser restored. If it did not for you, you have non-standard settings like disabled caching. I can assure you that it behaves the same on Firefox for Linux, Windows, macOS and Safari on iOS: go back, form content is restored.
In fact, the entire internet is full of people trying to get rid of this behavior.
> 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
Was this a hard requirement for the feature or just a nice-to-have? I understand why you'd want that behavior ideally, but it also seems the sort of thing that adds much additional complexity for a problem that isn't (at least in my eyes) severe. Having people re-fill things isn't too much of an ask, I think, and if it's something crucial, it might be better served with a preview page that allows additional changes. Or a "Make changes" link that redirects to a page that can load from the submitted state. There are easier ways to handle it than manually controlling navigation.
But yeah. If the behavior is a hard requirement from the business/product side of things, then using an SPA is no longer an architectural decision made for technological purposes, but is a feature requirement from beyond. And that's a whole different matter.
The issue is that, so far, we haven't figured out how to have a good fullstack DX.
Remix is probably one of the best attempts so far, but it still leans heavily towards being a very sophisticated renderer for the front end. The proof is you probably would not use Remix to create a 100% backend project with no front end. Same with SvelteKit or Next.
Until fullstack frameworks get more serious about the backend, we will be in this weird limbo.
In my current project I use Fastify as my main backend framework, and then use Svelte for SSR + hydration. I loose a lot of the frontend sophistication that SvelteKit brings to the table, but OTOH I have an amazing backend framework and total control and flexibility.
Bringing in React and turning that non-deterministic events firing all over the place greatly improved that situation, but this has become if someone needs JS, bring in SPA framework. This is in spite of the browser world getting much better. So just as JQuery was used to make SPAs to bad effect, SPA frameworks have been used to do minimal JS actions in a bad way.
In all seriousness it feels like there must be an elegant way to do more responsive modern functions while keeping the core server rendering concept. It's 2022 after all. But no I don't know a good solution either.
Often when I see people arguing against SPAs, they are peddling trivial toy websites that don’t do much and don’t change much.
When you need to build a serious application on the web with quickly growing feature sets and complex state management, just use a SPA. It’s 2022.
If Hey is a toy app you then you must be working on some truly alien projects from the future or something.
Compare native Mail app and Hey. If anything should be a SPA, it’s an email app.
Also who cares how much kb of JavaScript your mail app uses? It’s completely wrong metric to optimize for an app someone uses every day, multiple times a day and likely has the app open all the time.
(Also haven’t heard people using Hey much since the launch)
I can sort of see the point if the "A" part of "SPA" actually applies to your product, but for the dominant players that doesn't seem to be the case.
When someone submits a form and navigates back, don't you just re-display the empty form?
If it needs to be a form bounded with the uploaded file (maybe as part of a wizard), then why not ask the server for it instead of storing client side state?
Maybe using Javascript without a SPA looks hard because you're trying to avoid storing state on the server as well as bypass native browser features.