Ext Conference, Day 3

The third day of Ext Conference 2009 was only a half-day, which turned out to be a good thing given the trainwreck start. They were an inexcusable 20 minutes late in opening the door for what should have been 15 minutes of closing remarks. Instead, it turned into a 30+ minute demo of the new UI designer. Yes, the designer is awesome and will rock the ext world, but it is beyond me why they would improvise a demo on the morning of the last day. This should have been either on day one or possibly part of Jack’s keynote on day two.

With events now running 45 minutes late, the final two sessions ended up being pretty disorganized. I went to the “Mainframe to Web” presentation by Rich. I had just done a similar project and was interested in what he had to say. Turns out their showcase pretty much faked an integration with the backend by using a screen scraper on the server side which translated terminal session screens to ExtJS metadata. They didn’t change any of the backend code at all. I’ll give them credit for finding a clever solution, but I’m not convinced it is the best one. When we confronted a similar problem, we ended up wrapping backend functionality in AS/400 stored procedures we called from the middle-tier.

The positive side effect of the wheels-off schedule was that Rich rushed his presentation to try and wrap up on time. The other presentation, ExtJS deployment, was only halfway done, so I jumped in to catch the last half of it. In this case, it seemed like the heart of the presentation was in the last half, so I basically got the best of both presentations.

The deployment presentation covered a lot of the useful tools for bundling up your JavaScript. I had heard of JS Builder before, but plan on taking a deeper look now. It can create a single JavaScript file from many smaller files. YUI Compressor is the recommended tool for really putting the squeeze on your JavaScript files, but even then, Jamie still recommended ensuring you use GZip/Deflate on the web server for JavaScript files. He also talked about a tool for creating a multi-image sprite file of several small images that can also have a big impact. I came away with a lot of things to research and this should be a top presentation to check out when they put them online.

The final session for the day was Scott covering the Ext.Writer. This has got to be one of the coolest features of ExtJS 3.0 and they really should have moved this earlier rather than waiting for the last minute. The Writer addresses the problem of handling CRUD operations for Stores. It can use REST-like URLs like /app/update/1 or /app/delete/1 with the record ID as the final parameter. It pushes a JSON object back to the server containing the information that needs to be acted on. It even addresses passing a primary key back to the Store on a create operation. This is looking a whole lot cooler than Ext.Direct and I want to give it a try for my application.

