Long time readers may remember that I started using Ext JS about 3 years ago. At the time, I was using version 4.2.2. I recently started a new contract where they are using Ext JS 6.0.1. I have to say, this version solves a lot of the architectural issues I had with the 4.x series. But, there are still problems.
Since I’ve provided an evaluation of Angular 2 and React JS, I thought providing an evaluation of the current version of Ext JS would be appropriate since these three seem to be the main players in the corporate world.
Ext JS – The Good
I’ve always had three major complaints about Ext JS. Of the three, the fact that Ext JS is nearly impossible to test is the one that drove me away. In fact, I almost didn’t interview for the contract I have now because they are using Ext JS. This is because the 4.2 version that I was using implemented what they called the MVC framework. The problem is, the MVC framework they implemented was not anything the Gang of Four would recognize. Once I realized that what they were calling MVC wasn’t really MVC, I was able to learn how to use the product much better.
But being the TDD guy that I am, I was always frustrated by their implementation of MVC because in order to test anything in the Controller, I had to have the view available. And while I tried several ways of mitigating this problem, I was never completely satisfied with the solution. I ought to be able to test my controller without a view, or if I have to have a view, it should be some sort of fake view, or be able to render into a fake DOM like React JS does.
But, in Ext JS 6, they’ve provided an alternate framework. This time it is also more accurately named. They have provided an MVVM implementation. In the View, you provide your layout, declarative syntax to access the View’s state from the ViewModel and to specify the event handlers using listener blocks that tell the view what methods to call in the associated ViewController class.
In the ViewController, your methods can access the ViewModel by calling getModel() and can set the state of the view by calling the ViewModel’s set() method. Once this is done, the View can update using the ViewModel’s new state.
What this means for testing is that I can test without the View by overriding the ViewContoller.getModel() method to return the ViewModel. Run my test for a method and check the state of the ViewModel. Look Ma, no View!
Everything You Need
One of the biggest selling points for using Ext JS is that just about everything you could need is provided for you in once product. Unlike Angular or React JS where one project provides the framework and another project or projects provide components, nearly everything you are going to need for your application is provided out of the box. This is not to say that there aren’t third party providers for Ext JS, but the need for them is very limited.
One of the major attractions Ext has offered is that you don’t need to worry about cross browser rendering issues. If you still need to support REALLY old browsers, this may still be a big selling point for you. I think this will matter less in the future as the browsers continue to stabilize around standards.
Even though Ext JS uses a none standard way of rendering controls (see below) they do manage to achieve Adaptive and Responsive designs.
Ability to Control DOM Manipulation
Finally, if you are having trouble achieving performance with the current way you are rending DOM changes, you will be happy to know that Ext JS does provide a way of turning of rendering to the DOM while you make all the changes and then turning it back on to do the final rendering. But, at least my last usage of this, indicates that it doesn’t really turn off ALL DOM manipulation. If you are inserting new DOM elements, those go out to the screen. All Ext JS really does is to turn off their layout code.
Who Ya Gonna Call?
One of the strongest reasons many organizations choose Ext JS is because the price of the license gives you access to Sencha support. Companies I’ve worked for have used this for everything from “My code doesn’t work, what am I doing wrong?” and actually getting an answer to “I think you have a bug here.” and getting the bug fixed. Kind of a private StackOverflow with direct access to the programmers who wrote the framework.
Ext JS – The Bad
Standard JS best practice recommends placing “use strict”; at the top of you IIFE block to protect you from making stupid mistakes. Unfortunately, you can’t do this in your Ext JS code without having to work around the problems it produces.
As I mentioned above, Ext JS does their own layouts in order to achieve a presentation that will look the same regardless of what browser it is running on. However, the cost of this is that if you nest components too deeply, rendering your view or changes to your view, will take significantly longer than anyone is willing to wait around for. So, to get around this, you end up writing sub optimal code from just about every coding principle in existence. Specifically, DRY and SRP are difficult to achieve using Ext JS views.
Version X.0.0 is Always Broken
I’ve complained about this publicly before. But it seems to me, and everyone else I talk with that has used Ext JS that every .0.0 version is buggy. Things that used to work in the previous version no longer work. Despite the assertion from Sencha that they have thousands of tests. I always wonder what kind of code coverage they have and if they have a test that covers every feature for every component they have documented.
Ext JS – The Ugly
There is a lot that is ugly about Ext JS, but nothing is more visibly ugly than the HTML it produces. This is because, in order to produces a view that will render on any browser, they’ve resorted to using HTML tables to wrap just about every standard control. This is getting better. There is less HTML generated in Ext JS 6 than there was in Ext JS 4, but it is still relatively ugly.
SASS isn’t SASS
Up until version 6, Sencha’s theming engine used standard SASS. With version 6, they’ve dumped standard SASS for their own implementation that mostly does what SASS does but has a few embellishments that aren’t all bad, except for the fact that they still kept the SASS extensions for the files and the syntax is mostly the same.
Will I be able to use the “class” keyword in the future instead of Ext.define()?
None Standard Build Tools
So, is Ext JS for you? That’s a good question. You’ll need to evaluate if the good parts outweigh the bad parts. It isn’t like either Angular or React have everything. There is no perfect choice. There is the best choice for you and your organization.
- WebForms vs MVC–The War Is Over - September 25th, 2014
- Create A Desktop Application using Angular, Bootstrap and C# - October 15th, 2015
- Are You Doing Angular Right? - November 5th, 2015
- Adventures Working With Angular’s $scope - November 26th, 2015
- Using Gulp to Bundle, Minify, and Cache-bust - January 28th, 2016
- Reactions to React JS and Associated Bits - March 17th, 2016
- An Explanation of the Flux Pattern - March 31st, 2016
- Ext JS 6 by Sencha - The Good, The Bad, The Ugly - April 7th, 2016
- Do This To Increase Your Client Side Web Development Speed - April 21st, 2016
- ES2015 Code Coverage and Jest (React JS Unit Testing) - May 5th, 2016
- 4 Reasons To Drop MVVM - July 27th, 2016
- You Can Start Using Node Today - August 2nd, 2016
- TypeScript and Electron The Right Way - September 6th, 2016