Jan 21 2006


Code Samples in Pragmatic Ajax

Mark Haliday raised an interesting question in the comments of my post announcing Pragmatic Ajax. His question: are most of the code samples in the book Java? Without a scientific analysis, here's my best guess as to how the samples break down across the book:

  • 60% JavaScript
  • 15% Java
  • 9% Ruby
  • 8% .NET
  • 8% PHP

The extra space devoted to Java is largely due to the section of the Google Maps chapter devoted to carving up the SVG map which was done in Java, but has little or nothing to do with Ajax or Web 2.0. We just thought it was interesting.

No, in fact, the majority of the book is about JavaScript: how it works, how the various libraries for Ajax work with JavaScript, etc. We tried to devote equal time to integration with the four major web development platforms (Java, .NET, PHP, Ruby on Rails). We did that for good reason: I can write a pretty cool Ajax application with nothing but HTML and JavaScript.

Hope that helps clarify the purpose and nature of the book. Thanks for the question, Mark!

Jan 21 2006


Pragmatic Ajax is Final!

We're pleased to announce that Pragmatic Ajax: A Web 2.0 Primer is complete. We finished the manuscript this week, and the last beta will be pushed out this weekend. Then, its off to the copy editer to find all the spelling and grammatical mistakes that the Apple spellchecker missed. Finally, as fast as the print shop can churn them out (imagine picking up two cinder blocks and trying to run across the deep end of a pool and you get the idea) the book will be released in paperback.

We're pretty sure the book has something to offer every reader. But if you are looking for a shorthand cheatsheet of what WE learned while writing it, here you go:

  1. Microsoft believes that everything has to look exactly like them. Witness their introduction of namespaces, customized inheritance syntax and (shudder) interfaces to JavaScript. I'll rant more about the interface thing later, but suffice it to say, does this look like the kind of JavaScript you want to write?
  2. In 12 months, you'll never hear the word Ajax again unless you are cleaning your kitchen or taking a survey course in Greek mythology. But you won't stop hearing the phrase "Web 2.0" until the next bubble bursts.
  3. .rjs templates in Rails are a really really cool feature, but using them on a real project is a crap shoot right now because they tend to explode layout rendering at random times. I'm stoked about the feature, but I'll come back from the edge for now while it settles down.
  4. Writing a book about an emerging technology is hard hard hard. Here's a list of things that changed dramatically while we were writing the book:

In all, it was a great experience, and I'm really looking forward to seeing the final release in print. If for no other reason than to have a book with my name and a big sword on the cover.

Jan 20 2006


No thanks, Atlas, I'll take my JavaScript straight

