A desktop app still has the concept of routes, will have a sqlite database, and effectively has a domain (to handle deeplinks). Especially one as complex as photoshop. I used to be an android/iOS native developer.
"a certain level of feature richness" presupposes both what an app does and how it does it. There are many large classes of apps that both "don't have to have these things" and that having these things would be torturing abstractions. (e.g. multi-document interfaces, canvases, simulations, …)
Wrong? Maybe. The text editor I use does not have a sqlite database, nor a domain, nor a route. Neither does the command line shell I use. Nor the compilers and assemblers. I also have a game or two that are native applications. Not everything runs on the web.
No, I'm playing the "not every application is a web application". Or maybe even "not every website is an application."
Also, I think your conflating concepts in your own argument. My shell has a name, it's "bash". I lives on the file system under the path "/usr/bin/bash". The shell only has a few "commands" built in, stuff like "cd", "echo" and "history". It can run other applications, even stuff like Firefox or Photoshop, by executing the application that lives on the file system. The behavior of Firefox doesn't live in bash, it's its own application.
Or another example. I have a Gemini server. gemini.conman.org is the domain name of the site. The closest thing to an "app" I have on it is gemini://gemini.conman/org/8-Ball (where you ask it a question and it returns one of 20 stock answers). The rest of the site doesn't have "apps" but documents, like the King James Bible. So for the 8-Ball "application", what's the name? The route? The deeplinks? Is the King James Bible I have there an application? A route?
I can see where you are coming from. I'm just saying it's not a universal viewpoint.
From reading this discussion it felt a bit like if you try to shoehorn some Model-View-Controller pattern onto an arbitrary application. There are usually analogies but it does not match 1:1. Can still be useful to map it to your existing understanding.
From reading this discussion it felt a bit like if you try to shoehorn some Model-View-Controller pattern onto an arbitrary application. There are usually analogies but it does not match 1:1. Can still be useful to map it to your existing understanding.
This looks like a great system for operating multiple apps in a cooperative way, with multiple tasks! Boy, I wonder what we could call something like that. Maybe some kind of...cooperative...multi-tasking...operating...something. I don't know, any ideas?
Jokes aside, this does make some sense. I've worked on multiple projects that allowed the entire stack of services to be built as one binary, usually for debug purposes, and there are certainly benefits there. I'm not sure how generalizable it is to truly heterogeneous sets of applications, however.
This article would really benefit from Some numbers. As it is, it advocates for adding constraints, significantly reducing isolation between web servers and complicating deployment, all without presenting any concrete benefits, which are likely to be borderline irrelevant for most apps and servers.
So currently. It can handle 1000+ concurrent users per core at 10FPS (so 10k SSE events per second) generating 3mb of html uncompress per user (most apps don't have 300kb html per page). Each connection has a zstd compressor with 512kb window. So small changes result to 14-30bytes over the wire. Each render for each user does around 25 database queries. Handles much more if less is changing, these numbers are from a worst case cache thrash load test.
Writes are batched. So can scale to 50-100k TPS per core (sqlite is single writer but you can have different apps writers run on different cores if you need to).
This whole adventure mostly started because it scales well and the irony is most apps don't have that many users. So what to do with that performance.
spc476 | a day ago
When did an app (short for "application") become "a domain, a database and some routes?" (Me looks at Photoshop running locally on my computer ... )
[OP] andersmurphy | a day ago
A desktop app still has the concept of routes, will have a sqlite database, and effectively has a domain (to handle deeplinks). Especially one as complex as photoshop. I used to be an android/iOS native developer.
So am I wrong?
quad | a day ago
What are the routes, database, and domain / deeplinks for Calculator?
[OP] andersmurphy | a day ago
You obviously don't have to have these things. But, at a certain level of feature richness they become useful.
quad | a day ago
"a certain level of feature richness" presupposes both what an app does and how it does it. There are many large classes of apps that both "don't have to have these things" and that having these things would be torturing abstractions. (e.g. multi-document interfaces, canvases, simulations, …)
spc476 | 18 hours ago
Wrong? Maybe. The text editor I use does not have a sqlite database, nor a domain, nor a route. Neither does the command line shell I use. Nor the compilers and assemblers. I also have a game or two that are native applications. Not everything runs on the web.
[OP] andersmurphy | 14 hours ago
Even in the case of a command line shell.
I know your trying to play the whole "look how silly web devs are" card. But the concepts are more general than webdev.
spc476 | 13 hours ago
No, I'm playing the "not every application is a web application". Or maybe even "not every website is an application."
Also, I think your conflating concepts in your own argument. My shell has a name, it's "bash". I lives on the file system under the path "/usr/bin/bash". The shell only has a few "commands" built in, stuff like "cd", "echo" and "history". It can run other applications, even stuff like Firefox or Photoshop, by executing the application that lives on the file system. The behavior of Firefox doesn't live in bash, it's its own application.
Or another example. I have a Gemini server.
gemini.conman.orgis the domain name of the site. The closest thing to an "app" I have on it is gemini://gemini.conman/org/8-Ball (where you ask it a question and it returns one of 20 stock answers). The rest of the site doesn't have "apps" but documents, like the King James Bible. So for the 8-Ball "application", what's the name? The route? The deeplinks? Is the King James Bible I have there an application? A route?I can see where you are coming from. I'm just saying it's not a universal viewpoint.
wink | 30 minutes ago
From reading this discussion it felt a bit like if you try to shoehorn some Model-View-Controller pattern onto an arbitrary application. There are usually analogies but it does not match 1:1. Can still be useful to map it to your existing understanding.
wink | 30 minutes ago
From reading this discussion it felt a bit like if you try to shoehorn some Model-View-Controller pattern onto an arbitrary application. There are usually analogies but it does not match 1:1. Can still be useful to map it to your existing understanding.
academician | 16 hours ago
This looks like a great system for operating multiple apps in a cooperative way, with multiple tasks! Boy, I wonder what we could call something like that. Maybe some kind of...cooperative...multi-tasking...operating...something. I don't know, any ideas?
Jokes aside, this does make some sense. I've worked on multiple projects that allowed the entire stack of services to be built as one binary, usually for debug purposes, and there are certainly benefits there. I'm not sure how generalizable it is to truly heterogeneous sets of applications, however.
MatejKafka | a day ago
This article would really benefit from Some numbers. As it is, it advocates for adding constraints, significantly reducing isolation between web servers and complicating deployment, all without presenting any concrete benefits, which are likely to be borderline irrelevant for most apps and servers.
[OP] andersmurphy | a day ago
So currently. It can handle 1000+ concurrent users per core at 10FPS (so 10k SSE events per second) generating 3mb of html uncompress per user (most apps don't have 300kb html per page). Each connection has a zstd compressor with 512kb window. So small changes result to 14-30bytes over the wire. Each render for each user does around 25 database queries. Handles much more if less is changing, these numbers are from a worst case cache thrash load test.
Writes are batched. So can scale to 50-100k TPS per core (sqlite is single writer but you can have different apps writers run on different cores if you need to).
This whole adventure mostly started because it scales well and the irony is most apps don't have that many users. So what to do with that performance.