I didn’t sit through the final Q&A session as I needed to bugout for the airport. Based on the tweets so far, it doesn’t look like much was discussed. Overall, the conference was excellent and I can chalk up the final day to growing pains. What will be interesting to see is what happens in the coming weeks. Ext.Direct was talked up in about every session, but there is an incredible lack of detail for how it will be implemented with mainstream enterprise technologies (Java/C#). Abe talked about the Marketplace, which sounds like the equivalent of RubyForge for ExtJS. If they can get it up, it will be cool. Finally, the UI Designer is what everyone really wants but it is slated for v3.1, and no one would talk timelines for it.

Ext Conference, Day 2

After the 100mph pace yesterday, day two of the conference settled in to a comfortable 55mph. The big news of the day was during the keynote, when they released RC1 of ExtJS 3.0. Jack was the scheduled keynote speaker, but I get the impression he doesn’t like speaking in front of large groups. His keynote lasted all of five minutes. He covered the history of ExtJS in two minutes and said ExtJS 3.0 is here. And that was it. Abe was left scrambling to fill a rather large hole in the schedule, and he called up Darrell of the GXT (Ext GWT) team to talk about their v2.0 release.

Darrell is a nice guy, but I was ready to pull my hair out listening to him. I had lunch with him yesterday and to say he is excited about GWT is a major understatement. In spite of being a Java guy, I don’t like the idea of writing my web UI in Java. It’s like the Hibernate mafia who think you can write a database application without knowing SQL. Each of the tiers has a best-in-breed language for addressing that tier’s problems. An enterprise developer better know SQL for talking to databases, Java/C# for the middle tier and HTML, CSS and JavaScript for the front end.

After the keynote, we had another smoothie break. The smoothies were good, but the general consensus would have preferred coffee in the morning and smoothies in the afternoon.

Aaron kicked off the regular sessions with a breakdown of the signature demo in ExtJS 3.0 — Image Organizer. This is the meatiest demo so far, and was interesting to see how they structured the code and where they subclassed. The application uses Ext.Direct, but the backend was only PHP. One of the first questions Aaron got asked was when they would release other backends. He really danced around the question without giving a true answer, saying that maybe there would be something released in the next week or so. Ext.Direct is starting to sound like a lot of vaporware. They talk a good game of how it will be able to use annotations/attributes server side for exporting objects and other cool stuff, but no one is producing any code. Ext.Direct is the new Duke Nukem Forever.

The next session I attended was one of the funniest. Glen Liptka talked about user experience design with ExtJS. He is at Marketo, which has done the most incredible theming of ExtJS I have ever seen. He started the talk covering general usability and then demonstrated their application. The point he made that stuck with me is that your UI should have low WTF/min. Everyone got a kick out of that.

Next up was JC Bize talking about theming ExtJS. JC is the author of the Slate theme, one of the most popular third-party themes used in ExtJS. He is now an employee of Ext, LLC, so hopefully we’ll see some more cool themes in the pipeline. He showed off a couple cool themes and then got in to a basic example of how to change the theme of a panel. When playing with themes, Firebug is your friend. Unfortunately, he got sidetracked trying to answer an audience question and the presentation fizzled out.

I couldn’t catch the last session, as I had to make a phone call, but came back for the day-ending Ask the Ext Team. Nothing major came up. I tried to ask the question of why they didn’t use Sizzle for Ext Core, but my question didn’t get voted up and they ended the session before they got to it.

The day wrapped up with a social down by the pool with a cash bar. I really started to hate the Ritz after paying $8 for a beer. They definitely need to move the conference to someplace that understands Happy Hour. I managed to corner Aaron at the social and got my Sizzle question answered. He said they didn’t use Sizzle because it was too big and too slow. He did say the DOJO guys were working on a very cool new engine called Acme that looks promising. DOJO makes me nauseous just looking at it, so I won’t be investigating it.

The day ended for me again at the bar. I had dinner with another attendee who works at the DIA. Since I have a similar background, we had a lot to talk about. $35 for two margaritas and a plate of chicken quesadillas — ouch!

Day three is only a half day, but there are still two sessions I’m interested in, so it should be fruitful.

Ext Conference, Day 1

The first day of the first-ever Ext Conference wrapped up today. The day actually started last night when I got to the hotel. Jay Garcia and Shea Frederick both got in at about the same time as me. We had an impromptu meet-up at the hotel bar, where we hooked up with a few more conference attendees who were drawn to the geek conversation like moths to a flame.

One of the guys (Jerry), mentioned that Abe (Elias) was still in the big conference room preparing for the keynote. Since it was 12:30am, and tipsy geeks don’t have anything better to do, we paid him a visit. He was extremely cool, and ended up giving us the tour. He took us down to one of the other meeting rooms where a Rick, Aaron, Evan, Tommy and Chris were getting ready for their presentations too. After about a half-hour of the geekfest with them, I went to bed to be ready for the early start today. As a footnote to the evening, be sure to ask Jay how sissy drinks at the Ritz went over with him.

The conference started up at 8:30am this morning. Abe introduced the Ext development team, which was a lot larger than I expected – over a dozen people. He kept the introductions short so that we could get to Douglas Crockford, our keynote speaker. As he is a legend in the JavaScript community, it was exciting to see him talk in person. He covered a little bit of the history of JavaScript, then dived in to the future, including ECMAScript 5 (ES5). ES5 is going to be pretty impressive, but it will be years before we can really count on it being on all the desktops (thanks, Microsoft).

Most all the sessions throughout the day were at a good technical level. No fluff, just stuff. Aaron presented the new features of ExtJS 3.0, which drew almost everyone. They had to move the session back to the keynote ballroom. ExtJS 3.0 is super cool, with one exception, which I’ll discuss below.

Evan was up next, talking about Ext.data. Since there wasn’t a lot new in this space, this was more a rehash of the Ext.data classes. Evan definitely knows his stuff, and had some educational examples.

Chris then talked about Ext.direct. This is the one area of ExtJS 3.0 that I’m still skeptical on. One of the key parts of Ext.direct is the server-side component, yet everyone so far has been light on details for this piece. Chris is a Merb guy, so it didn’t help when he was showing Ruby code trying to explain it. Even listening to Jack discuss it in the hall left me feeling there were still a lot of smoke and mirrors around Ext.direct. In theory, Ext.direct should provide a server-technology agnostic RPC mechanism for talking to objects. I’m not convinced we actually needed this, and since I haven’t seen any real code behind it, I’m not sure what kind of state it is in. Hopefully, when Jack announces the release of ExtJS 3.0 tomorrow morning, I’ll get a chance to look at some code.

My final session for the day was watching Tommy discuss Ext Core. I’ve already covered Ext Core in some prior posts, but still managed to learn some things. Ext Core is going to really shake some things up when folks start to get familiar with it. I plan on wrapping up a post on the cool OO features of Ext Core this weekend.

That was it for the structured presentations. Here are a few other random thoughts and observations on the day:

  • Swag so far has been an Ext spiral notepad, a pen and a nice travel mug. There will probably be a riot if T-shirts don’t appear.
  • The next fool who gets up and asks about testing ExtJS websites with selenium is going to receive my travel mug upside their head. Asking the same question five times is not going to get you a different answer.
  • The meal was excellent. The hotel is nice, but a bit too ostentatious. It’s the Ritz, so you have to expect it, but it would have been more fun to have the conference in a more festive environment. Hint for Abe: Vegas, Baby!
  • Overheard a Salesforce architect talking about them moving to ExtJS. That would really rock if they did it.
  • The average age of the Ext dev team appears to be about 17 :-) . They have a lot of bright, young talent on their hands. It will be fun to watch what they do with it.
  • Someone actually asked, in the group Q&A, if there were any books on ExtJS. Paying over a thousand dollars for a conference and not doing your homework is just plain dumb. Never ask something in front of a large group that 15 seconds on Google or Amazon could answer for you.
  • All the sessions were taped and Abe said they would be put up on the Ext site. Presentations should show up too.

