Home » EXTjs » 7 Reasons To Evade Ext JS

7 Reasons To Evade Ext JS

I’ve worked with Ext JS now for a total of 2.5 years.  First with Ext 4.2 and now with Ext 6.x.

Here’s my experience, and warning, of why you should avoid this disaster of a framework.

7 Reasons To Evade Ext JS

Jack of All Trades

Master of none!

One of the great selling points of using Ext JS is the fact that it comes with “Everything you need” to build a web application.  That would be great if it were true.  But the fact of the matter is, it comes with all of the features you need but the features are all only partially implemented.  I’ve complained publicly several times that Sencha can’t possibly be testing the code they release because it only works in their demos.  If you try to use a feature they have documented as being available, you are likely to find that the feature doesn’t actually work.  How is it possible that you’ve written documentation for how something is supposed to work and yet you can release it without it working properly?  I can understand fringe stuff getting by.  We can’t think of every test.  But when this happens over and over again, you start to wonder what exactly they are testing.

A Wolf in Sheep’s Clothing

When I first started with Ext, the only design pattern they had available was what they referred to as MVC.  It took me two months of playing with the framework before I finally realized that what they were calling MVC wasn’t anything the Gang of Four would recognize as MVC.  I guess if you have a View, a Model and a Controller, you can call it MVC?  It doesn’t matter that the Models define records in a table or that the Controller is tightly coupled to your view.

Sheep Without Legs

OK.  So when they introduced the MVVM architecture I actually started to have just a bit of hope.  Yes, there were still some fundamental issues I have, but MVVM would make this tolerable.  But here is the issue.  Their idea of MVVM is that you would only need to implement it on a per page basis.

Let me try to explain.

Broken Data Binding

In my ideal world, when I build a new component, I would build that component using the framework the rest of my application is using.  So my component uses MVVM.  Sencha’s implementation gives you a View, ViewController, and ViewModel.  Mostly this looks more like MVC if you ask me but whatever, it has two-way databinding, so we’ll call it MVVM for now.  If you build a component that lives inside another component, the first thing you’ll discover is that binding only works from the top down.  That is, I can bind data at the outer layer and it will get reflected all of the way in to the inner most component that uses it.  But, if you change the data in the inner most component, it doesn’t reflect back up to the outer most component.  I’ve written a hack for this, and there is no promise from Sencha that this will ever get fixed properly, so I guess my hack is safe.

Broken Controllers

But it gets worse.  While child components can find data in models that are in parent components properly, they can’t find references to functions in controllers in the same way.  This is particularly problematic if you write a component that is a container of other components.  You would naturally want the child components to use the controller from the component that they were declared in.  But if you have an outer component that has your container component as a child and then other components inside of that.  The only way you can control what controller the child most components are going to notify of events is by wrapping the inner most components in their own component with their own controller.  This gets to be awkward when all you want to do is provide an event handler for one control in a column of a grid control.  Again, I have a monkey patch that fixes this, but why did I have to write it?

This is just one specific example of my “Jack of All Trades” point that I started with.

We won’t even address the question of if this is really MVVM or not!

Never Use the .0 release

I think most of us now are generally conditioned to be wary of the .0 release of anything that hasn’t been developed using Open Source methods.  There just haven’t been enough eyes on the project to ensure that everything works as it should.

But with Sencha, this extends to all of the patch releases at the very least and even into some minor releases.

While the 4.0, 5.0, and 6.0 releases were unacceptably broken, we find that every new patch or minor release that comes out afterward breaks something that was working.  We always have to ask, “Can we live with this?”

All or Nothing

As I said at the beginning, Sencha gives you everything.  That sounds good.  You won’t have to go looking for a grid control, or many other common controls you might want to use.

But the bad news is, you can only use controls that were written to be used with Ext.  Which other than what Sencha provides in the framework, doesn’t give you a lot of choices.  Don’t go thinking you’ll supplement Ext with a selection of third party controls.  It’s not going to happen.

Fences Protect AND Isolate

Up until this point in my post, no one can reasonably argue that anything I’ve said is actually a benefit.  At this point we switch to points that may vary based on how well you know JavaScript, HTML, and CSS.

You see, the good news, and actually a major selling point to many people, is that you can write a web application using Ext without having to know much, if anything about HTML or CSS.  And for that matter even the amount of JavaScript you need to know is relatively limited.

