Raible Designs

JavaScript and CSS Concatenation with wro4j

This past weekend, I decided it was about time to fix my YSlow score on this site. I did the easiest thing first by moving all my JavaScript files to the bottom of each page. Then I turned on GZip compression using Roller's built-in CompressionFilter. These changes helped, but the most glaring problem continued to be too many requests. To solve this, I turned to wro4j (as recommended on Twitter) to concatenate my JS and CSS files into one.

I have to say, I'm very happy with the results. I'm now sitting at a YSlow (V2) score of 75; 90 if I use the "Small Site or Blog" ruleset. I believe I can improve this by adding expires headers to my images, js and css. More than anything, I'm impressed with wro4j, its great support and easy setup. I was looking for a runtime solution (b/c I didn't want to have to rebuild Roller) and it seems to be perfect for the job. Furthermore, wro4j minifies everything on the fly and they'll have an expires header filter in the next release.

JAWR and the YUI Compressor are other alternatives to this filter, but I'm currently sold on wro4j. First of all, it passed the 10-minute test. Secondly, it didn't require me to modify Roller's build system.

At this point, if I'm going to implement JS/CSS concatenation and minification in AppFuse and Roller, wro4j seems like the best option. If you disagree, I'd love to hear your reasoning.

TIP: See Javascript Compression in Nexus for information on using YUI Compressor with Maven.

Consulting, SOFEA, Grails and GWT at next week's Denver JUG

Next Wednesday, I'll be at Denver's JUG meeting to talk about Independent Consulting and Building SOFEA Applications with Grails and GWT. The first talk will be a a panel discussion among local independent consultants, including James Goodwill, Matthew McCullough, Tim Berglund and myself.

This session explores the trials and tribulations of an independent consultant. How do you find contracts? Should you setup an LLC, an S-Corp or just be a sole proprietorship? What about health insurance and benefits? Are recruiters helpful or hurtful? Learn lots of tips and tricks to get your dream job and your ideal lifestyle.

The Grails and GWT talk is a preview of a talk I'll be doing at the Rich Web Experience in December. Below is a rewrite of the abstract in first-person.

Earlier this year, I participated in a major enhancement of a high-traffic well-known internet site. The company wanted us to quickly re-architect their site and use a modern Ajax framework to do it with. An Ajax Framework evaluation was done to help the team choose the best framework for their skillset. The application was built with a SOFEA architecture using GWT on the frontend and Grails/REST on the backend.

This talk will cover how Bryan Noll, Scott Nicholls, James Goodwill and I came to choose GWT and Grails, as well as stumbling blocks we encountered along the way. In addition, we'll explore many topics such as raw GWT vs. GXT/SmartGWT, the Maven GWT Plugin, modularizing your code, multiple EntryPoints, MVP, integration testing and JSON parsing with Overlay Types.

If you're in Denver next Wednesday night (November 11th), you should stop by the Denver JUG meeting. It'll be a fun night and there's sure to be a few beers afterward.

What would you like to see at TSSJS 2010?

A couple months ago, I was asked by TheServerSide to speak at next year's TheServerSide Java Symposium in Las Vegas. In addition, they asked me to help them evaluate presentation proposals and suggest topics/speakers.

First of all, I think the biggest thing that TSSJS could do to improve is to host more networking events. With the JavaOne Party being over, I think there's a tremendous opportunity to fill a gap in the networking needs of the Java Community. When I first attended TSSJS in 2006, there were a fair amount of parties and everyone got to interact quite a bit. In 2008, there were no networking events. I believe having a strong networking story would attract a lot more attendees, companies and sponsors.

Secondly, I think it's possible that TSSJS has too many server-side related sessions. IMO, the server-side (and middleware in general) isn't that exciting. TechTarget appears to own TheClientSide, so why not add some more client-side stuff to the mix? For example, I'd love to see a Struts 1 app-makeover using different technologies (for example, Flex, GWT and jQuery). I think HTML5 and Google Wave's Architecture sessions would be interesting too. If adding client-side sessions is too far away from TheServerSide, maybe it should be renamed to TheServerSide JVM Symposium and there can be all kinds of sessions on JVM languages (e.g. Scala, JRuby, Groovy) and all the great things those languages can accomplish.

