4 ms·

Strangely enough, this dichotomy seems to exist only for the web platform. Everywhere else (desktop, mobile etc) the model is SPAs. The only reason people dis

by aatd86 3y ago

Strangely enough, this dichotomy seems to exist only for the web platform. Everywhere else (desktop, mobile etc) the model is SPAs. The only reason people distinguish it for web is because of legacy: html + DOM, i.e. Documents. Documents don't generally require programmers even if using lateX. Both models can coexist. I believe that SPAs somewhat supersede MPAs and that an MPA can be a simplification sometimes for a specific kind of apps, a website being simply an app that has been broken apart and is sent piece by piece.

lloeki 3y ago
Oh my, may I remind folks about SDI vs MDI https://en.m.wikipedia.org/wiki/Multiple-document_interface https://en.m.wikipedia.org/wiki/Multiple-document_interface Or the window-is-application/process (Windows, Linux DEs) vs window-is-document-and-application-is-independent (MacOS) models Or spatial navigation vs file browser.
chriswarbo 3y ago
> Strangely enough, this dichotomy seems to exist only for the web platform. > Everywhere else (desktop, mobile etc) the model is SPAs. It exists for CLIs too, where some projects provide a collection of single-purpose programs (e.g. imagemagick) and others provide a single program which can do many things (e.g. git)
- masfuerte 3y ago
  git is a facade and "git add" actually calls "git-add". On Windows this means separate exes, git-add.exe, git-commit.exe, git-update.exe, etc. But all these exes are actually identical. So git is multiple copies of a single program which can do many things!
- paulddraper 3y ago
  No not really. Yes there are two approaches, but you can switch between the two with 98% of the code intact.
  - pas 3y ago
    and you have identified the problem. web dev tooling, despite the extreme churn, is still absolutely poo-poo to use the technical term. of course, mostly because very few oh-new-shiny-woah-such-modern tools doesn't even attempt to solve the problem of backend-frontend state sync. sure, maybe you get a piece of the puzzle (eg. a library that conveniently rerenders on state change, React, or one that you can wire up with all the fancy observables, Angular, or one that's super simple, sleek, even has magical runes that help with only rerendering the things affected by the state change, Svelte ... and maybe on top of these you get a state manager library, and then you still end up writing a thousand mutator/reducer in Redux by hand). So we are still nowhere near a nice end-to-end full-stack tool that helps model both backend and frontend changes and then helps to design and implement an efficient API between them. (Because, obviously, it seems that this is not obvious to most people. Hence we get solutions like expose your DB as REST API and ship your DB via WASM sqlite, and so on.) That said, even those might be better than one more frontend-only state management lib.
    - paulddraper 3y ago
      I think you're discounting (1) the fact that there is only one front end runtime, and any number of backend runtimes (2) the application is distributed across a network. Those are the reasons why SPA and MPA are so different
acdha 3y ago
> Everywhere else (desktop, mobile etc) the model is SPAs. > The only reason people distinguish it for web is because of legacy: html + DOM, i.e. Documents. There’s another key difference: the other model has preinstalled software and most functionality is on trusted clients. If I email you a Word document, you don’t have to download Word from the Office servers to open it, which creates very different trade offs. There’s also a big difference in trust: I don’t need to ask whether I want each web page I open to have access to the data on my computer. The web’s big selling point was the immediacy of being able open anything quickly and not needing to trust the remote server to run native code on your system (even in the 90s we knew that was a bad idea), so it’s not surprising that there’s so much gravity to its core model. The addition of more app-like abilities is really useful but it’s lead to a certain amount of app-envy where people often pick the cool technical challenge without asking whether they’re working on an app which needs it.
sfn42 3y ago
To me, the core of this entire issue is complexity and where it belongs. My view is that you should perform as much processing as possible in the backend. This allows you to send as little data as possible over the network and allows your application code to make more sense because all your domain logic is centered in one self-contained app. Now this self-contained app is just a software library, it doesn't do anything on it's own. But you can throw a CLI on top of it and use it through the terminal. You put a web api on top of it and use it from an SPA. You can use it as a backend for a server side rendered app. The ideal, in my eyes, is that th frontend only concerns itself with actually displaying things. It doesn't get a big list of data, filter and transform the data, then display it. It asks the backend for exactly what it needs and the backend provides exactly what it needs and it displays it and that's the end of it. Now you can have a website and a mobile app that are both trivial to develop and both use the same backend - if you fix a bug in the backend you've fixed it on both frontends. I realize this may not always be possible or practical, but I think it is both of those things more often than not.

