Microsoft Eats Its Young: AjaxPro is no more
Back when .NET didn’t have an Ajax pot to piss in, I voraciously read Michael Schwarz’s blog and followed his Ajax.NET framework. He eventually released a companion "Pro" version. Now, several Microsoft MVP awards later, he is packing it in. I, for one, will miss the competition in the .NET world. That leaves two major alternatives that I’m aware of:
Since the concepts around how Ajax apps should be built are still in flux, it would be nice to have a few alternatives in the .NET world (especially ones that don’t produce the XHR salad that ASP.NET Ajax does).
Technorati Tags: ajax, .net, ajaxpro.net, gaia widgets, anthem.net
Echo3 Custom Components Coming into Focus
I had a read of some of the Echo3 developer docs this weekend. In particular, the docs on how to create a custom component were very interesting. If you’ve read the custom component docs for Echo2, you know how messy that was. This time around it looks a little cleaner. There are basically three different object hierarchies:
- The client-side JavaScript components, extended from
EchoApp.Component. - Their corresponding client-side JavaScript synchronization peers, extended from
EchoRender.ComponentSync, which deal with manipulating the DOM hierarchy. - The corresponding server-side Java synchronization peers, extended from the convenience
nextapp.echo.webcontainer.AbstractComponentSync, which handles synchronization between the client-side and server-side component. - The server-side Java component.
The docs aren’t quite done yet, but already it looks as if component writers can leverage the framework much more than in Echo2. It’s good to see that event handler hygiene is encouraged in the docs.
Powered by ScribeFire.
New Year's Resolutions 2008
As I’ve posted before, I’m pretty leery of prognostication. My colleageus Noel and Dietrich have already made their predictions for 2008, anyway (here and here) so who am I to join the fray? Instead, let me dust off another hoary device and share my programming resolutions for 2008.
Read more »Ajax Predictions for 2008
I’m a little early this year for my 2008 predictions. No matter. I seem to have been a bit early with my 2007 predictions as well, and as they say in the venture capital biz, “too early is the same thing as wrong.” Some of my predictions did come true — Ajax is no longer such a big buzzword; a number of framework specific books (GWT, jQuery) have been published at the end of 2007; Microsoft’s Ajax stack continues to limp behind the rest. A few others did not, notably the ho-hum release of IE7 and the delay in FF3. So, let me try my hand at some more prognostication:
- Elegant, good looking frameworks like Ext and myGWT will gain traction. The more out-of-the-box good looks you can give them with CSS and bundle images and icons, the more acceptance they will gain.
- The JavaScript framework chaos will continue. The OpenAjax alliance will continue to be ineffectual in promoting things like widget interchangeability.
- Security will become a big headache, as less sophisticated developers start to venture into the wonderful world of Ajax, littering the web with state and control logic on the client side.
- Towards the end of 2008, FF4 and IE8 will start to change the landscape of Ajax and Web 2.0 with an update of JavaScript and new browser features.
- MS Volta will do nothing. It is just a FUD shot across the bow of GWT.
- Everyone except Craig’s List will have some form of Ajax on their site.
- Desktop RIA’s through Google Gears, Adobe AIR, etc., will start to make an impact in the second half of 2008. Look for desktop/web hybrids of the office productivity tools, such as word processors and Powerpoint clones, to see greater use in the corporate IT space.
- GWT’s compiler will produce more efficient code than 98% of JavaScript developers can do by hand.
- With the new browsers, a cross platform Canvas/SVG will be a reality by the end of the year.
- IE8 will still leak memory like a sieve.
Have any of your own predictions? Feel free to add them in the comments.
Technorati Tags: ajax, 2008 predictions
Eating crow on jQuery
When I was first getting acquainted with jQuery, I blogged about it quite a bit (here, here and here). There was a lot I liked, but I got easily frustrated. Having previous experience with Scriptaculous, I found the built-in effects features and even the Interface plugin a little under-featured. In particular, the lack of fine-grained queue control bothered me. I also struggled at first with jQuery’s lack of built-in object and class factories. I engaged in back-and-forth with jQuery team members about my posts. Then I moved on to other projects.
Recently, however, I returned to jQuery for Ajax Overhaul, my upcoming series of tutorials for IBM developerWorks. Ajax Overhaul tackles how to improve the user experience of dusty pre-Ajax applications with unobtrusive JavaScript. My series shows how to install lightboxes, modal dialogues, form validation and other Ajax goodies with minimal changes to server-side infrastructure. It was therefore imperative that I use a toolkit engineered from the ground up for progressive enhancement. Naturally, I thought of jQuery.
In the process of writing the first couple of installments, I discovered the not-so-secret ingredient to jQuery’s success: the plugin ecosystem. By officially sanctioning a broad range of plugins and providing hosting, support and PR for mature plugin libraries, the jQuery team has galvanized a really impressive developer community. So far in my writing for the IBM site, I’ve used Greybox, Thickbox, jTip and jQuery Forms – all really fantastic tools that empower even novice Ajax programmers to do really cool things with very little custom code and 100% adherence to progressive enhancement.
As long as plugin authors follow the rules, their libraries offer the same compatibility as the core jQuery distribution. (See this post, including comments, for details on how to write plugins that don’t create namespace collisions.) My only gripe with the plugin landscape is that it’s so scattered. Despite the availability of hosting on the jQuery servers, lots of plugin authors opt to host their own sites. There’s no one-stop shop like the one for, say, Firefox.
I still haven’t found a good plugin for managing classes, mix-ins and other inheritance schemes, but just by typing that I’m sure I’ll get comments to the contrary. Regardless, it’s easy to use jQuery alongside, say, MooTools.
As for my desire for fine-grained control of jQuery’s effects queues, all it took was one enterprising plugin author. jQuery team member Rey Bango pinged me a few months ago about developments on this front, and now the code is live. I haven’t yet worked with Luciano G. Panaro’s Fx Queues plugin, but at first glance it looks like exactly what I need. As Really Simple History matures, I’m looking to get involved in other open-source projects. Contributing to the jQuery ecosystem is at the top of my list.
Technorati Tags
Blogging from the GWT Conference: GWT as a Replacement for Java Swing Apps
Just here a short while and I’ve already heard some interesting notions from some hardware vendors (SANS, Firewalls, etc.) about how GWT might be the key to solving their deployment problems. Right now, many of them use Java (write once, run anyware, etc.) to write the desktop administration applications that manage their hardware. But Java is not trivial to package up and deploy for different OS’s. Many of these vendors seems to be considering GWT as an alternative, i.e. you get the RIA experience without having to deploy anything past a browser on the client.
More evidence that the browser is being viewed as an application platform, i.e. an operating system.
All guns blazing on Ext JS 2.0
The day has finally arrived: Ext JS 2.0 received its final public release today. Judging by the timeouts I’ve been getting all morning when trying to connect to the Ext site and blog, I’m not the only one who’s been waiting anxiously. Originally tied to the YUI framework but now a standalone library, Ext provides the best example I’ve yet seen of a completely client-side framework for desktop-style RIAs.
As Ajax libraries multiply, they need to differentiate themselves to get my attention. Ext does just that, providing a top-to-tails solution for GUI components: tabs, trees, grids, you name it. Prototype, jQuery, Mootools and Dojo provide powerful general-purpose tools for Ajax development. Ext, on the other hand, uses a component model whose baseline configuration gets you 90% of the way there and whose extensibility gets you the rest of the way. It’s a huge achievement that Ext does so while embracing Web standards and user experience design. You don’t use Ext to sprinkle a little Ajax on your Web 1.0 application; you use it to build powerful, data-centric applications from the ground up without relying on GWT or .Net to write your JavaScript for you.
For the example application I’m building to show off Really Simple History, I’m constructing parallel versions with Prototype, jQuery and Ext. Frankly, it’s the Ext version that I’m most excited to show off. I’ve been waiting patiently for a couple of months to find a hole in the schedule of busy Ext creator Jack Slocum. Now that Ext 2.0 is out there, I hope to publish an interview with him in this space soon.
With the Ext servers struggling to meet demand, you may have trouble trying to download the library, read the announcement or peruse the completely overhauled documentation. In the meantime, you can read this exhaustive Ajaxian post about all of the changes and new capabilities.
Technorati Tags
JRails: Scriptaculous on top of JQuery
Prototype and Scriptaculous had their origins in Ruby on Rails before spinning off. There they went head to head with the lighter, leaner JQuery. Now the circle is complete, with Scriptaculous functionality on top of JQuery making its way back into RoR in the form of JRails.
jRails is a drop-in jQuery replacement for Prototype/script.aculo.us on Rails. Using jRails, you can get all of the same default Rails helpers for javascript functionality using the lighter jQuery library.
This is certainly good news for folks who do a fair bit of mashing up. Combining two sites or services, one of which uses Prototype and the other JQuery, can be a bit painful.
Technorati Tags: ajax, prototype, scriptaculous, jquery, ruby on rails
Eating Some Crow on ThinWire
OK, so I was wrong in ThinWire. The issues around having to position and size components is obviated through the existence of two layout managers — SplitLayout and TableLayout. These layout managers calculate size and positioning for you (and override any values you may have explicitly set). They certainly make developing in ThinWire much less tedious than I previously thought. For an excerpt of the ThinWire handbook that discusses the two layout managers, see here.
For more sophisticated or fine grained layouts, you’ll likely want to develop your own layout managers. I’ll officially remove ThinWire from my list of 2007 Ajax Turkeys.