The Keene View on Web 2.0, Ajax and SaaS

Labels: AJAX, DOJO, training, tutorial

I attended the JavaOne show this week, after a 4 year gap. What a difference - who knew Java could be so boring? On the other hand, this is what it feels like to go to a show for a technology that has lost half of its market share in the last 4 years (at least when measured by O'Reilly book sales - not a particularly reliable source but better than no source at all). If you don't like that source, check out Andi Gutman's recent post that Java is losing the battle for the modern web.



Let me be clear here - at WaveMaker, we have hitched our wagon to Java and hope very much that JavaOne is showing us the ghost of Java present, not the ghost of Java to come.

Trade shows in general have been eviscerated by the flood of technical information on the web. But even in the new "I'm only here for the Tchotchkes" world of conference attendees, this was a surprisingly desultory affair.

Aisle after aisle was populated almost solely by people in ugly sports shirts wearing a vacant gaze that we all reserve for particularly humiliating situations. In fact, the only booth which seemed to have any mojo was the - you guessed it - schwag booth from Sun.

This morning, I found out what was wrong. I got one of those delightful ALL CAPS emails from JavaOne informing me that we had all been the subject of a viral attack by the dreaded Norovirus. So that was it!

There is something seriously wrong, not just with JavaOne, but with Java. After 10 years, Java remains an extremely complex development environment with nothing even approaching an easy learning curve. Microsoft has gleefully filled this vacuum, driving a vast J2EE to .Net migration at the low end of the market that nobody in the Java world seems willing to acknowledge.

The Sun promise to put Java runtimes everywhere is meaningless if nobody wants to develop for those runtimes. Adobe and Microsoft are doing a far better job making their tools simple enough for mere mortals and focusing on the presentation layer.

The news at the show was that Sun's front end technology, JavaFX, was *still* not ready. The world needs Sun to stand behind one of the 200+ Ajax frameworks already out there, not create yet another one. While we're at it, why can't they just put more effort into an Ajax toolkit they have already "partnered" with, like Dojo?

Here is my prescription for curing the Java Flu:

1. Fight for the low end: in modern warfare, death may come from above. In technology, death comes from below. Ten years from now, who will have more power over IT - web designers or core developers? If Microsoft and Adobe win the designers today, Java developers will be the Cobol developers of tomorrow.
   
2. Make Java easier: something is wrong when very useful but also very complex code frameworks like Spring are considered the "easy" way to do Java development. Java needs to be easy enough for your mother to build her web-based phone list with it. I'm talking Hypercard/Filemaker/Access easy.
3. Make Java prettier: just put a bullet in JavaFX and adopt something with momentum like Dojo or Ext. If you just can't stomach Javascript, then adopt GWT.
4. Make Java fun: can't do this without doing the first three items. For an example of one attempt to make Java easy, check out the WaveMaker download.
   

Remember when people built cool web apps with Java? When was the last time you heard about a cool web app that wasn't written in Rails or PHP? OK, people still build lots of cool stuff in Java, but the love is gone and its just a day job now.

Labels: DOJO, GWT, Java, JavaFX, JavaOne

[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

[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

Of the many sins that Silicon Valley practices, none are more dangerous or prevalent than the sin of smugness.

Savio Rodrigues has a good posting entitled Microsoft will prevail in the face of Freetards. His point is that Microsoft is learning from and adapting to the open-source movement, while the open-source movement is so enamored with "free" that they are not paying enough attention to the total cost of ownership from a customer's perspective.

Let's be clear - the free part of open source is a great innovation and worthy of a few minutes of self-satisfaction. The aftermath of the Y2K bubble was the erection of enormous barriers around IT to prevent tem from trying anything new that would cost the company money.

Free provides a "frictionless" entry point for new technology products into the corporation after finance barred the door. Free also enables technology self-service across the corporation, making it possible for anyone with an internet connection and a geek gene to get as wired as they wanna be.

However, free is only worth so much. If it takes me 3 hours to get my "free" open source download working, it cost me however much I or my boss thinks my time is worth x 3 = not free. Similarly, even if an open source product (for example Dojo) is technically superior in every way to Silverlight, that superiority is of no practical value if it is easy to hire experienced Silverlight developers but next to impossible to find, let alone hire, Dojo developers.

Thinking that free is the only aspect of software that matters is freetarded. This is where Microsoft can beat the open source community in general, just as its .NET platform is beating J2EE.

Let me quote from the insanely great Fake Steve Jobs blog:

Red Hat, the single company freetards always point to when they want to prove that open source can make money, has turned inept, with nothing but bluster and bravado and a deluded belief that they're actually a thorn in Microsoft's paw. Bottom line: they're the new Borland. They're 15 years old and have been publicly traded since 1999 and last year they did all of $400 million a year in sales. Microsoft does more than $1 billion a week. That's right. Red Hat's entire fiscal year is a good three days for Microsoft.

Microsoft is onto us. Time for open source software vendors to think beyond free.

Labels: ASP.NET, DOJO, j2ee, open source, Silverlight

Our engineering team just released version 3.1 of WaveMaker with lots of new goodies, including auto-forms (generate insert and update forms automatically from a database schema) custom widgets (use any Dojo widget, roll your own widget) and application templates (with custom look and feel).

We are also gaining converts to the WaveMaker motto: Make Waves, Not Code!

WaveMaker is an open-source framework for making Java web development quick and easy (kinda like a visual RoR for Java).

Peter Svensson just posted review of WaveMaker that stated:

The WaveMaker IDE has a number of very good features, listed in no particular order;

1. It is Web-based


2. It runs on its own Tomcat-server with a massive supporting act (the download is ~90MB!)


3. It's fully open-source under the GPL.


4. It uses Dojo 1.0 components, so you create your page(s) visually.


5. Complex components like Tree or (above mentioned) Grid can be connected to services on the server


6. You can create services inside the IDE; WSDL, Database Queries or custom Java code.


7. It generates generic WAR archives, for crying out loud!

Peter has also given us a good deal of constructive feedback on how to make Wavemaker even better. WaveMaker is democratizing Java web development, one Swedish blogger at a time ;-)

Our 3.1 release has also been picked up by Ajaxian, eBiz, AjaxWorld and TechFunk.

Labels: DOJO, Java FX, Peter Svensson, WaveMaker, WSDL

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

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