3 ms·

So, an app is a thing. It’s not an arbitrary term; it’s a stand alone program that runs on a device. A “thin client” is also a thing, it’s something that runs

So, an app is a thing. It’s not an arbitrary term; it’s a stand alone program that runs on a device. A “thin client” is also a thing, it’s something that runs “just the ui” for some network application. This is the distinction between web-app and website: state. I’ve worked on a lot of these projects, and that’s what it’s always boiled down to. There are only three combinations: - do you have two state models, one on the sever and one on the client? - do you have one state model on the server and just show views of that state on the client? - or (rarely) do you have state only on the client? All of these “modern takes” are basically just trying to reduce complexity by saying “maybe we only need the server state model? Isn’t that easier?” …and yes; it is easier to model state that way, but, unsurprisingly, other things become harder when you do; but this is not a new invention. It’s not even a new idea. Apps (like, actual apps) have done this for a long time too… and it’s ok. It doesn’t solve all your problems… but sure whatever. However. Maybe we don’t need to invent new ways to describe things that already exist…? I don’t think an arbitrary (and it is) four quadrant breakdown like this really does much to help people navigate this space. Bluntly, you can’t have your cake and eat it too. If you want app like behaviour, you need an app. These things like htmx make things easier, and quicker, but they don’t offer all the power of having a rich client state. If you want something that’s great, shortcuts don’t get you there… but, most people don’t need that stuff, it’s just nice… but if you’re not prepared to pay for it, don’t.

Dalewyn 3y ago
>So, an app is a thing. It’s not an arbitrary term; it’s a stand alone program that runs on a device. "App" is an arbitrary term, the word you are looking for is application. >Maybe we don’t need to invent new ways to describe things that already exist…? I agree. Can we also stop saying "AI" to refer to algorithms and macros which referred to applications?
- wokwokwok 3y ago
  https://www.apple.com/au/apps/ https://www.apple.com/au/apps/ There is a common usage for these terms, they are not arbitrarily. Describing websites purely on a “static vs dynamic” or “online vs offline” is arbitrary. That is simply assigning subjective values to the way you interpret a website as behaving and then categorising all websites by that subjective set of metrics. That’s what arbitrary means. How do I measure how “dynamic” a website is? Gut feel? It’s a meaningless metric. How “offline” is my website? Is it a bit offline? Certainty I know when it’s entirely off line… but on a scale of 0-10, how “offline” is a website that runs off an api vs one that fetches static json data files? Wouldn’t you say that categorising websites by these metrics is totally arbitrary? I certainly think it is. This is some classic armchair theorising (look it up); first you invent some labels, then you put everything under those labels in a way that is convenient (rather than data driven) then you talk about it to support some ideas you have.
PaulDavisThe1st 3y ago
And yet, in Microsoft's desktop-native version of MVC (i.e. no web-centric concepts or technology at all), they introduced an extra component - the View Model. The app's View Model is a reduced, simplified version of the Model which tracks changes in the Model; the View presents the state of the View Model; the Controller typically modifies the Model.
- wokwokwok 3y ago
  A server view model is server side state. A website (or a mobile app) is not a single application running on a distributed framework (in most cases). It is two applications. The question is usually: how complicated is the client application? Is it a thin layer that simply renders server state? Or does it have it own inherent state (like “this component is currently in a dragged state”)? All I’m saying is; if you want rich fluid client behaviour, you’re fooling yourself if you think any kind of hybrid “server only” approach is the best. It’s not. You cannot beat native apps for functionality. What you can do, is write apps more quickly and easily… and perhaps they will be better and more functional for the effort you put in… but ultimately, a well made, well structured native app (be it browser or desktop or mobile) is fundamentally able to do more, with less latency, than a server driven application. It’s just about where you put effort in, and what final end result you want at the end. It’s just easier and less complex to drive everything from the server.
  - DANmode 3y ago
    What is the meaning of "latency" here, when we're talking about dragging and dropping a Dashboard card (seamless feeling, because of the responsiveness of the local UI), or saving an update to text fields (again, should feel instant if your UI is done correctly)?
  - halfcat 3y ago
    > if you want rich fluid client behaviour, you’re fooling yourself if you think any kind of hybrid “server only” approach is the best. It’s not. You cannot beat native apps for functionality. Where does something like Microsoft Remote Desktop Services fit into this location-of-state model? It’s a classic thin client app, but you can run it in “RemoteApp” mode, where instead of remote controlling a full Windows session, you only see a single app’s window, making it largely indistinguishable from running a native app. It can be setup where the user sees, say, an Excel icon on their desktop, and the average user virtually cannot tell if they’re running a native app or a remote app. The experience is surprisingly good. Even over higher latency connections, I’ll notice slow server hardware before I’ll notice network latency. On the flip side, if we allocate a lot of server resources to a remote app, where a user is doing data analysis on a large data set, they will absolutely prefer the remote app. Point being, the latency tends to be a non issue.

