Web developers have to walk around dragging a ball and chain. It is fantastic that we have a ridiculous install base (browsers, the Web runtimes) and a dynamic language in JavaScript.

The ball and chain though is the fact that we have to care so much about the payload of the application that we write. Less code means less bytes to download, and less for the JS runtime to load up.

This has bad consequences:

• You are tempted to write hard to understand code
• You have to balance functionality and code size much more than other environments
• You end up getting tricky and come up with ways to dynamically load modules on demand
• All of this time is time not spent on the app logic.

When you run into a problem like this in computer science what do you do? Build an abstraction!

GWT has done a great job here. It’s very nature requires a compilation step, and once you have to deal with that step…. you can do a lot at build time to change the above dynamics.

For example:

• You can write nice explicit source code, and trust that the compiler will output optimized JS (which can look as ugly as sin for all anyone cares)
• Your application can get faster with a new release of GWT, as the compiler gets better
• A lot of advanced techniques such as code splitting, and deferred binding can be applied to allow logic to apply at build time as well as runtime.

Ignoring GWT, when you write a pure JS application for the Web, you are writing a cross platform application. Unlike clean portable C, you don’t have that compilation step to do clean up work for you on each platform, so you end up with a lot of runtime conditional logic.

You try to do object detection rather than user agent conditional, but still, you end up both downloading the code necessary to run in all environments, and you have the overhead of loading and executing that code.

Chances are you are smart and don’t do if() checks all the time, but maybe do so once when loading up. For large chunks of big differences, maybe you do something like:

var Foo = (sometest) ? function() {
    // do it like this
} : function() {
    // do it like that
};

If you take a look at some parts of popular JavaScript frameworks, you see that they are abstractions or fixes for various browsers. As browsers have stepped up to the plate recently, they have fixed a lot, and suddenly you take a step back. A lot of frameworks have a chunk of code to give us the ability to do smart things with CSS querying. Modern browsers support querySelectorAll (even with some bugs) and getElementsByClassName so a lot of the code is un-needed…. unless you care about the old browsers.

We shouldn’t have to download all of that cruft on the other side of the if() statement when we don’t use it!

The GWT compiler can output versions of your application targeted to a given browser. Only the fastest, minimal code, will get sent down. Deferred binding goes far beyond just browser type (can deal w/ locales and much more) too.

GWT isn’t the only horse in this race though.

Alex Russell started to sprinkle in some directives to Dojo that would enable you to do a build that is WebKit targeted. A major use case for all of this is making sure that you are sending down lean code in the mobile space. It can matter everywhere, but when you are dealing with grown up walkie talkies…. you want to really optimize.

And this brings us to YUI. I was really excited to see some of the features in the YUI 3.2.0 preview release. Great stuff for touch/gesture support, but what stood out for me was “YUI’s intrinsic Loader now supports capability-based loading”. A-ha!

I poked around the source to see how it was used. Here is one fake example that shows how it works. When you boot up YUI you can add in “conditions” which are in charge of working out whether to load something. You can currently tie on to user agent, or write a test function:

YUI({
    modules: {
        lib2: {
            requires: ['yui'],
            fullpath: 'js/lib2.js',
            condition: {
                trigger: 'node-base',
                ua: 'gecko'
            }
        },
 
        lib3: {
            requires: ['yui'],
            fullpath: 'js/lib3.js',
            condition: {
                trigger: 'event-base',
                test: function(Y, req) {
                    return Y.UA.gecko;
                }
            }
        }
    }
 
}).use('node', function (Y) { .... });

The YUI team uses this themselves to only load certain ugly DOM stuff for IE6 when needed:

"dom-style-ie": {
    "condition": {
        "trigger": "dom-style", 
        "ua": "ie"
    }, 
    "requires": [
        "dom-style"
    ]
},
 
YUI.add('dom-style-ie', function(Y) {
    // ....
});

This makes a ton of sense, especially for the libraries themselves to do this work. They are the ones that do the heavy lifting of cross browser ugliness, all to allow us to write to an API that works.

Beyond that, we can then ourselves split out code if it becomes a performance issue.

Of course, the value of the test() function is that you can do capability based testing (not just user agent testing…. hence the name!). This means that you can do a test say for Canvas support (as Zach mentions in the comments) document.createElement(’canvas’).getContext, and load up excanvas or another shim library if it doesn’t exist.

