Live data from Hacker News

os.js: JavaScript Cloud/Web Desktop Platform

os.js.org

21–30 of 100 posts

Re: os.js: JavaScript Cloud/Web Desktop Platform

#23

Looks cool! Certainly fits the "why not" category of why it exists though I can't figure out a way to make it useable; without a proper window manager (which can't be done inside of a web browser) using apps inside of the window becomes more difficult than simply having a tab for each app. In fact if every app opened up full screen and into a new tab that could almost be handy depending on the extension API, etc.

I could see a use as some sort of a Control panel.

Re: os.js: JavaScript Cloud/Web Desktop Platform

#28

Too bad browser JS is single-threaded. If you switch windows the background application stops. Kind of limits its ability as a desktop replacement no matter how much effort they put into it.

It certainly looks as if each app lives in its own process of sorts - check the 'process viewer'

I'm sure they could use some sort of thread/process implementation with a scheduler to do stuff. Speculation, each program could be compiled to some sort of bytecode, use asm.js to implement the guts of the thing, etc.

When you think about it, a single-core machine is "single threaded" as well, you just need some interleaving code to let more than 1 thing run at a time, and from some casual usage of the demo, seems they've done exactly that, so there you go

Re: os.js: JavaScript Cloud/Web Desktop Platform

#29

Too bad browser JS is single-threaded. If you switch windows the background application stops. Kind of limits its ability as a desktop replacement no matter how much effort they put into it.

What is the reason for requiring the single thread of execution in JavaScript? Trading race conditions for callback hell?

Even the concurrency provided by web workers, suffer from the same issues, you communicate with them via messages and they will not respond to messages if they are looping away somewhere else.

I'd love to have some simple pre-emption in JavaScript. Suspend code execution at one point and pick it up at another. Instead of having threads, have the fundamentals that allow threads. Has this been discussed and rejected by the JavaScript community?

I'd really like to know what the deal is here

Re: os.js: JavaScript Cloud/Web Desktop Platform

#30
post #2

While it looks like a nice exercise in front end JS, and looks cool, does it solve any problems? Do users actually need some more abstraction layers on top of Google Drive / Dropbx, etc? Either I am getting too sleepy, or they didn't provide any actual use cases in the homepage. It provides some sort of API ("simple, modilarized and flexible JavaScript APIs so you can easily make changes, extend functionality and cre…

A few use cases:

1/ Make a modular backoffice for CMS based website. Make an app to manage users, an app to manage content, an app to upload and manage gallery of media etc.

2/ Make a distributed OS. All services can scale and use backend power beyond what a single node can provide. If you need to burst in the cloud due to a heavy process for instance.

3/ Could use it to provide a separation between the OS and the GUI, providing a UX I may like even if the backend server has to be Windows or Centos or ... Or remotely operating a part of my machine at home?

4/ What about reducing the cost of HW it needs to run? Chromebook style.

5/ What about being less tied in my Web App to Google Drive API + friends by adding a abstract VFS layer in between like a OS does? Same for texting, emailing? Sure it only uses part of this and don't need the client, but the architecture is well splited on this project between the two.

6/ It is multi-user as its core, so it can be shared across an organization and not only on one computer. You could even create one account per project/team and share a set of common tools / organization / folders that way across online services.

With the rise of web apps, it seems interesting to investigate the possibility of a web OS to administrate and make those ones collaborate more nicely. Or at least the possibility of separating the UX and the execution on two different nodes for general purpose systems as well.

Post reply on HN