Comment by apatheticonion
4 years ago
I really view it as the opposite.
Prefer the writing of an SPA or serverless MPA.
If you consider that native desktop and mobile applications are siloed applications that coordinate with an API to achieve tasks - this is basically how SPAs or serverless MPAs work.
Part of the reason this is effective is because of the low cost nature of deploying applications like this.
For example; I can write a calorie counter that stores records in the client via indexeddb.
Given all the work is processed on the client, using an http server would be an unnecessary maintenance burden as it would simply server static files.
Rather than host the web application via a self managed http-server, I can just put my html files on S3 making hosting it free and unmanaged.
Should I decide I need to add user accounts and cloud storage - well I can then create a backend that exposes API endpoints to facilitate the tasks.
Those endpoints are then compatible with native applications, should I decide to write native mobile and desktop variations of my web application.
Furthermore, with Web Assembly expanding to offer the ability to write web applications using languages like C++, Rust, C#, Golang and the browser expanding access to OS subsystems like filesystem access - what we are seeing is that the browser is becoming a sandboxed UI toolkit, much like GTK or QT (except without native styling).
If there was anything that would empower Linux Desktops to be compatible with productivity software - it's progressive web applications.
Consider that Photoshop and Office are accessible on Linux via web today.
That's a lot of interfaces to create and maintain. The principle value of backend/MPA frameworks like Rails & Django is that they give you nearly all these interfaces for free in a neat package, which ends up being "good enough" for many use cases below Google-scale.
A calorie counter using IndexDB is a great example of something where an SPA is appropriate - like I said, "default to not writing an SPA, unless your project has specific, well understood requirements (e.g. you're building Figma) that make the SPA route a better fit".
I mainly work in the world of database-backed websites and applications, where going client-only without a backend isn't an option.
> Consider that Photoshop and Office are accessible on Linux via web today.
Never used Photoshop, but Office on the web still sucks compared even to native MS Office.
You're describing an actual client side (mobile or desktop) application made with web technology, not a web application. That's a fair use of SPA tech.
As soon as you need authentication, showing data across users, allowing visitors to see shared data, perform validation of inputs, send notifications when other user action happens, etc you're back in SPA hell.
Why do any of those attributes put you in SPA hell?
If you were to write an Android application that featured Authentication, would you also be in "app development hell"?
Languages, performance and UI decorations aside - it's basically the same thing, no?