Using modernizr and ilk, we could build out “plugins” for YUI that auto load based on common capabilities. You can imagine running a YUI build, having it detect that you are using a capability, and then automatically load up a plugin that has the condition all loaded up. What a great user experience as a developer!

Maybe it makes sense to come up with a common pattern and conventions for dealing with this issue. How do you name your CSS/JS? Do we setup server side hooks so we don’t even need loaders necessarily?

I can certainly see a day where you may be asking the Google Ajax Library service for jquery.js, but it is returning jquery.ie.js to you.

Diffable is an open source project that allows you to only send down the deltas in your application versions, versus full new downloads (which may have a large amount of duplicate data).

In their presentation, Josh Harrison and James deBoer, talk about the details after the start with the core issues:

Problem:

Frequently modified web resources must be downloaded in their entirety with every modification.
Even a small change invalidates the cache.
Rich internet applications often have large amounts of static content.

Idea:

Initial application resources kept in cache.
Changes to cached versions transmitted as deltas.
Deltas merged client-side to generate latest JS version.

Benefits:

Faster page load times for users with cached resources.
Small changes to large resources incur only small costs.

Steve summarizes things well in his post:

Diffable uses differential compression to reduce the size of JavaScript downloads. It makes a lot of sense. Suppose your web site has a large external script. When a new release comes out, it’s often the case that a bulk of that large script is unchanged. And yet, users have to download the entire new script even if the old script is still cached.

Josh and James work on Google Maps which has a main script that is ~300K. A typical revision for this 300K script produces patches that are less than 20K. It’s wasteful to download that other 280K if the user has the old revision in their cache. That’s the inspiration for Diffable.

Diffable is implemented on the server and the client. The server component records revision deltas so it can return a patch to bring older versions up to date. The client component (written in JavaScript) detects if an older version is cached and if necessary requests the patch to the current version. The client component knows how to merge the patch with the cached version and evals the result.

With this technique in action, you end up sending down JS arrays as deltas that looks like:

[0,10,"red",40,3," leaps",25,15,16,3,"."]

The data that these guys share is impressive. The results seem to add up for applications as large as Google Maps. Do they measure up for smaller apps? If large apps have a lot of static content, couldn’t that content be put into another download and even app cached away?

Also, it is a lot of work to implement this for a developer. Work on both client side and server side. It would be great if we can experiment with Diffable and then move things lower into the stack. Why can’t HTTP itself be smart enough to deal with diffs?

It did make me think of my favourite chaps @github. I know that GitHub is about development rather than deployment…. but what if they supported this natively (since they kinda grok diffin’ etc already) and offered a client side loader so you could github.load("project", ...).

It all just makes me realise that GitHub is poised to pounce in many directions. Good on ‘em.

Over the winter holiday, Ben and I whipped together Project Appetite, an open source example that consumes the feeds from the Palm application ecosystem (both Palm Catalog and Web distribution). We didn’t have long to come up with something, and one of the interesting stories was how we took an API and mocked up the middle, allowing server and client to get going quickly.

The feeds that the Palm ecosystem puts out are RSS 2.0 XML feeds, with extra catalog-y info in an “ac” namespace. We converted the format to JSON to make life easier for the JavaScript client consumer. Although you can DOMParser() away (and use the Microsoft component) JSON is just so much easier. What lives at api.projectappetite.com is the result of the munging, so others could consume JSON directly if they so wish.

The Data

We quickly put together some dummy data, and for ease, put it in a file app.js that the client could consume. Once we iterated on the format, one of us could go off and write the XML to JSON code. We actually implemented this in a variety of ways as we experimented. Ben created a simple JDOM translation, and I fought with databinding, which still seems to be a royal pain with Java. The reason I checked that out was to create an open backend on app engine, and I wanted to go from XML to JSON to Java for persistence via JDO. From one set of Java objects I could @PersistenceCapable and @XStreamAlias("asset_url"). It wasn’t worth the effort.

The Client

We created an Appetite object that would be able to query the model and get the data that was needed. The constructor took the apps data, and then it did its magic. In this case is created some caches to make querying fast.

The public API contained:

• app(id, locale): returns a single app based on id
• find(opts): the core engine for querying the app data
• types: contained the logic for filtering on top rated, top paid, newest, etc
• sorts: contained the sorting functions to return the data in the right order (e.g. by download count versus date)

