The Keene View on Web 2.0, Ajax and SaaS

Labels: AJAX, DOJO, training, tutorial

The much-hyped but poorly defined terms Web 2.0, Rich Internet Application (RIA) and Ajax are best understood when they are defined together.

Buzzwords represent job security for entrepreneurs like me who would be practically unemployable were it not for our secret knowledge of the true meaning of words like Web 2.0. However, even I must admit that these Buzzwords 2.0 get in the way of clear communication.

In addition, while there are many standalone definitions of terms like Web 2.0, it is much easier to understand these buzzwords mean by considering them together. With that in mind, here are my definitions of Web 2.0, Rich Internet Application and Ajax, complete with helpful graphics:

• Web 2.0 represents a market shift in consumer attention from expert-generated content (Yahoo) to user-generated content (Google)
• Rich Internet Applications represents a requirements shift for more interactive, PC-like web sites to simplify consumer creation of content (Blogger, MySpace)
• Ajax is an architectural shift to support RIA requirements

Definition of Web 2.0 - Shift In Consumer Attention

Consumer eyeballs still rule the web. The huge power shift over the last 5 years has been from expert-driven content (which could be created using expert tools like Adobe Dreamweaver) to user-driven content (which requires web based tools that are easy to use). The shift in consumer attention is also driving a shift in business focus as corporations look at ways to engage more effectively with their customers and employees.

Definition of Rich Internet Application - Shift in Web Requirements

In order for more people to participate in creating content for the Internet, the content creation tools have to be both simpler and more interactive. Rich Internet Applications seek to erase the difference in user experience between browser-based applications (Gmail) and traditional client/server applications (Outlook). A quick comparison of Gmail versus Outlook shows that RIAs have a big usability gap, but the Internet brings the offsetting benefit of dramatically simpler application distribution.

Definition of Ajax - Shift in Web Architecture

Ajax is an architecture which makes the browser smarter and more interactive by running Javascript programs on the client. Don't tell anyone, but the old name for putting logic on the client was fat client programming. Everything old is new again and it turns out the only way to make an interactive client is to do more processing in the browser.

The following diagram shows the fundamental changes between the Web 1.0 architecture (circa 2000) and the Ajax architecture.

Where is all of this leading?

Web 2.0 is driving new application requirements and in turn creating a demand for new development tools that can meet those application requirements. Building increasingly visual and interactive web applications requires a WYSIWYG Ajax tool - something like a Microsoft Access for the Web. Flex and Silverlight, Adobe and Microsoft are providing proprietary tools for building RIA applications.

For an example of an open-source tool for building RIA applications based on Spring, Hibernate and Dojo, check out WaveMaker . Download Wavemaker to see what a visual Ajax tool looks like! Wikipedia also lists a number of other Ajax frameworks for building RIA applications.

