The rise and fall of Ext JS

For being over a decade old, Ext JS is still a good platform to develop many enterprise-grade (think intranet) applications. From 2006 to 2015, I was actively invested in the Sencha community, answering forum posts, publishing articles, books, screencasts and conducting training around the globe.

The purpose of this article is to walk you through the history of this framework and along the way, express my observations and personal thoughts that I’ve held silent for nearly half a decade.

For me, this is the end of an era that lasted about 11 years and feel that the history of the framework should be discussed as the framework still has many features that keep enthusiasts around the world wanting to use it.

Let’s go back to 2005

2005 sparked a revolution for Web technologies. For those of you in the industry at the time, remember that we had front row seats to watch the birth of Single Page Applications (SPA) driven by really well architected JavaScript libraries.

Let’s set the stage for a moment:

• IE6 was still dominant with Firefox as its only serious competitor.
• Common debug tools (Chrome dev tools, firebug, etc.) had not been invented. This means that usage of alert(); was commonplace among developers
• Prototype JS and Scriptaculous were the dominant JavaScript frameworks
• DOM-based animations were still relatively new and were expensive (cpu-wise)
• While AJAX had been around for quite some time, good design patterns around its use were still being formed
• It was common practice to develop websites and applications using tools like Dreamweaver, textmate and vi.
• Smart phones did not exist.

In 2005, Google releases the beta form of its Maps website. This was a huge holy shit moment for the industry. This was the first website that gave us an opportunity to see maps being manipulated that didn’t require a page refresh and was a really good example of how asynchronous operations in the browser could improve the user experience of a website/application.

Enter the Yahoo! User Interface library

On February 13, 2006 Yahoo! released their first version of the Yahoo! User Interface Library (YUI) under a BSD license.

For the first time in a free library, web developers found many of the core features that came with the Prototype + Scriptaculous combo but with so much more:

• CSS reset
• A rich set of UI components — AutoComplete, Containers, TreeView, TabView and DataTable just to name a few.
• A layout manager. This was new to JavaScript frameworks at the time.

Many developers used YUI for what I call “Sprinkling AJAX” on a website, where they would place loosely coupled components on their web page to enhance them. Advanced usage of YUI came from within the enterprise and is where we would see a rather large leap forward for UI libraries.

Like many, I used the YUI component library, but felt that many features weren’t well thought out and the way one would couple them together as an SPA was not intuitive — at least for the first few releases anyway. For the application I was working on, I needed a robust data Grid component and searched endlessly trying other tools like MochiKit, dojo, Flex and so many other libraries. It wasn’t until stumbling upon a blog post detailing one man’s work and vision that forever changed my perspective on building SPAs.

Enter YUI-ext

In August 2006, a guy by the name of Jack Slocum (now CEO of Alta5) began to blog of his experiments with YUI. Over time, these experiments became more complex and Jack would start to bundle them into what would later be named YUI-ext (Yahoo UI extensions) — the precursor to Ext JS (Extensible JavaScript).

Jack Slocum’s blog was used to communicate his vision for YUI-ext and garnered community support from around the world.

The release of the Grid component for YUI-ext would forever change the trajectory of the library and the community as the GridPanel would become the core UI component for many applications to come.

Throughout its early life, Jack continued to build upon YUI-ext by adding features to the framework, such as animations, Modals, Tab Panel, Resizable elements and a layout manager that greatly expanded upon the YUI framework. These components would seldom extend the YUI library and had their own rendering functions.

One such addition that was rather groundbreaking at the time was the Documentation Center. Based off the JSDoc spec, the YUI-ext documentation was constructed with the framework itself, so it allowed you to immediately see the value of the framework if employed correctly.

Today, we take framework documentation for granted, but back then it was not very common to have good documentation on JavaScript frameworks. All YUI-ext developers found the accompanied documentation to be critical as it not only allowed you to learn, but it had examples that you see components action.

The YUI-ext documentation center

YUI-ext created a foundation for web programmers unlike anything the world had seen before and many developers flocked to the framework and invested in the newly formed community. The net result was the explosive expansion of YUI-ext.

From YUI-ext to Ext JS