Lastly, I've been asked to send a couple session proposals. Currently, I'm thinking about a doing GWT vs. Flex Smackdown with James Ward, but I'm open to other ideas. It's been quite awhile since I did a "Comparing Web Frameworks" talk. Maybe "Hot Web Frameworks for 2010" is more appropriate? I also think it'd be interesting to do a somewhat philosophical talk on "The State of Web Frameworks" and where we're headed in the next year.

What would make you want to attend TSSJS next year? Let me know your thoughts and I'll do my best to make them a reality.

Update October 22, 2009: Whoo hoo! It looks like TheClientSide will be a part of TSSJS Vegas next year. Should be a great show.

Creating a Facebook-style Autocomplete with GWT

Have you used the "To:" widget on on Facebook or LinkedIn when composing a message? It's an autocompleter that looks up contact names and displays them as you type. It looks like a normal textbox (a.k.a. <input type="text">), but wraps the contact name to allow you to easily delete it. Here's a screenshot of what Facebook's widget looks like.

Last week, I was asked to create a similar widget with GWT. After searching the web and not finding much, I decided to try writing my own. The best example I found on how to create this widget was from James Smith's Tokenizing Autocomplete jQuery Plugin. I used its demo to help me learn how the DOM changed after you selected a contact.

GWT's SelectBox allows you to easily create an autocompleter. However, it doesn't have support for multiple values (for example, a comma-delimited list). The good news is it's not difficult to add this functionality using Viktor Zaprudnev's HowTo. Another feature you might want in a SelectBox is to populate it with POJOs. GWT SuggestBox backed by DTO Model is a good blog post that shows how to do this.

Back to the Facebook Autocompleter. To demonstrate how to create this widget in GWT, I put together a simple application. You can view the demo or download it. The meat of this example is in an InputListWidget. After looking at the jQuery example, I learned the widget was a <div> with a unordered list (<ul>). It starts out looking like this:

<ul class="token-input-list-facebook">
    <li class="token-input-input-token-facebook">
        <input type="text" style="outline-color: -moz-use-text-color; outline-style: none; outline-width: medium;"/>
    </li>
</ul>

I did this in GWT using custom BulletList and ListItem widgets (contained in the download).

final BulletList list = new BulletList();
list.setStyleName("token-input-list-facebook");

final ListItem item = new ListItem();
item.setStyleName("token-input-input-token-facebook");

final TextBox itemBox = new TextBox();
itemBox.getElement().setAttribute("style", 
        "outline-color: -moz-use-text-color; outline-style: none; outline-width: medium;");

final SuggestBox box = new SuggestBox(getSuggestions(), itemBox);
box.getElement().setId("suggestion_box");

item.add(box);
list.add(item);

After tabbing off the input, I noticed that it was removed and replaced with a <p> around the value and a <span> to show the "x" to delete it. After adding a couple items, the HTML is as follows:

<ul class="token-input-list-facebook">
    <li class="token-input-token-facebook">
        <p>What's New Scooby-Doo?</p>
        <span class="token-input-delete-token-facebook">x</span>
    </li>
    <li class="token-input-token-facebook">
        <p>Fear Factor</p>
        <span class="token-input-delete-token-facebook">x</span>
     </li>
     <li class="token-input-input-token-facebook">
         <input type="text" style="outline-color: -moz-use-text-color; outline-style: none; outline-width: medium;"/>
     </li>
</ul>

To do this, I created a deselectItem() method that triggers the DOM transformation.

private void deselectItem(final TextBox itemBox, final BulletList list) {
    if (itemBox.getValue() != null && !"".equals(itemBox.getValue().trim())) {
        /** Change to the following structure:
         * <li class="token-input-token-facebook">
         * <p>What's New Scooby-Doo?</p>
         * <span class="token-input-delete-token-facebook">x</span>
         * </li>
         */

        final ListItem displayItem = new ListItem();
        displayItem.setStyleName("token-input-token-facebook");
        Paragraph p = new Paragraph(itemBox.getValue());

        displayItem.addClickHandler(new ClickHandler() {
            public void onClick(ClickEvent clickEvent) {
                displayItem.addStyleName("token-input-selected-token-facebook");
            }
        });

        Span span = new Span("x");
        span.addClickHandler(new ClickHandler() {
            public void onClick(ClickEvent clickEvent) {
                list.remove(displayItem);
            }
        });

        displayItem.add(p);
        displayItem.add(span);
        
        list.insert(displayItem, list.getWidgetCount() - 1);
        itemBox.setValue("");
        itemBox.setFocus(true);
    }
}

