Building Standalone Applications in JavaScript

With the increased power of JavaScript frameworks like YUI, JQuery, and Prototype, and debugging tools like Firebug, doing an application entirely in browser-side JavaScript looks like a great way to make simple applications like puzzle games and specialized calculators.

Is there any downside to this other than exposing your source code? How should you handle data storage for this kind of program?

Edit: yes, Gears and cookies can be used for local storage, but you can’t easily get access to files and other objects the user already has around. You also can’t save data to a file for a user without having them invoke some browser feature like printing to PDF or saving page as a file.

I’ve written several application in JS including a spreadsheet.


  • great language
  • short code-run-review cycle
  • DOM manipulation is great for UI design
  • clients on every computer (and phone)


  • differences between browsers (especially IE)
  • code base scalability (with no intrinsic support for namespaces and classes)
  • no good debuggers (especially, again, for IE)
  • performance (even though great progress has been made with FireFox and Safari)
  • You need to write some server code as well.

Bottom line: Go for it. I did.

Another option for developing simple desktop like applications or games in JavaScript is Adobe AIR. You can build your app code in either HTML + JavaScript or using Flash/Flex or a combination of both. It has the advantage of being cross-platform (actually cross-platform, Linux, OS X, and Windows. Not just Windows and OS X).

Heck, it may be the only time in your career as a developer that you can write a web page and ONLY target ONE browser.

SproutCore is a wholly JavaScript-hosted application framework, borrowing concepts particularly from Cocoa (such as KVO) and Ruby on Rails (such as using a CLI generator for your models, views and controllers). It includes Prototype, but builds plenty of stuff such as sophisticated controls on top of that. Its Photos demo is arguably impressive (especially in Safari 3.1).

Read More:   Why doesn't Array.push.apply work?

Greg already pointed you to Gears; in addition, HTML 5 will come with a standardized means of local storage. Safari 3.1 ships with an implementation where you have a per-site SQLite database with user-settable size maximums, as well as a built-in database browser with SQL querying. Unfortunately, it will be a long time until we can expect broad browser support. Until then, Gears is indeed an alternative (but not for Safari… yet!). For simpler storage, there is of course always cookies.

The downside to this would be that you are at the mercy of them having js enabled. I’m not sure that this is a big deal now. Virtually every browser supports js and has it enabled by default.

Of course the other downside would be performance. You are again at the mercy of the client handling all the intensive work. This also may not be that big of a deal, and would be dependent on the type of app you are building.

I’ve never used Gears, but it looks like it is worth a shot. The backup plan would be to run some server side script through ajax that dumps your data somewhere.

Not completely client side, but oh well.

Nihilogic (not my site) does a lot of stuff with Javascript. They even have several games that they’ve made in Javascript.

I’ve also seen a neat roguelike game made in Javascript. Unfortunately, I can’t remember what it was called…

If you want to write a standalone JavaScript application, look at XULrunner. It’s what Firefox is built on, but it is also built so that you can distribute it as an application runtime. You will write some of the interface in JavaScript and use JavaScript for your code.

Read More:   Javascript - telling setInterval to only fire x amount of times?

Gears might provide the client-side persistent data storage you need. There isn’t a terribly good way of not exposing your source code, though. You could obfuscate it but that only helps somewhat.

I’ve done simple apps like this for stuff like a Sudoku solver.

You might run into performance issues given that you’re completely at the mercy of the client’s Javascript interpreter. Gears would be a nice way of data storage, but I don’t think it has penetrated the market that much. You could just use cookies if you’re not fussy about that kind of thing.

I’m with ScottKoon here, Adobe AIR is great. I’ve really only made one really nice (imho) widget thus far, but I did so using jQuery and Prototype.js, which floored in such wonderful ways because I didn’t have to learn a whole new event model. Adobe AIR is really sweet, the memory foot print isn’t too bad, upgrading to a new version is built into AIR so it’s almost automatic, and best of all it’s cross-platform…they even have an alpha-version for Linux, but it works pretty well already on my Eee.

Standalone games in GWT:


In regard to saving files from a javascript application:

I am really excited about the possibilities of client-side applications. Flash 10 introduced the ability to create files for save right in the browser. I thought it was super cool, so I built a javascript+flash component to wrap the saving feature. Right now it only works for creating text based files (vcard, ical, xml, html, css, etc.)

  1. Downloadify Home Page
  2. Source Code & Documentation on Github
  3. See It In Use at Starter for jQuery

I am looking to add support for non-text files soon, but this is a start.

Given that you’re going to be writing some server code anyway, it makes sense to keep storage on the server for a lot of domains (address books, poker scores, gui configuration, etc.,.) For anything the size of what you’ll get in Webkit or Gears, you can probably also keep it on your server.

The advantage of keeping it on your server is two-fold:

  1. You can integrate it fairly simply as a Model layer in a typical MVC framework, and,
  2. Users get a consistent view without being tied to their browser/PC, or in a less-than-ideal environment (Internet Cafés).

The server code for handling this can also be fairly trivial, particularly if it’s written with this task in mind, so it’s not a huge cognitive burden.

Go with qooxdoo. They recently realsed 1.0, although most users of it say it was ripe for 1.0 at least two versions ago.

I compared qooxdoo with YUI and ext, and I think qooxdoo is the way to go for programmers – YUI isn’t that polished as qooxdoo, from a programmer’s point of view and ext has a not so friendly licensing model.

A few of the strong points (for me) of qooxdoo are:

  • extremely clean code
  • the nicest OO programming model I’ve seen among Javascript frameworks
  • an extremely rich UI widget library

It also features a test runner for unit tests, an API doc generator and reader, a logging facility, and several useful features for debugging, grouped under something called Inspector.

The only downside is that there aren’t readymade themes (something like skins) for qooxdoo. But creating your own theme is quite easy.

The answers/resolutions are collected from stackoverflow, are licensed under cc by-sa 2.5 , cc by-sa 3.0 and cc by-sa 4.0 .

Similar Posts