In January 2007 we found Jack extremely busy to push out YUI-ext 0.40 and it is this version where we find the namespace of the framework change from YAHOO.ext to a much simpler Ext (pronounced “ekst J S” or “E-X-T J S” by some of us old-school community members).

February 2007, Ext JS 1.0 was being developed in tandem with a new website, ExtJS.com. In April 2007, the launch of ExtJS.com was announced to the community along with the release of Ext JS 1.0.

The commit log from YUI-ext v0.40 to Ext JS v1.0 alpha

In 2007, the community witnessed the official monetization of the framework with the creation of Ext JS LLC, in addition to commercial licensing options and the release of 1.0. The majority of the community supported the effort as we fully understood the value of the framework.

Within a few short months and a shit load of time developing YUI-ext, Jack Slocum successfully created a massive following of community contributors. However, with the monetization of the framework came (arguably) necessary license changes that would forever fragment the community and its licensing changes that continue to plague the community to this date.

Ext JS 1.0

Version 1.0 of the framework was well received in the community and was mostly an evolution of YUI-ext where we saw a few more widgets released in addition to additional themes.

Ext JS was based off of the YUI core library, but version 1.0 allowed developers to use jQuery, Prototype or YUI via adapters as the core library for your applications. This helped attract many developers who were already using jQuery and Prototype + Scriptaculous.

Ext JS 2.0 — The XType revolution!

This version of the framework was rather revolutionary as it introduced something called “XTypes”, which allowed developers to generate UI configurations based on JSON in addition to more UI components, layout options, an updated OOP toolkit, an enhanced component lifecycle and a refreshed documentation system.

XTypes forever changed the way Ext JS applications were developed and were and forever will be somewhat of a mixed blessing. On one hand, you could have server-side generated UI configurations, that controlled your application’s rendering, but on the other hand this feature allowed developers generate entire applications with JSON alone.

Ext JS 2.0 was one of my favorite versions of the framework. It was extremely fast and easy to customize.

Ext JS 2.0.2 — The beginning of the licensing woes

At the very early stages of Ext JS’ development, Jack reached out to the community to discuss license changes and gave his first public insights into of his monetization strategy. With over sixty five responses, Jack then created a second thread to continue the conversation.

YUI-ext was released under the BSD license and Ext JS 1.0 was released with the LGPL license. With Ext JS 2.0.2, the license changed to GPL and spark a significant controversy on the web and is where many community advocates decided to break off of the Ext JS bandwagon.

Discussions in the forums began in April 2008, but they were preceded by publicly damning of the framework on places like C|NET, Slashot, Ajaxian and other personal blogs as early as February that year.

The following quote really summarizes the net negative effect of this change on the community and its full blog post can be found here.

The saddest part about this is that the Ext team really have built a fantastic library, and a vibrant community around it. The library had all the hallmarks of an open source success story. Now, however, Ext have committed the cardinal sin of an open source project: they have undermined the trust of their own community. I can see the strategy making a short term profit, and perhaps even a long term business. I cannot, however, see the community returning to full strength. In the long run, although Ext may have a successful commercial offering, they will lose a large part of their current and potential community to competing and still-open projects. The power of the community will see those competitors flourish.

This was spot on. A lot of people were very soured by the change and left the community. The negative sentiment was so bad in the community that Jack Slocum began to receive personal attacks, which prompted his first public response on his blog.

Ext JS 3.0

This version introduced Ext.Direct, a server-side platform that allowed for RPC calls to be set up rather easily. We also saw Flash-based charting that used the early YUI charting components (yeah — I wasn’t a fan either) and a new light ListView component. This version would be proven to be an evolution of Ext JS 2.0 and the Ext JS developer base continued to grow.

Sencha is formed

In June 2010, the formation of Sencha is announced with offices newly located in Palo Alto. News of this change was received very well, though the community began to recognize that the inventor of Ext JS had not been as involved in the community as before.

Sequoia Capital partners helped seed funding for Sencha and the net result was a very bright future for the newly minted company. With the addition of this new funding, a lot of amazing engineers were hired and moved to Palo Alto to participate in a rather aggressive schedule of new products. Sencha would go on to create Sencha Touch, the world’s first mobile HTML5 application framework in addition to a few other products that didn’t fair well in the market.