This method is called after selecting a new item from the SuggestBox:

box.addSelectionHandler(new SelectionHandler<SuggestOracle.Suggestion>() {
    public void onSelection(SelectionEvent selectionEvent) {
        deselectItem(itemBox, list);
    }
});

I also added the ability for you to type in an e-mail address manually and to delete the previous item when you backspace from the input field. Here's the handler that calls deselectItem() and allows deleting with backspace:

// this needs to be on the itemBox rather than box, or backspace will get executed twice
itemBox.addKeyDownHandler(new KeyDownHandler() {
    public void onKeyDown(KeyDownEvent event) {
        if (event.getNativeKeyCode() == KeyCodes.KEY_ENTER) {
            // only allow manual entries with @ signs (assumed email addresses)
            if (itemBox.getValue().contains("@"))
                deselectItem(itemBox, list);
        }
        // handle backspace
        if (event.getNativeKeyCode() == KeyCodes.KEY_BACKSPACE) {
            if ("".equals(itemBox.getValue().trim())) {
                ListItem li = (ListItem) list.getWidget(list.getWidgetCount() - 2);
                Paragraph p = (Paragraph) li.getWidget(0);

                list.remove(li);
                itemBox.setFocus(true);
            }
        }
    }
});

I'm happy with the results, and grateful for the jQuery plugin's CSS. However, it still has one issue that I haven't been able to solve: I'm unable to click on a list item (to select it) and then delete it (with the backspace key). I believe this is because I'm unable to give focus to the list item. Here's the code that highlights the item and you can see the commented-out code that doesn't work.

displayItem.addClickHandler(new ClickHandler() {
    public void onClick(ClickEvent clickEvent) {
        displayItem.addStyleName("token-input-selected-token-facebook");
    }
});

/** TODO: Figure out how to select item and allow deleting with backspace key
displayItem.addKeyDownHandler(new KeyDownHandler() {
    public void onKeyDown(KeyDownEvent event) {
        if (event.getNativeKeyCode() == KeyCodes.KEY_BACKSPACE) {
            list.remove(displayItem);
        }
    }
});
displayItem.addBlurHandler(new BlurHandler() {
    public void onBlur(BlurEvent blurEvent) {
        displayItem.removeStyleName("token-input-selected-token-facebook");
    }
});
*/

If you know of a solution to this issue, please let me know. Feel free to use this widget and improve it as you see fit. I'd love to see this as a native widget in GWT. In the meantime, here's the GWT Facebook-style Autocomplete demo and code.

Ajax Framework Analysis Results

Way back in January, I wrote about how my colleagues and I were evaluating Ajax frameworks to build a SOFEA-style architecture. To make our choice, we used the following process:

1. Choose a short list of frameworks to prototype with.
2. Create an application prototype with each framework.
3. Document findings and create a matrix with important criteria.
4. Create presentation to summarize document.
5. Deliver document, presentation and recommendation.

When I wrote that entry, we had just finished step 2 and were starting step 3. I first wrote this blog post a week later, when we delivered step 5. Here is the comparison and conclusion sections of the analysis document we composed.

Framework Comparison
In order to evaluate the different frameworks against important criteria, we created a matrix with weights and ranks for each framework. This matrix shows how our weighting and rankings lead us to the winner for our project. You can view this matrix online or see below for a summary.

Note: Criteria whose values were identical across all candidates were weighted at zero. Charting capability was weighted at zero b/c we decided to use Flash for this.

This matrix indicates that GWT is the best candidate for our team to develop SOFEA-style applications with. In addition to the matrix, below are graphs that illustrate interesting (and possibly meaningless) statistics about each project.

Conclusion
After working with the various frameworks, we believe that all the frameworks were very good and could be used to write applications with. If all weights are equal, these frameworks were almost even when compared against our evaluation criteria. The graph below illustrates this.

Even after applying the weighted criteria, the evenness doesn't change a whole lot.

Without considering the even or weighted criteria, we believe the decision all comes down to what the developers on the project feel they will be most comfortable with. If you're developing with Dojo or YUI, chances are you're dressing up existing HTML and possibly using progressive enhancement to add more rich functionality. On the other hand, Ext JS and GWT are similar to Swing programming where you build the UI with code (JavaScript for Ext JS, Java for GWT).

