The big news today was about Google Chrome. Chrome is web browser built by Google based on Webkit that is going to be their way of finally killing off Microsoft. They actually created an online comic book to explain why they created Chrome and the technology behind it.

What makes Chrome special compared to Safari or Firefox is their JavaScript VM called V8. The V8 JavaScript engine provides JIT compilation of JavaScript code, so your JavaScript RIA applications run with blazing speed. ExtJS is incredibly fast in Chrome. Another awesome feature is the ability to create a shortcut to a page that actually is an application link. For example, here is Chrome viewing the ExtJS API documentation:

Notice the window decoration with tabs, navigation, etc… Selecting the Create Application Shortcuts option will create a Start Menu, Desktop and/or Quicklaunch shortcut to the page you are viewing. Opening the shortcut opens the page as a pseudo-application, like this:

This creates a kiosk-mode view, without navigation. This web page of documentation is now essentially a standalone application. Google obviously intends Chrome to be the primary client-side hosting environment for its web-based application suite. This is also really good news for folks using JavaScript for RIAs. With the V8 JavaScript VM, you can have JavaScript performance on par with what a plug-in can do, and thus don’t need the plug-ins.

When Chrome goes final, I don’t see why anyone would not want to use it. It is extremely fast, with a clean UI and will completely change peoples perspectives on web-based productivity software. ExtJS becomes stunning in Chrome, and I’d actually bet that Google buys ExtJS to use it as their main JavaScript library. The only question becomes Google motivations. Will they “not be evil” or will Chrome turn into adware/spyware. Time will tell, but I’ll be using it until I think it is evil

So I had to ditch my PHP mistress for a bit and come back to the real world. I spoke tonight at the Spring Dallas User Group, giving a presentation on the ExtJS JavaScript library and integration with Spring MVC. We had close to 20 people in attendance, which was more then I expected given the short notice.

Erik Weibust and I had discussed me presenting to the group several months ago. I orginally planned to present in July, but vacation plans got in the way of the meeting date. In the interim, quite a bit happened in the ExtJS world. The fallout from the change to GPL from LGPL had simmered down, and they released a new version.

The presentation went well. Some folks had worked with ExtJS while others were learning about it for the first time. In spite of the turmoil from the license change, I’m still very excited about it. The 2.2 release added some cool stuff and I’m looking forward to digging in to it on a project.

For those in attendance, or the simply curious, I’ve attached the presentation, sample project and my own Spring JsonView implementation. Note that for the sample project, you will need to download the ExtJS distribution yourself and place the contents of it in the web/resources/ext directory. I didn’t want to redistribute ExtJS in my sample.

ExtJS Presentation

ExtJS/Spring Demo Project

Custom JsonView Project

We finally started a somewhat meaty RIA-ish project at work. My original intent was to use ExtJS for the bling, but it wasn’t through the corporate approval process and the available themes didn’t match the desired corporate color scheme. So instead of ExtJS, we’re using JQuery UI 1.5.

So far, I’ve been extremely impressed. It does not have near the number of UI widgets that ExtJS has, but I haven’t needed them for this web project. One of the most impressive things about JQuery UI is how easy it is to theme. Some silly-smart folks over at Filament Group created an on-line theming engine for JQuery UI called ThemeRoller. With ThemeRoller, I can specify the RGB values to exactly match the desired corporate color scheme and even add some cool effects. There is also a great blog post on how to use the ThemeRoller theme to create your own components.

I still like ExtJS, but I think JQuery and JQuery UI are really starting to get a lot of traction. The ability to create custom tailored themes is pretty huge for corporate and custom development, and right now, JQuery has the leg up on ExtJS in this space.

I attended my first ever meeting of the Spring Dallas User Group on Wednesday. They had Keith Donald from SpringSource speak about the new Spring WebFlow 2.

Although my team uses the Spring Framework for all the projects, I’ve always had mixed feelings about Spring because I am not a fan of XML configuration. But the Spring Framework 2.5, with annotation-driven bean wiring has really started to change my opinion. I had similar feelings for Web Flow, but the v2 has definitely improved things. While I’m still not that excited about the core Web Flow state engine, they introduced Spring JS (JavaScript), which was very exciting.

Spring JS provide a JavaScript library for decorating pages so that you can add rich widgets for RIA-goodness but still have the page degrade gracefully in less sophisticated browsers. The original version was based around my favorite ExtJS library, but they changed to Dojo when the ExtJS guys shot themselves in the foot with the license change to GPL. This reinforces my opinion that ExtJS really screwed the pooch. They had the chance to be associated with the best Java framework out there, and lost it.

The user group meeting was very interesting and it was a great group of people. Since one of the organizers is a friend of mine, I’m even going to be the guest speaker in July talking about ExtJS and Spring. I’ll share more on how that goes as the presentation starts to take form.

Apple Insider is running a very interesting series of articles about Adobe Flash and its future. The first article in the Flash Wars series covered the history of Flash. The second part jumps in to all the hurdles and competitors Flash faces, from Microsoft to Apple.

I sat in on most the Flex track at Dallas TechFest, and it is an interesting technology. But I also share the same opinion as the author of the AppleInsider artice — Flash/Flex has a rough road ahead of it. One of the biggest points that I think a lot of folks won’t notice in the article is the suggestion that open standards are a competitor to Flex. By open standards, they mean Ajax, JavaScript, CSS and HTML. I reached the same conclusing after playing with some of the first-rate JavaScript libraries out there like JQuery and ExtJS.