That’s the good news.  The bad news is, if you know anything about any of these, you’ll probably end up frustrated by EXT.  This is because Ext’s JavaScript controls most of the layout.  So if you are used to going into developer tools to tweak the CSS and then applying that to your style sheet, you are going to be very disappointed.  Pretty much nothing you do in developer tools is going to work as you would expect.  And figuring out how to apply those to your code is going to be a lot harder than you are used to.

Their Way or the Highway

Once again, many people see this as an advantage.  And once again if you aren’t familiar with how the rest of the JavaScript world does things, this is going to sound fine.

Sencha CMD

Everything runs through Sencha CMD.  A tool for building all things Ext.  If you want to bundle and minify your code, the standard way of doing this is by using “requires” statements in your code and then running Sencha CMD and have it figure out what you are using and put it all in one bundle.

The problem with this is that there are several much better ways of doing this that are available using Node and various NPM packages.  Again, if you are a JavaScript developer, you are going to wonder what Sencha is thinking.

Ext.define()

Another place where proprietary shows up is in how Ext defines “Classes”.  When it was first introduced, TypeScript was new.  But now, we not only have TypeScript, which does much of what Ext does and some things it doesn’t, but we have an evolving JavaScript standard that I’m afraid Sencha won’t be able to keep up with.  They already discourage the use of ‘use strict’;.  Once again, there is only one place where this will get you in trouble, and the work around actually produces more efficient code.  But still, the point is, Sencha is relying on ECMA Script 3 standards while the world has largely moved on to ECMA 2015 and beyond.

Anyhow, my point here is that Ext is not just a framework but also functions, largely, as its own language.  Not quite as much a fork from the standard as Coffee Script, but also not nearly as close to the JavaScript spec as TypeScript.  So while it is still JavaScript, if you are a JavaScript programmer, it isn’t going to feel quite like JavaScript to you.

Themes

The final place you will find “Proprietary” lurking is with the Themes.  There are several really good CSS frameworks out there.  Sencha uses none of them.  And while the syntax they use for creating themes has been SASS up until Ext 6, now they even have their own proprietary SASS compiler.  Watch out here because they are still using the SASS extensions so you are likely to make some assumptions here that aren’t true because, once again, they’ve only implemented enough of the SASS engine to do what THEY need to do.

VB All Over Again

Every time I hear someone praise how great Ext is, it is normally because it has everything you need out of the box and allows you to get stuff done quickly.  Basically the same argument for using Visual Basic back in the day.  And yet I learned to never take a VB job because it almost every instance, while it was possible to write well structured code in Visual Basic, it was generally so difficult to do that the code I would be maintaining would need to be rewritten in order to make any sense of it.

Ext suffers the same issue.  There is nothing in Ext to force you to write well structured code.  The code I have had to maintain has almost always followed every anti-pattern known to man.  In this case, this isn’t Sencha’s fault directly other than the fact that the only reason my code tends to be cleaner than most is because I’m more likely to code a fix to an Ext bug than I am to work around the problem with an anti-pattern.

In comparison to other frameworks that are available, if all you want is a tool that will get you a semi working application quickly, and you don’t care so much about having to rewrite it when you need to change it in some way, Ext is your tool.  If on the other hand, you care about design and you want to be able to maintain what you’ve written, you should look elsewhere.

Remember, if it sounds too good to be true, it probably is.

 

Other post in EXTjs

