Ext

We first heard about Marketo a long time ago, as they were a very early adopter of the Ext framework. The initial version of their marketing automation application was very nice even using pre-1.0 versions of Ext, and it has steadily improved over time. In addition to using the standard Ext components extensively, Marketo also employs their own custom UI theme to give the application a polished and distinctive look. They have also extended the base Ext platform with many sophisticated user interaction techniques that add power and expressiveness to the user experience.

I recently spoke with Glen Lipka, Marketo’s Director of UX and Product Management, and Paul Abrams, lead UI engineer, about their application and their use of Ext.

Tell us a little bit about Marketo and how you’re using Ext.

Marketo is sophisticated yet easy marketing automation that helps B2B marketing professionals drive revenue and improve accountability. In short, we are a Marketing department’s one-stop, on-demand resource. We use Ext as the fundamental base for the client-side interface. Additionally, I use the numerous examples posted on extjs.com and the forums as my UI design toolkit. When faced with a feature or problem, I often look at different UI examples. The samples on Ext give me confidence that we could implement that approach quickly without reinventing the wheel.

Did you evaluate other JavaScript frameworks when starting work on Marketo? Why did you choose Ext?

We started using Ext very early, when it was called YUI-Ext. We were using YUI and Prototype and homegrown and others at the time. The mishmash wasn’t helping us, rather it was making maintenance difficult. When we started using YUI-Ext 0.33, there were lots of hurdles, but it still made things much better. We understood the vision and bought in. We skipped 1.0 and introduced 2.0 when it came out in Beta. By this I mean that we ran 0.33 and 2.0 simultaneously. The new efforts in 2.0 totally transformed our development process. The flexibility of the system and the general intuitive nature of how it was built made it an easy choice to standardize on.

How does Ext fit into your overall technical architecture?

We have a LAMPhp stack using the Symfony framework. Before Ext, we used a lot of one-off HTML. The CSS and HTML burden of trying to maintain duplicate code everywhere was a hassle. Now, we use Ext configurations and subclass components we want to extend. The potential of UI variations has dropped significantly and we can now reuse UI patterns much more effectively.

How has the transition from .33 to 2.0 been going?

We introduced 2.0 in the fall of 2007 and ran it with 0.33 and our legacy code. The new tree, grid and other components were much more in line with our needs. There were many useful enhancements in 2.0.

We are finally ready to remove the legacy 0.33 code. We hoped the technical switch would involve upgrading components to their Ext 2.x equivalent and be relatively painless. It took six months on and off experimenting with different strategies before finding a new app structure and upgrade approach that worked, and then a couple of months of solid work rebuilding all the components derived from YUI and YUI-Ext 0.33 from scratch in Ext 2.x. Unfortunately, little was reusable. We have delayed a few components while we are designing a new skin, and later this year we will have a 100% Ext 2.x application. This has been a long time coming, but we are excited about it.

The Marketo application is extremely feature-rich. How did you manage the UI code complexity?

Just like Ext, we organize our code base into components and try to reuse as much code as possible. For example, our main Viewport lives in a folder/namespace and gets its own .js and .css files. We also have custom extensions for most of the major building blocks such as trees, combo boxes, grids, dialogs, etc.

What features could we add to Ext to make building a rich application like Marketo easier in the future?

There have been several places where building a custom extension involved overriding private methods, so more subclass hooks and smaller methods would help.

Ext also needs a unified Ajax session manager similar to the role of the Ext window manager. A rich web application like Marketo needs more management over the user session, such as detecting a session timeout and showing a login prompt. Another example is managing groups of Ajax requests, so that making a request to the same group could abort ongoing requests. Building an Ext RIA would involve creating a Viewport and an Ajax session manager, and then building components on top of that foundation. We rolled our own session manager in the 0.33 days and need to hook in the new Ext 2.x components.

Do you have any advice for developers just starting out with Ext for the first time?

If you are building a large application, don’t try to use Ext to decorate an existing app via “unobtrusive JavaScript” or build an app half with conventional construction and half with Ext. Instead, embrace Ext as a framework and start from scratch with something like a Viewport, and build components on top of that foundation.