Thursday, April 4, 2013

ExtJS: desperately need a debug version

Update to this post: there is a debug version.

I missed it when using ExtJS 2, then with ExtJS 3. Now I'm using ExtJS 4 for a new web user interface, and the situation is the same: I desperately need a debug version of ExtJS!

On the plus side: The best web gui toolkit

ExtJS is, in my opinion, the most complete JavaScript library for making desktop-like apps in the browser. It has been there for long time, and is actively developed. It's relatively easy to extend components and develop your own. The community is large, the documentation is OK, and it's possible to create useful, functional, "rich" user interfaces. It's possible to get the job done.

Beware: It's a full time job

The examples look nice, and one could get the idea that it's a quick and easy path to develop your own rich gui. Nah. It's all trial and error F5 style development. It takes a lot of time and effort to get halfway fluent with it. There are many gotchas to learn about.

It sucks the energy out of me

For me, working with ExtJS is no pleasure. It brings a new flow stopper way too often. Why?
  1. The nature of JavaScript.
    JavaScript is not a type safe language. There's no safe refactoring. No compile time confidence. That's a fact, nothing to improve here.
  2. ExtJS performs no checks.
    No input checking (preconditions, assertions), no checks for common errors.
Let's look at an example: "Uncaught TypeError: Object #<object> has no method 'read'"</object>

Aha, some script execution error occurred. Let's check the detail:

Not that helpful. Something internal in ExtJS on line 39145 failed. ExtJS does not catch this one (or any other) and tell me what the real problem is. Nor does the stack trace go back to my userland code.

In this case the problem was that I did not include some data store model prior to using it. My fault. But it doesn't have to be. There are plenty of reasons for such time consuming debugging, just because problems are never detected, and throw at last moment, deep down:
  • Developer error: wrong API use
  • ExtJS bug
  • ExtJS annoyance
  • Old code: upgrading an older app, or copying an older example from the internet

But wait: I'm using "ext-all-debug.js"

Unfortunately, the naming of the ExtJS JavaScript files is, imo, wrong.

JQuery got it right:
The original JS file, with apidoc:
The minified version for production:

This has become the standard, and makes perfect sense. The minified file name contains the ".min". And they both contain the version number - this way there's never a web browser having a stale version in the cache.

ExtJS files:
ext-all.js: The minified JS file.
ext-all-debug.js: The original source code, comments stripped. Useless.
ext-all-debug-w-comments.js: The original source code.

What I (and probably every other ExtJS developer) need is a version that contains code with input checking to throw as early as possible, with a meaningful message. You know... common  programming practices... absolutely mandatory for any library code.

Summing it up

As it is now, you have to test every single functionality to be sure it works. Upgrading an app from ExtJS 3 to ExtJS 4 is no fun. Lots of things don't work anymore, but you have to figure out a) which and b) what to change. And the same will be true for version 5, 6 and 7. And any minor upgrade can break things too.

If you have ui tests then at least you will know about some defects early. But you still need to figure out the hard way how to fix them. And writing and maintaining automated ui tests is another full time job.

Please, Sencha, do yourself and every of the 2 million developers a big favor and add error checking to your libraries, and strip it in the "min"-ified production version for equal performance and file size.


  1. Thanks for the info! I've updated my code and written a short follow-up post:
    I'm using it now and my first impression is that there's not much error checking, but at least some. I'll see if it improves my development experience.