Very quickly the client was mocked up and the frontend was build out using this API. Again, at this point the entire front end could be built without waiting for server infrastructure.

The Server

Since the client API mocked out the functionality needed for the frontend, the server could actually reuse this logic. This is when the node.js server was born.

To play nice with node, we went back to the other files and added logic to export the data. E.g. in the client.js:

// check to see if you are running inside of node.js and export if you are
if (typeof GLOBAL == "object" && typeof GLOBAL['node'] == "object") {
    exports.Appetite = Appetite;
}

Once that was in place, we could load up all of the information that we need:

// -- Load up the libraries
var sys   = require("sys"),
   http   = require("http"),
   posix  = require("posix"),
   apps   = require("./apps").apps,
   client = require("./client");

And then we can get access to the client API via:

var a = new client.Appetite(apps);

We created a simple mapping that enabled a URL such as /app?id=[id]&locale=* to be converted to a method call of app({id:id, locale:locale}). We did this in a generic way that enabled us to add URL endpoints by simply added to the responder hash. The functions would return an object that could contain error codes and the like.

For example, the app end point:

// /app?id=[id]&locale=*
app: function(params) {
    if (!params.id) {
        return {
            error: 501,
            body: 'I need an id!' 
        };
    }
 
    return {
        body: a.app(params.id)
    }
},

We also added a magical DEFAULT handler to take care of bad URLs.

Finally, we would boot up the listening server and handle responses:

// -- Create the HTTP server binding
var host = process.ENV['APPETITE_HOST'] || 'localhost';
var port = process.ENV['APPETITE_PORT'] || 8000;
 
if (process.ARGV.length > 3) { // overwrite with command line args
    port = process.ARGV[3];
}
if (process.ARGV.length > 2) {
    host = process.ARGV[2];
}
 
http.createServer(function(request, response) {
    var path = request.uri.path.substring(1);
    var output;
 
    var responder = (typeof responders[path] == "function") ? responders[path] : responders['DEFAULT'];
    output = responder(request.uri.params);
 
    var contentType = output.contentType || "text/javascript";
 
    if (output.error) {
        response.sendHeader(output.error, { "Content-Type": contentType });
        response.sendBody(output.body);
    } else {
        var body = (contentType == "text/javascript") ? JSON.stringify(output.body) : output.body;
        response.sendHeader(200, { "Content-Type": contentType });
        response.sendBody(body);
    }
    response.finish();
}).listen(port, host);

After 86 verbose, commented code, we had a server that would respond to URLs and return data. And in this time the frontend continued to be built out.

Being able to reuse the client JS and wrap it to become a server was a lot of fun. I am definitely a big node.js fan! Now, I am looking forward to doing a lot more with Project Appetite…. but for now we are working on a pretty cool webOS application, and getting the developer platform better and better.

Some coffee in your Node

In an aside, the node hello world has been ported to CoffeeScript:

# To run, first install node and coffee-script
# Node: http://nodejs.org/#download
# CoffeeScript: http://github.com/jashkenas/coffee-script
#
# In a terminal window:
# $ cd coffee-script
# $ ./bin/node_coffee -r hello_web.coffee
# Tested with Mac OS X 10.5.8, Node 0.1.26, CoffeeScript 0.5.0
 
sys: require "sys"
http: require "http"
 
http.createServer( (req, res) ->
  res.sendHeader 200, {"Content-Type": "text/plain"}
  res.sendBody "Hello, World!"
  res.finish()
).listen 8000
 
sys.puts "Server running at http://127.0.0.1:8000/"

I love your work and respect you, @ppk, but you just wrote a very naïve post. Guessing @dalmaer slipped you a mickey, so I’ll forgive you.

I did see PPK with a drink, but I didn’t drop anything in it, I promise! :)

What are we talking about here? PPK has written a post commenting on the interesting “Apple’s mistake” essay by Paul Graham.

I love PPK and he is doing great work, but I have to respectfully point out a few things here, especially as some folks thought I put him up to it. For those who are jumping on him in entirety, here does have some things right too! Don’t just get mad at the fact that he called developers arrogant and stupid ;)

There are fantastic web applications on the iPhone. I use Gmail and Google Reader as a Web app, for example. The browser is good, but I have written many times (before being a Palm employee! These are my thoughts… blah blah) about how I wished that Apple let me go the extra mile and access more from the Web side of things.

