Build Cross-Platform Applications for desktop using HTML, CSS, Javascript
appjs.org
appjs.org
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.)
[1] I'm not sure what the current status is, but I think they want to phase it out?
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/
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.
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.
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.
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.
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.
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.
My point is simple: IE's sandbox was broken repeatedly, creating a bad reputation and scoring marketing points for other vendors.
* 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
It creates a custom scheme named appjs:// and handles are requests with this scheme manually without any server listening.
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.
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.
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?
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.
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 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
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 :)
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?
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.
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.
https://github.com/arturadib/node-qt
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.
And you used to be just a front end hacker.
I'd recommend placing a few screenshots of example apps on the front page running natively on different systems (mac, windows, linux). Well done!
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
In fact, Adobe has been getting worse with Linux support altogether lately (including the Flash runtime).
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.
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.
This also means that AppJS-based apps can't be shipped on Mac App Store because CEF makes use of private frameworks.
Why wasting time and re-creating everythin from scratch?!
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).
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:
(former gives a cross-platform runtime, latter is merely a JS framework)
Mike/Verelo.com
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.
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. :/