JavaScript is an easy language, full stop. It isn't perfect, but if I had to teach a language to eager newbies, I'd prefer JavaScript over C# or Java. But apparently, some folks think JavaScript is too hard. With Atlas, you are encouraged to use helper libraries so that you can write code like this.


  Demo.Person = function(firstName, lastName, emailAddress) {
      var _firstName = firstName;
      var _lastName = lastName;
      var _emailAddress = emailAddress;

      this.getFirstName = function() {
          return _firstName;


      this.dispose = function() {
          alert('bye ' + this.getName());
  Type.registerClass('Demo.Person', null, Web.IDisposable);

Without Atlas, I'd be forced to this:

  Demo = new Object();
  Demo.Person = function(options) {
    this.firstName = options.firstName;
    this.lastName = options.lastName;
    this.emailAddress = options.emailAddress;

The plain old JavaScript looks easier to me. I guess all those accessor methods and busywork code make the Atlasized version more "scalable" or "enterprise". :-)

Humor aside, there is a serious question here. Does it help to make one language look like another, like the C#-izing of JavaScript shown above? If it does help, is it a short-run, "training wheels" kind of thing, or a long run plan? If you're building Ajax apps, drop a comment and let us know what you think.

Ad: Fortunately, there's more to Atlas than the misguided C# veneer. We'll be talking about some of the better parts at the Pragmatic Studio in Reston, VA, Feb 9-11.

Jan 11 2006


The Ajax Experience

We'll also be speaking at The Ajax Experience in San Francisco, May 10-12th. Brought to you by No Fluff, Just Stuff and The Ajaxians, the show promises to be a fun conference filled with talks by the people working on all the new hotness.

Jan 11 2006


Pragmatic Ajax Studio

We're in the final run-up to the inaugural Pragmatic Ajax Studio. We're putting on the show in conjunction with the Pragmatic Programmers, following the format of their celebrated Pragamatic Rails Studios. And, like those guys, we'll be talking about Rails at the show. However, enlike those guys, we'll be talking about Java and .NET too. Because we understand that Ajax isn't tied to a single server-side framework, and that many of you will have to work across multiple platforms to get your Ajax apps finished. So we cover it all, in three days. For more, just visit the official site, where you'll find the entire curriculum and all the information you'll need to come join us.

Jan 03 2006


First to Fail

We've seen a number of blog posts recently looking back over the technology trends of 2005 and looking ahead to 2006. Unsurprisingly, one of the oft-repeated Important Things(tm) from last year was the rise of Rails, Ruby, dynamic languages, and the hype machine surrounding them. I have one piece of advice for most of those bloggers, and I quote one of the deepest thinkers of our time, Noel Gallagher: "don't look back in anger". (He also famously wrote

She's got a brother We don't get on with one another But I quite fancy her mother And I think that she likes me

(and I think there's wisdom there for all of us.)

One of my favorite sub-memes of this major meme is that 2006 will show that dynamically typed languages are a fad and Java and .NET will again rule the day, and especially that 2006 will be the year that we see one spectacular failure of Ruby in the enterprise and this will be the death knell of this trend.

I have two words in response: "duh uhhhhh". Of COURSE we're going to see a massive public failure of a project written in Ruby or Python or Lisp or SmallTalk or Perl or whatever. It is inevitable. We'll see massive flameouts on a grand scale. You know why? Because for all that Rails or Ruby or Python or what have you attempt to solve a lot of the problems of modern software development, none of them can solve the underlying problem, that software is written by people and is often written by uninterested people. Now that the hype machine has generated enough attention on these dynamically typed platforms, it is only a matter of time before they are adopted by teams who are uninspired by or uninterested in their technical merits, propensities, and features. These teams will use them because they think they can get the same paycheck with less work, and their projects will fail. Loudly.

Does this mean that these languages, platforms and frameworks will be demonstrated to be the emperor's clothes? Not at all. It will merely announce their ascendence into the time-honored tier of Tools that People Use. Nobody has ever claimed, for instance, that using Ruby will make all projects succeed. Just that, in the hands of developers who care, projects can succeed faster and be better. Arguing that a large failure of a Ruby project in 2006 will be a death blow overlooks two important facts:

  1. there will be many more loud failures of Java and .NET projects in the same time frame
  2. there hasn't been a loud failure of a Ruby/Rails project yet.

Do either of these facts mean that Java and .NET have failed? Nope, but it sure is interesting, no?

Dec 20 2005


Bidding Projects with Ruby/Rails, Take 2

Since I have received several comments and private emails on my first post about bidding projects in Java or Rails, I decided to add some expansion and clarification.

  1. People want to know what Java stack we prefer/use. Spring, Hibernate, sometimes Tapestry. We use AspectJ where appropriate.
  2. To those who are worried that we are encouraging a price war that is bad for developers: We pay ourselves (and our contractors) better for Rails work than Java work. This is good for everybody: Developers have more fun, make more money, and customers get better products cheaper and faster. I don't see the problem here.
  3. On overcoming resistance to Ruby and Rails because they are new: This is a real issue, and rightly so. If a Rails project is difficult to maintain because Ruby developers are in short supply, then a small development savings up front doesn't look so great to management. One thing I point out to customers is that maintenance cost is some function of the size and quality of the codebase. A well-written Ruby codebase can be an order of magnitude smaller than a similar codebase in Java.
  4. Some people took my "worst case" number (10% advantage for Ruby) and extrapolated that Java could catch up. That extrapolation is going in the wrong direction. The reason that my number is 10% and not 50% is difficulties that sometimes arise due to the relative immaturity of the Ruby/Rails stack. For example, say we bid one project at 20% cheaper with Rails. But, that price includes the hidden cost of building a database driver and some specialized XML processing that does not exist for Ruby (and does for Java). On our next similar project, we'll be able to deliver 30% cost savings over the Java bid, because the plumbing will already exist for both platforms. And remember, these numbers come after paying developers more.
  5. What are applications that are "nowhere near the Rails sweet spot"? This is a complex question, and I'd like to defer answering this one until I have time to do it justice. If somebody posts something in line with my thinking I'll certainly link it here.
  6. A few people have asked questions which amount to "Please give me much more intimate details of exactly how Relevance does business and gains a competitive advantage." I will politely decline. :-)

Dec 19 2005


Ruby/Rails: Put Your Money Where Your Mouth Is

OK, we have had plenty of debate and hype about Ruby on Rails. It's time for IT executives and decision makers to say "Show me the money!" If Ruby on Rails is so fabulous, where are the on-time, under-budget projects?

So, here you go. For the past 18 months, we have been quietly bidding web projects with both Java and Ruby on Rails. The numbers for us, so far, fall out like this:

  • For applications in the Rails sweet spot (CRUD+Ajax on the web) our Rails price tends to be 30-50% less than the same bid implemented in Java.
  • For applications that are nowhere near the Rails sweet spot (do you know what these are?), our Rails price tends to be only 10% less than the same project implemented in Java
  • Applications are completed twice as quickly in Rails.
  • When customers want an hourly rate, our hourly rate for Rails work is slightly more than our hourly rate for Java work. However, given that applications are finished 30-50% faster, Ruby/Rails still delivers more per dollar.

This is not to say that the "10x productivity" claims of Rails developers are simply false. There are specific parts of Rails development that are indeed that much faster. But other parts are not, and the 10%-50% above is what we have seen on real projects over the past 18 months.

When 10% is Bigger than 50%

I actually find the 10% number to be the astonishing part of our experience so far. The 50% number sounds better up front, but basically amounts to the same claim that many other people have already made: Rails is extremely productive doing what it was designed to do. The 10% number suggests a much more compelling argument. "Ruby is more productive than Java, period. Even when Java libraries already exist to solve a problem, and you have to roll-your-own in Ruby, Ruby will come out ahead on sizable projects." It is this 10% edge that prompted me to write the Enterprise Hammer articles.

Given my ideas about why we are more productive in Ruby, I would expect Python or Smalltalk developers to have a similar edge. Anybody out there want to share some numbers?

Dec 16 2005


Announcing Pragmatic Studio: Ajax

I am thrilled to announce that Justin and I are teaming up with the Pragmatic Studio guys to produce Pragmatic Studio: Ajax. Join us Feb 9-11, 2006 in Reston, VA for an intense three days learning how to build rich, interactive applications on the web. Details here.

Dec 14 2005


Samples and Slides from TSE

The slides and samples from The Spring Experience talks are now online at: Skip to the last slide in either slide deck to get the link for the sample code.

Popular Tags