Sencha Touch was originally developed with support for WebKit only (Android, iOS) would remain separate from the desktop framework until they were unified in version Ext JS 6.0.

It’s important to note that here, Sencha expanded its engineering team by acquiring technologies like jQTouch, Raphael JS and a few other open source technologies. Sencha also began to hire on key community contributors and enthusiasts. These actions would also change the Sencha community.

Ext JS 4.0

The fourth version of the framework was a very ambitious project to revolutionize how Ext JS applications would be developed. This would be the biggest overhaul of the library since the 1.0 to 2.0 rewrite and I had the pleasure of working on my second Ext JS in Action book during the development of this framework.

• An all-new class system was introduced to the framework. From a (radically simpler) single method call, developers could define their class within it’s namespace and register the XType. In addition to this developer experience change, we saw the introduction of Java and Ruby-like language semantics added to the framework, which include Statics and Mixins.
• Initially met with skepticism from the community, a new MVC pattern was introduced into the framework, which would prove invaluable some years later.
• In prior versions, developers could only override, extend classes to inject functionality into a component. To solve this problem, component-based plugins were introduced into the framework.
• The YUI-based Flash charts were kicked to the curb in favor of a pure HTML5 solution.
• The GridPanel and Tree Panel went through a massive rewrite and became more like close cousins rather than distant relatives in previous versions. This allowed for significant code reusability across both UI patterns and leveraged the newly minted plugin architecture to allow developers to enable features like editing or BufferedView (vertical pagination) with ease.
• Inspired from Adobe Flex, the framework introduced two new layouts, VBox and HBox. These immediately became a huge hit in the community. To make this happen, the layout engines were rewritten to introduce code reusability and efficiency across layouts.
• Introduction of Sencha Cmd, a command line tool that would help you bootstrap, upgrade and create builds.

With the release of Ext JS 4.0, we witnessed a third revolutionary change to the framework. This was initially well-received in the community, though the framework did not deliver on its promise for some time to come.

Ext JS 4.0 performance problems rock the community

Many changes to the framework were marketed under the veil of performance. Released April 26, 2011 Version 4.0 of the framework launched with a negative reaction from the community. These performance issues would not be resolved until many precious months later and were arguably the cause for another major fracture in the community.

With the updated architecture, Sencha’s engineers were on to something great, but it felt rushed.

GridPanel — arguably the most widely used component — was re-engineered to accelerate performance. But the community would deal with performance issues for sometime after its release. Other components, such as TabPanel, suffered from reduced performance as well. One community member posted that Ext JS 4.0 was “Slow as hell”.

Sencha responded with a rapid campaign of bug fixes and updates. It wasn’t until version 4.1 of the framework that serious relief in performance would be achieved as detailed in this fantastic blog post and version 4.2 which brought the promises of a faster (and stable) buffered GridPanel component as demonstrated in the below video.

To me, this version would be the “Windows Vista” of Ext JS releases. While version 4.0’s new architecture was a major leap forward for the framework, performance and stability issues with core components such as the GridPanel made using the framework rather difficult and pushed a subset of developers away from the framework.

Version 4.0 was also the first version that introduced a radically new way of theming your application with SASS and would undergo a few major breaking changes through its lifespan.

During the life of Ext JS 4.0, the community itself began to change. We saw core team members at Sencha depart the company in waves. These changes would also negatively impact the community.

The Sencha community was impacted by the release of Angular JS by Google. Many developers jumped onto the NG bandwagon and never looked back.

Ext JS 5.0

This version of the framework was rather light in architecture changes when compared to version 4.0, but it brought forward new core features that would prove useful in the onset, but later show to increase the complexity of Ext JS applications.

Such features include Model View ViewModel (MVVM), data binding with validations and routing. Most developers who were using 4.0 were used to the prior MVC patterns and most felt that it presented an adequate platform to develop and maintain large scale applications.

The introduction of MVVM was not required by Sencha but strongly suggested as a best practice and many developers (including myself) adopted the strategy. Depending on the size of the application, the net result could be hundreds of additional view model files introduced to your source code.