Although you can do great apps like Gmail, the user experience available to Web developers isn’t anywhere as close to that of the iPhone SDK.

• APIs: You are unable to access the rich APIs on the device. Sure you can get local storage and appcache, but you can’t get to the compass and the [insert tons of APIs here]. Your app may not need it, but they may be able to greatly benefit from them… let alone the enhanced graphics and performance.
• Discoverability: There are two worlds. The Web and the App Store. How does a user find out about your Web app? Sure they could use the power of Google etc…. but if they are trained not to do that anymore? Fortunately we have PhoneGap and Titanium and … stepping up here

So, the feeling of “come on iPhone devs, don’t be stupid and just develop a web app!” is going a tad too far. There are very valid reasons to use native. With PhoneGap et al, there are growing reasons to cover various bases.

At Palm I am excited to push the Web stack further by having it as the SDK, not as an option in the browser. I believe that the Web can be the unifying platform across the multitudes of devices that users will have in the future. This world is going to cause a large number of changes to how we develop experiences, and I am excited by the challenge and working with the Web community (companies and individuals) to meet the challenge.

There is so much to be done on both the technology side (html5 on devices, apis, services, gpu, etc) and on the delivery side (future of app stores, richer discoverability, etc). You can also create fantastic applications for many platforms using Web technology TODAY!

Update

Faruk Ateş has written a detailed post on this topic too that discusses similar issues to my post above, but also goes beyond with more details on $, and the SDK experience.

“Just what the world needs—another sucky JavaScript library,” he said. When I asked him what made it ‘sucky’, he elaborated. “It’s a JavaScript library written by Java developers who clearly don’t get JavaScript.”

This quote is by Kevin Yank, talking to Dmitry Baranovskiy, author of the fantastic Raphaël graphics abstraction library. He writes up more on the issues they see with Closure. This is the few of one side of the community towards the open source release of Google Closure and its tools.

It was bound to happen. When I started at Google I quickly wanted to learn about how Gmail, Google Maps, and all the revolutionary front ends that helped make Ajax happen. Closure was the heart of it, and I quickly wanted to see a way to get the knowledge out there. This was years ago now, but the same reasons permeate through. Even at the time there were a ton of great JavaScript libraries. It wasn’t that I wanted Google to come down the mountain like Moses and bless the world “thou shalt use Closure!” However, some smart people had worked for some time refining their use of the browser runtime and Closure was the art and science of that ongoing experiment. Having the world able to at least see the experiment would be a good thing. Other libraries could learn from it.

No one from Google has said that you should, or must use Closure!

I realize that we live in a world of heros or zeroes. There isn’t room for much in between. You are either going to be a X killer, or you are killed by X. There is no time to tell the longer arching tale. Closure came to us late in the game, where folks are often perceived to be in their camps. I love JavaScript because it allows a diverse group of libraries to do what they do best. Developers and designers can find what suits both their personalities and their particular project.

If someone asks me (and they often do) “Which Ajax library should I use?” there isn’t a simple answer. It is nuanced. It is complicated. It is frustrating! How many of you have even changed libraries in a project? It is embarrassing to go back in time and see what happened with Bespin. At various times we had MooTools, Prototype, Dojo, and SproutCore. Is that productive? Obviously no.

You build many things on the Web. A web site isn’t a web application, and then blend together so you often can’t tell when you go from one to the other (and it doesn’t of course matter at all). jQuery has made a living starting out as a fantastic DSL for sprinkling behaviour onto web sites and going from there. SproutCore and Cappuccino are the other extreme, and Dojo was the kitchen sink of JS development a long time ago. Speaking of Dojo, I really wish that Dojo and Closure had collided a long time ago. I think that it would have benefitted both sides, even though I know that it would have added some overhead for both too. When you are on an internal framework it is built for your needs. If you take a look at the Closure components they feel very Googley out of the box. At the end of the day though, Dojo and Closure are so similar in many ways, that having them joint at the hip a few years back would have been really exciting. C’est la vie.

One tricky thing about Closure is that you can’t look at all of the widgets and packages equally (same for most libraries to be fair). Some are battled hardened to the hilt as they are on important production systems acting as core functionality. The keyboard handling and localization support is top draw. Others may be cool but placed in via an interesting 20% project that isn’t as mission critical and hence battle hardened. Not all code is equal. In fact, I find the line by line code criticism tiring. It is so easy to take someones code and find fault with it (at least perceived fault). I am sure there is bad code in Closure. That is true for all code. It is much harder to be a creator though. Don’t get me wrong, it is good to point out potential issues, but there is a big difference between:

“I noticed that code X does Y. I think there is a bug there that would affect ….”

and

“Code X SUCKS. Mwhahahahahah. SUCKS!”

My new years resolution for 2010: “Say *sucks* less”.

The criticism that made me laugh hardest was the assertion that the Closure engineers were Java folks who wanted JS to be Java. They are far from it. They are old school JS engineers who have done amazing things on the Web and have just learned a few things along the way as they build huge scale JS systems.

Google is of course a big place with engineers with opinions :) When you have the creators of various languages and platforms under one roof that is always going to be the case (From Python to C++ to Java to Go, and then Closure, GWT, etc on the JS side… even jQuery ;). Many of the frontend engineers aren’t fans of Closure (as in: doesn’t fit them) but they do understand where some of the strengths are. Some of the engineers have even weighed in:

NOTE: The following quotes were taken from a Facebook comment stream. There is context missing (for example, Joel talks below about how he didn’t use the term ‘natives’ for example

Joel Webber, GWT guru: “I’m unfortunately not too surprised to see self-appointed “Javascript natives” pissing all over Closure, because it tells them something they don’t want to hear — namely, that you can’t get enough optimization leverage on large applications without some constraints on your code’s structure. The kind of stuff that you see in many Javascript libraries (e.g. lots of dynamic tests to figure out what to do in a function) pretty much guarantees that you’ll have an unoptimizeable mess.”

Gavin Doughtie, Dojo and Google Photos: “As one of the Javascript natives, I must say after three years of using Closure that it gives you a nice split between development-time dynamism and deployment-time optimization. I have found few Javscript idioms unavailable to me when coding, yet still benefit from static checking and optimizations once I’m ready to ship.”

I am more of a JavaScript native than anything else. I am not going to be rushing to use Closure on a project any time soon. It doesn’t fit many of the projects I work on to be honest, and it doesn’t fit me as well as some of the other libraries.

That being said, I am thankful to Google for putting this code in the commons (and the fantastic tools around it!) so we can all check it out (and some of us use it). I hope that the hard part of open sourcing a project kicks in and we see a community form around it, including taking in contributions. I still also harbor the hope that Dojo and Closure joined forces, but that is hard to do (a lot of people using both code bases!)

When it comes to getting closure, I hope that you don’t jump to the extreme and ignore and abuse it, and I also hope that you also don’t think that you SHOULD use it without checking it out and understanding the tradeoffs.

For example, this is crazy:

“I hate to admit but I “might” have switched from jQuery to Closure strictly because of the Google brand.”

Roundup on Closure

• Erik Arvidsson, founder of Closure, awesome JS hackers, on the history
• Alex Russell, founder of Dojo and Chrome Frame
• Dimitry presentation on JavaScript libraries
• Google Closure: how not to write JavaScript
• Learning Closure with goog.net
• Inheritance Patterns in JavaScript

When posting on the Bespin Pie back in the day, I showed the Dojo animation code that we used to fake out our canvas pie animation:

var anim = dojo.fadeIn({
    node: { // fake it out for Dojo to think it is changing the style :)
        style: {}
    },
 
    duration: 500,
    easing: dojo.fx.easing.backOut,
 
    onAnimate: function(values) {
        var progress = values.opacity;
        renderPie(progress);
    }
}).play();

Pete Higgin’s hinted that we should cleanup this hack (asking to do the opacity and then getting the value back out) and finally (due to a weird bug in a WebKit nightly that gave me reason to poke) I cleaned it up:

new dojo._Animation({
    duration: 500,
    easing: dojo.fx.easing.backOut,
    curve: [0.0, 1.0],
    onAnimate: renderPie
}).play();

I am sure there is an easier way too!

FYI, the “pie” is finally a pie menu in tip, which will make its way to a Bespin version push soon with functionality we have been dying to get in production since the initial prototype.

We are having a great time using Canvas for Bespin and a few other projects. Having text, images, and boxes as the primitives on the Web just isn’t good enough, so leap frogging to HTML5-land where we have the ability to arbitrarily paint pixels is fantastic. Mix this with the ability to directly manipulate video, and you have new opportunities.

However, Canvas also has obvious issues. How do you make it accessible? Or searchable? We have some ideas there, but they are a long way off. The goal has never been to use Canvas as the shiny toy. With Bespin, we actually tried to do it with DOM, and it wasn’t so much chutzpah as “can’t get it to perform”-pah that lead us down the path of Canvas. The usual suspects in the stack weren’t working for us, whereas others were blazing (e.g. JavaScript performance has blown us away, as has Canvas itself).

With major browsers like Firefox 3.5 (Safari 4, Chrome 2, etc) I am very much excited to work with browsers (say, the great Firefox team :) to kick into gear on the next level of improvements. The current batch have been competing on the performance of JavaScript. The new engines are fantastic, and really change the game on what can be done. Add in Web Workers to the magnitude speed bump of JS and Web devs can truly build responsive low-latency applications. We are now seeing improvements to the DOM, the next frontier. It is all well and good to have your JS run nice and speedy, but if the DOM can’t keep up then we are still in trouble. This is why we had to go to Canvas for Bespin in the first place! I am hoping that we will be able to push on DOM and other APIs to get to a point where our DOM based Bespin can come back to town.

There is a time and a place for Canvas though. Rather than running the show, I much prefer the unobtrusive extensions that you can provide. I am also looking forward to seeing more tools that use a server side component to do some image manipulation… now work on the client through Canvas and ImageData. Vlad pondered why CSS spriting tools are all server-side for example.

Christian Effenberger has been doing this kind of work for a long time, and there is room for a lot more. I really like having Canvas available in more places, such as anywhere an image can be used (e.g. WebKit CSS extensions where you can use a Canvas as a background-image). That gives you full control to style something in zany ways, while still staying in DOM land. It also means that things can play together really nice. We continue to push more into CSS (transitions, gradients, etc.) and animation libraries (Scripty2 looks nice!).

There is still much work to be done on putting the pieces together. I don’t know about you, but doing some common things with layout and UI still drive me nuts. Having the low level new tools like border-image are cool, but I really long for a tool that graphically lets me take a mock, cut it up, and build it out as a generalized component (stretches in the right place etc). The tool could then spit out more than just a border-image version, but old style divs + CSS to make it work everywhere. One tool, run output anywhere.

So, time to take a breath, take a look at what bleeding edge folk are doing to get rich experiences, and push it into the core platform itself. This will mean less Canvas, but used in the right places, and we will move down the stack again. If we don’t push use cases down into the core, then we are doomed to stagnate or fork the Web.

A contingent in the JavaScript community is pretty much solely focused on securing the language. Security is always important, but even more-so when you are dealing with a language that runs in a user agent to run the Web.

Whenever you try to add a feature to a language you are instantly dealing with legacy and backwards compatibility.

Perl has a strict mode that is very popular in the community. I remember projects where if I checked in a module without use strict; and -w I would get beaten up.

Back to JavaScript, how can we apply stricter rules on what we do in the JavaScript runtime after the face? One solution that the ECMAScript Edition 5 folks came up with is borrowing use strict but since they couldn’t add it to the language itself, they have you put it in a string "use strict";. You can place it at the top of the file, or even as the first statement in a function.

I find it incredibly ugly, yet pragmatic. It works.

However, then I saw some new items:

"use strict,cajita";

And currently you can’t switch the order around? It looks for absolute keys? That seems a little crazy. Surely all of these should be possible:

"use cajita,strict";
"use strict,cajita";
"use strict";
"use cajita";

Then this little pragmatic hack starts to get real messy. I start to joking imagine a ludicrous world like this:

(function() {
  "use strict";
  "use let"; // let's get let in there!
  "use cramda"; // I love Alex's cramda, let me use it!
  "use e4x"; // XML inline. Screw templates
 
  // If I see a var with the same name, REALLY use let instead
  "let x;"
  var x;
 
  // Now I can use the cramda
  "x = #(a, b) { "\
  " ... logic here ... "\
  "};"
 
  // And the let... ironic that it is in a string now
  "let y = <xml></xml>";
 
  // Annotations come to JavaScript!
  "@Serializable"
  function someThing() {}
})();

I like to think of myself as pragmatic, but why do I feel so cranky about "use strict";? :)

