Very recently, Sencha released the newest version of ExtJS–4.0. This release was significant, in addition to other important changes, because ExtJS 4 signals a real shift in how Sencha is pushing developers to use ExtJS. Before, you could really kind of hack together ExtJS apps, regardless of how well your efforts aligned with “best practices.” The same is still true, I suppose, but ExtJS 4 is now all about MVC…and they are quite vocal about it.

By this, I mean that this rework of the framework has been explicitly designed, optimized and advertised to be used in a very particular MVC-ish way. There are even some fairly involved (but still inadequate, IMO) tutorials that describe the “preferred” way for designing a full-on MVC ExtJS 4 app, and the SDK comes with some tools baked in that will even build out the “preferred” structure for you.

So it just so happened that mere weeks after the release, I had the opportunity to develop a new app, and I decided to take the dive into ExtJS 4. Here are my thoughts on the experience, in no particular order.

Learning…and Learning

First, the learning curve–for me at least–was initially pretty steep. It wasn’t so much the MVC aspect of ExtJS 4, but just the decided lack of documentation about how to implement this new preferred way. Yes, Sencha’s API documentation has a “guide” for building an MVC app. However, the example app is way too simple, and the relationships between the M and V and C’s of the app are so canned, that it is tough to extrapolate the principals directly to real, “messier” apps.

However, I persevered, kept reading the docs and trolling the help forums, and finally got into the flow of what I needed to do. Although my initial experience was, honestly, a bit painful and frustrating, I quickly began to see the benefits of this “preferred” approach. Once you get everything set up to use the MVC optimizations of the framework, you can really start to fly in your development. Even though this was my first ExtJS 4 app, I really think I developed it faster than any prior ExtJS app…and I think the MVC approach was the main reason why.

Dynamic Loading is Awesome

One really cool part about ExtJS 4 is the dynamic loading system. Basically, this prevents you from having to load the entire framework just to render a form field, for example. Rather, the dynamic loading system will retrieve the necessary classes when they are needed…and only then. But the coolest part about this, for me, is that custom controller, model, and view files are dynamically loaded as well. So, for example, you could create 5 model files, 5 controllers, and a dozen or so views, and NEVER have to link any of them on any of your html files. Rather, you simply set up the ExtJS application, point it to the correct path on your system, and it will take care of loading up the files as necessary.

I love this because I tend to create a bunch of files in a very short period of time. The thing I always forget, however, is to add the stupid link on my html page. Now, this is no longer an issue. I simply create my files as normal, and the framework takes care of the rest. Very cool.

The Line in the Sand

To be perfectly honest, I’m very excited about the possibilites of ExtJS 4, and I’m excited to get to work with it on future projects (and maybe a re-write of Gloss, once I’m invited to the Sencha cloud beta…). However, I am a bit concerned about what this means for the future of ExtJS.

As I mentioned before, this new MVC-based approach is not simply another “feature” for the new release. No, if you look through the blogs and screencasts, you quickly understand that this is the direction that Sencha wants to move ExtJS developers. On the positive side, there is much to be said for this move. Obviously, if ExtJS developers adopt this paradigm wholesale, there will be a lot more cohesion and understanding baked into the community. As Sencha itself advocates, if every developer on a team were to learn this model, everyone would always be on the same page when it came to developing ExtJS apps–and new developers would have a very clear path for orientation and training. I see the logic in this position, and I hope it works out that way.

However, I also see this move as a line in the sand–whether intentional or not. For ExtJS developers who aren’t willing, able, or interested in going down the MVC path, I think it could be good motivation for some to seek greener pastures in jQuery, or other JS frameworks. I think many of these would probably continue to use pre-4 versions, but it might definitely stifle interest from some when contemplating an upgrade (and messy migration).

But on yet another hand, while such a clear direction from the ExtJS team might potentially scare away some developers, it could also be a very attractive proposition for others. Especially for development teams who are seeking to establish common practices and standards related to development, such a well-defined direction could be quite attractive.

Wrapping Up

I feel like I have more to say, but I’ll wrap up instead :). Regardless of what happens as ExtJS 4 continues to roll out, I am personally excited about the prospects. While my one experience ran the gamut of frustration and jubilation, on the whole I came away pretty pleased with my work, and I feel that new changes introduced in 4 will only be a boon to my development efforts.