You may remember that I blogged about ExtJS before. I was impressed by ExtJS but somehow didn't consider it for my owngoing projects.
This time I'm working on a project that would normally become a GUI application. Fat client-style. But I'm still wanting to make it a web application because I wouldn't like to force the dozens of users to install updates frequently. And I'm also a newbie regarding UI toolkits like Qt or Gtk. So I thought I give ExtJS another try.
You can't hurry love
ExtJS takes some learning. And with the limited literature on the web dealing with programming applications in ExtJS I felt pretty alone. Many tutorials that I found on the web that deal with what I wanted to know only used version 1.x. And 2.x works differently. So I needed support from #extjs (IRC channel on freenode), read parts of the API documentation and the ExtJS forums (why oh why can't it just have a simple mailing list - web forums stink). With jQuery you will get results quickly. But ExtJS isn't just giving you a few JS commands and classes to simplify your life. It's a whole new paradigm really. It's like you code a GUI application that works on the web. If you use layouts and panels and not just simple DOM-manipulating operations then you may need to take your time before you get something done that actually works. The API documentation is very complete. But the classes are wired together and subclassed in a way that you sometimes have to guess which documentation page describes certain attributes. (Where the heck are the items documented in tree panels again?)
I'm using Pylons as a backend and usually I have 70% Python code and 30% in static Javascript and HTML templates. But with ExtJS the equation is more like 30% Python code (for dealing with backend calls and JSON) and 70% Javascript with virtually no templates. Javascript is by far not as comfortable as Python so it's a little drawback. But it's roughly (very roughly) similar to Python so it should feel familiar.
Licensing chaos
Recently ExtJS turned around the licensing terms a little thus annoying many developers in the community. And I must say that I was close to not even considering ExtJS again because they frightened me with their "commercial license". I'm (fortunately) not a lawyer but I'm pretty sure that the only case where you would need to pay for ExtJS is when you write applications using ExtJS that you use publicly and do NOT want to put your application/web site under the GPL. The important result for me was: as it's an intranet application within our organisation we do not need to share the source or put the application under GPL. And for any other cases I usually put my projects under an open-source license anyway. Of course life would be easier for everyone if ExtJS just used the MIT license. But the library is of very high quality and very capable. From what I have seen so far I would happily write commercial applications that depended on ExtJS (then paying for the license and support of course). My point is: if you like ExtJS (perhaps even from just enjoying their programming samples) then see if you really need the commercial license.
What ExtJS isn't useful for
The spectrum of applications where ExtJS is a good catch is a little limited. For example I wouldn't make a customer web site using Ext unless they need a kind of GUI-style application. For effects and a little AJAX jQuery is much easier to understand and use and it's MIT-licensed so I wouldn't really have to worry about legal stuff. And the design is fixed. You would easily spot an ExtJS-based web site because you usually don't style the widgets. The icons and widgets come in three different colors but that's it. I wouldn't want to start playing with a few hundred lines of CSS that ExtJS comes with unless I really have to. It doesn't even play nicely with my existing style sheets because there's little they don't redefine for their own purposes. For example don't expect LI tags to produce list items with dots in front any more.
Debug hell
Pylons has a nice online debugger. So if anything fails in your Python code then you can comfortably analyse the situation and quickly fix the problem But if most of your work is done in Javascript then you have to debug Javascript instead. Unfortunately most programming errors that I encountered lead to very strange error messages pointing to lines in ExtJS' main file ext-all.js. Other developers in #extjs recommended that I use the (1 MB large) extjs-all-debug.js file to help me nail down the origin of the error message. But I hardly ever got more useful messages. Clicking on the error messages in Firebug made my PC slow down like an ant in a mud puddle and after half a minute showed me a line of ExtJS internal code that didn't help me either. So my current strategy is trying out things slowly. And whenever something works I check in my changes into the Mercurial repository I use for the project. Thus I can exactly see what I changed and what might cause the problem. But this is surely not a very modern way to debug applications. Mercurial and Firebug are the only tools to save my life. By the way many of my problems are giving components the same DOM ID as an existing DIV on the web page. ;)
Validation done twice
I have seen other developers' web applications already where they fully trust the Javascript to do the right thing. They happily send everything that was deemed good by the Javascript code to the backend. Even SQL injections. That's obviously a bad thing. So you'll have to validate the data your backend gets. Just be aware that you will need to do the validation twice - in your JS frontend and then again in the backend. Just don't trust anything that JS does. Whatever you do: validate what ExtJS sends to the backend! Everything else is optional.
Definition versus instantiation
A central thing I had to learn was the difference of defining some "component" to actually instantiating it. It's not very complicated from an object-oriented point of view. But my first attempt to get a layout and a couple of panels working made me do everything in the doReady() call that is triggered when all referenced elements of the web page are loaded. I hesitate to use derived/subclassed components because it seems too complicated - although other developers recommended to do that. So to save memory and CPU cycles you rather define Javascript arrays containing the attributes that you would later use to instantiate a certain component. Think of it as 'just in time instantiation'. Creating instances of everything right from the start is a waste of resources and will probably slow down the application.
Does half a megabyte of JS make things fast?
Yes, surprisingly it does. Half a megabyte is the largest amount of Javascript I had ever dealt with. But it's loaded once and then usually kept in the browser cache. And looking at the start page of my employer's web site they also use that much Javascript but accomplish much less than ExtJS. ;) The advantage of ExtJS' approach is that the application runs on the client/browser and not on the server. So everything is ready to use in the browser and the server just needs to send and receive data in the background. No loading times when you switch from one web to another. It becomes indistinguishable from a fat client application.
May the source be with you
Stay tuned for maybe more experiences once I finish my appliation. I hope I keep the patience because it took me three days of readig, trying, understanding, err'ing and programming to finally have a border layout with a tree view, a panel view and a click handler. What helped me a lot was reading the well-documented source from ExtJS' layout browser and Saki's web site. And my personal favorite useless but amazing loading effect can be seen here. :)
6 Comments
I've just started using it
Submitted by Wladimir van de... (not verified) on
I've just started using it and I must say I really like extjs. It's soo refreshing. It makes doing a lot of things, like handling forms and tables so much easier than in plain HTML, and looks great too.
On the documentation aspect I must agree, it's quite good overall, but sometimes quite hard to find the right place to find documentation for something.
Nice article. Thanks. :)
Submitted by Eugene (not verified) on
Nice article. Thanks. :) Eugene
You say your a newbie to Qt
Submitted by Mark Pitchless (not verified) on
You say your a newbie to Qt and Gtk type programming which also explains the steep learning curve for extjs, as it follows that approach. Should you ever decide to learn a GUI lib like QT your Ext experience will be very useful.
For me Ext was brilliant as it brings that type of GUI to the browser with built in binding to server sent XML, JSON.
@Josuha: Actually I have
Submitted by Christoph Haas on
@Josuha:
Actually I have given up using ExtJS - even for a project where the widgets would have been really useful. The results can be found in my followup post (http://blog.workaround.org/2008/10/22/extjs-impressive-for-the-user-pain...). Perhaps with some training I would have got better results but pondering over examples and docs and being left alone with simple problems that could be solved with two lines of jQuery I decided that I rather struggle with the quality of jQuery plugins and write more HTML instead of fighting ExtJS.
Reading your post I almost
Submitted by Joshua (not verified) on
Reading your post I almost thought you were in my head. I am in the same *exact* situation and hold the same opinions. There is quite the learning curve with ExtJS and the IRC channel is a good place to get "real help".
Keep on keeping on though, it gets easier and the API becomes more natural. Of course, with little information about "real application design" in 2.0 who knows if we are doing it right ;)
I just got over the initial
Submitted by JGMartin (not verified) on
I just got over the initial learning hump of ExtJS and I'm liking it quite a bit, partly because I don't like hassling with style sheets, but mainly because of how much modular functionality it's providing me with just a few options. I really how easy it is to do, for example, regex-based validation and masking (which is not my only validation, of course), or extending/modifying the existing classes, and so on.
Recently I've been doing a lot with json metadata, so server-side (Coldfusion) I can pass in all the form/grid configs, column lists, data, etc and "put it all together" in my js file, so each user can have totally different functionality and layout without too much hassle. Very useful for what I'm doing. (As an aside, I'm glad that Chrome and Firefox seem to be "invested" in improving javascript performance.)