Dalewyn 3y ago

>So, an app is a thing. It’s not an arbitrary term; it’s a stand alone program that runs on a device. "App" is an arbitrary term, the word you are looking for is application. >Maybe we don’t need to invent new ways to describe things that already exist…? I agree. Can we also stop saying "AI" to refer to algorithms and macros which referred to applications?

wokwokwok 3y ago
https://www.apple.com/au/apps/ https://www.apple.com/au/apps/ There is a common usage for these terms, they are not arbitrarily. Describing websites purely on a “static vs dynamic” or “online vs offline” is arbitrary. That is simply assigning subjective values to the way you interpret a website as behaving and then categorising all websites by that subjective set of metrics. That’s what arbitrary means. How do I measure how “dynamic” a website is? Gut feel? It’s a meaningless metric. How “offline” is my website? Is it a bit offline? Certainty I know when it’s entirely off line… but on a scale of 0-10, how “offline” is a website that runs off an api vs one that fetches static json data files? Wouldn’t you say that categorising websites by these metrics is totally arbitrary? I certainly think it is. This is some classic armchair theorising (look it up); first you invent some labels, then you put everything under those labels in a way that is convenient (rather than data driven) then you talk about it to support some ideas you have.

PaulDavisThe1st 3y ago

And yet, in Microsoft's desktop-native version of MVC (i.e. no web-centric concepts or technology at all), they introduced an extra component - the View Model. The app's View Model is a reduced, simplified version of the Model which tracks changes in the Model; the View presents the state of the View Model; the Controller typically modifies the Model.

wokwokwok 3y ago
A server view model is server side state. A website (or a mobile app) is not a single application running on a distributed framework (in most cases). It is two applications. The question is usually: how complicated is the client application? Is it a thin layer that simply renders server state? Or does it have it own inherent state (like “this component is currently in a dragged state”)? All I’m saying is; if you want rich fluid client behaviour, you’re fooling yourself if you think any kind of hybrid “server only” approach is the best. It’s not. You cannot beat native apps for functionality. What you can do, is write apps more quickly and easily… and perhaps they will be better and more functional for the effort you put in… but ultimately, a well made, well structured native app (be it browser or desktop or mobile) is fundamentally able to do more, with less latency, than a server driven application. It’s just about where you put effort in, and what final end result you want at the end. It’s just easier and less complex to drive everything from the server.
- DANmode 3y ago
  What is the meaning of "latency" here, when we're talking about dragging and dropping a Dashboard card (seamless feeling, because of the responsiveness of the local UI), or saving an update to text fields (again, should feel instant if your UI is done correctly)?
- halfcat 3y ago
  > if you want rich fluid client behaviour, you’re fooling yourself if you think any kind of hybrid “server only” approach is the best. It’s not. You cannot beat native apps for functionality. Where does something like Microsoft Remote Desktop Services fit into this location-of-state model? It’s a classic thin client app, but you can run it in “RemoteApp” mode, where instead of remote controlling a full Windows session, you only see a single app’s window, making it largely indistinguishable from running a native app. It can be setup where the user sees, say, an Excel icon on their desktop, and the average user virtually cannot tell if they’re running a native app or a remote app. The experience is surprisingly good. Even over higher latency connections, I’ll notice slow server hardware before I’ll notice network latency. On the flip side, if we allocate a lot of server resources to a remote app, where a user is doing data analysis on a large data set, they will absolutely prefer the remote app. Point being, the latency tends to be a non issue.