By now you have probably read about the critical Java vulnerability and how easy it is to take over a machine from a web page via a Java applet.

Apparently, Sun fixed it fairly quickly, but even then some people say their fix was too specific and thus there are still problems. Apple on the other hand, were not diligent and are still yet to provide a fix. Ouch.

Painful news as JavaOne approaches and Sun tries to push JavaFX. I was trying to think of a Java applet that I have used (knowingly) in the recent past, and I think the only candidate is the Facebook photo uploader.

I have been watching some research for a talk on JavaFX and I am really torn. In theory, the Java platform is phenomenal and should be a great choice for doing this kind of development. The scene graph work in JavaFX is very nicely done, but the implementation seems to be a touch off in much of what I have seen. Scrolling causing the applet to go blank? Browser crashes? Ouch. But, JavaFX is new, and has a chance to get better. Their problem is that they are squeezed from both sides. The browser platform itself is accelerating quickly, and it has the advantage of being native. Once you go to plugin land you are competing with Flash with its large share and proven ability.

Getting webby

I find myself wanting to get more and more webby. This is why I was excited to work with the Jetpack project that we just launched today at Mozilla Labs. Being able to extend the browser using Web technology itself is going to open the door for more playing. People have created 7000 addons for Firefox alone, but as someone who has done a touch of XUL, I am happy to stay in my familiar territory of HTML, CSS, JS. Jetpack has just been born, and is incredibly early stage, but I can’t wait to see it grow and get the APIs that people want in a secure extensible model.