Version 5.0 of the framework introduced Tablet support, which was well regarded in the community as prior versions did not execute well within the confines of these (at the time) relatively new devices and would plant the seeds to the unification of Ext JS and the mobile bits of Sencha Touch.

A deadly blow to freelancers and the supporting community

With the release of Ext JS 5.0, Sencha changed its pricing model and that would cause irrevocable damage to the community.

Since the beginning, Sencha sold single-seat licenses. This allowed a very healthy pool of freelancers to thrive off of the industry that was born from Jack Slocum’s vision to create an extensible web UI framework in 2006. I can speak from experience as my career is a product of this vision, its earlier community and the industry that was created.

This would all change when Sencha’s pricing model removed the single seat license in favor of a 5 pack of licenses in 2014 and would prove to be a deadly blow to the community that had supported it. As a result of this change, Sencha community developers took to Twitter, blogs and the Sencha forums to vent their frustration.

Looks like I’m among the majority who were shocked to see the price jump so high. I can’t believe that I just pitched the idea of using Ext/Touch at my new job and of course they went for it. Guess it’s my fault for assuming the price wouldn’t skyrocket like this. Now I am going to have to change course, and find something else, damnit.

In response to the licensing change, one upset developer wrote the following in his blog.

The developer uproar should get the decision makers at Sencha to realize they made a mistake. If they reverse course that’s great, but the fact is in the short term this will make them more money. But in the long term, as less and less new developers make it into large companies they will start loosing that business. The developer eco-system is a long play, don’t sacrifice long term survival in the name of short term gains.

The only thing I can say is that if your looking at Sencha Touch for mobile development stop right now and look at the Ionic Framework or Kendo UI instead. Don’t let the ‘amount’ of controls affect your decision, it’s not quantity is quality, you can easily build anything you want with either solution.

Shawn’s thoughts completely summarized a majority of the community’s reaction to these licensing changes. Unlike 2006, there were tens of thousands of JavaScript frameworks and libraries for developers to choose from in 2014 and many Sencha community members focused their efforts in helping build communities around Angular JS, Kendo UI, Ionic and others.

Ext JS 6.0

The merger of Ext JS and the best bits of Sencha Touch found its way into the framework in this version. For many developers and organizations dependent on Sencha technology, this unification of the frameworks was well received as the differences between Touch and Ext JS were a sore point.

React JS gains popularity and the Sencha community continues to decline

React JS entered the community in 2012 and slowly gained popularity in the JavaScript community. Around 2014, its popularity began to accelerate and in 2015, we saw the introduction of React Native, which further intensified the adoption of the (now labeled) React Ecosystem.

Looking for alternatives to Sencha, many programmers (both prior employees and community members alike) found React JS and fell in love with it.

Much like the early Ext JS community, the React JS community invests in itself by providing freely developed components and it’s this continued investment that helps make the transition from Ext JS to React JS much easier. And like the early Ext JS community, the React JS community is live, vibrant and very much involved with evangelizing and improving the framework.

The uncertain future of Sencha and it’s communities

Sencha’s back and forth with license changes, in addition to the missteps with pricing and history of failed product releases have damaged the community and the industry it created, quite possibly to the point of no return.

I’ve personally been involved with the Ext JS community for over a decade and have helped companies develop mission-critical software using Sencha technologies and over the past three years, these same organizations have decided to pour money into migrating off of the Sencha platform because they simply do not trust in Sencha’s ability to deliver. The sale of Sencha to IDERA only amplifies those fears and may lead to a further decline of its battered community and struggling industry.

On to better things

I disconnected from the Sencha community in 2015 and will miss the good old days of the early Ext JS community. I am sad to say goodbye as I have many fond memories and have built life-long relationships with amazing people across the world.

I am glad to leave Ext JS behind to focus on technologies that have greater investment by big companies like Facebook, Microsoft and Twitter and are valued by the global community of JavaScript developers. I believe that Sencha can learn a ton by studying many of the communities surrounding leading edge technologies and hope that they can implement changes that are in the best interest of their communities and technologies before it’s too late.