You can get offline support without an SPA. Of course, that may mean replicating some of your back-end behaviour in JavaScript, but that doesn't necessitate building an SPA, or the whole app in JS.
Please do share which crappy SPAs you're thinking of
I'm a Front End Dev and work with SPAs for the past 2 years. Working an offline-enabled PWA powered by Svelte and Redux. Honestly, I have a hunch that an HTML-based oriented development can still provide a great (measured) offline experience, without needing to rebuild wholesale to SPA.
It's a totally different ballgame if the app is mostly client-side utility anyway (calculators, etc), but the HTML + a bit of JS handling Service Worker and offline presentation should enable a great offline experience. I haven't seen it done in a large scale, but it should work.
One path to a SPA that supports all those features without implementing them, and is also "progressive" (i.e., the first request comes from the server so that it's fast even on mobile, and search engines and non-javascript browsers are supported) would be:
- Implement a non-SPA web app in Node.js
- Include (parts of) the server-side code in a Service Worker. That way, after the SW is installed, the SW would handle requests instead of the server.
- Polyfill the missing parts. For example, you could polyfill the database to store updates when offline and sync them later.
Maybe you could make a framework where you can share code between Node.js and the Service Worker, similarly to how you can do server-side React today.
I think JS is fine for some UI sugar, but the app should be usable even with JS off. What you are talking about is indeed better accomplished with an SPA.
i don't need to get the code. nor the markup. that's already loaded in the browser. if i need to get anything, it's raw data. i also don't need to send anything back so i can manage state. being able to load data in the background can also improve the user experience. and for those apps that don't need a backend, i won't need to get anything ever after the first load. SPAs can, if written right, function completely offline, once loaded.
It is not fair to compare SPA or big frontend frameworks with "pure JavaScript" or messy jQuery as some imply.
By putting 20% the effort we put nowadays with these big frameworks into well organized "sprinkles" it is a very viable alternatives. Tools such as Stimulus, unpoly, htmx,etc make this very approachable and maintainable.
To me, SPAs only make sense in two scenarios: 1) You have the requirement for the app to work offline, or on really bad network connections (subway, etc) or 2) You already have a team which only wants to do SPAs and everything else is uncool to them.
You could just ignore the JS churn and stick with enough jQuery to be useful. Most SPA apps don't need to be SPA. Backends don't need to be micro services.
spa apps are more complex that the example. Sure it looks it could work but the amount of logic within an SPA is not just a simple click here , fetch json , replace html fragment. The title is a bit misleading. I don't think it's possible to do SPA without Javascript.
I don’t get the hate against SPA’s. An SPA done right offers amazing interactibily and instant navigation to new views. You already have the templates cached. They probably load from a cdn with good caching policy. If done well you can totally run offline.
Sure you can build with php, laravel, django. The promise of SPA is a clean separation of UI from the APIs. The same REST APIs that external customers use is the same API you develop on. See travis-ci as an example. It’s the same api that the mobile apps can use.
This separation allows the api to return very lightweight stateless responses. You can scale much better when there is less state kungfu.
The UI can manage the state in very responsive manner. No round trips, instant 60fps render.
And no JavaScript is not slow. It’s just that people don’t know it well and end up loading megs of bloated libs with a 1000 ad tracking libraries.
Wait what? Other than "the client blocks JS" which is niche beyond niche the SPA is the one that actually performs better with a spotty network. Fully offline or "occasionally connected" is half the reason to use an SPA. Just as an example once downloaded FB messenger is fully functional over an unreliable network.
The spas that won't work are the ones that need to keep state while offline. Everything else works pretty fantastic, and arguably better than most spas which need to do heavyweight xhr Json or grpc calls, though if you can have a persistent grpc connection over websocket you might be competitive performance-wise.
Absolutely. There are so few places where you actually need an SPA. And now with form_with doing remote forms by default and getting inline responses from the server it is a real stretch for someone to say they absolutely need some of these JS frameworks to get some simple non page load functionality.
So much whining about SPAs. A properly written SPA is very performant and really doesn't have huge differences compared to MPA.
If anything the only thing that's changed is people understand how to properly write a SPA and JavaScript web development is finally reaching a period of some level of stability.
It really depends on what you're trying to do. Want a fully offline app? Good luck without SPA.
Please do share which crappy SPAs you're thinking of
reply