You will see a lot of Bespin in there too. Below is a screencast where I create a Jetpack feature on the fly (no reloads!) using Bespin, and once you install Jetpack it embeds the puppy into the tutorial and the developer area too. Much more than can be done though!

Ian Hickson: “I expect I’ll be reverse-engineering SQLite and speccing that, if nothing better is picked first. As it is, people are starting to use the database feature in actual Web apps (e.g. mobile GMail, iirc).”

When I read that comment to Vlad’s post on HTML 5 Web Storage I gulped. This would basically make SQLite the HTML 5 for storage in the browser. You would have to be a little crazy to re-write the exact semantics (including bugs) of SQLite and its dialect. What if you couldn’t use the public domain code?

Gears lead out strong with making a relational database part of the toolbox for developers. It embedded its own SQLite, in fact one that was customized to have the very cool full text search ability. However, this brings up the point of “which SQLite do you standardize on?”

The beauty of using SQL and SQLite is that many developers already know it. RDBMS has been mainstream for donkey’s years; we have tools to manage SQL, to view the model, and to tweak for performance. It has gone through the test of time.

However, SQL has always been at odds with many developers. Ted Neward brought up ORM as the vietnam of computer science (which is going a touch far ;). I was just lamenting with a friend at Microsoft on how developers spend 90% of their time munging data. Our life is one of transformations, and that is why I am interested in a world of JavaScript on client and server AND database. We aren’t there yet, but hopefully we can make progress.

One of Vlad’s main questions is “Is SQL the right API for Web developers?” and it is a valid one. I quickly found that for most of my tasks with the DB I just wanted to deal with JSON and hence created a wrapper GearsDB to let me insert/update/select/delete the database with a JSON view of the world. You probably wouldn’t want to do this on large production applications for performance reasons, but it works well for me.

Now a days, we have interesting APIs such as JSONQuery which Persevere (and other databases) use. I would love to see Firefox and other browsers support something like this and let us live in JSON throughout the stack. It feels so much more Webby, and also, some of the reasons that made us stay with SQL don’t matter as much in the client side world. For example, when OODBMS took off in some Enterprises, I remember having all of these Versant to Oracle exports just so people could report on the darn data. On the client the database is used for a very different reason (local storage) so lets use JSON!

That being said, at this point there are applications such as Gmail, MySpace search, Zoho, and many iPhone Web applications that use the SQL storage in browsers. In fact, if we had the API in Firefox I would have Bespin using it right now! We had a version of this that abstracted on top of stores, but it was a pain. I would love to just use HTML 5 storage and be done.

So, I think that Firefox should actually support this for practical reasons (and we have SQLite right there!) but should push JSON APIs and let developers decide. I hope that JSON wins, you? I also hope that Hixie doesn’t have to spec SQLite :/

Related
It was also interesting to just read this post Abusing Web Storage via Sam Ruby:

Alberto Trivero: The aim of this white paper is to analyze security implications of the new HTML 5 client-side storage technology, showing how different attacks can be conduct in order to steal storage data in the client’s machine.