The tools available for JavaScript development have gotten increasingly better in recent years. IntelliJ IDEA has a JavaScript Editor that provides many of the same features as its Java editor. Aptana Studio also has excellent support for authoring and debugging JavaScript. However, we believe the Java debugging and authoring support in IDEs is much better. Furthermore, we are more familiar with organizing code in Java projects and feel more comfortable in this development environment.

Based on this evaluation, we believe that GWT is the best framework for our team to develop SOFEA-style applications with.

Flash Forward to Today...
The core GWT library from Google doesn't have a whole lot of widgets, nor do they look good out-of-the-box. So early on, we experimented with two alternative implementations that continue to leverage GWT concepts and tools:

• GXT: a GWT version of Ext JS
• SmartGWT: a GWT version of SmartClient

Unfortunately, over the past few months, we've found that both of these implementations are too heavy for our requirements, mostly because of the file size of the generated JavaScript code. For example, a feature I wrote generated a 275K *.cache.html file using GXT. After determining that was too slow to give users the initial "pop", I re-wrote it without GXT. After a day, we had an application with *.cache.html files of 133K. Yes, that's over a 50% reduction in size!*

Because of these findings, we are proceeding with the core GWT library from Google and adding in new components as needed. It is cool to know you can make a UI "pop" with GWT, as long as you stick to the core - close-to-the-metal - components. For those applications that can afford an initial "loading..." state, I'd definitely recommend looking at GXT and SmartGWT.

* To make refactoring easier, I copied GXT MVC into our source tree and modified all imports.

My Drunk on Software Interview

Back in February, I met up with James Ward and Jon Rose for a Drunk on Software interview. We enjoyed some good beer and had a great conversation about SOFEA, open source and RIA. See larger video here.

Optimizing a GWT Application with Multiple EntryPoints

Building a GWT application is an easy way for Java Developers to write Ajax applications. However, it can be difficult to release a GWT application to production before it's finished. One of the most important things I've learned in Software Development is to get a new application into production as soon as possible. Not only does getting it from dev → qa → prod verify your process works, it also can do a lot to test the viability of the new application.

One of the biggest issues with GWT applications is size. The project I'm working on compiles Java to JavaScript and creates ~570K *.cache.html files (one for each modern browser). These files end up being around 180K gzipped. I believe this is an OK size for an entire application. However, if you're going to release early, release often with GWT, chances are you'll just want to release one feature at a time.

When the first feature was completed on my project, the *.cache.html files were around 300K. Rather than using branches to release to QA and UAT, bug fixes and new features were developed on trunk. Unfortunately, the QA and UAT process took several weeks longer than expected so by the time the feature was ready to release, the *.cache.html files had grown to around ~570K. The reason the file had grown so much was because it included all of the other features.

Earlier this week, while running to a dentist appointment, I thought of a solution to this problem. The basic idea was to optimize the compilation process so only the to-be-released feature was included. Even better, the solution didn't require more modularization. The results:

Before: *.cache.html -> 569K, gzipped 175K
After: *.cache.html -> 314K, gzipped 100K

According to my calculations, that's a 56% reduction in size. How did I do it?

1. Created a new FeatureName.java EntryPoint with only the to-be-released features imported.
2. Created a new FeatureName.gwt.xml that references the new EntryPoint.
3. Copied old (kitchen-sink) EntryPoint.html to FeatureName.html and changed the reference to the nocache.js file.
4. Created a Maven profile that allows using -PFeatureName to build a FeatureName-only module.

One downside to doing things this way is it's possible to create a WAR that has the same name and different features. Surely the Maven Overlords would frown upon this. Since this is just a temporary solution to release features incrementally, I'm not too worried about it. A possible workaround is to create different WAR names when a feature's profile is activated. I believe the true "Maven way" would be to make the "kitchen sink" application into a JAR and have several WAR modules with the different EntryPoints. Seems a bit complicated to me.

Other than this Maven publishing issue, the only other issue I can foresee is keeping the two EntryPoints and HTML files in synch. Then again, the separate files allow a feature to be customized for the release and can be deleted when its no longer needed.

What do you think? Do you know of a better way to compile a GWT application so it only contains certain features?

Ajax: The State of the Art with Dion and Ben

This morning, I added Dion and Ben's talk titled Ajax: The State of the Art. Below are my notes from the event.