I’m hoping tomorrow rocks too. We went non-stop from 8:30am to 6:30pm today, and it was a lot of fun. If they can keep up the momentum, this will turn out to be one of the best technology conferences I have ever attended.

Beyond the Core

In my earlier post, I compared the new Ext Core JavaScript library with JQuery to demonstrate how close they are on core functionality. I explicitly kept the scope narrowed down to areas where the two libraries overlapped, and my conclusion was that both are winners but I prefer Ext Core since I use ExtJS and prefer the coding style.

In this post, I want to get in to demonstrating some of the features of Ext Core that are either coded differently from JQuery or that the base JQuery library does not implement. The excellent Ext.Core manual has more detail on all the functions, so I’ll just bring attention to some of cool functionality I like.

Base Class Enhancements

One feature that might be controversial for some developers is that Ext Core augments some of the base JavaScript objects to ensure some features are present across implementations and to add some useful helper methods. The JavaScript Augmentation section of the manual has details on all the enhanced methods. Function, Array and String are the three base objects that get augmented.

For example, the String object is augmented with a static format() method that essentially allows the String to function like a typical printf function:

var dest = 'World';
var greeting = 'Hello';
var msg = String.format('{0}, {1}!',greeting, dest);
// msg contains "Hello, World!"

The Array object is augmented with indexOf() and remove() methods, and the Function object itself picks up several OO-centric functions.

The reasoning behind the augmentations are in the manual. I have mixed feelings on augmenting the language’s base objects, but the features are appreciated.

Namespaces

Using a namespace mechanism so that all your variables don’t pollute the global namespace is something every JavaScript coder should be doing. There are plenty of code snippets out there to demonstrate how this is done, but Ext Core makes it easy for you by including namespace support as a part of the library. All this is handled through the Ext.namespace() static method.

Take a look at the sample below. The comments indicate the filenames:

