And So It Begins

There was a ton of JavaScript news around this year’s JavaOne. First was Greg Murray‘s JMaki, a library that allows JSP and JSF developers to easily add scripted components (e.g.: Dojo widgets) to their pages with minimal effort.

Next was the less lauded, but arguably more important, Phobos. Think of it as an app-server for JavaScript. These apps can take advantage of the huge number of available Java APIs for doing most anything under the sun. FWIW, Jot takes much the same tack, but fixes the database layer impedance mismatch with a wonderful abstraction. Instead of imposing the amazingly painful “build, deploy, test” process that Java tools try to hide (and usually fail at miserably), both Phobos and Jot acknowledge that the future belongs to dynamic languages. You might still hear lots of FUD out of the static languages camp about how interpreted and/or late-binding languages are tremendously slow, but the truth is usually that your language choice probably isn’t the bottleneck.

It’s usually bad algorithm choice or an inability to move things that are actually slow to a faster path. I think this is part of why my love affair with Python hasn’t ended despite the proverbial writing having been on the wall for a long time. I mainly blame the craptastic XML-SIG, earlier versions of Zope, and Guido’s weird malaise about web development for this, but that’s another sad story for another day. In Python, you don’t worry about language speed. You develop fast and then when you need to optimize, you profile. If things really aren’t tractable (which is rare), you just move those critical sections to C. This is a common theme across most modern scripting languages. In Java, you can still get to C via JNI, but it’s a second class citizen. Perhaps it’s all the “pure java” marketing BS. Perhaps it’s how difficult JNI makes it to get across the border and back. Who knows, but Java has certainly suffered as a result.

Phobos is starting to fix this by acknowledge that instead of making the Java mistake (again) and attempting to boil the ocean in yet another new language, we should be riding on the investment in libraries that are already available and make it possible for application authors to work at a faster, higher level and drop down to “the metal” where it makes sense. Obviously Phobos won’t solve all of Java’s myriad problems, but it will at least allow the Java platform to compete on developer productivity. The tools haven’t saved us, and I doubt they ever will. Time to look up the stack. Kudos to Sun for having the foresight to free developers from the shackles of expressive mediocrity that Java has imposed for so long.

Which brings me to GWT. I got asked about this at the smackdown panel and of course I hadn’t had nearly enough time to dig into GWT to form a coherent answer. I’m not sure that just looking at the code and playing with the demos has given me enough depth to give a useful answer either. From where I sit, GWT looks like the physical manifestation of hiring managers’ frustration when trying to hire for “ajax developer” or “UI engineer” positions. The truth of the matter is that there just aren’t very many of us in the world and interestingly, Google employs a fair number of them. That they did GWT smacks of recruiting desperation and the need to better leverage the Google SSFPU (super-smart fungible programming unit).

Turns out you can’t just drop a good hacker into UI programming and trust that it’ll work out. Not only does someone in the UI engineering role need to have a solid appreciation for the constraints of the web, they need to be multi-language clued, know when to defer to visual designers, have the balls to push back on stupid requirements, and empathize with users. And that’s the baseline. No wonder Ajax is sexy and hard to hire for. The great apps in the Ajax word are developed by great engineers and designers.