Ajax started out as a bunch of hacks. It showed that we could take our web interfaces and do a lot more with them. A hack isn't necessarily a bad thing. Often, they turn into something much more elegant over time. The new browsers have many amazing capabilities that we haven't taken advantage of yet. We've seen discussions on Ajax go from how to do XHR to frameworks and how rich and mature they are. Dojo is great for Enterprise Development (packing system, namespaces). jQuery is well-suited for lightweight developers (PHP). Prototype is fantastic for people who do a lot of JavaScript development and take it very seriously.

Today's Ajax landscape is mature, really rich, and really exciting. Today, Dion and Ben are going to talk about technologies they're really excited about for the future.

Canvas
The building blocks of the web are text, boxes and images. With canvas, it really makes a lot more things possible. You can do bitmap rendering and image manipulation. They're showing a slide with Doom and Mario Kart running. Canvas 3D does true 3D rendering. Firefox and Opera have done prototypes of this. Can you do canvas-type things today in a browser? Yes, if you use Flash or Curl. Dion and Ben are excited about canvas over plugins for the following reasons:

• No start-up delay
• Available on mobile devices today
• Rendering fidelity with browser (especially important for typography)
• No bridges necessary (no marshalling/unmarshalling)
• Not a plug-in

The <canvas> tag originally came from Apple's Dashboard. Dashboard's programming model was in HTML and JavaScript. Dashboard is using WebKit under the covers. Today, canvas support exists in every major browser except for IE. The good news is there are Flash and Silverlight bridges to add support to IE. There's also an ActiveX component that wraps the Firefox implementation and allows it to run in IE.

SVG
Dion and Ben aren't that excited about SVG because it's such a huge spec. We've been struggling with the HTML standard for the last 10 years and the thought of another huge spec for the next 10 years isn't that appealing.

Fast JavaScript
Almost all major browsers have a Fast JavaScript implementation. Chrome has V8, Safari has SquirrelFish Extreme, Firefox has TraceMonkey and Opera has Carakan. This is exciting because of industry trends and how companies are trying to reduce computation cycles in data centers. The more computing that can be put on the client, the better. IE doesn't have anything, but Dion and Ben believe they are working on something.

Web Workers
Interface latency is awful for applications. Jakob Nielsen once said:

0.1 second is about the limit for having the user feel that the system is reacting instantaneously. 1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay.

Anything that takes longer than a tenth of a second should be pushed to a background thread. Unfortunately, there are no threads in the web. Maybe we can add threads to JavaScript? Brendan Eich has said that "Threads suck" and there's very little chance for threads getting into JavaScript. Gears brought Worker Pools and this is going into HTML 5 as Web Workers. You could also use Java applets to do this. With the latest Java Plugin, many of applets' long-standing issues have been solved.

Desktop Integration
The ability to build desktop apps as web apps is very exciting. There's a few technologies that demonstrate this: Fluid, Mozilla Prism, Adobe AIR, Appcelerator Titanium and Gears. The Palm Pre demonstrates the logical extension of this. The Palm Pre uses the web stack as its developer SDK. It's very cool that web developers don't have to learn anything new to become a Palm developer. Desktop integration is exciting especially if we can access desktop applications like email and address book.

The Ajax frameworks that are out there have done a lot to make web development simpler. However, there's still a lot of pain with CSS and cross-browser issues. What if you took canvas and combined it with a sophisticated grid-based layout in JavaScript?

There's a lot of platforms out there: Microsoft Silverlight, Adobe Flash, Apple Cocoa and Sun's JavaFX. The web often isn't considered a platform. Dion and Ben believe there should be an Open Web Platform. The problem right now is there is no central location to find out how to get stuff done. You have to search and find resources from many different locations. Mozilla is putting it's resources into creating an Open Web Platform. This site will consist of 4 different areas:

• Home
• Documentation (for different frameworks, browsers, quirks)
• Dashboard (state of the open web)
• Roadmap (what's going on)

This is not just Mozilla, it's very much a community effort. This is something that Ben and Dion have been working on. But there's something else they've been working on too. They've been talking about all these cool things, but what about an interesting application to test all these technologies?

Bespin
As they looked at code editors, most of them provide awful user experiences. Bespin is the Editor of Your Dreams and contains the following features:

• Accessible from anywhere - any device in any location
• Simple to use, like Textmate (not heavyweight like Eclipse) - an editor, not an IDE
• Wicked Fast - performance, performance, performance
• Rock-solid real-time collaboration, like SubEthaEdit - it just works
• Integrated command-line, like vi - Fun like Quicksilver, social like Ubiquity
• "Self-hosted" environment, like Emacs - For extreme extensibility, but with JavaScript!

For viewing files, they couldn't bring themselves to use a tree. Instead, they developed a file-browsing interface that looks very much like Apple's Finder. Personally, I like Finder, but wish it had Windows Explorer's path bar that allows you to simply type in the path without mouse clicks. Back to the command line. They've done a lot to make things more discoverable so users can easily find the power of the editor.

Bespin could be used to engage developers more with open source projects. Checking out projects, modifying code and creating patches can be a real pain. Bespin could be used to interface with open source projects in the cloud. You could login, modify code and easily patch/build with the click of a button. One other thing they want to do is to have the server do code-analysis as you're developing.

Is it OK to love a software tool? You must love your software tools. What we do as Software Developers is one of the most difficult jobs on the planet. Programmers, like poets, start with a blank slate and create something from nothing. If you don't love your tools, you'll start resenting what you do. If you don't love your tools, it shows in your work. -- Dave Thomas at RubyConf08

Thunderhead
A GUI Toolkit written with canvas and JavaScript. Allows you to do layouts with very little thought. It's a lab experiment that's in progress, stay tuned for more information.

All users care about is the user interface. Dion and Ben believe there's a key to creating compelling user experiences. It all has to do with managing expectations. It's not that different from how you manage relationships in your life. Expectations for movies and games have changes drastically over the years. What used to be the web (animated gifs and awful web pages) has also changed drastically (video of Apple's online store). What was cool with MapQuest got changed drastically with Google Maps. What we have today isn't the end of the game - expectations will continue to change. However, users have different expectations for software.

Alan Cooper has done some interesting work in this area. The software designer needs to focus in on a user's goals. There are basic things you can apply to all users, for instance "sex sells". An example of this is Delicious Library. This application allows you to keep track of things in your home such as books, movies, music and games. They made $500K in 3 months and made $54K the first day, with no advertising.

The quality of any software is determined by the interaction. If the interaction isn't good, it will poison the entire experience. Donald Norman has a good quote: "Attractive things work better". In society, this is often called "Dress for Success".

The Open Web is hear to stay because it has:

• An Easy Programming Model
• Easy Remoting
• Extensive Customization Vectors (e.g. GreaseMonkey)
• Easy Deployment
• Great Widgets
• Great Visual Effects
• Great Mobile Story
• Desktop Integration
• State-of-the-Art Plug-ins

Bespin is a tech preview that they hope to release next week. Thunderhead will be released at the same time.

Conclusion
This was a great talk and easily the most inspiring of the conference. Dion and Ben always do a great job and the sexiness of their presentation made it all the more appealing.

The State of the Web 2009

This afternoon, I attended The State of the Web 2009 at Web Directions North. Below are my notes from this session.

This panel has quite the list of superstars:

• Chris Wilson (Microsoft)
• Dan Connolly (W3C HTML Working Group)
• Mike (TM) Smith (W3C HTML Working Group)
• Lars Erik Bolstad (Opera)
• Scott Fegette (Adobe)
• John Allsopp (Organizer and Style Master Developer)

John is moderating this session and is starting by asking each panelist to speak about what they believe the state of the web is.

Chris Wilson
The future of the web may be as ubiquitous as electricity. Chris has a desktop, two laptops (one 10" NetBook, one is a 13" MacBook) and an iPhone. There's a lot of difference between these devices, especially when it comes to screen size. Chris uses a number of different browsers throughout the day. The web isn't just one browser, it isn't just one platform. He's showing a slide with a browser market share graph from http://www.netapplications.com.

Many different browsers are a reality. Many different devices are a reality. Web builders need to learn to write scalable applications that run across multiple browsers, devices and environments. They need to use progressive functionality and learn the tools they have in CSS and HTML. Semantic structuring helps.

Developers need to learn to live with multiple browsers. Cross-browser interoperability will get better, but it's likely to be an issue forever. Test suites with new specifications are helping. Developers should build for browsers of today and tomorrow.

You should build the applications you want to build and then figure out how how to make them degrade gracefully on the web.

Lars Erik Bolstad
Opera Software has 600 employees in 10 countries. They've been developing Opera and other browsers since 1995. The bulk of what Opera does is based on commercial browser deliveries to OEMs around the world.

Devices, platforms and networks: they come in all shapes and sizes. Only one thing unifies them: The Web. The browser is becoming more and more important on these devices. Users are not satisfied with WAP-based content anymore, they want the same content no matter which device they're using.

Opera Mini does its processing on the server-side. This allows Opera to gather statistics. These stats show that users around the world hit the same top sites on their mobile devices as they do on their desktops. It's a one-to-one match. Opera is seeing tremendous growth in the usage of Opera Mini, both in developed countries and emerging markets.

The point: don't just develop for desktop browsers. The mobile market seems to be growing much faster. The problem is actually more in the hands of browser developers since they have to satisfy the user's desire to see the same content on mobile vs. desktop.

Opera is focusing on advancing core browser technology in three areas:

• Web standards: CSS (webfonts, backgrounds/borders, transitions, transforms), HTML 5 (video/audio, persistent storage, drag and drop) and W3C Geolocation API and "Mobile DOM" API (access to camera, address book, calendars).
• Performance: VEGA (vector graphics-based rendering, hardware acceleration) and CARAKAN (new JavaScript engine, native compilation). For more details, see http://my.opera.com/core.
• Web applications: Standalone web apps, RIAs, Widgets. Gears support and Developer Tools.

Dan Connolly
The web is kinda important these days. It's a big deal. Make a mistake and 300 million dollars go away (see end of last entry about United news). One of the beauties of the web is you can easily participate as an individual. You can report bugs, write articles and be a part of many web standards groups. Most of the other systems in the world don't provide this kind of access.

Dan has been under a rock for the last 5 years working on Semantic Web stuff. Now that he's back in the game, it's incredible how much stuff is going on. He's glad there's JavaScript frameworks so he doesn't have to learn everything. The default security policies in browsers are a little rickety at this point. They allow you to download and run JavaScript from virtually any site. Caja might help to solve this. Dan believes that security will become more important and stricter to protect web users.

Scott Fegette
Scott is a Product Manager in the Web Group of Adobe. At the beginning of each year, they do heavy user research. Adobe wants people that develop content for the web to be as expressive as possible. Scott is going to give us a peak into the conversations he's had with the web community.

One of the biggest topics on people's minds is The Economy, but it's not negative as you might think. Small web designers are actually getting more business in the downturn, likely because companies are polishing their presence on the web. People are working much more distributed these days. There's a few areas that Adobe generally asks about: CSS, JavaScript, HTML (both statically and dynamically).

Frameworks are becoming more important to developers, as well as with clients. They've even seen some clients demand certain frameworks. Two years ago, when Adobe talked to small design shops and agencies, most web sites were built statically. Now they're developing with frameworks like WordPress. Out of 60 folks they talked to, only 2 were using static systems and not CMSes.

In the JavaScript frameworks arena, jQuery is the dominant leader. Shops are starting to use CSS frameworks as well. The only one Scott mentioned was Reset. Design is becoming a technical discipline and Adobe is calling this Stateful Design. WYSIWIG is definitely dying and designers aren't developing with visual tools.

The kind of projects that people are working on has changed a lot. Many shops are being asked to do work on mobile development. The iPhone has done wonders for the industry in raising the awareness of what a mobile device can do.

The other big investments for Adobe is RIAs and AIR. Ajax has matured enough that it can now compete with proprietary plugins like Flash. The reason for AIR is to allow web developers to use their skills to develop desktop applications. Flash and Flex are often overkill for browser-based applications, but they do often handle video and audio better than Ajax applications.

Mike (TM) Smith
Mike is also known as the "W3C HTML jackass". Mike thinks the state of the web is that it's a mess in a lot of ways. If you don't believe him, ask Doug Crockford. Most of this stuff is going to remain a mess for the next 20 years, unless another genius like Tim Berners-Lee comes along and invents something new. However, the good part about it being a mess is that we all have jobs.

One of the biggest things they're trying to do with HTML 5 is not breaking backward compatibility. Other working groups at the W3C don't share this philosophy, hence the reason they don't have browser vendors participating. Many of the ideas for HTML 5 game from Gears and Ajax Framework developers like John Resig. All this will make things less messy, especially with the help of browser vendors.

Developers like the ubiquitous web and are pushing the mobile web. Mike thinks everyone just needs to get a life (big applause). For mobile, SVG has already been a big success. You will see significant great things with SVN happen in major browsers by next fall. If you're a web developer, you should spend some time experiment with SVG. It will payoff for you. If it doesn't pay off for you and you see Mike next year at Web Directions North, you can punch him in the face.

Location-aware applications will be big as well. Browser vendors are implementing the Geo Location API. It's implemented in Opera, Firefox, WebKit and Gears. Video on the web will be significant as well. The SVG working group pioneered video support into standards, before HTML 5. Many of the problems they face are related to video codecs. The only way to solve the problems with video on the web is with money and lawyers. Very specifically, there's no royalty-free codec for video. This is nothing that standards bodies can solve. The most promising is that Sun Microsystems is developing an open codec and spending money to make sure they're not infringing on patents.

Not only is the HTML Working Group improving markup in HTML, they're also working on coming up with new APIs that give you access to features. If you have ideas that aren't included in HTML 5, the group is definitely interested in hearing about them.

After each panelist talked, John asked them questions about what's the biggest thing they'd like to see implemented by everyone (open video codec, geo location api were the winners). Mike also did some complaining about XML and how broken it is because there's no failure mechanism. There was some audience banter with Chris about SVG in IE.

Conclusion
This was a very interesting session, especially to hear from the people who are building/supporting the future of the web. I liked Scott's talk on what Adobe's hearing from their users. I also liked hearing Mike (TM)'s opinionated thoughts on XML and his non-marketing approach to most everything related to the web. Lars from Opera had a marketing-ish presentation, but it was nevertheless interesting to hear what Opera's working on. Good stuff.

Choosing an Ajax Framework

This past week, my colleagues and I have been researching Ajax Frameworks. We're working on a project that's following SOFEA-style architecture principles and we want the best framework for our needs. I'm writing this post to see 1) if you, the community, agree with our selection process and 2) to learn about your experiences with the frameworks we're evaluating. Below is the process we're following to make our choice.

1. Choose a short list of frameworks to prototype with.
2. Create an application prototype with each framework.
3. Document findings and create a matrix with important criteria.
4. Create presentation to summarize document.
5. Deliver document, presentation (with demos) and recommendation.

For #1, we chose Ext JS, Dojo, YUI and GWT because we feel these Ajax libraries offer the most UI widgets. We also considered Prototype/Scriptaculous, jQuery and MooTools, but decided against them because of their lack of UI widgets.

For #2, we time-boxed ourselves to 3 days of development. In addition to basic functionality, we added several features (i.e. edit in place, drag and drop, calendar widgets, transitions, charts, grid) that might be used in the production application. We all were able to complete most of the functionality of the application. Of course, there's still some code cleanup as well as styling to make each app look good for the demo. The nice thing about doing this is we're able to look at each others code and see how the same thing is done in each framework. None of us are experts in any of the frameworks, so it's possible we could do things better. However, I think it's good we all started somewhat green because it shows what's possible for someone relatively new to the frameworks.

For #3, we're creating a document with the following outline:

Introduction

Ajax Framework Candidates
(intro and explanation)

  Project Information
  (history)
  (license / cost)
  (number of committers)
  (support options)
  (mailing list traffic (nov/dec 2008))

Matrix and Notes

Conclusion

For the Matrix referenced in the outline above, we're using a table with weights and ranks:

Our strategy for filling in this matrix:

• Customer adjusts the weight for each criteria (removing/adding as needed) so all weights add up to 1.
• We rank each framework with 0, .5 or 1 where 0 = doesn't satisfy criteria, .5 = partially satisfies, 1 = satisfies.

The list of criteria provided to us by our client is as follows (in no particular order).

• Quality of Documentation/Tutorials/Self Help
• Browser support (most important browsers/versions based on web stats)
• Testability (esp. Selenium compatibility)
• Licensing
• Project health/adoption
• Performance
• Scalability
• Flexibility/extensibility
• Productivity (app dev, web dev)
• Richness of widget/component library
• Charting capability
• Ability to create new widgets
• Match to existing Java team skill-set
• Ease of deployment (on Ops, QA, Users)
• Degree of risk generally
• Ability to integrate with existing site (which includes Prototype)
• Easy to style with CSS
• Validation (esp. marking form elements invalid)
• Component Theme-ing/Decoration
• CDN Availability (i.e. Google's Ajax Libraries API or Ext CDN)

What do you think? How could this process be improved? Of course, if you have framework answers (0, .5 or 1) for our matrix, we'd love to hear your opinions.