Build Cross-Platform Applications for desktop using HTML, CSS, Javascript(appjs.org)
appjs.org
Build Cross-Platform Applications for desktop using HTML, CSS, Javascript
http://appjs.org/
22 comments
I think for us, this is redundant as we made a direct jump to the cloud, but for applications that need to be built on the desktop, this would be great.
Mike/Verelo.com
Mike/Verelo.com
This looks really cool, but for HTML5 games to work well it really could do with these things:
1) support for hardware-accelerated rendering with canvas2D
2) support for hardware-accelerated WebGL
3) ability to turn off the extremely restrictive driver blacklists in Chrome (which will turn off hardware acceleration for ~50% of users, and is not necessary if building a desktop app)
Yeah, basically games really need hardware acceleration. I know they don't mention games at all but something like this is great for additional distribution platforms and monetisation, as long as it has hardware acceleration. Anyone know if it covers that?
1) support for hardware-accelerated rendering with canvas2D
2) support for hardware-accelerated WebGL
3) ability to turn off the extremely restrictive driver blacklists in Chrome (which will turn off hardware acceleration for ~50% of users, and is not necessary if building a desktop app)
Yeah, basically games really need hardware acceleration. I know they don't mention games at all but something like this is great for additional distribution platforms and monetisation, as long as it has hardware acceleration. Anyone know if it covers that?
It's based on Chromium so it's pretty likely it will support just about everything and even more.
My experience with other wrappers is that's not so, sometimes they're based on Chromium but don't support WebGL, the Web Audio API, etc. etc. I suppose wrapping Chromium is harder than you'd think.
I really wish someone would take over development of lov8 (http://code.google.com/p/lov8/).
This! Neither side has to lose, for the other to win. Both apps and the web will live on and grow as different experiences. People should stop trying to use web technologies for everything. They are killing what made the web great, while at the same time making native apps suck more.
Node.js is pretty "close to the metal", and HTML-as-a-GUI holds great promise for quality, and for cross-platform delivery. Maybe you can't touch the bottom and you can't reach the top, but you can get at the widening middle.
And you used to be just a front end hacker.
And you used to be just a front end hacker.
This guy's opinion of course omits the huge problems of walled gardens, dickwad Apple rules, closed platforms, 30% royalty absurdity, and the archaic development process of native apps.
To which the counterpoint is "awesome UX". You'll never get that with web tech.
Sandofsky works at Twitter BTW.
You are probably right about most of the problems, though how much of a problem they really are is related to where you place yourself on a purist-pragmatic continuum.
Sandofsky explicitly mentions development: "Today, for high level work, I am as productive using Objective-C as JavaScript." That's my experience as well.
Sandofsky works at Twitter BTW.
You are probably right about most of the problems, though how much of a problem they really are is related to where you place yourself on a purist-pragmatic continuum.
Sandofsky explicitly mentions development: "Today, for high level work, I am as productive using Objective-C as JavaScript." That's my experience as well.
`node-webkit` looks similar to this: https://github.com/rogerwang/node-webkit
Very interesting - kind of like PhoneGap for your computer.
I'd recommend placing a few screenshots of example apps on the front page running natively on different systems (mac, windows, linux). Well done!
I'd recommend placing a few screenshots of example apps on the front page running natively on different systems (mac, windows, linux). Well done!
I think Topcube does this as well: https://github.com/creationix/topcube
Topcube, however, is missing the Mac version.
Another interesting idea would be to ditch Node all-together and use HTML5/CSS3 literally for everything your desktop app needs. With localStorage and other APIs being implemented in Chromium, one does not need the server part anymore.
Topcube, however, is missing the Mac version.
Another interesting idea would be to ditch Node all-together and use HTML5/CSS3 literally for everything your desktop app needs. With localStorage and other APIs being implemented in Chromium, one does not need the server part anymore.
It seems to me that ember.js is a better approach to this - much cleaner application model and richer data support with routing and view state.
That said, I'm with you broadly on Javascript+HTML5 on the desktop. Actually just wrote something up around my thoughts on how to do this with Ember.js if folks are interested:
http://bit.ly/LybVgo
That said, I'm with you broadly on Javascript+HTML5 on the desktop. Actually just wrote something up around my thoughts on how to do this with Ember.js if folks are interested:
http://bit.ly/LybVgo
appjs.purpose !== emberjs.purpose
(former gives a cross-platform runtime, latter is merely a JS framework)
(former gives a cross-platform runtime, latter is merely a JS framework)
The tech is different but the purpose is the same - to give a great application experience with software written in JS/html/css, on every platform with a single codebase. Ember is betting on the browser to be the runtime, appjs is writing their own.
oops, yes. sorry.
If you could do a one click install with no internet access this could have huge potential.
Yesterday, while working with C# and sql compact I realised the need for something like this.
Not that I have anything against C#. Love that thing, but it is complex (.NET).
Yesterday, while working with C# and sql compact I realised the need for something like this.
Not that I have anything against C#. Love that thing, but it is complex (.NET).
Instead of a "one click install" how about a "clickonce install". ClickOnce, the installer/updater built into .NET since .NET 2.0. It can also work for installing via CD or over a fileshare if you don't want it over the internet.
Pokki (http://developers.pokki.com) is a similar platform that builds to Windows and supports WebGL.
The hardest part of all of this is getting a runtime that builds/installs seamlessly across platforms. I just did an 'npm install appjs' as per docs, and it failed (Mac).
I myself have gone through great lengths to create a similar (minus Webkit) runtime for Mac, Windows, and Linux:
https://github.com/arturadib/node-qt
https://github.com/arturadib/node-five
Despite all my efforts there are edge cases where it simply won't install/build.
Keep up the good work though -- this is a much needed project. (Bear in mind too that Mozilla and other companies are coming out with their own runtimes for web apps, so such projects will likely be rendered obsolete by them).
I myself have gone through great lengths to create a similar (minus Webkit) runtime for Mac, Windows, and Linux:
https://github.com/arturadib/node-qt
https://github.com/arturadib/node-five
Despite all my efforts there are edge cases where it simply won't install/build.
Keep up the good work though -- this is a much needed project. (Bear in mind too that Mozilla and other companies are coming out with their own runtimes for web apps, so such projects will likely be rendered obsolete by them).
Why are you trying to reinvent the wheel?
I already mentioned XULRunner here, and I´d suggest you have a look at it. There are a few applications you may have heard about using it https://developer.mozilla.org/en/XULRunner_Hall_of_Fame
I already mentioned XULRunner here, and I´d suggest you have a look at it. There are a few applications you may have heard about using it https://developer.mozilla.org/en/XULRunner_Hall_of_Fame
ugh. have you ever developed stuff in XUL? It's not a great system. It's also pretty ancient, so there's probably cruft there support old XUL applications built in 2002.
I think the main problem is that XUL is like HTML, but not. So people's brains are already wired to understand html, but when there's something that looks identical to it, but has it's own set of quirks, it takes a lot of time getting used to. It's as if someone took C++ and changed just enough stuff so that you wouldn't notice it until you tried to run it.
How many html tags do you recognize here: https://developer.mozilla.org/en/XUL_Reference ?
Lots of the tags are somewhat historical because css wasn't as powerful back in 2002 as it is today. Most people starting to hack XUL won't know the difference between a bbox and a deck tag.
I think the main problem is that XUL is like HTML, but not. So people's brains are already wired to understand html, but when there's something that looks identical to it, but has it's own set of quirks, it takes a lot of time getting used to. It's as if someone took C++ and changed just enough stuff so that you wouldn't notice it until you tried to run it.
How many html tags do you recognize here: https://developer.mozilla.org/en/XUL_Reference ?
Lots of the tags are somewhat historical because css wasn't as powerful back in 2002 as it is today. Most people starting to hack XUL won't know the difference between a bbox and a deck tag.
I admit not having worked extensively with XULRunner. Maybe 4 years ago was it, but I know that html can be used via the html namespace https://developer.mozilla.org/en/XUL_Tutorial/Adding_HTML_El...
It looks quirky, but I thought the most important part of using web technologies is to use Javascript and CSS; which can be applied over XUL elements just like HTML.
Also compared to the current project it is vastly superior in terms of features and functionality that can be tapped into with Javascript.
There is space for improvement, like with most software, but it is in fact a tested technology already.
It looks quirky, but I thought the most important part of using web technologies is to use Javascript and CSS; which can be applied over XUL elements just like HTML.
Also compared to the current project it is vastly superior in terms of features and functionality that can be tapped into with Javascript.
There is space for improvement, like with most software, but it is in fact a tested technology already.
There's no wheel being reinvented. XULRunner is based on XUL, which makes it fundamentally different from the goal of above projects (that is, to use HTML technologies alone to build 'native' apps).
Some of us at Mozilla Labs have tried to fill this gap through the Chromeless project (https://github.com/mozilla/chromeless), but we've stopped working on it in favor of a more general runtime for web apps (that's what I was talking about in the last sentence: https://wiki.mozilla.org/Apps/WebRT).
The very fact that XULRunner/Chromeless didn't take off like PhoneGap did in the mobile arena for example is evidence that there's room for innovation in this space.
Happy to elaborate on this, but only if you promise you'll be nicer :)
Some of us at Mozilla Labs have tried to fill this gap through the Chromeless project (https://github.com/mozilla/chromeless), but we've stopped working on it in favor of a more general runtime for web apps (that's what I was talking about in the last sentence: https://wiki.mozilla.org/Apps/WebRT).
The very fact that XULRunner/Chromeless didn't take off like PhoneGap did in the mobile arena for example is evidence that there's room for innovation in this space.
Happy to elaborate on this, but only if you promise you'll be nicer :)
I´m sorry if my comment could be read hostile, it was not intentional.
But what I don´t understand is what more are you trying to achieve that cannot be done in XUL with a browser tag (https://developer.mozilla.org/en/XUL/browser), and where you can stick to vanilla html/js/css, if XUL is not an option?
But what I don´t understand is what more are you trying to achieve that cannot be done in XUL with a browser tag (https://developer.mozilla.org/en/XUL/browser), and where you can stick to vanilla html/js/css, if XUL is not an option?
It failed to install on your Mac because there is no port for Mac at the moment:)
Good Work!
https://github.com/arturadib/node-qt
This seems to be done currently through means like this: http://www.quora.com/Rdio-online-music-service/What-technolo..., it'd be nice to see an even simpler approach (like appjs) replace it.
I'm enamored with the idea of writing desktop applications with web technologies, but I'm not enamored with the idea of running a node.js instance locally for every such desktop application.
What I would like to see is a "privileged mode" Chromium (or Firefox) that would let applications break out of the browser sandbox and directly perform operations such as filesystem I/O. Privileged Mode Chromium would obviously be a huge security threat if it's allowed to run any old code, so it would be wise to prevent it from downloading and executing scripts over the network, or maybe have some kind of script signing support in place so that the only scripts allowed to execute are the ones with the app developers' signature on them. Or maybe I'm talking out of my ass here and what we have right now works just fine. Feel free to correct me here.
Also, one question. Isn't the node.js instance serving my application visible to other applications on the same system? Can't a malicious application take advantage of this fact and cause my app to misbehave?
(Offtopic: I must point out an irritating and potentially harmful design trend that is emerging as a result of Twitter Bootstrap's popularity: the top navigation bar that stays in place as you scroll downward. It wastes precious screen space, looks ugly and doesn't add anything of value to the website. Why is it so important that I be forced to look at your website's logo and navigation bar all the time? I'm not picking on the AppJS developers here; this is a general sentiment directed towards all the designers who embrace this terrible trend.)
What I would like to see is a "privileged mode" Chromium (or Firefox) that would let applications break out of the browser sandbox and directly perform operations such as filesystem I/O. Privileged Mode Chromium would obviously be a huge security threat if it's allowed to run any old code, so it would be wise to prevent it from downloading and executing scripts over the network, or maybe have some kind of script signing support in place so that the only scripts allowed to execute are the ones with the app developers' signature on them. Or maybe I'm talking out of my ass here and what we have right now works just fine. Feel free to correct me here.
Also, one question. Isn't the node.js instance serving my application visible to other applications on the same system? Can't a malicious application take advantage of this fact and cause my app to misbehave?
(Offtopic: I must point out an irritating and potentially harmful design trend that is emerging as a result of Twitter Bootstrap's popularity: the top navigation bar that stays in place as you scroll downward. It wastes precious screen space, looks ugly and doesn't add anything of value to the website. Why is it so important that I be forced to look at your website's logo and navigation bar all the time? I'm not picking on the AppJS developers here; this is a general sentiment directed towards all the designers who embrace this terrible trend.)
What I would like to see is a "privileged mode" Chromium
(or Firefox) that would let applications break out of
the browser sandbox and directly perform operations such
as filesystem I/O.
It may have been a very good idea, but the sandbox implementation was shoddy, and 'Local Machine Zone' exploits are one of the main reasons IE has such a terrible security reputation. So other browsers should be wary about introducing a 'privileged mode'.
People can always install untrusted applications written in C. Why should the fact that your application is written in HTML+JavaScript make any difference? If it's just another native application; the implementation is unimportant to the end user.
Now, security is important, and it would be nice if all applications could be verified as to security. But they aren't. So while it would be good to figure out how to properly sandbox desktop HTML+JavaScript applications, I don't see as how failure in that regard should retard their adoption anymore than it retards the adoption of native applications written in C.
Now, security is important, and it would be nice if all applications could be verified as to security. But they aren't. So while it would be good to figure out how to properly sandbox desktop HTML+JavaScript applications, I don't see as how failure in that regard should retard their adoption anymore than it retards the adoption of native applications written in C.
The obvious different is that you don't want to execute arbitrary C code just because a compromised ad network is serving malformed HTML. The ease of attack is much greater on the web.
Mozilla has used "no IE-like privileged mode" as a marketing point in the past. There's obvious benefits, but I hope any modern browser is going to be careful about the sandbox is implemented.
Mozilla has used "no IE-like privileged mode" as a marketing point in the past. There's obvious benefits, but I hope any modern browser is going to be careful about the sandbox is implemented.
You're comparing incomparable things. Serving a web page in an unsecured environment is an obvious security problem, but completely unrelated to whether you have written a native application in HTML+JavaScript or something more traditional like C.
Would the C version of your native desktop app download code from an online ad network? Then it is just as problematic as a web app in an unsandboxed browser. If the C implementation of your desktop app wouldn't do that, then the HTML+JavaScript implementation of the same application shouldn't either, and there is no problem.
Would the C version of your native desktop app download code from an online ad network? Then it is just as problematic as a web app in an unsandboxed browser. If the C implementation of your desktop app wouldn't do that, then the HTML+JavaScript implementation of the same application shouldn't either, and there is no problem.
Actually, you the one making this strange comparison to C code.
My point is simple: IE's sandbox was broken repeatedly, creating a bad reputation and scoring marketing points for other vendors.
My point is simple: IE's sandbox was broken repeatedly, creating a bad reputation and scoring marketing points for other vendors.
Mozilla and its successors, Firefox and Thunderbird are actually built on XUL[1], which is an XML-based UI description language which can be mixed with HTML and SVG, styled with CSS and programmed just like HTML with JavaScript. Then there's the xulrunner, which lets you write standalone apps on this tech. It's never taken off much, but I don't know if that's down to flaky implementation or just lack of interest. (if you don't like XUL, just use a minimal amount of it to embed your HTML app)
[1] I'm not sure what the current status is, but I think they want to phase it out?
[1] I'm not sure what the current status is, but I think they want to phase it out?
XUL is not html, and you'll have to hit the docs every time you need something. Also, debugging XUL is a pain. XUL is pretty ancient too, so that probably doesn't help either.
Sticking with plain jane html is definitely the better approach, however I doubt the XUL implementers would have ever known that back in the year 2000. There's still a bunch of tools for XUL, but fairly rusty: http://xul.sourceforge.net/
Sticking with plain jane html is definitely the better approach, however I doubt the XUL implementers would have ever known that back in the year 2000. There's still a bunch of tools for XUL, but fairly rusty: http://xul.sourceforge.net/
AppJS does not use http server to handle requests. It only simulates client/server.
It creates a custom scheme named appjs:// and handles are requests with this scheme manually without any server listening.
It creates a custom scheme named appjs:// and handles are requests with this scheme manually without any server listening.
Actually, there's already filesystem I/O in HTML5.
I'm not sure what you mean by "privileged Chromium mode". You could very well just use the regular mode that exists in your browser to create a full-blown application. Of course there's always contraints, because you only have available the HTML5 api, but now days you can do lots of stuff with it - it pretty much has everything a regular app would need (disk IO, network IO, UI, etc.).
As far as security goes, the Chromium sandbox is much more secure than any other code you would be writing yourself - after all it's the same thing that runs inside your Chrome browser, which is world-class secure.
For the Node instance, I also don't see any issue here. Sure the web-server that is initialized on your local machine is visible across your local network, but you can simply secure it just as you would with any regular web-application.
I'm not sure what you mean by "privileged Chromium mode". You could very well just use the regular mode that exists in your browser to create a full-blown application. Of course there's always contraints, because you only have available the HTML5 api, but now days you can do lots of stuff with it - it pretty much has everything a regular app would need (disk IO, network IO, UI, etc.).
As far as security goes, the Chromium sandbox is much more secure than any other code you would be writing yourself - after all it's the same thing that runs inside your Chrome browser, which is world-class secure.
For the Node instance, I also don't see any issue here. Sure the web-server that is initialized on your local machine is visible across your local network, but you can simply secure it just as you would with any regular web-application.
Re: "the Chromium sandbox is much more secure".
Have seen code targeting IndexedDB in Chromium that crashed the browser, and in one instance rebooted the machine, each and every time it was called.
Have seen code targeting IndexedDB in Chromium that crashed the browser, and in one instance rebooted the machine, each and every time it was called.
Link? This interests me.
What you're describing is well in line with Mozilla's Apps, WebAPI and even Boot2Gecko projects.
Firefox Nightly includes the ability to install an app (a webapp with a manifest file) and you get a runnable program in a platform-specific location. The WebAPI project is expanding the web platform to include other needed capabilities, driven in large part by the Boot2Gecko OS where everything is HTML, JS and CSS.
For each API, people are working out how the permissions should work. The general goal is to expand capabilities while keeping it as secure as possible without being annoying.
Firefox Nightly includes the ability to install an app (a webapp with a manifest file) and you get a runnable program in a platform-specific location. The WebAPI project is expanding the web platform to include other needed capabilities, driven in large part by the Boot2Gecko OS where everything is HTML, JS and CSS.
For each API, people are working out how the permissions should work. The general goal is to expand capabilities while keeping it as secure as possible without being annoying.
AppJS uses node.js to have node advantages:
* Node is modular so apps you develop with appjs. * Node built-in modules like FileSystem are necessary for desktop apps with the advantage of better implementation than Chromium alternatives. * Node is popular among developers. * Node has lots of third-party modules for nearly everything
* Node is modular so apps you develop with appjs. * Node built-in modules like FileSystem are necessary for desktop apps with the advantage of better implementation than Chromium alternatives. * Node is popular among developers. * Node has lots of third-party modules for nearly everything
Check out macgap
https://github.com/maccman/macgap
If you are using WebSockets for communication between Node.js and WebView then you can setup the server so that it accepts only one connection at a time. Also, when app starts you could generate random hash and pass it to Node.js and WebView environments. When Node.js server receives request that does not contain the valid hash then just drop the connection.
AppJS does not use http connections. It only simulates it. It uses a custom scheme (appjs://).Whenever a request with this scheme is made, AppJS routes it to your javascript code in node.js.
You just described NaCL.
I still find XULRunner better suited for this task.
It felt a bit like Prism (https://mozillalabs.com/en-US/prism). Unlike them, who are just slapping a browser inside a chromeless window, you are actually building it from the ground up?
It looks like AppJS is built on top of CEF framework which is basically a stripped down version of Chromium.
This also means that AppJS-based apps can't be shipped on Mac App Store because CEF makes use of private frameworks.
This also means that AppJS-based apps can't be shipped on Mac App Store because CEF makes use of private frameworks.
[deleted]
If your app runs on HTML/CSS/JS where's the point to make locally installed app out of it?
One reason might be a better hardware accessibility (at the moment) but with the pace Chrome, WebGL, etc. are evolving there shouldn't be any reason in near future and you would have cross-platform apps without any installation and update hassle.
One reason might be a better hardware accessibility (at the moment) but with the pace Chrome, WebGL, etc. are evolving there shouldn't be any reason in near future and you would have cross-platform apps without any installation and update hassle.
Q: "What's better than this stack for application development?"
A: So many things. Cocoa comes to mind.
HTML/CSS/JavaScript were never created to build applications, and it's very apparent when you do so. I've built a lot of web apps, but out of necessity. I think we're going to actually see the opposite trend in software: moving client-server apps away from browser-based solutions and toward native apps. In fact we're already seeing that movement—and I would argue that a big reason behind it is how much writing client apps in JavaScript sucks.
A: So many things. Cocoa comes to mind.
HTML/CSS/JavaScript were never created to build applications, and it's very apparent when you do so. I've built a lot of web apps, but out of necessity. I think we're going to actually see the opposite trend in software: moving client-server apps away from browser-based solutions and toward native apps. In fact we're already seeing that movement—and I would argue that a big reason behind it is how much writing client apps in JavaScript sucks.
I personally find disturbing how people wants to do _everything_ with web technologies. Can't they just learn how to write native apps? I wouldn't like to see my desktop full of slow and bloated web apps.
> Can't they just learn how to write native apps?
They can, but then they need to either write multiple ports of the app or target only a small subset of the market.
The first sucks (speaking as someone who in fact works on a project that ships a nontrivial native app on several different platforms), and the second loses you customers _and_ creates people who give you bad press because you're "locking them out" by not providing an app on their platform.
Of course web technologies are not the only way to write cross-platform apps, but the other options I know produce results that are even less appealing to users.
They can, but then they need to either write multiple ports of the app or target only a small subset of the market.
The first sucks (speaking as someone who in fact works on a project that ships a nontrivial native app on several different platforms), and the second loses you customers _and_ creates people who give you bad press because you're "locking them out" by not providing an app on their platform.
Of course web technologies are not the only way to write cross-platform apps, but the other options I know produce results that are even less appealing to users.
The potential of web tech for universal availability and cross-platform is very alluring, even if it still has many pitfalls and inadequacies.
Does Facebook have a native windows app?
What a waste of time!
Appcelerator is putting its titanium desktop framework under opensource which does EXACTLY THAT.
It already works on win/lin/mac and would only need a cleanup and update.
Why wasting time and re-creating everythin from scratch?!
Why wasting time and re-creating everythin from scratch?!
What I don't get is, honestly, the reason web apps are so much more awesome on PC's and Mac's than desktop applications are is that they are 0-configure, 0-install, 0-trace. These days, the people with the fastest computers aren't the geeks - they're people who buy a fast clean empty computer, install Firefox and never anything else and just use web apps. If they uninstall any crap that came with the computer, and keep, say, Windows (or Mac) and Firefox updated (both these OS's and Firefox are pretty proactive about this too), then after a year, their computer screams compared with anyone who downloads anything. (Such a person will normally at least start up skype, an antivirus, media programs, office suites, cam software, sometimes bittorrent or other specialty software, etc etc etc. The list goes on. All of which like to update themselves, have an update process in the background, sometimes hanging, bugging the user, etc, and all of which like to start up with the computer.)
Honestly, what the desktop experience is missing is quite simple: 1) seeing the first screen within 5 seconds of asking for it 2) every action takes a few seconds including 'installation' 3) when you close the tab it's gone.
Honestly, even if you have a VM that is 100% in RAM on the fastest computer available today, usually all programs fail at number 2 - if for no other reason than that their installation program requires the user to click Next Next Next Next Finish.
What would fix this? Well, for one thing if any web app also had root access to a non-networked-except-with-its-own-servers 100% do whatever they want with it local VM. Yet to my knowledge there is not even a distribution (of any kind of operating system whatsoever) that is geared toward giving its entire stack over to 1 application, assuming that it is all now 'tainted'.
Off hand, it would seem the requirements of such an OS would be:
- Fast startup, no unneeded services
- Very small footprint, so that a web service can go wild on it, modifying it however it wants, removing anything it doesn't want, basically, it's theirs now - and the resulting blob can be written out to disk quickly when the app closes.
- Extremely secure. No way for the app to break out of its jail, where it has total root.
- Some graphics acceleration would be awesome if this can be done securely, secure access to opengl, etc.
- EXTREME STANDARDIZATION THAT DOESN'T CHANGE FOR YEARS OR IS SUPER-PREDICTABLE.
This is the MAIN area where Firefox shines: you can TARGET it. Whereas, targeting Windows: good luck. Targeting Linux: um, a slew of questions immediately pop up. Mac: which version?
The difference between offline games and online games is just huge. Imagine if you could run any hardware accelerated game "right from your browser" waiting a few seconds for it to load. The threshold to trying it out would fall 1-2 orders of magnitude. (I would argue, for an indie house falling 3 orders of magnitude).
I do realize that this overlaps with NaCL. However, NaCL is not really about providing the full desktop STACK to developers in a standardized way: instead it focuses (from what I gather) on just the op codes. That's great, but it hardly provides OpenGL (or DirectX) or a slew of other things that desktop applications have if they want it.
Basically, I am saying: if VM software is advanced enough that security researchers run random viruses on their everyday boxes with their normal hard-drive mounted, just in a vm, then how is VM software not advanced enough to give a full desktop access to a web site, all cordoned off with write-on-modify semantics and standardized, so that the user has 0 security implications to this?
Basically, the ONE thing I would add to the experience is putting at the top of any tab that has this, the number of VM's currently running. Whereas I expect flash to work well with 10 instances, that may be asking for too much here.
Honestly, what the desktop experience is missing is quite simple: 1) seeing the first screen within 5 seconds of asking for it 2) every action takes a few seconds including 'installation' 3) when you close the tab it's gone.
Honestly, even if you have a VM that is 100% in RAM on the fastest computer available today, usually all programs fail at number 2 - if for no other reason than that their installation program requires the user to click Next Next Next Next Finish.
What would fix this? Well, for one thing if any web app also had root access to a non-networked-except-with-its-own-servers 100% do whatever they want with it local VM. Yet to my knowledge there is not even a distribution (of any kind of operating system whatsoever) that is geared toward giving its entire stack over to 1 application, assuming that it is all now 'tainted'.
Off hand, it would seem the requirements of such an OS would be:
- Fast startup, no unneeded services
- Very small footprint, so that a web service can go wild on it, modifying it however it wants, removing anything it doesn't want, basically, it's theirs now - and the resulting blob can be written out to disk quickly when the app closes.
- Extremely secure. No way for the app to break out of its jail, where it has total root.
- Some graphics acceleration would be awesome if this can be done securely, secure access to opengl, etc.
- EXTREME STANDARDIZATION THAT DOESN'T CHANGE FOR YEARS OR IS SUPER-PREDICTABLE.
This is the MAIN area where Firefox shines: you can TARGET it. Whereas, targeting Windows: good luck. Targeting Linux: um, a slew of questions immediately pop up. Mac: which version?
The difference between offline games and online games is just huge. Imagine if you could run any hardware accelerated game "right from your browser" waiting a few seconds for it to load. The threshold to trying it out would fall 1-2 orders of magnitude. (I would argue, for an indie house falling 3 orders of magnitude).
I do realize that this overlaps with NaCL. However, NaCL is not really about providing the full desktop STACK to developers in a standardized way: instead it focuses (from what I gather) on just the op codes. That's great, but it hardly provides OpenGL (or DirectX) or a slew of other things that desktop applications have if they want it.
Basically, I am saying: if VM software is advanced enough that security researchers run random viruses on their everyday boxes with their normal hard-drive mounted, just in a vm, then how is VM software not advanced enough to give a full desktop access to a web site, all cordoned off with write-on-modify semantics and standardized, so that the user has 0 security implications to this?
Basically, the ONE thing I would add to the experience is putting at the top of any tab that has this, the number of VM's currently running. Whereas I expect flash to work well with 10 instances, that may be asking for too much here.
This description is a lot like Boot2Gecko, except that Boot2Gecko is currently targeting phones rather than desktops. Chrome OS is a similar concept (though I admit to not looking too deeply at it)
I guess I didn't describe myself plainly enough. What I mean is that it should be just like Flash, working inside an HTML page right from any tab in your browser, no extra 'install' - except a full VM instead of a Flash instance.
If an application (some accounting program say) comes in Windows, Mac, and Linux downloads and is supposed to be downloaded and installed, but works fine if you install it in a VM with a plain image, why can't they put it on the web behind some HTML that asks for a jailed VM - and be given one? So that if you are on Windows, whenever you open that web site in a new Firefox tab, you use its app (right from that tab) in a few seconds without any (visible or persistent) install. Even THOUGH it is a native-only application that isn't built around networking (requests over http) nor any kind of internet technology like javascript. It's just a local program.
If the 'just a local program' could live just as happily in a new tab in a vanilla base-OS, you wouldn't need to go through installing it to try it, or uninstall it if you're not interested: this is where a 'web app' shines. Getting to the first screen takes less than one second (click the link you heard about it from, including on a Google search) as opposed to 15-45 seconds minimum to click through Download, Save, wait for it to download, Double-click in Downloads window (hopefully still in foreground) to open, Click 'Install', click 'I accept' click next, click next, click finish. Click OK and hopefully run now. (If there is no 'run now' then click Start, click Programs, find the new entry, click it.
Likewise, after you see the first screen you can say 'No this isn't what I had in mind at all' and click Back in your browser or close the new tab: 1-2 seconds. On Windows uninstall is: Click Start, Click Control Panel, click Add Remove Programs, wait for it to load, find the program, right-click, click Uninstall, click OK, wait for it to uninstall, click OK. (Or you could wager on whether they included an Uninstall icon next to their program icon in the start menu, but most programs don't).
If this web alternative were possible...then anyone could develop however they normally develop a native application (not app) - instead of having to turn it all into a client-server app or do it in javascript, flash, etc - and just let a user use it from their browser without 'actually' installing it. I guess my concept - since it is based on the usability of using something without actually-installing it (so that it goes into your normal start menu, for example) - is too nuanced for people, or I am not describing it right. :/
If an application (some accounting program say) comes in Windows, Mac, and Linux downloads and is supposed to be downloaded and installed, but works fine if you install it in a VM with a plain image, why can't they put it on the web behind some HTML that asks for a jailed VM - and be given one? So that if you are on Windows, whenever you open that web site in a new Firefox tab, you use its app (right from that tab) in a few seconds without any (visible or persistent) install. Even THOUGH it is a native-only application that isn't built around networking (requests over http) nor any kind of internet technology like javascript. It's just a local program.
If the 'just a local program' could live just as happily in a new tab in a vanilla base-OS, you wouldn't need to go through installing it to try it, or uninstall it if you're not interested: this is where a 'web app' shines. Getting to the first screen takes less than one second (click the link you heard about it from, including on a Google search) as opposed to 15-45 seconds minimum to click through Download, Save, wait for it to download, Double-click in Downloads window (hopefully still in foreground) to open, Click 'Install', click 'I accept' click next, click next, click finish. Click OK and hopefully run now. (If there is no 'run now' then click Start, click Programs, find the new entry, click it.
Likewise, after you see the first screen you can say 'No this isn't what I had in mind at all' and click Back in your browser or close the new tab: 1-2 seconds. On Windows uninstall is: Click Start, Click Control Panel, click Add Remove Programs, wait for it to load, find the program, right-click, click Uninstall, click OK, wait for it to uninstall, click OK. (Or you could wager on whether they included an Uninstall icon next to their program icon in the start menu, but most programs don't).
If this web alternative were possible...then anyone could develop however they normally develop a native application (not app) - instead of having to turn it all into a client-server app or do it in javascript, flash, etc - and just let a user use it from their browser without 'actually' installing it. I guess my concept - since it is based on the usability of using something without actually-installing it (so that it goes into your normal start menu, for example) - is too nuanced for people, or I am not describing it right. :/
isn't this is an overkill.. using node.js for running desktop apps
You can use flash (OMG) or just plain HTML/JS (I've developed something in the past using both)
But you know, we are in an app era right now and this technology has lost part of his original appeal