Live data from Hacker News

os.js: JavaScript Cloud/Web Desktop Platform

os.js.org

41–50 of 100 posts

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

#41
post #33
post #29

Earlier quoted context omitted.

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 u…

The single thread limitation is caused by the global interpreter lock[0] that's common to most interpreted languages. Along with JS, it also appears in CPython and Ruby MRI, the reference implementation of Python and Ruby respectively. [0] https://en.wikipedia.org/wiki/Global_interpreter_lock

That doesn't eliminate the possibility of pre-emption though does it?

A theoretical version of setTimeout that triggered immediately suspending the active code and executing the timeout function then resuming (or potentially not).

That only requires the interpretor to execute one piece of code at a time. The notions of thread safety would apply to the interpreted code, but not to the interpretor itself.

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

#42
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…

I'm a fan of the "why not" answer when it comes to just about everything tech. So many great things come from those two words.

I agree whole heartedly. My most loathed feedback is "What's the use case?".

I have done a lot of odd projects, (A JavaScript desktop amnong them) and have hit this same "Why" "What's it good for" etc.

I find it difficult so to fathom how people can look at things and see nothing of value. Sure I can think how something could be done differently, possibly better even. There's always some value, practical, aesthetical, inspirational, insightful or even inciteful.

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

#43

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.

There's no reason you can't have multiple "apps" running at the same time, you just don't have preemption ( https://en.wikipedia.org/wiki/Preemption_(computing) ) so it's possible for one application to tie up the CPU indefinitely. That's definitely not whats happening in this case, since the UI is still responsive.

Alternatively, to get true isolation and preemptive multitasking you could have a sort of "window server" that sends UI events to Web Workers and received drawing commands of some kind (a React virtual DOM?)

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

#44
post #31

Earlier quoted context omitted.

A single core machine can multi thread, but without a timer interrupt it's hard work. What can JavaScript do to provide an interrupt short of emulating a processor with an interrupt via some form of: while true() { do an instruction; check for interrupt; } It's not an efficient way to go.

This is just an event loop, no?

In a sense it is, and in a way that is the problem with the current model of JavaScript.

That line

  do an instruction;
Is the smallest unit of code execution. In JavaScript* that is an event. Let's call it a wibblywoop.

JavaScript is effectively designed around the premise that a wibblywoop takes a negligible amount of time. This premise is false. Oftentimes it does take a negligible amount of time, when it doesn't the impact of responsiveness is severe. This is why everything becomes a callback. The language itself has indicators that this should not be the case. the existence of things like Array.Map shows that there was certainly an intention at some point for a function to be able to do a significant workload and return a result.

* in implementations anyway. The language itself doesn't seem intrinsically bound to the event model.

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

#47

That's interesting, it's an operating system emulation running in the browser, and the one thing missing is.. a browser.

Would definitely be interesting how many levels we could go down. I'm going to assume 2.

Why 2?

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

#49
An example for the "why" question -- the "web desktop with apps" style seems to work for NAS control panels (namely QNAP and Synology). As far as I know, they are using Sencha ExtJS for the UI -- which, although pretty complete and mature, doesn't get a lot of developer love.

https://www.google.com/search?tbm=isch&q=qnap+control+panel

https://www.google.com/search?tbm=isch&q=synology+control+pa...

Here is a QNAP demo, if you search around you may also find a Synology one that works. http://www.qnapworks.com/live-demos.asp

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

#50

I cant really see any good use cases. But WOW am i impressed that, is one of the cooler things i have seen on the web.

Always cool to see these in action, but multiple "online desktops" have come and gone since the mid-2000s. I personally built one myself in 2010 only to realize it had been tried and failed a few times. My next instinct was that to get attention and attract users I'd need a mobile-style UI. My instincts were wrong, and your gut is right. There wasn't a strong enough use case.

The motivator for these projects is typically something along the lines of, "it would be great if there was just one OS or interface I could use on any device." As engineers it's very easy for us to see the usage pattern of apps, the speed, power and ubiquity of web tooling + JavaScript and say, "aha! The next logical evolution is all of your client logic on the web!"

Alas, if it were only that easy.

"Unfortunately, this ability to see patterns can prove catastrophic as you attempt to build your own company. The more you generalize the solution to a particular pain, the further removed it becomes from that specific pain. While it might end up being able to solve a lot of pains, it won’t be very good at solving any particular one." [1]

A shared, web-based environment is probably where everything is going. I mean we're more than halfway there with most operating systems, cloud backups, tons of SPAs, etc. The problem is there's no consumer-driven need for a fast transition to a JavaScript "OS" environment. Everything is just good enough, and offloading all device logic to the web, for the end user, is barely noticeable (if not a minor detriment as older devices still have rendering issues). It's likely that everything will converge on this sort of environment (but without the desktop metaphor) because engineers want to head towards elegant solutions, but it will take time. (You won't convince people to start switching with software alone if it means they have to figure out how to open Chrome / Safari / Whatever on their phones, first.)

FirefoxOS [2] is probably getting pretty close. The sooner we get to an OS just being a glorified web browser, the more we drive development spending way down and cut costs for the consumer. Then the software will already exist, packaged with the phone. But you need the phone first --- not the software. That's the product. That drives consumer demand. "JavaScript OS" becomes a reality as soon as web-rendering matches native performance on ubiquitous, low-end devices. The software will exist to sell the product, not vice-versa. (We'll also have a Cambrian explosion of offline-first front-end tooling. ;))

... Yeah, I've done a lot of thinking about this. ;) Was my first big pet project.

[1] http://degoes.net/articles/engineer-entrepreneur/

[2] https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS

Post reply on HN