Not coincidentally, great engineers and designers value great tools. Great tools allow them to express themselves better, faster, and with less effort. This is why the smartest hackers I know want either a fully dynamic language or C. Everything else (yes, you Java and C#) are bad compromises to these folks. They raise the average by enforcing mediocrity. This is a Good Thing (TM) on average but a truly awful thing for people who need to move faster than the herd. Traversing the stack with ease, closure to slab allocator, is what defines great hackers. A high-profile investor and former hacker has written broadly on the subject, so I won’t try to rehash his observations. What I do find interesting though is that folks who think they want great hackers are shocked by how bloody honest they are when they finally land one. These people call bullshit because they’re constitutionally unable to stomach dumb. Before I moved to the valley, I thought that the shorter average tenure of people at tech companies here was the result of competition, but the more time I spend here the more I realize that for the best-of-the-best, it likely has more to do with the impossibility of moving Mt. Stupid than with competitors offering a better package or employers folding up shop.

So what does that have to do with GWT? Well, I think that like Java and C#, it’s going to raise the average. This is also a Good Thing (TM). I’ll go out on a limb and say that it’s a safe bet that Bob, Cal, and Andy won’t be picking it up any time soon. If they do, it’ll probably be to build tools for other people. Oddly that might even be a sign that it will succeed in a broader market.

The obvious next question is “what does that mean for Dojo?”.

After mulling it over for a couple of days, I think that it will boil down to “coopetition”. At a minimum we’ll probably see Dojo widgets integrated into GWT as an external project. Lord knows our licensing makes that a no-brainer. Beyond that, there are a lot of places where it’s a “battle of paradigms”. We think that markup is the fastest way to declare initial UI state but not a very good way to express logic. GWT takes the tack that it’s easier for most programmers to declare UI layout in Java since they don’t have to learn another language. We think that JavaScript is a better language and that it would be better of people learned more, not less, of it. GWT clearly doesn’t agree. We think that imposing a compile cycle on webapp development is one of the worst things you can do for productivity. GWT seems to make the argument that library breadth makes this moot.

At the end of the day, both approaches are trying to get to a better level of productivity for building more responsive apps, and that can only be good for everyone.

Update: just saw that the Ajaxians have been thinking about GWT as well.


  1. Mike
    Posted May 20, 2006 at 6:31 pm | Permalink

    Similar to Yahoo’s supporting PHP, apparently spreading stupidity is becoming widespread. The competition is about avoiding rtfm. fun, fun, fun…

  2. Posted May 20, 2006 at 6:48 pm | Permalink

    Hey Mike,

    I’m not sure I agree with you on the PHP front.

    One of the features of expressive languages is that they give bad developers more of a chance to be…um…well…bad in exactly the same way that they let great developers do amazing things with less effort.

    The good news is that they create a market for quality. I for one don’t really want to be using tools that let the incompetent hide out behind IDE’s and crappy code generation. Fortunantly PHP, JavaScript, Python, Ruby, Perl, and other scripting languages make that much harder. In essence, you know sooner when you have a mess on your hands.


  3. grumpY!
    Posted May 20, 2006 at 10:19 pm | Permalink

    speaking as someone who has watched yahoo’s employment of page generation tools from their earliest incarnation, i can say clearly that php was a major step forward given the tools that came earlier. a quick summary:

    tool 0: headers that said basically ‘count N bytes from here and insert this file’, thats it! biggest bug: you could clobber your own html by missing a byte, but i cannot conceive of anything faster. ran on custom webserver (apache still not widespread)

    tool 1: inlined ‘script’ like commands that required support at the shared object level, meaning if you wanted a function called foo() in your html, you needed to put fooFun() in your .so as well. biggest bug: lots of coredumps in this model, lesson learned that not all coders are systems coders.

    tool 3: php. biggest bug: letting php turn you into an idiot.

    alex is 100% correct when he states that the best coders at the front end are able to track the entire stack and know whats happening. coders who can’t see past the web layer, or who have no experience with efficiency-minded coding often rely far too much on the mythology that hardware and network resources will happily absorb all of their abstractions and waste.

    i would be surprised if GWT gets much traction.

  4. Mike
    Posted May 20, 2006 at 10:49 pm | Permalink

    Hello Alex,

    I would have to agree with you. I have improperly voiced my PHP rage to a wrong war.

    I believe IDE’s carry a vision… a dream. Currently as it stands, just an illusion and certainly a wrong answer to the delicate world of web. I take too much joy coding with my scite text editor to be eager to explore the world of IDE’s. I sometimes wonder though. A friend recently demoed the new Microsoft .net IDE that supposedly does lots of ajax magic. I enjoyed the demo. After a few minutes of dragging, clicking, etc he delivered the promised and compiled out a single web page that did some trickery when a button was clicked. He wasn’t sure if the operation was server side or client side and took pride for it saying ‘It hides all the confusing stuff.’ I don’t know how creative can you get with that, but I certainly wouldn’t want to speak my mind using Microsoft IDE.

    Perhaps one day writing applications becomes actually more productive using IDE’s (LabView is already doing a good job with it with hardware programming.) And that day, IDE users can then take the pride for playing the test monkey for Microsoft for all those years and their hard work paid off. I shall retire then.

    On a different note, I think yahoo’s support for PHP is creating a disaster. It makes PHP coders believe this is THE language web development and there will be no graduating. PHP is a good jump start, but promotes horrible web development practices as it is.


  5. Posted May 24, 2006 at 4:29 pm | Permalink

    Hello guys,

    I must say that i share the same feeling about IDE’s (nice one here:
    But as of the choice of the programming language, I don’t think it matters that much, as long as you, the programmer know enough things about what you are doing. Just look at JavaScript and how many great things you can do with it (applause for Alex and Dojo). A few years ago nobody thought this can be done in js, people looked at js as to a “toy” programming language. The same thing applies to Java, PHP or anything else. You can do stupid things in any language; but that doesn’t mean that the language itself is stupid. WordPress is made in PHP, right ? I think it’s an excellent script, don’t you ? There are excellent apps made in other programming languages too. What I am trying to say is that if you are not a good programmer, or if you don’t know all the facts about what you are doing, you can use any language; still the result will be the same: crapy. I have seen a lot of java, php and even a lot more .net crappy apps. The programmer, not the language matters.
    Also, keep in mind that JavaScript, PHP, Python didn’t have the promotion that Java or .net had. These languages evolved supported by their online communities; they did not target the enterprise level as Java and .net do. And they managed to hold on and evolve, and that says a lot.
    Now both Java and .net want to “provide” AJAX out of the box. They want you to build AJAX apps without knowing what it is all about, and in my oppinion, quoting Mark, that “promotes horrible web development practices as it is”.

    Dojo rocks.


  6. Posted May 27, 2006 at 2:12 pm | Permalink

    Hello guys,
    I have recently started using Dojo so I thought I would checkout the blog… Anyway, I am currently developing a JS centric web content management system. I have been a Java programmer for years, but more and more I moving towards the possibilities of more JavaScript centric apps. In age where persistence of objects is becoming increasingly integral to application development, it is going to become increasingly important for object lifecycles to become more dynamic. JavaScript a true dynamic language is much more prepared for the realm of object augmentation, and dynamic behavior modification that is going to become increasingly part of the software as object lifecycles really become more persistent. I don’t think that the GWT takes web development in right directioon. By taking Java bytecode and converting it JS it is defeating some of the great potential of JS. It is most likely going to produce slow, unoptimized JS, I would imagine as well. With my development, I am focusing on developing my application using a domain data model actually lazy loaded into the JS environment, for a true client-centric programming model. A distinct departure from the server-centric model that attempts to make the activity on the browser transparently handled, rather than vice-versa, but I think that it is direction that the web is going. Anyway, I really appreciate Dojo, that I have contributed a lot to providing a more structure framework for JS development.

2 Trackbacks

  1. […] Speaking of Ajax, I would have to say (and I’m certainly not alone in this assessment) the star of the show was the Google Web Toolkit. In my last few Ajax talks, I’ve bemoaned the fact that Google hadn’t yet released something akin to the Yahoo! UI Library – well, looks like I can finally change my tune! I haven’t had a chance to play with it yet (seriously guys, where’s the Mac version already?) but it certainly got my attention. Whether or not GWT is at the right level of abstraction, considering it originates at Google and allows developers to write Ajax apps in Java, it will gain significant mind-share (one of my coworkers is *very* enthused). That said, I think Russell has some great thoughts in his JavaOne wrap up. Speaking of Alex, Sun is pretty keen on Dojo (of course so is IBM) though I’m not entirely sure why. I’m not saying anything negative about Dojo (I think it is clearly the most ambitious toolkit in the Ajax space) I’m just curious why Sun and IBM have embraced it. But that’s a post for another day! […]

  2. By Agile Ajax on June 13, 2006 at 7:01 am

    More GWT Developments

    The ferment going on around the GWT is truly impressive. Whether this bubbling activity is caused by all the frustrated Java programmers that this framework has unleashed on Javascript and the browser, or by the Google name that draws people