Yes, it is. That's what databases and POST data is for and it's all incredibly quick.
Almost all applications that are written in the world today are glorified forms.
That's reality because 95% of apps are written for the business world. Most don't really do much apart from take some form data, apply business logic to it and show the results/send some messages.
Even most consumer apps like Facebook/Twitter/TikTok/Pintrest/etc. are basically glorified forms.
You can do save/load state all in nanoseconds, any competent programmer can easily aim for 50ms page loads, well under human detection.
This is incredibly basic stuff and how it was done for decades before SPAs.
You have rose-colored classes for the past. Multiple-megabyte state cookies were very common in business applications written in .NET WebForms, because even simple CRUD business applications have a lot of state to carry around that nowadays is simply managed in-memory by JavaScript. 50ms load times were out of the question; you were lucky if you could do it in 500ms. No "competent programmer" could do anything about this because WebForms didn't let them. As soon as you needed to filter one dropdown based on another dropdown, you needed to write custom JavaScript anyway.
Writing a stateful front-end that just asks for what it needs from a well-built API when it needs it is enormously simpler than trying to store all state in some server session and having to work around your own framework whenever you need a dynamic dropdown list.
We all seem to have collectively forgotten how awful web frameworks used to be, and how little interactivity the user actually expected. Things are way better now.
WebForms is an unrepresentative example because it needs to carry all the view state between the front end and backend and was enormously complicated under the hood to make the programming model easier. Nothing else works like that, the state is stored in session storage in memory on the server, and the client just sends a cookie containing the key for its session.
To add to this: Microsoft recognized that third-party control developers were dumping too much info into the ViewState bag, and this was largely fixed in later versions.
It's also possible to store ViewState "on the server side" instead of on the client side. So instead of sending megabytes up and down with every request, the client just gets a unique identifier. The downside is increased memory usage, but that's often better, especially for internal enterprise apps.
The parent's point was that you don't need Javascript for that; some of the state (i.e., the state of the parent dropdown) could be stored in the URL, or in a form variable...which is how things were done in the days before Javascript.
Yes, you would need multiple pages. But that is how most form-based SPAs work today anyway, and avoiding a page reload isn't always preferrable to just reloading if the SPA version requires heavy amounts of JS and the good-old-static version loads in the blink of an eye.
> Almost all applications that are written in the world today are glorified forms.
Yeah, but our users like interactive forms. When a widget is changed, they like feedback instantly.
Just about any shop that reloads the entire page when you change a single filter gets annoying pretty fast.
Imagine an online computer store: tick the box for "16GB RAM", wait for page to reload, tick "32GB RAM", wait for page reload, tick "512GB SSD", wait for page reload, tick "1TB", wait for page reload.
Now you may argue you still have to wait if it is an SPA, but then you're only waiting for the results. You can quickly tick all four boxes in an SPA and each one may cause a background request, but that doesn't matter because you don't have to wait for each request to complete to make your next selection.
> Imagine an online computer store: tick the box for "16GB RAM", wait for page to reload, tick "32GB RAM", wait for page reload, tick "512GB SSD", wait for page reload, tick "1TB", wait for page reload.
> > Imagine an online computer store: tick the box for "16GB RAM", wait for page to reload, tick "32GB RAM", wait for page reload, tick "512GB SSD", wait for page reload, tick "1TB", wait for page reload.
>
> Tick all the boxes and then click "Apply filter".
Many places do that, but it's not as user-friendly as not having to click "apply". If there's a large number of filters (Buying a computer on Amazon, for example), the "apply" button is off-screen most of the time - scroll to either the last filter or the first one to even know that there is an "apply" button.
Also, some fields do not work too well by having a separate "apply" filter step. You drop-down the manufacturer selection, choose "Lenovo", click apply and now there is a new drop-down for "Model".
The better experience is one where both those drop-downs exist, and second one is populated only after a choice is made on the first one. In all the pages I've seen that have drop-down #2 dependent on drop-down #1, those that got a JSON list via AJAX were much more pleasant to use than those that reloaded the entire screen just to add 5 items to the drop-down #2.
As the creator of the software, it's more important to have happy users than have an easier maintenance burden.
You don't need an SPA for that, you can still filter the DOM with JS (Vanilla or a Reactive framework) and save the state in cookie or the URL, and have the server handle the state.
> You don't need an SPA for that, you can still filter the DOM with JS (Vanilla or a Reactive framework) and save the state in cookie or the URL, and have the server handle the state.
Doesn't that still reload the entire page when a checkbox is clicked?
Not necessarily, you can update the URL with the History or Location API without a reload.
In that case you download the whole list and filter it on the client. The assets (images, documents, icons) can be lazy loaded, so the browser will fetch them only when visible.
I'm all in for reducing the usage of frontend heavy frameworks, but I also agree that as soon as you start with the "sprinkles" you're opening the pandora's box in the long term if not using state based ui rendering (what React, Vue, etc give you)
Example:
I have an application where a form input expects an URL. As soon as any URL is entered, I need to:
1) Provide feedback on wether that's a valid URL or not, before the user submits the form
2) Show a suggestion for a page title, which is usually the <head> title extracted from that URL. If the user clicks on the suggestion, that should become the value of the next input in the form.
Other than this, this is a pretty basic form. But how do you give a decent experience without JavaScript?
Right, a bit of jQuery would do it in this case... but then more and more similar small tweaks are necessary, and before you realise you're swimming in spaghetti.
The idea that we should use react to do a form input suggestion... To avoid spaghetti code?
I can't make that logical jump. If you can't keep that tiny bit of code organized, why do you want to pile on the entirety of react and why would that be more organized?
Maybe you're saying it's a snowball of these things. I've seen that happen, but it didn't have to.
I agree using React just for that is overkill. And yes, I'm talking about how it snowballs when you later get more requirements like now we need this dropdown to change accordingly, now we want to show validations as you write, now we need to check for email uniqueness before submitting, etc, etc...
But, the worst part in my experience, is that without one of these "opinionated" frameworks such as React or Vue, each new developer that joins the team (after others leave) have a total different idea of how to organize the code, or they have a hard time understanding the "custom" organization and ideology behind the structure you've had to invent to keep in maintainable.
Again, I'm not a fan at all of frontend heavy frameworks, but they do solve a real problem, specially in large apps and large teams or teams with a lot of turnover.
I'd say it is the exact situation in the backend regarding using Flask vs Django, Sinatra vs Rails, etc... having a set of imposed opinions and structure have long term benefits as soon as you're not the only one working on the codebase.
Almost all applications that are written in the world today are glorified forms.
That's reality because 95% of apps are written for the business world. Most don't really do much apart from take some form data, apply business logic to it and show the results/send some messages.
Even most consumer apps like Facebook/Twitter/TikTok/Pintrest/etc. are basically glorified forms.
You can do save/load state all in nanoseconds, any competent programmer can easily aim for 50ms page loads, well under human detection.
This is incredibly basic stuff and how it was done for decades before SPAs.