The Keene View

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

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

Web 2.0 Expo was last week - 10,000 people attending a trade show for a market that doesn't exist anywhere but in our own minds. As is usual when we let our imaginations run wild, every one of those attendees was looking for something different.

For example, I was on a panel session entitled "Web 2.0 and the Breathing Enterprise" - it was a good session, but darned if I know what a breathing enterprise is, any more than I know what Enterprise 2.0 is.

After the second day, our team was thrilled because we had gotten over 200 leads and given almost 100 product demonstrations in two days. During that same time period, however, we had 4,000 WaveMaker downloads and over 100 new registrations to our WaveMaker community.

I'll take 100 people who have downloaded my product and used it enough to want to be part of my community over 100 tchotchke-seekers any day!

Labels: WaveMaker, Web 2.0 Expo

[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

Web 2.0 apps look all shiny and bright, but we all know what horrors lurk within the typical enterprise IT shop. Web 2.0 will not be able to transform the enterprise until it can deal with real world integration nightmares like CICS systems, flat files accessed through obscure SNA protocols and AS/400s programmed in RPG.

Who is going to tame all this real world IT stuff and bring it into the bright shiny Web 2.0 world? SnapLogic and WaveMaker, that's who!

WaveMaker and SnapLogic announced today a partnership to use SnapLogic's Really Simple Integration platform to wrap any legacy data source as a web service. Once SnapLogic has "tamed the beast", WaveMaker provides a point and click, WYSIWYG development platform to expose legacy systems via rich internet applications.

Although we are performing very different tasks, both SnapLogic and WaveMaker are getting incredible value from creating web service-based products. SnapLogic wraps any data source as a web service, while WaveMaker assembles applications from any collection of web services. Chris Marino of SnapLogic also blogged about our partnership.

The following marketecture diagram shows the power of this approach. Rather than a rat's nest of one-off adapters, replicated data and custom data conversions, there is one clean API to the data - web services - and one simple tool for exposing the web services - WaveMaker!
To demonstrate the power of the rich and thin approach to web 2.0, WaveMaker and SnapLogic will be demonstrating an application at Web 2.0 Expo this week that integrates mainframe, minicomputer and relational data into a simple inventory tracking and re-ordering sytem. Stop by our booths and check it out!

Labels: CICS, Snaplogic, WaveMaker, Web 2.0

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

The next Visual Ajax User Group webinar and meeting will be next Thursday, April 17 at 12 PST. The speakers will be Scott Miles and Steve Orvell. Scott is the module owner for the Dojo Grid and Steve is a core contributor for the Dojo Grid. They will be talking about "Ajax Grids - Taming and Tooling The Widget Beast."

To attend the webinar, send an email to rsvp@visualajax.org

Our last meeting was a lively discussion led by Alex Russell on how to overcome the structural challenges of Ajax entitled, Saving Ourselves from the Unweb.

If you wish to attend in person, the meeting will be at the offices of WaveMaker Software, 301 Howard Street, 22nd Floor

Our next two meeting will feature Ajax experts from two ends of the mashup spectrum:

• May 15 - Stefan Andreasen, CTO, Kapow - Data Enabling the Ajax Mashup
• June 19 - Adam Sah, Architect, Google Gadgets - Ajax-enabled Google - Architecting Google Widgets/Gadgets and Ads

Please let us know if there is a topic or speaker you would like to see in an upcoming meeting by sending email to info@visualajax.org. For more information on the Visual Ajax User Group, click here.

[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

I spoke yesterday with Michael Cote of Redmonk and Ryan Stewart of Adobe (the RIA blog is here, on ZDNet here podcast is here). What follows are some of the highlights of our discussion on the state of the RIA market.

Today, there are two ways to build your first Web 2.0 application:

1. Buy $300 worth of O'Reilly books and kiss the next few weekends goodbye


2. Download WaveMaker and follow the 15 minute tutorial

For anybody but the most hardcore or masochistic tech-heads, this seems like a no-brainer decision.

If Web 2.0 is about putting more power into the hands of end users, that message hasn't hit the Ajax world yet. In general, Rich Internet Applications toolkits from Dojo to Flex are well beyond the reach of anything but the most sophisticated developers (not that I am a particular fan of Flex).

WaveMaker is focused on lowering the price of admission for Web 2.0 application development. WaveMaker provides an easy on ramp to building web applications, allowing non-expert developers to build rich internet AJAX applications

How complicated an application can you build with a visual Ajax tool? Well, we built the WaveMaker studio using WaveMaker, so you can build a very complex application indeed using visual Ajax tools!

What kinds of applications are best for a visual Ajax tool like WaveMaker? We see our community building three kinds of applications:

1. Rich Internet Application prototyping. Business analysts


2. Rapid Application Development using database driven forms generation


3. Face of SOA applications. Assemble rich internet applications by combining web services and data services.

WaveMaker is the PowerBuilder for Web 2.0 - we make it easy for large community of people to get benefits of rich internet applications.

As usual, the bogeyman for all this Rich Internet goodness is Microsoft. The current fragmentation of the Ajax market and related squabbling between toolkits fanboys makes Microsoft's Silverlight solution a much simpler choice for developers.

More importantly, before the introduction of WaveMaker's visual Ajax studio, Microsoft's visual studio was winning over the novice developers by default. It's time for the open source world to provide a compelling and CIO-safe alternative to Silverlight and WaveMaker is just the company to do it!

Labels: ASP.NET, Dojo WaveMaker, Flex, RIA, Rich Internet Application, Silverlight, Visual Ajax

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