// first.js
Ext.namespace('First');
First.name = 'Tim';
 
// second.js
Ext.namespace('Second');
Second.sayHello = function(name) {
    alert( String.format('Hello, {0}',name) );
};
 
// main.js
Ext.onReady(function() {
	Second.sayHello( First.name );
});

The three JavaScript files don’t even need to be imported in this order. Everything happens through the namespace references declared at the tops of the files and managed by Ext Core. In this case, objects called First and Second were created under window, and the sayHello method and ‘name’ variable were placed under them. This means our code only added two variables to the global space. This didn’t make a difference with only two variable declarations, but can have a huge impact with a typical application.

Namespaces can be hierarchical, so you can limit the global pollution to a single entry. For example, you can define a namespace like this:

Ext.namespace('Application.Init');

Ext Core will create all the intermediate namespaces, so you could places variables under both Application.Init and Application with this single declaration. This provides a similar naming hierarchy to what you would find in Java packages or C# namespaces.

Encode and Decode

Ext Core provides helper methods to encode and decode both JSON and URL-encoded data. The Ext.encode and Ext.decode will encode or decode JSON objects to and from Strings. This is useful for the AJAX methods, as I demonstrated in my other post. In the current beta, the encode and decode methods aren’t implemented yet, but they are in the documentation, so I’m expecting to see them before the final release.

The Ext.urlEncode and Ext.urlDecode methods will encode or decode JSON objects to URL-encoded strings. One typical example is to decode query string parameters. For example, if the page URL was this: http://mycoolapp.com?name=Tim&lang=Java, you could easily decode the query string into a JSON object using this snippet:

var params = Ext.decode( document.location.search.substr(1) );
alert( String.format('Hello, {0}', params.name) );

Yes, this is a bit of a hack. I didn’t do error checking to ensure there was a value for search before using substr(). The substr() is necessary when working with a query string because the search value will start with a question mark (?), which the Ext.urlDecode method won’t strip off.

Templates

Ext Core thankfully includes Templates, a feature generously carried down from ExtJS. Templates simplify the repetitive generation of HTML fragments, which is something that typically happens in AJAX intensive web application. The Ext.Template class allows you to define an HTML fragment as a template, using tokens which will be replaced with the values from a JSON object. For example, here is a code sample of a Template used to format an RSS feed from Slashdot that I turned into a JSON object:

// Feed.data is an array of JSON objects that look like this:
// {title: 'title', link: 'link', description: 'description'}
 
var template = new Ext.Template(
            '<div class="story">',
            '<h3><a href="{link}">{title}</a></h3>',
            '{description}',
            '</div>');
 
// stories is the id of the empty div on the page
var stories = Ext.get('stories');
 
Ext.each(Feed.data, function(item) {
    template.append(stories, item);
});

This snippet also demonstrates the Ext.each() helper method for iterating over the contents of an array. You can download the full snippet here to play with.

As Ext Core is still in beta, there is a disconnect between the API documentation and the actual implementation. If the Ext.Template class is updated to correspond to the documentation, there are also some neat formatting effects that can be applied. For example, instead of the placeholder {description}, you could use {description:ellipsis(20)} which will truncate any string longer than 20 characters and place ellipsis at the end of the string.

I’ve covered a few of the cool features to make your JavaScript code easier and more maintainable. Ext Core also has some neat OO functionality that I’ll cover in another post.

It’s Coming!

Yes, it is that time of year. Dallas TechFest is in the air. This is the premiere, cheap technology conference in the North Texas area. Last year’s event was at the Addison Convention Center. This year, TechFest has gone Hollywood and moved the conference to the Westin Stonebriar Resort up in Frisco. Attendance is capped at 650 people, and it should sell out easily.

Dallas TechFest

Register now and reserve your spot. I’ll be speaking on using ExtJS with Spring, so be sure the say hello.

Feedback

