Browsers use 1085 times more memory (299,656K/276K) than x11/wingdi for apps running in my(any) cloud.

How did we get here? Applications running over browsers are useful, in a way, but there are too many layers of crap between the ui and the app. We have at least 2 perfectly good guis X11 and wingdi target those, I did.

Shown above is my calc app running over my cloud on my antibrowser and on the javascript implementation of the machine turning any javascript capable browser into the gui terminal a gui app really needs. The Chrome memory footprint 299656K, my (anti)browser 276K. Now my apps that run over my cloud don't know and don't care where the UI is, the interface is very much like a simplified x11. My servers both web and cloud are simple state machines as are the routers, no windows server no apache server just straight C and sockets all routers pass packets WITHOUT COPYING! there is room to encode routing info needed for clouds and nested clouds. My remote ui (antibrowser) is also very simple and the code has been written in C, java(although that's slow) C++ and at least in part in awk. Look at the C. It has been built for windows mingw native and linux. Yes there is a any browser hack for those who like the bloat of 299,656K to run their apps over a cloud instead of 276K antibrowser.

https://bitbucket.org/timcdoc/antibrowser/src/master/ antibrowser source code. I was just about to get @Tom McGuire to optimize my cloud and web routers and probably the antibrowser C, 276K is still waaaay too much for an application memory footprint. A side effect of having a simple UI interface is the cloud router can issue a cloud server shortage error message by doing just the following char fail_text[] = "l$ 0 100 100 \"No cloud servers available now\"\nU 2000000\nO 0 0 0\n"; when dumped to a remote ui tells the UI left justified text, font 0 at x 100/10000width and y 100/10000width display "No cloud servers available now" wait 2 seconds then shut off the UI. See protocol.txt in antibrowser source for more info. Next up, I'll start working on the nested cloud() cloud(2) so a cloud ui would encapsulate another cloud a layer down and shuttle ui back and forth given the locations. Just got a tiny app server four banger calculator written in C for cloud(0) I'll have to make a free #SDK the memory footprint is 152K without even trying, I can squeeze it down a lot more I am sure. The tiny app/server has no gui of it's own, doesn't need one. It can already run over a network this is the server side to the tiny NOT browser client which is handling the UI in this case.