ExtJS, in particular, can do about everything Flex can do, and do it without a browser plug-in. It also has APIs around the non-visual aspect of applications that put Flex to shame. Although ExtJS has licensing issues which I’ve griped about before, if you accept it at face value as a commercial product, it really is the best thing going right now for building RIAs.

I have never really cared about the GNU General Public License much before. I always regarded it as the license of choice for the real open source zealots and actively steered clear of it based on its viral nature. All the Java open source tools I care about are released under much less-restrictive, user-friendly license like the Apache Software License or variants of the MIT/BSD licenses. But that all changed this week when my favorite JavaScript library, ExtJS, changed their license to GPL v3.

I have been tinkering with ExtJS for a month now, and have really fallen in love with it. You’ll never want to code an html table again once you’ve worked with ExtJS. The library had been dual-licensed as LGPL or commercial. LGPL is much less restrictive than GPL, and it drew a lot of folks in to ExtJS. Without warning, on Monday, the license for ExtJS was changed to regular GPL in a point release. To say the community around ExtJS is a bit agitated would be an understatement.

This change has actually caused me to rethink my opinions about the GPL. I considered it a viral license before, based on the fact it infects everything it touches. Most other professional software developers share the same opinion. But now, seeing what it has done to ExtJS in less than a week, I have decided the GPL is a cancerous license – it doesn’t just infect the host, it kills it.

ExtJS got mindshare by having the LGPL license. Developers were willing to try it, evangelize it, and participate in the community. They felt a sense of ownership in contributing to it and helping the new users on the forums. The surprise change has destroyed that goodwill and the new license makes it very difficult for anyone to take an interest in it. Most companies are strongly anti-GPL, for good reason, so corporate developers won’t be allowed to play with it. And no company is going to go out and buy commercial licenses on blind faith with such a small, unproven software shop.

Now that ExtJS is licensed as GPL instead of LGPL, I expect to see the community evaporate. That leaves ExtJS competing as a purely commercial endeavor against the likes of Microsoft Silverlight and Adobe Flex. The customer-business relationship will be a lot harsher for ExtJS than one of a community-supported open source project. They will become slaves to their biggest clients, effectively ignoring the community that got them the mindshare to begin with.

I can appreciate the ExtJS folks wanting to make money with the work they have done. The dream job of every software developer is to be paid well to work with the technologies you enjoy. But switching to GPL was the wrong way to approach it. Like cancer, the GPL is going to kill the host.

In the past decade, enterprise software development has gone through a major paradigm shift. This shift was the introduction of middleware, a.k.a application servers. The objective of the application server was to break the client-server model and move logic into a middle tier where the application logic could be cleanly broken down into discreet, testable layers implemented with object oriented languages. This push to application servers was driven both by the acceptance of object oriented programming and by vendors eager to make boat loads of money selling their middleware to businesses.

One of the side effects of the push to middleware was that databases no longer mattered. The goal of middleware was to abstract out the database. The thinking was that you designed a clean domain model at the middle tier, and various ORM technologies would map that to your database. Developers, in theory, no longer had to be experts in SQL, DDL, stored procedures and indexes. Application servers were going to save us from all this, turning databases into nothing more than data sources.

Another effect of application servers was the introduction of server controls, or widgets, used to help generate HTML views in the MVC pattern. Examples include tag libraries, JSF and JSTL. The application server would generate the entire view and return the complete HTML document to the browser to be rendered to the client. Applications servers were just reinforcing a similar layer of abstraction at the other end of the stack. Browsers were simply windows into the views being generated in the middle tier.

And then came AJAX. Suddenly, through the magic of web services, JavaScript and the XMLHttpRequest object, the browser proved it could be more than a simple rendering engine for HTML documents generated by the application server. The browser itself proved to be a rich application development environment that could be dynamically updated without making expensive round trips to the server to get full HTML documents. This acceptance of the browser as a platform in its own right is causing another paradigm shift that is going to do to middleware what middleware did to the database – render it irrelevant.

The future of web application development will center around JavaScript and the browser, not on application servers. Browsers will make AJAX requests for JSON data back to services, and no one is going to care how those services are provided. In the same way the application server really didn’t care about the underlying database, the next-generation browser application is not going to care how the AJAX request is fulfilled.

Good web applications will still implement clean, layered abstraction via MVC, but it will be implemented in JavaScript at the browser level, not in Java or C# in the middle tier. The ExtJS library is the best example so far of what the future is going to look like. Other possibilities include Adobe’s Flex and Microsoft’s Silverlight, but both these require plug-ins which the pure JavaScript solution doesn’t need.

It is entirely possible that application servers go the way of the dodo, being supplanted by simpler tools which handle AJAX requests. Web servers will serve the basic content (html, js, css) to the browser, which will then make the AJAX requests to populate the model of the application.

A side effect of all this will be the death of XML used for intra-application communication, to be replaced by JSON. This can’t happen soon enough. I have seen way too many applications use XML internally to pass data around. XML web services were designed for tying together heterogeneous processes across system boundaries and are not an efficient protocol to be used inside a homogeneous system. Unfortunately, developers got “high on XML,” which led us to the mess we have today of trying to use XML Web Services for everything. JSON will kill this silliness through its terseness, performance and ease of use within the JavaScript application layer.

Another possible side effect of the marginalization of application servers and middleware is that databases could start to matter again. I would expect that a smart database vendor will implement connectivity directly via JSON, in the same way they provide JDBC or ODBC connectivity today. The browser will send AJAX requests directly to the database server, which will return a JSON-encoded resultset. Expect to see standardization around what the database JSON request/result protocol looks like.