It has been fun watching the comments on my write-up yesterday about Ext Core on some of the sites it got posted to. It is clear, for some people, discussing JavaScript libraries has drifted into the same hazard zone as discussing religion and politics. While I appreciate all the feedback, and probably should have signed up for adwords before posting, I do want to clarify a few things:

  • GPL – I hate it, deal with it. There are two reasons a library author would use GPL. First, to prevent someone else from monetizing their effort (ala ExtJS), or second, because open source is an agenda and not a license. An altruistic developer who is interested in helping other developers without expectations of a return will use a reuse-friendly open source license for their libraries like Apache or MIT. If you’re trying to change the world, please, go ahead and use GPL. If you just want to help out your fellow developers, use something with no strings attached.
  • ExtJS Haters – still a surprising number of geeks out there who are bitter about the change from LGPL to GPL. I was a vocal critic of the change too. I got over it — I bought a license and no longer care. Best $289 I’ve ever spent. If you’re looking for a free ride, look elsewhere. Ext LLC is for-profit entity and I agree with them. People should be able to put food on the table writing cool code, and I won’t deny the talented developers at Ext LLC that right.
  • Fluff – I especially got a kick out of this. It was the longest blog post I have ever written (1800+ words) and tried to touch on as many areas as I could. I plan on following up with some more detailed posts. Guess you can’t make everyone happy.
  • The Conclusion – JQuery is an awesome library. I’ve used it for years. I’ve also used ExtJS and will now use Ext Core more. Why? For the same reason some developers gravitate to Perl and others to Java — Style. I come from a OO Java background, and thus the coding style of the whole ExtJS/Ext Core duo is more in line with my preferred comfort zone. Both JQuery and Ext Core are awesome libraries. Pick the one that suits your personal style and objectives.

New Kid on the Block

On this cloudy Dallas Saturday morning, the ExtJS team announced the availability of Ext Core (beta). Ext Core is the core DOM selection, manipulation and events library of ExtJS which has been extracted out into a separate library released under a more liberal license. They smartly released this under the very permissive MIT license, in contrast to the cancerous GPL used for the full ExtJS.

What makes this interesting is it positions Ext Core as a direct competitor to the popular JQuery library. I really like both ExtJS and JQuery, so I decided to run a quick comparison of the two libraries to see if Ext Core is up to the task of replacing JQuery in my developer toolbox. Since there is so much overlap between the two, it makes no sense to use both.

Round 1 – Size

Library size of the two is pretty close. The minified version of JQuery runs about 56K, while the minified version of Ext Core weighs in at 75K. The 19K difference might matter for an iPhone application, but even then, I would consider it negligible. Both are pretty small libraries, so we’ll call Round 1 a tie and move on to feature comparison.

Round 2 – Load Event

How each of these libraries works the document ready event is more a matter of style. The JQuery convention is to use the dollar sign ($) for for operations, although you can fall back to using the full name (jQuery). Setting up a ready event in JQuery looks like this:

$(document).ready(function() {
    // do cool stuff
});

Ext Core uses the static Ext class for the same functionality. Like the jQuery object, the Ext object is the heart of Ext Core. Setting up the ready listener in Ext Core looks like this:

Ext.onReady(function() {
    // do cool stuff
});

One big difference is the onReady method can take an additional parameter specifying the scope in which the onReady method should execute. This is not a big deal in most cases, but shows Ext Core’s attention to support object oriented JavaScript. Since I’ve never actually needed to specify the scope, I’ll call this round a tie too.

Round 3 – Selectors

This is the heart of both libraries, and a full comparison could fill a dozen pages. The short story is they both support basically the same set of CSS3 selectors along with some custom enhancements. From looking at the documentation, I couldn’t find any typical use cases that either couldn’t handle. Like the document ready example above, it just comes down to a matter of convention. For example, here is the code from each to add a class to a set of nodes:

// JQuery
$('td.age').addClass('someclass');
 
// Ext Core
Ext.select('td.age').addClass('someclass');

One major style difference between the two is that Ext Core has a tighter focus in handing elements with ids, since that is critical to the full ExtJS library. For example, Ext Core has the get() method to directly grab an element by ID, along with a memory-friendly fly() method. The fly() method does not create a new element wrapper in memory, and instead reuses a single global element object. This can save a lot of memory when you just need to do quick manipulations of single objects.