by aatd86 3y ago

lloeki 3y ago

Oh my, may I remind folks about SDI vs MDI https://en.m.wikipedia.org/wiki/Multiple-document_interface https://en.m.wikipedia.org/wiki/Multiple-document_interface Or the window-is-application/process (Windows, Linux DEs) vs window-is-document-and-application-is-independent (MacOS) models Or spatial navigation vs file browser.

chriswarbo 3y ago

> Strangely enough, this dichotomy seems to exist only for the web platform. > Everywhere else (desktop, mobile etc) the model is SPAs. It exists for CLIs too, where some projects provide a collection of single-purpose programs (e.g. imagemagick) and others provide a single program which can do many things (e.g. git)

masfuerte 3y ago
git is a facade and "git add" actually calls "git-add". On Windows this means separate exes, git-add.exe, git-commit.exe, git-update.exe, etc. But all these exes are actually identical. So git is multiple copies of a single program which can do many things!
paulddraper 3y ago
No not really. Yes there are two approaches, but you can switch between the two with 98% of the code intact.
- pas 3y ago
  and you have identified the problem. web dev tooling, despite the extreme churn, is still absolutely poo-poo to use the technical term. of course, mostly because very few oh-new-shiny-woah-such-modern tools doesn't even attempt to solve the problem of backend-frontend state sync. sure, maybe you get a piece of the puzzle (eg. a library that conveniently rerenders on state change, React, or one that you can wire up with all the fancy observables, Angular, or one that's super simple, sleek, even has magical runes that help with only rerendering the things affected by the state change, Svelte ... and maybe on top of these you get a state manager library, and then you still end up writing a thousand mutator/reducer in Redux by hand). So we are still nowhere near a nice end-to-end full-stack tool that helps model both backend and frontend changes and then helps to design and implement an efficient API between them. (Because, obviously, it seems that this is not obvious to most people. Hence we get solutions like expose your DB as REST API and ship your DB via WASM sqlite, and so on.) That said, even those might be better than one more frontend-only state management lib.
  - paulddraper 3y ago
    I think you're discounting (1) the fact that there is only one front end runtime, and any number of backend runtimes (2) the application is distributed across a network. Those are the reasons why SPA and MPA are so different

acdha 3y ago

> Everywhere else (desktop, mobile etc) the model is SPAs. > The only reason people distinguish it for web is because of legacy: html + DOM, i.e. Documents. There’s another key difference: the other model has preinstalled software and most functionality is on trusted clients. If I email you a Word document, you don’t have to download Word from the Office servers to open it, which creates very different trade offs. There’s also a big difference in trust: I don’t need to ask whether I want each web page I open to have access to the data on my computer. The web’s big selling point was the immediacy of being able open anything quickly and not needing to trust the remote server to run native code on your system (even in the 90s we knew that was a bad idea), so it’s not surprising that there’s so much gravity to its core model. The addition of more app-like abilities is really useful but it’s lead to a certain amount of app-envy where people often pick the cool technical challenge without asking whether they’re working on an app which needs it.

sfn42 3y ago

To me, the core of this entire issue is complexity and where it belongs. My view is that you should perform as much processing as possible in the backend. This allows you to send as little data as possible over the network and allows your application code to make more sense because all your domain logic is centered in one self-contained app. Now this self-contained app is just a software library, it doesn't do anything on it's own. But you can throw a CLI on top of it and use it through the terminal. You put a web api on top of it and use it from an SPA. You can use it as a backend for a server side rendered app. The ideal, in my eyes, is that th frontend only concerns itself with actually displaying things. It doesn't get a big list of data, filter and transform the data, then display it. It asks the backend for exactly what it needs and the backend provides exactly what it needs and it displays it and that's the end of it. Now you can have a website and a mobile app that are both trivial to develop and both use the same backend - if you fix a bug in the backend you've fixed it on both frontends. I realize this may not always be possible or practical, but I think it is both of those things more often than not.