ExtJS Creator Jack Slocum Discusses Upcoming 2.0 Release

Posted by Scott Delap on Oct 03, 2007 01:38 PM

Community

Java

Topics

Web Frameworks

The ExtJS team recently released the alpha release of version 2.0. This comes roughly a month after a preview release of the framework. Among the new features:

 

• Grouping and Summary of Tables
• Scrolling Tabs
• Anchor Layout
• Tree Widget with Columns
• Web Desktop
• New API Documentation Center
• New Samples

It is noted that the API of ExtJS 2.0 has stabilized and is being used by several clients in production environments. The framework is licensed under LGPL 3.0, commercial, and OEM licenses. The final version is being targeted for sometime near October 31st.

InfoQ caught up with ExtJS creator Jack Slocum to discuss the release:

Explain ExtJS in relation to the JavaScript ecosystem of JQuery, Dojo, Prototype, YUI, etc. Are we moving towards tiers of JavaScript frameworks? Furthermore why do we need ExtJS with JQuery, YUI, or Prototype. Why not just ExtJS (which is an option)?

 

jQuery, Prototype and YUI are primarily core JavaScript libraries. While YUI, and more recently, jQuery do have collections of widgets built to work with them, none offer a truly integrated and complete application development platform. While the core libraries are great, there are still many holes left for the developer to fill when it comes to application development, and Ext is here to help bridge that gap. Dojo is really the only other major open source framework attempting to provide an integrated application platform similar to Ext. While Dojo is a great toolkit, we feel that Ext offers a more cohesive framework for developing applications. The Ext components were designed to work with other Ext components so the process of using them together is seamless. That type of interoperability can only come when a close knit team is doing the design and development with the same goal in mind, which is something generally not found in open source projects. All of our components have been built from the ground up with presentation, performance, interoperability and extensibility in mind, and we think it shows.

Ext can definitely be used as a stand-alone framework. In fact, barring any other requirements, that is the preferred choice as it offers the smallest file footprint and tightest support and integration. However, we also offer the ability to integrate with jQuery, YUI or Prototype as the base library for core services like DOM and event handling, Ajax connectivity and animation. One reason one might opt for such integration is when they have a requirement to use an existing library-specific widget that Ext does not natively offer -- the YUI history control is a perfect example. To use that control YUI's base library would be required, so Ext can leverage that dependency instead of adding duplicate base functionality of its own, thus minimizing the overall application footprint. Another reason for this approach would be if one wanted to progressively add Ext into an existing application that was already based on another library. Again, if the alternate library is already available, Ext can use it. We are all about giving our developers options and optimizing for performance. In fact, anyone could add an adapter for other frameworks as well. By implementing our base library adapter interface, someone could easily leverage Dojo, Ajax.NET, Moo or any other JavaScript library as the base for Ext!

What is the most difficult thing about supporting the various JS libraries?

 

The most difficult challenge is probably the most obvious one: keeping the other libraries up-to-date and working nicely with Ext. As each new version of each library comes out, we also have to test them and see if any changes were introduced that might break things for Ext developers.

Similarly what is the biggest pain/issue with supporting the various web browsers?

 

The biggest issue for us is simply the amount of time it takes to test and verify changes and additions to the framework. It's not only different browsers and browser versions, but different doc types on each browser as well that must be supported.

One nice thing about Ext is that we've built many tools directly into the framework itself to handle cross-browser issues, including a base component class for normalizing box model issues transparently, as well as platform-specific constants and auto-applied CSS classes for working around browser quirks without using CSS hacks. Because this support is built right in, and because the core framework is stable and well-tested, the end developer can generally develop without too many cross-browser concerns, thereby speeding development and drastically reducing testing on the application end.

If you had to define the driving force of ExtJS 2.0 what would it be?

 

Developer productivity and a solid, consistent foundation to build on. Although the 1.x version of Ext was a great library to build on, there were certain areas identified that could be made easier and require less expertise and code by the developer. We want to tackle some of the more difficult problems when building a complex application, such as deferred rendering and component life-cycle and not require developers to handle it manually. The other major improvement for 2.0 in a more robust foundation in place for customizing components (plugins), grouping components (containers) and component initialization. The new consistency across layouts and components means that once you understand how to configure and work with one component in Ext, you will be able to work with any component in the framework in the same way. That leads to faster and easier development for the end user, while sacrificing nothing in terms of Ext's size or performance.

What is the most innovative feature of 2.0 in your opinion?

 

Probably the new container architecture. In 1.0, application layout was primarily focused around the BorderLayout (for layout) and the BasicDialog (for application dialogs and windows). While these components looked good and were extremely functional, they were limited when it came to reusing code to extend their built in functionality. Using the new container and layout architecture, for 2.0 we’ve added a quite a few additional layout managers (CardLayout, ColumnLayout, FormLayout, TableLayout and several others - 9 in all) and consolidated the container API so whether you are adding a component to a TabPanel, Window, Panel, etc the API is always the same. In the end, we aren't just offering widgets, we are offering an integrated framework that works well together and has the foundation in place to grow with our user’s applications.

How would you make the argument for using ExtJS and JavaScript for client applications over technologies such as Silverlight and Flex?

 

In some ways, Ext is actually complementary to the new plugin-based technologies. Both Flex and Silverlight support DHTML/Ajax development as part of what they can do, and our Adobe AIR Simple Tasks demo application is a perfect example of Ext working well under that exact scenario. In fact, in that example, Ext is providing a look-and-feel quality that you would not even be able to achieve in AIR natively without spending countless hours writing your own widget wrappers and custom CSS!

Of course the native platforms have some natural advantages that JavaScript does not currently have like native compilation and better tool support. However, there will likely always be a place for the simpler development and simpler deployment model of JavaScript-based applications. Anytime a plugin is required, it adds more complexity in terms of development, deployment and maintenance. Microsoft publishes an "Enterprise Sliverlight Deployment Guide" involving SMS, Active Directory and a host of other headaches -- something you'll never see for a JavaScript application! Also, with newer mobile platforms (e.g., the iPhone) coming out with vastly improved JavaScript/DHTML support (that is actually favored over plugin support), it seems that there are still some very good reasons why you might choose JavaScript over a plugin.

The bottom line is that there are many tools available, and developers should choose the best tool for the job at hand. Sometimes that might be a plugin-based technology, but we're confident that JavaScript-based technologies will maintain a place in the web development toolbox for some time yet, and Ext is well positioned to play a prominent role.

What is next for ExtJS?

 

The current focus in on having a solid and stable 2.0 release. Although the first release is an alpha, we already have a head start on that since the 2.0 codebase has been being used by quite a few developers for a couple months.