References
A number of others have gone before me in defining these terms individually. Jonathan Schwartz recently pointed out that Java has always had RIA capabilities (but he also admits they didn't work very well until recently). Here are my personal favorites definitions:

• Web 2.0. Tim O'Reilly at O'Reilly Media has a good definition of what is web 2.0
• Rich Internet Application. Adobe initially defined the term rich internet application. The Burton Group also has a good white paper on Ajax and RIA (registration required).
  
• Ajax. Jesse James Garrett of Adaptive Path originally defined Ajax.

Labels: AJAX, RIA, Rich Internet Application, Web 2.0

WaveMaker announced a partnership last week with Enterprise DB, specifically their blades program. Enterprise DB (based on Postgres) is being bundled with the next release of WaveMaker to beef up the database part of our Ajax development platform.

Now Lewis Cunningham, a Senior Solutions Architect for Enterprise DB, has posted a great WaveMaker product review. He compares WaveMaker to Oracle Forms and Oracle ApEx, with the difference that WaveMaker works with standard Java and the Oracle products only work with Oracle PL/SQL.

Lewis says:

Wavemaker Studio is much more of a GUI IDE than the ApEx application builder. ApEx looks and feels like HTML while Wavemaker looks and feel like a rich, desktop application. Wavemaker Studio just doesn't feel like you're running in a browser.

I will be posting about my progress with Wavemaker as I play with it. I am liking it now that I have it configured and working. I think one of the big things that both Postgres and EnterpriseDB have been missing is a very robust application tool. Wavemaker might just be the tool.

The cool thing about the WaveMaker/EnterpriseDB partnership is that it took exactly one phone call between myself and the Bob Zurek, the CTO of Enterprise DB, to "negotiate" the entire relationship. As I pointed out in the Silverado Rules for Open Source Success, open source is not just good for creating user communities, it rocks for creating vendors ecosystems too!

Labels: AJAX, ApEx, EnterpriseDB, Oracle Forms, Postgres

[This article is based on a talk by Scott Miles, WaveMaker architect and module owner for Dojo Grid, and Steve Orvell, WaveMaker engineer and core committer for Dojo, that they gave at the Visual Ajax User Group]

Ajax developers expect too little of their tools! Why do we put up with endless code/debug cycles with our favorite Ajax library just because there is no way to visualize a UI while you are developing it?

Imagine life without Firebug. Now estimate the amount of time you spend in Firebug just trying to figure out why a particular widget didn’t render the way you wanted it too. A WYSIWYG Ajax editor takes away a great deal of needless widget layout pain.

Just as importantly, a WYSIWYG Ajax editor provides a much easier on-ramp to learning Ajax programming, opening up a much larger market opportunity. Today, the perceived difficulty of learning Ajax can drive developers often choose proprietary solutions by default.Until it is easy to build Ajax user interfaces, the ability to build rich internet applications will be restricted to only the most skilled developers. Broad adoption of Ajax requires easy-to-use, WYSIWYG Ajax tools.

Why Visualize Your UI?

Why do you want to visualize your UI while you are building it? As the client gets thicker, the interactions get more complex. As interactions get richer, the potential for wasting a lot of time coding grows. To torture a metaphor: in Ajax, a picture of your UI can save a thousand lines of code.

Alex Russell of Sitepen talked about saving ourselves from the unweb at the Visual Ajax User Group on the value of Semantic HTML for building Ajax apps. From our perspective, the semantic web may be coming, but it ain’t here yet (look here for more on the open web). In particular, HTML parsing and rendering can be slow. While other visual design tools may take different paths, the particular approach that WaveMaker chose was to use JSON (Javascript Object Notation) instead HTML/XML.

How a WYSYWYG Ajax editor works

A WYSYWYG Ajax editor is meant to make Ajax widget layout easy, without hamstringing the developer. The general things that any visual Ajax editor needs to be able to do include:

1. Ajax page designer: the page designer includes palettes of widgets, a WYSIWYS page editor, and property inspectors to change widget properties.


2. Drag and drop: developers can move widgets from the palette onto the page designer.


3. Visual feedback loop: developers can see how their page will look and change widgets on the fly to see the effect on the design (e.g., sizing, positioning).


4. Generate Ajax code: the Ajax editor generates the appropriate css, html and JavaScript to implement the design at runtime.


5. Import/export widgets: there is a straightforward way to create new widgets and import them into the Ajax editor to create a robust ecosystem of 3rd party widgets.

Rules for making WYSYWYG-able Widgets

Ideally, a WYSYWYG editor should be widget agnostic – it should be able to support several different Ajax widget libraries. More importantly, people who build widgets should design the widgets up front for visual tool-ability. Good widget design can reduce or even eliminate the back-end coding needed to bring a widget into a visual Ajax tool.

WaveMaker is a visual Ajax designer that can host a variety of toolkits and widgets. Our experience developing WaveMaker has enabled us to crystallize seven widget design principles that simplify the task of hosting the widgets in a visual design tool:

• Portability is critical: no matter how good a tool is, developers need the flexibility to switch tools. If the output of a WYSIWYG Ajax editor can’t be edited in vi, then the proprietary lock-in may outweigh the tool’s short-term benefits. Similarly, a widget that introduces its own markup language will require its own proprietary tools (think Silverlight).


• Performance counts: an Ajax editor needs to produce Ajax apps that have acceptable load times and responsiveness, making it easy, for example, to produce minified JavaScript.


• Well defined dependencies: make it easy for the tool to discover and incorporate images, css and other libraries required by a widget.


• Limit create only functionality: a WYSIWYG tool need to be able to change properties like sizing and positioning dynamically, not just at the time of widget creation. Having to recreate the object every time a property changes is inefficient.


• Straightforward APIs: widgets should follow an API naming convention (e.g., for getting and setting attributes) that simplifies exposing properties through a visual tool.


• Automatic re-rendering: Widgets should also be responsible for updating their visual representation when their properties change. One good way to do this is via property setter methods.


• Make it easy to expose events: a naming convention where all event methods start with onFoo makes it easier for a tool to be smart about what events a widget can respond to and then expose them in a straightforward way.

A good example of a WYSYWYG-able Widget is FCKEdit. This is a heavy-weight widget that is completely self-contained and comes with an Ajax-friendly JavaScript integration technique. On the other hand, FCKEditor does not expose resizing hooks (we had to figure that part out on our own).

Dojo Dijits contains a whole library of WYSYWYG-able Widgets. A visual Ajax tool like Wavemaker can easily wrap Dojo widgets with Javascript “meta-data” descriptors that allows the studio to create generalized property editors. The same process can be used to make other Ajax widget libraries available within studio, such as Google Gadgets and Ext.

Tooling the Dojo grid

The trick in tooling a complex widget is to determine what behaviors to tool. The goal is to provide the right subset of features through the tool without preventing the developer from going in afterwards and creating what they need.

For example, the Dojo grid is tremendously capable. Not all these capabilities are accessible through WaveMaker, such as fixed columns, combined cells and subrows. Think about all the things you can do with Excel and how long it took for Excel to get it’s grid tooling right. In the same way, WaveMaker is exposing a subset of Dojo grid features today, and will increase the richness of those capabilities over time.

Options for representing the Dojo grid data included raw javascript, table markup and json.

An equally difficult challenge is deciding what code to generate to implement a given Dojo grid definition. In general, there are three options:

1. Semantic HTML: generate HTML that includes rich Dojo grid semantics


2. Raw Javascript: chuck HTML and define the grid in Javascript


3. JSON: uses an object notation instead of semantic HTML to speed parsing

The following three sections give examples of these different approaches

Semantic HTML Markup definition for a Dojo grid

The following example comes from the Dojo Nightly builds grid tests. It shows a way to use “enriched” HTML to define a Dojo Grid (a la Alex Russell). The really cool thing is that this code runs even if JavaScrip is turned off in the browser.

If you already know how to code html tables, this is an elegant approach. However, its elegance and readability is offset by the performance hit the application takes in parsing the HTML.

<table dojoType="dojox.grid.Grid"
 store="csvStore"
 query="{ Title: '*' }"
 clientSort="true"
 style="width: 800px; height: 300px;">
 <thead>
  <tr>
   <th width="300px" field="Title">Title</th>
   <th width="5em">Year</th>
  </tr>
  <tr>
   <th colspan="2">Producer</th>
  </tr>
 </thead>
</table>

Raw Javascript definition for a Dojo grid

The following example shows setting up a Dojo grid using raw JavaScript. Although JavaScript is powerful and expressive, this essentially junks sSemantic HTML concept in favor of just getting ‘er done. is, however, confusing and difficult to read.

<script type="text/javascript">
// a grid view is a group of columns
var view1 = {
 cells: [[
  {name: 'Column 0'},  {name: 'Column 1', width: "150px"},
 ],[
  {name: 'Column 8', field: 3, colSpan: 2}
 ]]
};
</script>

Json definition for a Dojo grid:

Json (JavaScript Object Notation) represents a third way to represent grids. To see this in action, look at the widget source tab in the WaveMaker page designer. The main benefit is that it is readable and plugs easily into a visual Ajax tool JSON provides a highly readable, name/value pair approach to defining widget parameters. Best of all, it provides a format for widgets that parses and renders quickly and enables easy data interchange between the visual studio, the browser and the application server.

dataGrid1: ["turbo.DataGrid", {}, {}, {
 column: ["turbo.DataGridColumn",
  {caption: "Name", columnWidth: "50px"}, {},
 column1: ["turbo.DataGridColumn",
  {caption: "Addr", columnWidth: "100px", index: 1}, {},
}]

Summary

Until there are visual tools that simplify the task of building Ajax user interfaces, the ability to create rich internet applications will be restricted to only the most skilled developers. Broad adoption of Ajax requires easy-to-use, WYSIWYG Ajax tools. WaveMaker is an example of an open source development platform that includes a WYSIWYG Ajax editor. Try it out and let us know what you think at http://www.wavemaker.com/downloads

Labels: AJAX, DOJO, JSON, Visual Ajax, WaveMaker, WYSIWYG

A year ago, I bought a Dell desktop running Windows Vista. Last week, I finally got it working…mostly.*

This week, we are releasing WaveMaker for the Mac (OS 10.5 Leopard to be specific) and Safari. Although the Mac is a visual platform, it has always been behind on WYSIWYG development tools. With Wavemaker, the Mac is leaping back in front.

The WaveMaker Visual Ajax Studio download for the mac is at http://www.wavemaker.com/downloads or just click here.

After many years of languishing in the education and design ghettos, Mac has once again become the defacto standard of leading edge techies. I attended an open source CEO conference recently where I was the only PC user at a breakout session of 10 people.

Our press release included a spiffy quote from Jean-Louis Gassé, General Partner at Allegis Capital and ex-Apple executive: "WaveMaker's Visual Ajax Studio for Mac comes at a very opportune time. Apple is gaining momentum in the Enterprise and WaveMaker gives enterprise users an easy and visual way to build Web applications."

Mac developers had their moment, back there in the days of Hypercard and Filemaker pro. Now the Mac platform is becoming a defacto standard for developers once again.

Here are some of the key reasons the entire silicon valley seems to be moving to the Mac:

1. Ajax platform of choice: Safari is lightning fast and leads the pack in standards-compliance. I can't remember the last time I saw any web app demoed on Internet Explorer, and if Firebug* ever gets ported to Safari, Firefox will be in trouble.
2. Video platform of choice: we just went through a 3 week death-march to create a new screencast for WaveMaker. Of that time, about 8 hours was spent creating content - the rest of the time was spent wrestling with the brain-dead video software we were using on the PC (Camtasia). In contrast, my 12 year old niece just created a 30 minute class presentation using i-movie. Enough said.
3. The Incredible shrinking desktop: with more and more compelling web applications, I find myself spending less and less time working within my Windows desktop.
4. The disaster that is Vista: given that I have to relearn the whole user interface to move from XP to Vista, I might as well relearn an interface that actually makes sense.
5. That cool backlit logo on the Mac laptop: let's face it - the knowledge that you will look good in a coffee shop probably sells more laptops these days than Ghz or RAM stats.
   

When I was in college I saw Steve Jobs demo the Apple Lisa in front of about 30 of us Stanford Comp Sci nerds. It is still to this day the best demo I have ever seen, despite the fact that the Lisa flamed out famously. I know that Macs will never take over the world, but it's sure nice to see them back in the race.

Then there's also the part about it just plain works! Which brings us back full circle to my Dell/Vista saga: after spending dozens of hours, many hundreds of dollars on utilities that didn't work, and a spectacular lack of help from Dell (the answer ended up being on an Intel site, having to do with the Intel Matrix storage manager, not that you really wanted to know).

Interested readers may also want to check out another good blog post on why PC developers are moving to the Mac.

*corrected - original post confusingly said Firefox, causing a great deal of what passes for glee among the trolls ;-)

Labels: AJAX, development, Macintosh, RAD, WaveMaker

[This article is based on a talk by Alex Russell, the co-founder of Dojo, that he gave at the Visual Ajax User Group, with added editorializing and pontification by Chris Keene, CEO of WaveMaker. You can safely assume that anything insightful and true came from Alex's talk and anything smarmy and argumentative is part of Chris' "value add"]

The original use case for the web - researchers working with static documents - doesn't bear much resemblance to the multi-media, consumer-oriented web we have today. The HTML web browser infrastructure that got us this far won't get us the rest of the way.

The web has always been about the worst platform for any particular task (unless your task is to display a poorly formatted doctoral thesis). Ubiquity, searchability and combinability have always made up for the web's many weaknesses.

We are reaching a fork in the road, however, where the web's traditional strengths may be dramatically eroded by a "hollowing out" of the HTML semantics. There are basically two responses to this challenge of evolving the web. They are:

1. Evolve HTML = Better Semantics, Smarter Clients. Evolve the existing web by pushing browser vendors to add semantic HTML capabilities that support next generation web apps. This allows for the web to remain a collaborative community that preserves the advantages which the web has traditionally enjoyed even sa it transitions to handle new tasks.
2. Hollow out HTML = the "Un-web". Abandon HTML and replace it with a powerful but proprietary alternative like Adobe Flex or Microsoft Silverlight. Let's call this the Un-web, as it carves out walled gardens which will curtail the web's traditional openness.

The web needs to evolve to support building the Rich Internet Applications that people want to use. At the same time, web tools need to evolve to be able to handle the increasing complexity of building these apps.

Example of Semantic HTML - The Dojo Grid

Web development and customer expectations have far outstripped the table management capabilities of HTML. Why do we expect so little from HTML? Is it too much to ask for capabilities like locked columns and subcolumn formatting? Is the only solution to improve the grid to break HTML by going to a proprietary solution like Silverlight?

A great example of how to evolve the web through semantic HTML is the Dojo grid, which was contributed to the Dojo project by WaveMaker engineers Scott Miles and Steve Orvell.

Here is a screenshot of a Dojo Grid:
















With Dojo 1.1, we can use HTML that has additional semantics "layered on" to create a grid like this. Note that it looks a lot like normal HTML beefed up with extra attributes to encode the semantics that allow us to "say what we mean":

<SPAN DOJOTYPE=" dojox.data.CsvStore"
 JSID=" csvStore"  URL=" names.csv" >
</SPAN>

<TABLE DOJOTYPE=" dojox.grid.Grid"
 STORE=" csvStore"  QUERY=" { Title: '*' }"  CLIENTSORT=" true"
 STYLE=" width: 800px; height: 300px;" >
 <THEAD>
  <TR>
   <TH WIDTH=" 300px"  FIELD=" lastName" > Last</TH>
   <TH FIELD=" firstName" > First</TH>
  </TR>
 </THEAD>
</TABLE>

The Dojo grid also showcases a core strength of Dojo - it's disciplined architectural approach. The Dojo architecture focuses on extending HTML semantics in an layered way that still give us room for HTML to evolve to meet usage like this half-way in the future (e.g., with the HTML 5 tag). Note that we use a non-semantic tag (a span) to denote something that exposes a fundamentally new capability (data stores), but extend existing HTML semantics for grid configuration.

The result is a very clean layering of Dojo semantics on top of vanilla HTML and css. For example, even with Javascript turned off in the browser, you can still tell what the Dojo grid is supposed to be doing. We can even supply the data via an HTML table in order to get full downward-compatibility.

Replacing HTML with Javascript is enticing but dangerous. Dojo uses Javascript to extend HTML semantically rather than throwing it away. Adding semantics to HTML gives HTML the carrying capacity to support next generation of web design.

Hollowing Out HTML - The Un-Web

While parts of the web evolve, there are also web constraints that don't change, such as the latency of communication and the static application deployment environment (aka browser + plugins). There are huge restrictions in not being able to send down an execution binary along with each web app, but huge deployment efficiencies as well.

One way to overcome the limitations of HTML is to replace HTML with proprietary web technologies like Flex and Silverlight. These technologies pose the risk is that the searchable, collaborative HTML web that we know and love gets hollowed out from the inside. This effectively carves out areas of the web that are not searchable or combinable with anything that has gone before.

Save The Web - One Browser At A Time

It is up to the Ajax and open source communities to "liberate" the HTML web from the Unweb. For example, "liberating" the Dojo grid is an on-going community effort involving large amounts of goodwill, time and cash.

Rapid evolution of the HTML browser can get us to the future, but only if we get a lot more demanding of the web browser manufacturers. What we can't afford is another 6 year drought like what we got when Netscape abandoned the browser wars and Microsoft IE had the world all to itself.

The key to the web's future is real competition between the browser vendors that will force them to evolve the browser quickly. These features include:

• Auto update capabilities
• 3-d rendering
• Support for new semantics in HTML
• In short, give us native ability within the browser to do what we otherwise have to do in Javascript libraries

What we know is that we have never gotten good browser enhancements and tools from the market leader. So now you know what you need to do to save the web - download and use the underdog web browser and give it all the love you can ;-)

Labels: AJAX, DOJO, Dojo WaveMaker, Flex, Silverlight

The Meteoric Theory of Applications (to paraphrase Mary Loomis) is this:

Applications are like meteorites - they never migrate, they just land and stick.

With all the excitement over rich internet applications and Web 2.0, there is much talk of a vast migration of applications from client/server to the web (Judith Hurwitz describes when not to salvage legacy applications). While this will undoubtedly happen, it misses a much more important IT skills migration.

The real power of Web 2.0 lies not in modernizing legacy client/server applications, but in modernizing the skill sets of client/server developers. If an app was built in VB or MS Access and it works, leave it there. The real question is what to do with the developer who built that app?

Developers with 10+ years of experience with client/server tools have no clear way to "upskill" to building Web 2.0 apps. Consider the skills that a typical Visual Basic/Visual Studio developer would need to learn to start building an Ajax application:

• New database: MySQL
• New server language: Java
• New application server: Spring ($26.39)
• New database access framework: Hibernate
• New client/server messaging layer: Json
• New client language: Javascript
• New client toolkit: Dojo
• New styling language: css
• New IDE: eclipse

No wonder there is such a shortage of Java web developers!

WaveMaker is focusing on the skills migration - how to enable non-expert developers to build Ajax applications by using visual tools (for a good review of WaveMaker as an alternative to VB, see Java at the eye of a perfect storm).

Last week, WaveMaker hit 1,000 downloads a day - seems like we hit a nerve!

Labels: AJAX, WaveMaker, Web 2.0

I know I'm dating myself, but Bill Cosby had a pretty funny routine where a PE Teacher explains that the purpose of air is to pump up basketballs and volleyballs.

Now Adobe has launched their Air product (with a matching Kevin Lynch NY Times article, and GigaOm fan dance) to allow platform to allow browser apps to escape from their little Firefox and IE prisons and flit gaily across the desktop like "real" apps.

Now what exactly are the benefits here? According to the NY Times article:

1. I can click an icon on my desktop instead of a bookmark in my browser. Yawn.
   
2. I can run an application without the browser border. Snore.
   
3. I can run an application offline. Now this is cool, but hardly new, following earlier moves by Google Gears, Dojo Offline and Mozilla Prism

As I have written, Air, Flex and Silverlight are"back to the future" approaches for Rich Internet Applications that would have us believe that the future of the web lies in a proprietary animation engine (Flash) or an ancient and proprietary fat client architecture (Silverlight).

At WaveMaker, we believe open-source toolkits like Dojo are the best enterprise Ajax choice a more flexible, open-source browser choice. To be fair, we in the Ajax community still have a lot of work to do to be truly ready to take on giants like Adobe and Microsoft - but that's where the power of the community can make a difference.

Speaking of community, you can come find out more about the the Dojo toolkit at the upcoming Visual Ajax User Group meeting. On Thursday, March 20 from 12-1:30 PST, Alex Russell, one of the co-creators of Dojo, will be talking about the Zen of Dojo - how to make Dojo development effortless for beginner and expert alike. Come in person or sign up for the webinar by sending email to rsvp@visualajax.org.

Labels: Adobe, Air, AJAX, Dojo WaveMaker, RIA

You can't swing a dead cat at a Web 2.0 conference these days without hitting a dozen Rich Internet Application (RIA) toolkits. The Olliance Group recently identified 58 RIA products, many of them either proprietary or incompatible with the other 57 approaches.

Just to set the stage, here is my personal definition for a Rich Internet Application:

"Rich Internet Applications match the responsiveness of traditional desktop apps by minimizing web page refreshes. RIA taps into the collective power of the Internet to supply widgets and services for building web clients, like rss feeds, Google maps and Youtube. The goal of RIA is not merely to emulate a PC GUI in a browser (aka the Silverlight sell-out), but to deliver browser-based clients which far outperform PC GUIs in speed and functionality."

Ajax* is a particular architecture for building RIAs that is favored by open source libraries such as Dojo, Jquery, Ext and dozens of others. The perpetual flamewars between adherents of the various Ajax toolkits is a huge gift for the proprietary RIA products like Microsoft Silverlight and Adobe Flex.

Many Ajax toolkits seem more focused on posting esoteric animated graphics widgets to the Ajaxian web site than they are on meeting mundane but critical enterprise needs. To be fair, whizzy graphics are an important element of RIA's appeal. However there are more fundamental concerns to address before RIA can be considered enterprise-ready.

Into this maelstrom of splintered efforts comes the Dojo 1.0 release. Dojo has been in development for 3 years, making it one of the more mature toolkits available. Dojo also has the backing of IBM, BEA and Sun and will ship standard with their Java servers.

Previous versions of Dojo were criticized as being too big and too slow. Dojo 1.0 attempts to address those issues. Even more importantly, Dojo has also addressed a number of the hard issues required to gain enterprise adoption:

1. Internationalization and accessibility: Dojo supports localization, keyboard navigation and vision-impaired users, making it appropriate for both global businesses and government applications.


2. Excellent data handling: the Dojo grid (plug: built by ActiveGrid's own Scott Miles and Steve Orvell) easily handles 100,000+ rows with dynamic loading and complex rows, making it suitable for building the most data-intensive web clients.


3. Interoperability: Dojo supports the OpenAjax hub, making it possible for an enterprise to integrate and support web applications built with different Ajax toolkits.


4. Corporate look and feel: Dojo supports the ability to define a corporate look and feel or skin that can be used across a set of applications.

Although choice in general is good, no CIO wants to be stuck supporting a dozen squabbling Ajax toolkits a year from now. Dojo 1.0 may not be the ultimate winner, but it sets clear expectations for what an enterprise-ready Ajax toolkit should be able to do.

*Ajax is an acronym for Asynchronous Javascript And XML (only the acronym Self-Contained Underwater Breathing Aparatus can approach Ajax in shear implausibility).

Labels: AJAX, DOJO, Ext, Flex, JQuery, OpenAjax, Silverlight

Infoworld recently announced a new Ajax tool for Eclipse, called , RAP. While this is a logical step forward for the Eclipse community, it is an evolutionary dead-end from a Web 2.0 viewpoint.

The goal of enterprise Web 2.0 is to democratize the development of web applications by lowering the learning curve. Enhancing Eclipse does nothing to solve the fundamental skills gap between the Java "high priests" and the traditional application developers who are skilled in visual tools like Access and PowerBuilder.

Eclipse is the heavyweight champion of the heads-down Java server programming world. Ajax is the lightweight champion of the rich internet client world. These are clearly different tasks, so presumably would benefit from using different tools. Other than masochism, why would someone decide to saw logs with a hammer?

Given the cost and difficulty of hiring Java developers, putting them into the UI design role is a waste of resources. In addition, the skills that make a developer good at server programming do not necessarily translate into web page layout skills.

At ActiveGrid, our goal is to enable application developers to assemble web applications visually without needing deep technical skills in Java, Javascript, css, etc. This vision requires two components:

1. Studio for lightweight page assembly: Web 2.0 application developers need a visual and lightweight tool for assembling web pages - they need a DreamWeaver for Ajax.


2. Java server framework for seamless services integration: the web pages created by a Web 2.0 application developer should integrate seamlessly with a standard Java back end using something Json/Spring/Hibernate server.

While Ajax for Eclipse represents an incremental step forward, it is not at all clear that this is the best way to build Ajax clients. We are betting that the right tools for building Web 2.0 applications will unlock a wave of developer productivity within the enterprise equivalent to what simple blogging tools have done for web publishing.

Labels: AJAX, Eclipse, RAP

Over the next few months, almost everything about the company-currently-know-as-ActiveGrid will undergo dramatic transformation. We are announcing the first step in this transformation on Monday with our acquisition of a top Dojo tool provider, TurboAjax.

TurboAjax brings an incredibly cool Dojo widget builder and equally talented developers into ActiveGrid. We first saw their products on July 26 and had a signed Letter of Intent exactly one week later - probably a land speed record for software acquisitions!

This acquisition also lands us at the center of the Dojo community of AJAX developers. Why Dojo? Well, we are targeting the enterprise, where internationalization and security are critical. We believe Dojo is creating the best UI toolkit for enterprise developers.

Earlier this week I waxed eloquent on the flaws in proprietary non-AJAX solutions like Silverlight, Flex and JavaFX. However it is also fair to point out that there are many challenges within the open source AJAX community as well, including:

• Lack of commercial support: without the availability of commercial support, AJAX will not achieve enterprise adoption. With this acquisition, ActiveGrid will now stand behind both the TurboAjax products and the Dojo Toolkit.


• Missing features: common complaints around the Dojo toolkit include lack of complete documentation and robust samples. If AJAX toolkits are to be adopted, they need the same polish as proprietary solutions like Flex.


• Inconsistent standards: as the saying goes, the nice thing about AJAX standards is that there are so many to choose from. There is an alphabet soup of Javascript libraries out there, including JQuery, Prototype, Rico, Scriptaculous, Ext and YUI. Each of these takes a very different approach to solving the same problem.


• Security: don't even get me started on the security challenges in an environment full of widgets, gadgets and 3rd party web services. Suffice it to say that when this rock gets turned over, lots of ugly stuff creepy-crawly things will slither out.

The AJAX world needs a RedHat to create a common distribution and provide commercial support and training behind an enterprise-ready toolkit. With our TurboAjax acquisition, ActiveGrid is taking an important first step down this path. Stay tuned for our next move!

Labels: AJAX, DOJO, Ext, JQuery, Prototype, YUI

David Precopio recently blogged here about Portals, wikis and other transitory technical phenomena. In 2000, portals represented a vision for how a new, user-driven web was going to develop - one which paradoxically required lots of new proprietary software and teams of developers.

Shortly after 2000, application server vendors looking for a way to boost sagging license revenues (what do you mean we can't charge a premium for a commodity J2EE product?!) glommed onto portals as a handy revenue extender/floor wax. They immediately shifted into high gear, selling the whitening and brightening qualities of their "collaborative" web products.

Into the middle of all this crept the real collaborative web products. Using social media as their proving ground, they pioneered user generated content, interactive UIs (remember those nice client/server UIs - they're back as AJAX) and web services (remember those nice objects - they're back as services).

We met a company recently that referred to their 20 person portal project as "our latest boat anchor." Portals are just the latest example that technology vendors often have the right idea about what the future needs but too often try to implement the tools of the future from the worn out components of their past successes.

Labels: AJAX, David Precopio, j2ee, portal, Web 2.0