Okay, that is a lot as a general recommendation. I mean we did not learn much detail. Until now. Here are four Big Things that really stand out:
1. HTML? CSS? Never heard of 'em.
First comes a shocker. The qooxdoo user codes no HTML or CSS and needs know nothing about those two disappointments. Just as my Lisp compiler reads my Lisp code and spits out optimized native machine code, qooxdoo takes your qooxdoo/Javascript and produces the HTML and CSS to drive the browser. Upside: qooxdoo developers write less code and never have to worry about browser variability again.
To a Web noob like me there is a second big win here: I do not have to learn HTML, CSS, or the vagaries of the different Web browsers my client might want supported. I am a bit of a rarity in my ignorance of those things but soon I should have a lot of company now that qooxdoo has set the bar as high as it has on insulating the web app developer from lower level technology.
By the way, in case you are wondering: yes, there is a widget (two, actually) that will accept classic HTML.
First comes a shocker. The qooxdoo user codes no HTML or CSS and needs know nothing about those two disappointments. Just as my Lisp compiler reads my Lisp code and spits out optimized native machine code, qooxdoo takes your qooxdoo/Javascript and produces the HTML and CSS to drive the browser. Upside: qooxdoo developers write less code and never have to worry about browser variability again.
To a Web noob like me there is a second big win here: I do not have to learn HTML, CSS, or the vagaries of the different Web browsers my client might want supported. I am a bit of a rarity in my ignorance of those things but soon I should have a lot of company now that qooxdoo has set the bar as high as it has on insulating the web app developer from lower level technology.
By the way, in case you are wondering: yes, there is a widget (two, actually) that will accept classic HTML.
2. I do declare. Not!
The second thing that hits us is a consequence of the first: we are going to be writing a lot more Javascript than we would be with libraries such as Dojo where authors still write HTML/CSS. With declarative tools we sit in Lisp or Ruby or PHP on the server generating HTML. Not qooxdoo (but see next) and not YUI.
I am not at all happy about this but I will live and if it ever bothers me enough I will spend a weekend exploring the qooxdoo markup contrib called QxTransformer. Right now I need to catch up on a backlog of functionality the client has had to do without because of the six weeks it took me to identify qooxdoo as The One.
The second thing that hits us is a consequence of the first: we are going to be writing a lot more Javascript than we would be with libraries such as Dojo where authors still write HTML/CSS. With declarative tools we sit in Lisp or Ruby or PHP on the server generating HTML. Not qooxdoo (but see next) and not YUI.
I am not at all happy about this but I will live and if it ever bothers me enough I will spend a weekend exploring the qooxdoo markup contrib called QxTransformer. Right now I need to catch up on a backlog of functionality the client has had to do without because of the six weeks it took me to identify qooxdoo as The One.
3. OO is not the Grail, but OO rocks
Stendhal said it best in "On Love" in the chapter on Infatuation: (paraphrasing poorly) we do the object of our desire two injustices, first setting them on a pedestal unreasonably high and then, when they inevitably disappoint, setting them too low. OO is not the Grail, it is just a profound advance in serious application development. All by way of introduction of another stunner: qooxdoo's slightly more substantial object model layered atop the core Javascript OO capabilities.
Stendhal said it best in "On Love" in the chapter on Infatuation: (paraphrasing poorly) we do the object of our desire two injustices, first setting them on a pedestal unreasonably high and then, when they inevitably disappoint, setting them too low. OO is not the Grail, it is just a profound advance in serious application development. All by way of introduction of another stunner: qooxdoo's slightly more substantial object model layered atop the core Javascript OO capabilities.
To be honest this struck me as a bit of a yawn until I decided to start carving up my existing code into distinct qooxdoo classes. This is a very big application and I needed code re-use almost immediately and doing it in HTML with Javascript glue was...well, before qooxdoo I was pretty much starting to build my own abstraction layer atop the core tools--there was no way around it.
But now that I have used qooxdoo's OO to partition my rapidly growing code base I have more than once had that wonderful sense of getting something for nothing after doing a major refactoring (you know, taking all the pieces and throwing them up in the air) and having it Just Work after two or three tweaks. Furthermore, I will not bore you with the details but I have not even started leveraging the full capabilities of qooxdoo's object layer: even more benefit will be reaped moving forward because of some nifty reactive capabilities.
But now that I have used qooxdoo's OO to partition my rapidly growing code base I have more than once had that wonderful sense of getting something for nothing after doing a major refactoring (you know, taking all the pieces and throwing them up in the air) and having it Just Work after two or three tweaks. Furthermore, I will not bore you with the details but I have not even started leveraging the full capabilities of qooxdoo's object layer: even more benefit will be reaped moving forward because of some nifty reactive capabilities.
This came as a pleasant surprise. I do more OO in more ways than you can imagine in part because I normally program with Lisp's CLOS which is to normal OO what normal OO is to binary arithmetic but by the time I stumbled onto qooxdoo I had been doing Javascript, HTML, and CSS for a couple of months under a lot of pressure so I never had the time to build a sensible OO abstraction atop Javascripts primitive little OO pretensions. Thus Javascript had endowed me with a bit of child mind and I was able to experience the mundane code structuring win of OO as if for the first time. It rocks.
3. Layout the Wazoo
I may have lied. This may have been the first stunner I felt in my gut. The others I knew would be huge if they panned out, but this was the first one I saw in action working as beautifully as had the other frameworks left me hanging. With other frameworks I could find no way to get built-in layout schemes to use the full window real estate available. That cuts two ways: I either ended up with unused whitespace (and with our app we need all we can get) or my application panels grew so large that the browser itself put up scroll bars, meaning I had to window-scroll my scroll panes around. No, that was not a candidate for production release. Note that to a large degree this is the same as point #1: a framework is not hiding HTML/CSS from me if I am still victim to surprising browser decisions, such as oh gosh that is big let's use a scroll bar here.
I may have lied. This may have been the first stunner I felt in my gut. The others I knew would be huge if they panned out, but this was the first one I saw in action working as beautifully as had the other frameworks left me hanging. With other frameworks I could find no way to get built-in layout schemes to use the full window real estate available. That cuts two ways: I either ended up with unused whitespace (and with our app we need all we can get) or my application panels grew so large that the browser itself put up scroll bars, meaning I had to window-scroll my scroll panes around. No, that was not a candidate for production release. Note that to a large degree this is the same as point #1: a framework is not hiding HTML/CSS from me if I am still victim to surprising browser decisions, such as oh gosh that is big let's use a scroll bar here.
How good is qooxdoo at layout? When I popped open the Firebug debugger in FireFox, where by default it begins by seizing application window real estate, the qooxdoo layout engine handled the downsizing impeccably, right down to adjusting scroll bars to accurately reflect the new dimensions.
4. Message In A Bottle
This feature is huge in a small way, by which I mean I could probably roll my own version of qooxdoo's Message mechanism in a an hour but--wait for it--I did not have to. They did. That is huge, the huge thing being that the qooxdoo team really has set out to create a compleat Web application development environment and with such a beast comes pleasant surprises such as their Message mechanism which allows a nice decoupling of widgets: one widget can dispatch "Make it so" and anyone responsible for "it" knows to roll up their sleeves simply by having subscribed to "Make it so".
Beyond the Message mechanism we have the Event mechanism. The documentation of every widget lists the events it might generate and what data the event will carry, and in toto we have an engine with an event model dozens of times richer than pure DOM.
5. I know, I said "4"
Number five is an umbrella win, too detailed to list: as I whined above, this Lisp God is now writing an awful lot of Javascript leveraging more and more qooxdoo all the time. Again and again your highly critical correspondent is finding nothing but good news in qooxdoo.
Yes, I could make a bug report every other day if I had the time, but a long time ago I figured out that I am not looking for a perfect library, I am looking for a powerful library that is fundamentally sound (so anything broken can be readily fixed) and actively maintained (so things actually get fixed).
Summary
qooxdoo: fast, powerful, complete, rich, well-engineered, and it hides browsers, HTML, and CSS. Great doc, loads of examples, fine community. It's all good.
16 comments:
Nice post. :)
One tip that you may or may not have heard from others: if you find yourself writing a lot of javascript and are relatively new to the language, check out Douglas Crockfords work.
He essentially carves out a subset of javascript, which makes the language more pleasant and safe to work with. See the book "JavaScript: The Good Parts". Much of the same material can be found as video at: http://developer.yahoo.com/yui/
Crockford is also the original author of the JSLint tool; very useful for detecting bad/unsafe idioms in your js code.
I myself very recently (a few weeks back) got back into javascript and other modern web tech, and found Crockfords work very useful to get started.
Javascript isn't that bad really. :)
Cheers,
ThomasN
What browsers have you tested your code in? The qooxdoo home page does not do well in Safari or Firefox, nor do some of the demos. Reduce the browser window size and the left margin disappears off to the left and can't be scrolled to. The same happens in the demo pages where the lower portion of the page can't be scrolled to. Clearly the claim that you don't have to consider "the vagaries of the different Web browsers" or learn HTML and CSS is not well tested (and incorrect). The pages are not even valid XHTML 1.1 as the DOCTYPE claims.
I tried the demos in IE 5.2 and got a completely blank page, same result when javascript is disabled.
The newsreader demo is over 700kB, one file has nearly 27,000 lines of code - light it is not. And qooxdoo uses browser sniffing, a discredited approach to dealing with different browsers.
If you are going to sing the praises of a library or development framework, you should balance your enthusiasm with its shortcomings, particularly when they are as obvious as those noted above.
Rob.
Thomas: Thx for the lead. I am sure you are right, Mr. Crockford saved my butt when I needed to generate JSON on the JS side. (He has a tool for that.)
Robg: If you are going to sing my unpraises you should address what I wrote: I learned along time ago not to look for perfection, rather for the most effective library with the best overall engineering and active maintenance. FWIW, our rather intense Web app is now working beautifully on Chrome, Safari, and FireFox on Windows and that is enough for us for now. As for you lecturing me on responsible writing, jeez, you did not read my blog subhead either. :)
kt
Disclosure: I'm on the qooxdoo project.
As for the raised issues:
* The qooxdoo home page is not - (*blush_of_shame*) - made with qooxdoo. We use a more wiki-style authoring system.
* Some demos (maybe quite a few) use fixed layouts, this is a known issue. Point is, the demos are quite technical, trying to zero in on specific implemenation features, often stipped-down, and don't get much love beyond that; they are to inform developers, and are not showcase applications. Important here is that it works in applications that care.
* As for the DOCTYPE (of the demos, I suppose), this shouldn't be much of a problem since the HTML page of a qooxdoo app is close to empty anyway. But we welcome any hint to improve :).
Otherwise, thanks for the nice praise singing, Kenny ;-).
Thomas
Kenny: I thought I did address two points in your post: the claims that you need not to learn HTML or CSS and that you can ignore browser peculiarities. A major drawback with such frameworks is that you are reliant on the authors to support the platforms you care to develop for.
I'm happy that you think it is a useful tool, and it's nice to know that you only wish to support a small subset of common browsers and versions.
ThomasH: you're out on a bit of a limb with XHTML 1.1, but that's your choice. I don't see any comment from you or Kenny on the large volume of code for the news reader demo, is that indicative of qooxdoo apps?
Rob
Rob: sorry, I did indeed neglect responding to the big download issue. I whiffed on the 700k initial hit issue only because it is a non-issue (in my mind) where one is talking about RIA so I ended up responding to other points I thought more telling. So why is a 700k hit a non-issue? Quite simply my 700k /application/ loads into a browser faster than any good-sized desktop application starts up. My life come to an end if I double click a JPG and somehow I allowed GIMP to become the default application for JPGs. And this is not just an "everybody else sucks, too" argument. The other point is that when hunkering down for an intense image editing session, it is OK that my children grow old while GIMP launches.
As for "you are reliant on the authors", wow, this time you whiffed like A-Rod in the playoffs on what I said, two things in fact: the great engineering means I am delighted to be reliant on these authors. It also means, this being open source, that I can probably fix things faster than the authors. If you read (I think) the first article, you'll see a quick mention that qooxdoo came up hugely short on datagrids, but that their code is so clean I could carve out a freat datagrid in a day. This then gets back to why it is so insanely important to find libraries with fundamentally sound engineering. kt
At the risk of sounding sycophantic, I tried qooxdoo after reading the first and second posts, and it's been great. I wrote a small internal app in a couple days, and we're all rather impressed by both the final product and the speed of development.
I had to write the back-end in Perl rather than Lisp because of tertiary considerations; but I have to say qooxdoo is one of the more hassle-free frameworks I've tried. Like you, I have no illusions of perfection, but it's definitely better than "usable."
Thanks for the tip.
Ah, yes, the size issue, I forgot about that.
As for the 700K/27 KLOC build size (well, 630K in my book, but never mind): You have a rather constant overhead for the qooxdoo run time system (OO system, properties, unified events, ...). This is substantial for small applications, but becomes moderate as your application grows (we support apps with couples of hundreds of classes and I-don't-know-how-many thousand lines of code).
As for the LOC, this is simply due to a rather freehanded use of newlines in the generated output. Turning that off in the build configuration leaves you with a meager 311 lines of code :-).
But the count of newlines in generated output doesn't say much. More important is the application code (the code you actually write). These are the line counts of the JS files that make up the Feedreader (including comments):
415 ./Application.js
130 ./io/FeedLoader.js
171 ./io/FeedParser.js
3 ./io/__init__.js
78 ./model/Article.js
208 ./model/Feed.js
149 ./model/FeedList.js
3 ./model/__init__.js
146 ./view/AddFeedWindow.js
151 ./view/Article.js
48 ./view/Header.js
205 ./view/List.js
140 ./view/PreferenceWindow.js
107 ./view/ToolBar.js
258 ./view/Tree.js
2 ./view/__init__.js
2 ./__init__.js
This makes roughly 2,300 LOC, MVC-based 3-pane GUI, feed parser and everything. Sounds much better, doesn't it :-) .
Thomas
Kenny -- met you at LispNYC. Thanks for the heads up about qooxdoo... it's great!
Kenny - I'm interested in writing a web app using Lisp. Just received PCL, so while I have been programming for decades, I know very little Lisp. I need to provide both static and dynamic pages, so I'm interested in knowing what would be your choice for framework and db.
Thanks, Steve
Steve: I still like qooxdoo. DB? Nothing wrong with Postgres if you have the Postmodern library. Good luck with the project. kt
Thanks for posting about your Quest for a RIA framework. I am in a similar situation and hope to save myself a couple of weeks... I can imagine that after (perhaps as much as) 6 months using qooxdoo, you might have changed your opinion on some elements...or are you still as positive about qooxdoo?
Reimer,the RIA work got outsourced to vietnam for now and they are using the toolset they know best, Rails. I have not been following the toolkit scene, but my guess would be that qooxdoo has only increased its lead. The thing that stood out most was how good were the internals, and that (along with other things) tells me they also have the best engineers.
And six years later I am hard at it with qooxdoo and a few months away from go-live with Tiltons' Algebra.
qooxdoo has only gotten better over the years.
Post a Comment