Yesterday I took my second swing at learning Ext JS 4.1 and spent 5 hours on their MVC tutorial. First, I’d like to point out that while their naming conventions and directory structure conventions are highly organized, look at the files you create during the tutorial.

You have the following files open in your editor:

1. Users.js – app/controller
2. User.js – app/model
3. Users.js – app/store

That doesn’t lead to any confusion. Nope, nope, not at all…

Ext JS4 Uses Sophisticated JavaScript

Ext JS 4 is a complete re-think and re-design from Ext JS 3. (I don’t have experience with v3; the Sencha website points this out and has several transition guides.) The application is cleanly separated into the Model-View-Controller pattern. The code makes excellent use of JavaScript classes and studiously avoid polluting the global namespace, and the whole thing is organized around non-blocking, asynchronous actions for performance. All of these are good things. This has been thought through by people who have lived with less well-designed tool kits and worked with code that allowed the weaknesses of the JavaScript language design to overcome its strengths.

When I made my first try at Ext JS a few weeks ago, I didn’t know enough JavaScript to really understand what is going on. I’m an experienced programmer with lots of languages under my belt but the JavaScript “class is an instance” and prototyping were new to me. Since then I’ve read and worked extensively with JavaScript.

A Second Attempt

This time my challenge was the asynchronous, auto loading, auto-everything nature of the toolkit. “When [it] is good it is very good, but when [it] is bad it is horrid.” (With apologies to Longfellow.) The difficulty with all this asynchronous, auto-everything is that when there is a problem there with how you’ve hooked up the MVC components, you generally don’t get an error. Rather, things just don’t work and without a clue as to why. This is not a small toolkit: the “very simple” tutorial loads 162 JavaScript files from the library. There’s no stepping through that. Also, there is very little imperative code during creation of the MVC; almost everything is deductive. You cannot find a line in the code you wrote on which to put a break point.

A Site To Investigate

Last night I was sufficiently frustrated that I had decided to give up on Ext JS and work with other frameworks and libraries. And I inadvertently found a website of great interest while searching for which frameworks/libraries have To-Do functionality, because that is something that I need immediately.

The site, with the header TodoMVC says it best:

Developers these days are spoiled with choice when it comes to selecting an MV* framework for structuring and organizing JavaScript web apps. Backbone, Spine, Ember, JavaScriptMVC… the list of new and stable solutions goes on and on, but just how do you decide on which to use in a sea of so many options?

To help solve this problem, we created TodoMVC – a project which offers the same Todo application implemented using MV* concepts in most of the popular JavaScript MV* frameworks of today.

The Glory and Pain of Ext JS4

I’ll certainly be working through the various implementations on TodoMVC. After a night’s sleep (and seeing some additional documentation and examples, I’ve reconsidered about Ext JS. I’m willing to give it another go, albeit with trepidation.

Ext JS reminds me of a C++ 3D visualization library that I used on my thesis, VTK. The library was flat-out brilliant, with enormous functionality that handled much of the graphics heavy lifting. The problem was that it was (still is?) a pipelined architecture, as a Producer-Consumer chain. The difficulty came about when something didn’t work: a wrong setup or erroneous input usually just produced no output or else the app crashed. There were few errors. And because components were run in distinct threads before the time that debuggers really supported threads – good luck! The insides were large and complex and therefore essentially opaque. I fear the same may be true of Ext JS. I would rather use a less capable architecture than one which is opaque to me.