Related Post

  • Ext JS 6 by Sencha – The Good, The Bad, The UglyExt JS 6 by Sencha – The Good, The Bad, The Ugly 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 […]
  • How Not to Choose a FrameworkHow Not to Choose a Framework In my job as a JavaScript architect, trainer and mentor, I’m often asked, “What’s your favorite framework?”  Or “What is the best framework?” And it surprises people when I give them two […]
  • EXT DataBound CheckboxGroupEXT DataBound CheckboxGroup Today I’ve decided to post a control I created for EXTjs that might be useful to you.  The problem I was running into was that I had a group of checkbox controls that all needed to be set […]
  • Reactions to React JS and Associated BitsReactions to React JS and Associated Bits I’ve been learning React JS over the last several weeks.  Currently, I now know 4 of the major JavaScript frameworks: Angular 1, Angular 2, EXTjs (4.2 – 6.0.1), and now React JS.  To be […]
  • JavaScript Crazy Talk – Are you guilty?JavaScript Crazy Talk – Are you guilty? I heard this so frequently, I decided it is time to write about it. (When writing web applications)  Business rules always belong on the server. One of the last conversations I had at […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer focusing on ASP.NET, C#, Node.js, JavaScript, HTML, CSS, BootStrap, and Angular.JS. Does your team need additional help in any of the above? Contact Dave today.

  • Let’s pretend I don’t work for Sencha for a moment, I still take issue with many points here. Being someone who has spent a decade with Ext JS and built successful applications for internal and customers, I would like to disagree with you.

    First I’d like to say is you saying don’t use a .0 release. Maybe I’m just more of an expert in Ext JS but I develop using any Ext JS release and upgrade to any Ext JS release and fine only minimal issues. Yes, 4.x was a mess but if you’ve noticed the people in charge of the framework then are now gone and 5.x and 6.x are much much better (I upgraded from 5.1.1 to 6.0.0 in 15 minutes). 4.x introduced many breaking changes for each release but that’s because a lot had to be done to get perf somewhat back in order. It’s like if your car runs like crap, you may end up replacing the engine.

    All or nothing as a bad thing? I guess you hate Apple for not letting others build a phone that can run iOS? I enjoy having a common api for all pieces. This is one of the strong points of Ext JS.

    MVC/MVVM Before MVVM I never understood people’s issues with the controllers. You say they are tightly bound to views, I’m sorry you were programming wrong. Yes, getting events from views you had to setup the ComponentQuery selector to get it but once you’re into an event listener, what you do in the controller is up to you. If your controller methods became tightly bound to a view then you were not architecting things properly. For MVVM, I’m not familiar with your need for a hack. Just created this simple example: https://fiddle.sencha.com/#fiddle/1dkk and if I change the value of the textfield the form’s title changes. If I click the button, the form’s title and textfield’s value change as you’d expect. Maybe link to the situation that you talk about for clarity?

    Cannot use CSS to layout items? That’s just plain false. Sure, if you opt into using one of Ext JS’ layouts, the JavaScript will control things (since IE8 is still supported you know). But if you don’t specify a layout, it will still use ‘auto’ layout but it doesn’t really do anything. For a simple example: https://fiddle.sencha.com/#fiddle/1dkl Easy, just a couple divs with minimal CSS that can easily be overridden even.

    Sencha Cmd… we used to have build tools using Node but many of our clients said they couldn’t get permission to install Node on their machines, good ole enterprise IT! These days, Node is more accepted but having Cmd tightly integrated with Ext JS and now other products is a huge win. We aren’t constrained by someone else’s project, once again the all or nothing argument is a pro also. I know today’s web dev wants to use x, y, z and create their own thing but having a single thing that every Ext JS dev can use the same command line (no grunt vs gulp vs whatever arguments). Cmd is also something else I use with success and with ant under the hood I’ve done some great things with it.

    Ext.define is more powerful than ES2015+ class, simple as that. Sure it’s using a custom class system under the hood and the use of callParent makes ‘use strict;’ impossible but not everyone is able to use a browser that supports ES2015. For example, have you walked into a bank and noticed what OS they are using? I walked into Bank of America the other day to refinance my truck and the browser he was using, IE9. Ok, so you can transpile it back but then I’d ask you about backwards compat for the Ext JS api with new ES class. You’d loose functionality. Not saying it won’t happen but right now the ES class needs to mature and catch up.

    Themes are great in Ext JS using SASS and inheritance. Fashion is a JavaScript SASS like compiler that we’ve been in communication with the SASS and compass people. For my uses, I use plain SASS and have zero issues with Fashion compiling it. If SASS releases a new feature then yes, if people ask for the functionality we’d have to write it in Fashion which may take some time. However, Fashion is like compass only with JavaScript. Not sure your issue there as I’m sure you’ve used compass which is a Ruby SASS compiler. Are the people behind SASS maintaining compass? And like the CSS argument above, you could still use a CSS framework with Ext JS. In the end, it’s all HTML/CSS in the DOM so you can do whatever.

    • I’m so glad to hear from Sencha. Really. I’m hoping to get a lot of these issues

      Since 4.x is water under the bridge at this point, I’ll ignore your comments about that. Maybe there was a better way. Unfortunately the documentation we were provided didn’t make that other way obvious to us.

      Regarding my comments about 6.x, these are my personal experience and I have recognized bug reports filed for every “hack” I’ve had to create with no commitment regarding how or when they will be fixed. EXTJS-15503, EXTJS-15354, and EXTJS-21727 to be specific.

      Regarding my comments about .0 releases. This was true for 5.0 and 6.0 and is as recognized a problem with Sencha products as 1.0 releases have been with Microsoft products. And in fact, we find that stuff that was working in previous minor releases breaks while fixing things that weren’t working.

      Do you have an example of using Bootstrap to theme a Sencha application? Can that be done?

      I believe everything else you disagree with is just a matter of opinion. So, I’ll just leave it at that and let my readers decide which is more important to them.

      • I think the issue with 15503 and 21727 is largely due to working outside of the “package” that MVVM on a per view is. So if a view has a model and controller, it’s only supposed to handle that view and if you want to go above it then that breaks the encapsulation. Will admit we do this for models that a child can bind to data to some parent model and that’s very handy but the more models you have the less perf you’ll have with all the binding targets. With a controller, I 100% think that a child shouldn’t be able to bypass a controller to get to some parent controller. If you want to share code, setup a superclass controller to extend, mixin or a singleton utility class.

        I don’t have an example of using Bootstrap but an Ext JS component could be made to have an HTML structure Bootstrap would want. Your milage may vary on a specific Ext JS component as Ext JS and Bootstrap were never made to work together.

        • In AngularJS, Angular 2, or React, it is “turtles all the way down” That is, I can create a component that implements the same pattern as the view and it all continues to work. When we create components that are container components with their own controller and pass the child components in from the config …. that is, we define the whole view in one page but use a component that has its own controller … the inner components want to use the controller from their wrapping component rather than the controller from the main view.

          One rather common example, I think, is sub-classing a grid component so that the look and functionality that is common in your app is only written once. You still need to pass in the column information, and you would hope that the listeners you define on those columns would call the controller for the view they were declared in rather than the view they are contained by.

          The only alternative, other than the hack I’ve written, is to create yet another child component that you can nest in your container component.

  • Greg Lafrance

    I’ve been using ExtJS for six years so I thought I’d chime in. Personally just about the only thing I like about ExtJS is the fact that through my work I’ve gotten pretty productive in it, and the rates are good. Beyond that I just wish it would die already.

    Once you get good at ExtJS you can be pretty productive. Using Ext.define() works very well to create a large application because you can easily extend the framework grid panel, form panel, etc. or just create something new by extending the ExtJS container.

    And refactoring is very doable, for example the code base I currently work on is horrible to a large extent. Duplicated code everywhere, and overly complex. It is fairly easy to pull out the code to a separate component and use that component where the duplicated code was. You have to deal with how the code and event handlers were being implemented in those multiple places, but you would have to deal with that in any language.

    Styling is tough only because of the horribly bloated DOM ExtJS generates, and the need to find that magic CSS selector to style what you want. But if you put in the time to learn ExtJS styling and theming, it becomes easier.

    And ExtJS stores and models make it easier to get data in and process it.

    I could go on with many other aspects of ExtJS that are somewhat good and make you productive, but I really want to get to what I dislike about ExtJS.

    As a company, I don’t really like Sencha. In the forums their employees either leave most questions unanswered, or else treat the questioners like dirt. They make comments that come across like “are you dumb of what” all the time. “Animal” is one of the worst. Really unprofessional and pathetic. Just no excuse for that.

    The JavaScript revolution is going on, but with ExtJS you are largely in a box, and can’t use it with many other libraries and frameworks. You can do it, but at your own risk.

    Sencha CMD is a blessing and a joke. Learn how to use it and stay within a narrow usage pattern and you are fine. But if you don’t have the exact version required by the app, good luck.

    So overall I would say ExtJS is good to be productive once you get used to it, but that takes two to three years.

    But you have to pay for it, and bonehead Sencha multiplied the price 10x and alienated many developers.

    ExtJS is being used, but is widely hated, even by those who use it, and when Sencha investors finally wise up and stop pumping money into this lost cause, the money will dry up, it will go to open source, maybe, and then it will simply die. And then we can celebrate and big enterprise companies can also use angular/react etc. and contribute to the JavaScript revolution.

    I like ExtJS in some ways, but it really sucks.