// Add a class to the element with ID of 'header'
Ext.fly('header').addClass('someclass');

For the memory saving fly operation, I’ll give the advantage to Ext Core, although they are essentially equal in their DOM selection abilities.

Round 4 – Events

Like the selectors above, there are basically style differences between the two libraries in how they handle basic event use cases. JQuery adds some methods to the jQuery object for registering common events. For example, here is the code to add a click event to a button for each, including the JQuery shortcut:

// JQuery with bind()
$('#myButton').bind('click', function() { alert('Clicked');});
// JQuery with shortcut
$('#myButton').click(function() { alert('Clicked');});
// Ext Core
Ext.fly('myButton').on('click', function() { alert('Clicked');};

JQuery brings some some additional enhancements to the game in the form of “live” events. This provides a way of attaching an event to all current, and future, instances of the selector. JQuery also supports event namespaces, where events can be fired in a hierarchy. Both are powerful concepts, but I’ve never had to use either.

The secret sauce for Ext Core is in extended configuration. With Ext Core events, you can also configure the scope (a common Ext Core theme), along with configuring the event propagation, extra parameters, and a delay. Here is a sample of a click event configured with ‘this’ scoped to the onClick event itself, to only fire once (single), with a delay of 100ms and an additional parameter (forumId) to be passed to the event handler:

el.on('click', this.onClick, this, {
    single: true,
    delay: 100,
    forumId: 4
});

So again, I’m going to call this round a tie. Both libraries handle simple event binding very easily. If you need the live events, the nod goes to JQuery. If you need the extra configuration options, Ext Core is your best bet.

Round 5 – DOM Manipulation

Once again, the two libraries provide a near complete overlap of basic DOM manipulation functionality. Each can easily create, move, add and insert DOM elements.

JQuery aims for convenience. For example, one feature of JQuery I really appreciate are simple methods to clear the content of a DOM element and set the text. For example, given:

<div id='message'>First Message</div>

With JQuery, it is simple to update the text:

$('#message').text('New Message');

The text() method removes all the child nodes of the matching elements and appends a text node containing the specified text. The text() method without a parameter will retrieve the text for a matching element. For Ext Core, you have to drop down to the DOM to set the new text value:

Ext.fly('secret').dom.innerHTML = 'New Message';

The Ext.Element class does not provide simple methods for setting the text or removing all the children of an element, which I find to be an annoying inconsistency.

On the plus side, Ext Core provides a lot more methods for manipulating the DOM. One of the cool ones is the radioClass() method. This method will add a class or classes to an element and remove that same class (or classes) from all the siblings. For example, here is a simple table with a row having the ’selected’ class:

<table class="data">
    <thead>
        <tr><th>Name</th><th>Age</th></tr>
    </thead>
    <tr>
        <td>Bill</td><td class="age">20</td>
    </tr>
    <tr class="selected">
        <td>Alice</td><td class="age">21</td>
    </tr>
    <tr>
        <td>Jeff</td><td class="age">22</td>
    </tr>
    <tr>
        <td>Susan</td><td class="age">23</td>
    </tr>
</table>

This one line of Ext Core code will remove the ’selected’ class from the current TR element and add it to the first row in the table:

Ext.select('table tr:first').radioClass('selected');

So for this round, I’ll give the advantage to JQuery for the more consistent API, especially around manipulating the text nodes of an element. This is something pretty simple for Ext Core to address, which they really should. Ext Core does, however, offer more powerful DOM manipulation options.

Round 6 – Effects

I’m not a big effects junkie, so I won’t have a lot to say about this. Both Ext Core and JQuery provide a very similar set of effects for elements (hide/show, fade, slideIn/Out, etc…). Ext Core provide a more powerful API for creating custom effects, while JQuery addresses this with its rather extensive set of plug-ins. I’m calling this one a tie.

Round 7 – AJAX

Ext Core and JQuery both make AJAX simple, but again, we’ll see that JQuery adds more simplified methods while Ext Core offers more powerful configuration. Here is a sample of an AJAX call that returns JSON data:

// URL returns a JSON object like this: {name: 'Tim'}
 
// JQuery 
$.getJSON('http://myurl', function(data) {alert(data.name);});
// Ext Core
Ext.AJAX.request({
    url: 'http://myurl', 
    success: function(response) {
        var data = Ext.decode(response.responseText);
        alert(data.name);
    }
});

JQuery provides the simplified getJSON() method where the parameter to the callback has already been decoded into a JSON object. For Ext Core, the callback receives the XHR response object and you have to decode the text to JSON.

The Ext Core request() method demonstrates a typical ExtJS convention of using a JavaScript configuration object as a parameter instead of using multiple parameters.

Both libraries provide strong AJAX support, so we’ll go with a tie for this round too.

Round 8 – Documentation

There is no contest in the documentation department. While the JQuery documentation has improved, the Ext Core documentation blows it away. From the excellent manual to the high-quality API documentation, Ext Core sets the standard for what all documentation should look like.

Round 9 – Intangibles

For JQuery, the biggest intangibles are its plugins and support from Microsoft. JQuery is intentionally designed to provide a simple core set of functionality and to be easy to extend. There are hundreds of plugins people have written for JQuery in the Plugin Repository. As with all things open source, some are very good and some are kinda crappy, but you can be pretty certain to find a plugin that covers about anything you might be trying to do that is not covered by the core JQuery API.

Microsoft support is also a biggie. They have decided to include JQuery as a base JavaScript library in their web tools going forward. This means you won’t need to get special blessings to use JQuery in large corporate environments — it will be part of the core Microsoft bundle, with support and all.

Ext Core, being brand new, is lacking in both community and support. Ext LLC, the company behind ExtJS and Ext Core is a small software shop trying to get by in a tough economy. While their products are cutting edge, I’m expecting them to be bought out by a larger company before too long. I keep trying to talk my Spring Source contacts into buying them, but I have a feeling they’ll be bought by Adobe.

So from an intangibles perspective, JQuery is the winner. It is guaranteed to have longer legs under it, at least until we see where Ext LLC ends up.

Conclusion

Both Ext Core and JQuery are solid, complete base JavaScript libraries. JQuery leans towards simplicity while Ext Core offers enhanced configuration. The choice of which to use will come down to where you are now.

  • If you use JQuery, and don’t anticipate using ExtJS, stay where you are. You’ve got a winner.
  • If you use ExtJS and have used JQuery as a light weight option for when you didn’t need the widget library, Ext Core is now your library of choice.
  • If you are in search of a JavaScript library, the choice is tougher. Unless there is a particular JQuery plugin you want to use, I recommend going with Ext Core. It starts laying the groundwork for using ExtJS, which you’ll want to do as you get in to building RIAs.
  • If you’re a corporate Microsoft shop, you probably don’t have a choice. JQuery is now something you can slip by the infosec police without making waves.

Ext Core is definitely a winner. In the past, I have used JQuery for projects that need simple DOM manipulation and ExtJS for when I need the widgets, layouts, etc… Now that I have Ext Core, I don’t see using JQuery anymore for the simple cases. I can standardize on using the same API paradigm between Ext Core and ExtJS.

Follow-up #1: Beyond the Core
Follow-up #2: Slick Speed

Thanks, Atlassian

We received some good news today at Orange Leap from our friends at Atlassian. They approved us for an open source license to use Confluence.

This is a huge deal for us. Confluence is the gold standard for Wiki software, and we had really come to depend on it during our evaluation. Organizations don’t understand how important this kind of software it until they use it. My team implemented Confluence at Countrywide, and it quickly grew from a software development tool to an enterprise asset.

So thanks, Atlassian. And for folks who have never seen it, I highly recommend checking out Confluence. There is no better way to share knowledge within an organization.

On the Cloud

Unless you’re a geek from another planet, you’ve been hearing the buzz about cloud computing for the past year. Amazon has been one of the major thought leaders in this space with their EC2. Combined with their other web services, Amazon provides about the most complete cloud implementation. There is only one problem…. price.

A small EC2 instance would run about $73 a month. Yes, you can go cheaper if you turn it off, but how many people actively turn off their websites? It can get cheaper if you reserve capacity, but the $325 up front cost is a bit too steep for me.

I’ve been looking at cloud solutions for a development playground for a while. After taking a look around, I quickly discovered that quality hosting of Java applications is pretty difficult to find, especially given my requirements. I want a host that is running Java 6, Tomcat 6, MySQL 5 and allows me to do what I want with the instance. Shared hosting is obviously not the solution, so I looked at “Virtural Private Servers (VPS)” as an option.

Even VPS has been a pricey option. GoDaddy wants around $45/month for a virtual Linux server with 512MB of RAM. I tried one for a bit, but it wasn’t cost effective for a playground environment. I had about given up hope until I stumbled upon Mosso.

Mosso is Rackspace’s new entry into the cloud computing space. They are trying to get a foothold against Amazon in a pretty simple way, trash them on price. For an equivalent size cloud server, Mosso costs about the same as Amazon. But unlike Amazon, Mosso scales down to smaller instances. For about $22/month, you can get a Linux cloud server with 512MB of RAM that you can do what you want with.

I signed up for one of Mosso’s cloud server accounts last week to use for Java. 512MB of RAM is plenty for what i want to do. You can pick what Linux distro and version you want to use, and I was pleasantly surprised to see they had the latest and greatest (Ubuntu 8.10/Fedora Core 10). They are obviously targeting this at alpha-geeks.

One big difference with Amazon is that Mosso does not offer Windows. They provide you with a very naked (read secure) base Linux install to start with. You have to be competent with Linux (ssh, bash, shell commands) to even have a chance with Mosso. I’m pretty comfortable with Linux, but there are still some things I had to consult some friends on. In the end, I setup exactly what I wanted: Ubuntu 8.10, JDK 1.6.0_13, Tomcat 6.0.18 and MySQL 5. I’m using the instance to run some Java sample applications I’m working on and will use it as the backend for a Facebook application I’m going to play with.

The only downside I’ve found with Mosso is that it is pretty immature compared to Amazon, especially in the area of documentation. You can see the Rackspace guys are working on it, but there are still a lot of holes. I was pretty frustrated setting up iptables for a firewall because the documentation says “look at this sample” but there was no sample attached. Fortunately, Google and a friend saved me. The documentation for setting up email has the same holes.

Once I got past the documentation issues, Mosso has proven to be a winner. This is going to put a lot of pricing pressure on Amazon and the others in this space. You’d have to be an idiot to pay GoDaddy twice as much for the same thing. I’m willing to bet you’ll see about everyone hit $20/month for a usable cloud server before too long. Amazon will definitely have to drop their price.

On a side note, here is a good sample of an iptables rules file you can use with Ubuntu on a Mosso cloud server. Just be sure to change 10001 to whatever port you want to use for SSH:

*filter
 
# Allow loopback adapter
-A INPUT -i lo -p all -j ACCEPT
-A INPUT -i ! lo -d 127.0.0.0/8 -j REJECT
 
#  Accepts all established inbound connections
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
 
#  Allows all outbound traffic
-A OUTPUT -j ACCEPT
 
# Allow SSH (very important - set to right port)
-A INPUT -p tcp -m tcp --dport 10001 -j ACCEPT 
 
# Allow 80 and 443 (web traffic)
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT 
 
# Allow ping
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
 
# Reject all other inbound - default deny unless explicitly allowed policy
-A INPUT -p all -j DROP
-A FORWARD -p all -j DROP
 
COMMIT

Changing Tide

I’ve been checking out some of the stats on my blog this week. Its coming up on a year that I’ve been blogging, which means I’ve easily beaten the averages. One of the interesting tidbits has been the browser report. As you can see below, my guests have a clear browser preference:

Browser Report

The list goes on for another 20 lines into the “long tail”, but I stopped at Opera, which is about the end of the line for mainstream browsers. It is amazing how clearly Firefox dominates as the browser of choice for geeks.

It is stats like this that should have Microsoft very worried. What is cool in Geekland eventually makes it to mainstream. We could easily see a future where Internet Explorer is the exception rather than the rule.