AjaxWorld 2008 impressions I

This is the first in a series of post on what I saw, talked about and experienced on the AjaxWorld conference this year in San José. The conference has just ended and I'm sitting in the hotel room after a nice crabcake burger and a glass of wine and will soon head off to Mountain View in search for a SF bookstore.

Anyway.

My impressions of the conference as a whole and of the state of the industry (which one might hope would have a correlation) is that the world is being split in two. Luckily, most people isn't particularly interested in the bad part :) What I mean by that is that a seizable portion of the talks and booths revolved around products that continue to pile complexity upon complexity on the developers to shield them from the browser.

I'm primarily talking about Oracle and Icefaces here, of course. But also talks on GWT and PHP-generated server-side templates for JS did their best to muddle the waters. Of course, this is not really fair in my part, since everyone is trying their best to solve the problems as best they can. If it so happens that someone has struck upon a substandard architecture and haven't had time to think through all the angles, it's certainly not because of malign intent.

On the whole I was happily surprised to see a lot of companies present whose products and talks were attracting a lot of attention, who were in essence advocating thin server solutions across the border, wholesale. Smartclient from isomorphic has grown a _lot_ since I checked it out a year or so ago.

They have basically built 50% of Dojo all by themselves, for their client side framework, and I couldn't help but thinking: Agnostics what a waste! How much time it must have taken them. And then immediately: Wow, that's really smart, we should have that in Dojo :) What I was most impressed with was their efficient focus in metadata. Nowadays we have JSON-Schema, which was not a luxury they had when they started out, of course. They have a tool which let you import schemas of different formats, though, so JSON-Schema support is probably on their radar.

Why is schemas so important? Well, they have many (all?) components schema-aware, so that if you attach a schema to a Form component, up pops a form with the correct fields, date fields have a datepicker, int fields have validations for integer values and so on. Also, the form gets generated by itself, of course, and can be remaking itself dynamically. Why don't we have such a thing in Dojo? Actually, there's no reason at all, but right now I'm blogging. Also their grids work in the same way, and have a couple of extra features like sort fields which can be enabled for any column (filters).

My only gripe with Smartclient is that the web-based IDE is non-free (but they have a 60-day demo), and also that they have written a whole new toolkit instead of leveraging jQuery, Dojo, Ext or something. Their toolkit is LGPL and all, but still think that it would have been simpler if they hadn't been so monolithic. Now, I _am_ just grumbling. the Smartclient DIE was absolutely wonderful with tons of smart components and a clean separation o f concern between the client being created and the services it consumes. Very good.

UPDATE:
As @ckendrik points out in the comments below, when the first versions of Smartclient were created, no toolkits were available (2001), which explains both the long list of features and the reason for a homegrown solution. I'm not at all suggesting that Smartclient is fracturing the framework space. It is actually very uncommon for companies with similar products to actually leverage an existing framework; Appcelerator, TIBCO, et.c. have their own frameworks as well. This is very much alleviated by the fact that many companies are starting to provide bridges to other frameworks; Smartclient have extension for GWT interaction, for example.

Coming up: " jMaki - buried treasure", "WaveMakers upcoming massive cloud gambit", "Lessons learned around Mars" and finally "SSJS - the only way forward".

Your trusted uncle in San José,
PS

Comments

Hi Peter,

One correction on SmartClient - it's not that we ignored existing toolkits and built our own. When SmartClient was created, there was nothing we could meaningfully leverage.

For perspective, SmartClient 1.0 was released in 2001, and we provided advanced OLAP grids to Informatica in 2002. At Informatica we were working alongside Alex Russel who at the time had a project called NetWindows, a precursor to Dojo that was later abandoned, and which, at the time, was not ready to handle basic screen layout use cases, let alone the OLAP functionality..

If there had been something to leverage, we would have :)

As long as you're going to be writing more about the conference, we'd greatly appreciate it if you could correct what you said previously. We quite agree that it's a bad idea for new frameworks to keep appearing and re-inventing the wheel, when there are several open source projects that people could be contributing to instead.

We certainly do not want to be publicly labeled as the type of company that further fractures the Ajax framework space. That's quite inaccurate.
Script Uncle said…
Hi @ckendrick,
I didn't really mean it that way. Please see my update above which I hope clarifies my intentions.

Cheers,
PS
Ted Goddard said…
You describe server-side Ajax frameworks as being more complex than client-side frameworks, but isn't the opposite really the case? By re-using a fixed JavaScript kernel in the client for all applications, a server-side framework is more strongly factored.

Of course, the most important measurement of complexity is the perception of the application developer, but again, the higher-level abstractions available to the server-side developer show that server-side Ajax frameworks are less complex.
Script Uncle said…
@Ted: I'm not sure what you meant by a server-based framework being more strongly factored than a javascript client-side kernel.

I assume that you assume that you should have the same client functionality all the time, and if you put everything in a server-based web framework that would simplify new changes to the client?

If so, that is not the case at all :) The client is made up of simple text files. When these change, the client change. Also, the client can have (as in the Dojo case) a smart loading system which can reload functionality and change itself, should this be needed.

When you define the client UI on the server, you are mixing metaphors, much like you would when having a class do two things instead of one. When you create the client separately, no logic need to get 'mapped'.

Cheers,
PS
Ted Goddard said…
Exactly; with a server-side Ajax framework, the client-side JavaScript can be the same for every application. If the client-side JavaScript is free from eval() it even means that the complexity is low enough for a security analysis to be performed.

Perhaps there are different metaphors at work in the client-side and server-side cases: with a server-side framework, the client is simply the projection of the "view" in MVC. With a client-side framework, the client and server act more as peers in a distributed system (like CORBA). After all, the data and the business logic are on the server.
Kris Zyp said…
Peter,
Yes, we definitely want schema-aware components in Dojo. Forms and the grid would greatly benefit from self-configuring/self-decorating based on schemas. It's on my todo list, but feel free to work on it as well.
Script Uncle said…
@kris zyp: Sounds good to me. Right now my immediate target is to make a mess of a first implementation of a 'multi-grid' that can manage several datastores and follow $ref -erences between them.

At a quick look it feels fairly doable to chuck in schemafication to forms, actually. This winter is going to be great! :)
Eugene Lazutkin said…
@kris zyp: "Forms and the grid would greatly benefit from self-configuring/self-decorating based on schemas." Add charts to the list. It is essentially a visual representation of tables and as such should share the data part with grid. We should converge things rather than fracturing them with incompatible APIs and implementations.
Kris Zyp said…
@Eugene Lazutkin: Yes, absolutely.
Script Uncle said…
@eugene lazutkin: Most definitely! I just hadn't got that far in my mental processes, apparently :). Th Charting schema will be a bit more complex, since we'll have to define a lot of canvas / gfx API stuff as well.

But that's really great, because when done, we'll have a generic method for serializing/deserializing gfx and charting parts. Hmm. Isn't there some stuff like this in gfx already? I'll have to check it out.

Cheers,
PS