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:
- Users.js – app/controller
- User.js – app/model
- Users.js – app/store
That doesn’t lead to any confusion. Nope, nope, not at all…
A Second Attempt
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:
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.