OK, why should you listen to a Lisper on Javascript frameworks? Because we use Lisp so obviously we have better instincts when it comes to developing applications. In fact, this road would not have ended so well had not Lars, a fellow Lisper developing a killer new Lisp Web programming framework called Symbolic Web (SW) brushed aside my enthusiasm for Dojo and mentioned he found qooxdoo interesting, although for now SW uses a little jQuery. "A little" because the whole idea of Symbolic Web is to do most of your programming in Lisp which of course is the only way to go but SW is still emerging from the sea and I had a requirement now (well, six weeks ago, but there is major new release of SW just out I need to look into but as this Road will reveal I am not likely to change horses now because of what I found in qooxdoo (not that SW will not eventually catch up)). Gasp.
The second question might be how a Lisp god and Interwebby know-nothing ended up doing heads-down intense Interweb development. Well, it was the Lisp credentials. A former client using mostly Lisp was having great luck with a Ruby/Rails front end but was looking for more speed and hoped having a Lisp image serve the pages directly would make for better response.
What happened next was pretty neat, and again Lisp conquers all. I told the client I would look at what they had and what they needed for a few days to decide if even I could help them, because I can do a lot of things but one thing I cannot do is exaggerate how little I knew about Web programming and even static HTML eight weeks ago.
A glance at the existing screens and Rails code had me thinking, "No way", but I was curious anyway about even getting an application to drive a web site so I fired up a tutorial on Web app development using tools from my Lisp vendor of choice, Franz.
How good are Lisp, Franz, the tutorial, and the WebActions tool? In the three days I was supposed to be deciding whether I could help the client I managed to execute a respectable fraction of the first component they needed. Sorry, no screenshots, NDA and all that.
So now there I am with a contract and a browser toolbar sagging from the weight of bookmarks to sites on HTML, CSS, and for the hell of it jQuery though I was not sure why but everyone was jumping up and down about it. And then I needed it.
Well, not jQuery. I needed a razzle-dazzle spreadsheet-like grid presenting data from an arbitrarily large table of data held on the server. Now at this point I had already rolled my own Ajax paging mechanism, but something superficial but nonetheless important for that this being an important application was holding me back: my HTML looked like crap. Meta-holding me back was my sense from surfing the Web that getting good results out of HTML/CSS was a black art requiring years of practice which certainly leaves me out. Enter FlexiGrid. A URL which as I write responds "Please contact the billing/support department as soon as possible."
Which brings me to why I dumped jQuery. What I found was small, yes, and add-ons, yes, but a hodge-podge of add-ons does not a professional development environment make. By the time I punted I had contribs from three people and while each was lovely alone together they looked like, well, a great decorator on a multiple-personality binge. And beyond appearance there came a surprising result: FlexiGrid did not offer a "row selected" event. Meta-worse was the author's response. "Right, no row-selected event." Ooops. Next up was jqGrid and that was fine but I still had Crazed Decorator Syndrome going and now I am looking for the next widget I need and a light went on: we are building an application here, not a Web page/site. It is wonderful that jQuery is small, but small is exactly the wrong thing for developing a sophisticated application with a coherent look and feel never mind coherent engineering underneath so widgets can play well together. Enter Dojo. But first...
In case you are wondering where the client went, they are encouraging my search for a pre-fab solution. Probably seeing the gorgeous FlexiGrid widget compared to my ugly efforts did not hurt, but the client has good instincts anyway (they use Lisp, right?) so they are leaning towards my original assessment that I am overmatched if I am going to try to turn out a hot application on short experience with HTML and CSS even though at this point I have wondered aloud to them how much HTML/CSS I might have mastered in the same time I was spending beating my head against pre-fab, this being the classic failed deal we make with the devil when we reach for 4GL: yeah, wow, a complete browser screen in five minutes. Gee, could we get the first sub-item appearing on the same row with the item? No. The client wants it. It cannot be done. That was Datatrieve on VAX/VMS twenty-five years ago, but nothing has changed. 4GLs get their apparent power by making decisions for me which works only if I (and my client) are not making any decisions.
But no, the client says "find a framework" and I decide to try again with Dojo. Again?
I had looked at Dojo before. The word on Dojo was incredibly good. Of course that word was from their Web site. When I tried to confirm by eyeballing the doc I could not find it. I mean, there were some great links, but all the pages they led to were blank. Next! But now I was back, encouraged by the news that OpenLaszlo had just placed a bet on Dojo. IBM as well, but OpenLaszlo is more important because I know they are geniuses, they have a dataflow hack like mine.
Oooh-ooh! Another reason Dojo looked good was a benchmark I had found showing the thing was fast. I have no idea if the benchmark is valid, but the pictures are gorgeous so I trust it. So why did I dump Dojo?
Well, OK, I did not really. It came in second. The question is why did I keep looking such that I found the eventual winner. Easy: too frickin hard to get to work. The documentation is awful. They know this and are addressing it but did I mention we need this now? Overall Dojo fit the bill of being a Compleat Solution with solid backing and a great future, but after banging my head against the wall over something (ah, it was the six hours I spent trying to figure out the "build" mechanism for a compressed production release of my JS culminating in watching a blurry video that finally showed how to do it) I went for a better way surf (as in there's gotta be) and saw YUI touted as a serious solution.
A quick glance at the enormous volume of well-organized documentation and exhaustive examples and the client and I agreed at once to give it a try. And I will tell you right now YUI has the best graphic designers, because their stuff looks hot. Dojo is a close second there, too. YUI is a complete solution with a big backer, gorgeous style, and more doc than you can imagine. How did it get dumped?
Stuff was not working well. Even with all the doc and examples it was hard to get working. When I dug into the source to see why things were not working, I did not like what I saw. And the death knell: YUI abandons the declarative model. Why is this so bad? Hellooooo, Lisp? Remember?
Up thru Dojo I was programming in Lisp 90% of the time, doing just enough JS to get information back to the Lisp server application where HTML could be generated and sent back, even that Lispily thanks to HTML generating macros. And YUI was going to make me give that up and be as hard to figure out as Dojo and I suspect worse under the hood. So regretfully I informed the client my battles with Dojo would be resuming.
So how does this road end up at qooxdoo?
The weekend was coming up. Weekends are mine, so I decide to follow-up on Lars's hint about qooxdoo. qooxdoo is the ultimate threat to YUI because qooxdoo also says Just Code Javascript, and if I am forced to do that by YUI I may as well do it in qooxdoo where the code is as good as YUI's is bad. (I looked at about fifty lines of it for five minutes, I should know.) Anyway....
qooxdoo is amazing. They need help on the graphic design (never look directly at their tab control, use a mirror) but other than that the engineering is terrific. [My bad: they simply leave anything more than the utilitarian look up to the developer, witness this before/after case study.] The documentation and examples are also abundant here, and the support is great. They even do dataflow! Yes, I wish I could spend all my time in Lisp sending over HTML, but two things on that.
One, there is a side-project that brings a declarative model back into qooxdoo. QxTransformer. I have no idea where that stands, but I did see a note on-line where a developer spoke of it in the past tense. [Now resurrected.]
Two, hey, I can write some Javascript. I did ten years of C before I did fifteen years of Lisp, Javascript is not a problem. And it even has lambda, something this guy still does not understand. Lisp/markup would be better, but when dealing with mission-critical stuff (the client is doing valuable data crunching but does not win until they make it accessible) any team can roll up its sleeves and crank out the work even if they have to do without the brilliance of Lisp.
This entry is getting long and I am getting tired and my bartenders are starting to worry about me so I will leave a detailed praise singing of qooxdoo to my next entry, but allow me a bit of a rant. What a mission-critical effort cannot stand is fundamentally flawed solutions that seem to offer a fast track but in fact bleed developers to death. This can be jQuery with an incomplete solution forcing me to try to build an application out of mom and pop contribs or YUI with fundamentally bad code or some other framework that might be just plain slow.
As a developer I am not looking not to work, I am looking to have my work yield quality results predictably. I might spend four hours trying to figure out how to do something in qooxdoo but once I do it turns out to be insanely simple and work beautifully. Moral: their documentation needs an index! But I am keeping my big yap shut because documentation is a bitch and they have done a ton of it and I do not document my stuff so...I keep my big yap shut. But the point is that my work now yields results reliably and predictably and this will accelerate as I learn the framework and even learn better how to navigate the documentation.
qooxdoo not only fits the bill of being a complete solution well documented with many examples but it also has high-quality code under the hood, which both gives me confidence that I have found the right tool and not incidentally serves as useful further documentation. More next time.
13 comments:
Nice post. Sometime in your copious amount of free time you should see whether you can use Parenscript to write the javascript you need for Qooxdoo. That would be cool.
I would be digging into this stuff as well but this client of yours keeps me busy too. :-)
That is the second strong recommendation I have received for Parenscript but I gots to tell you, I played with it and was not impressed. No slight intended, just that I think the threshold for me on where it is helpful is higher than can be reasonably achieved without implementing the CLHS in JS.
Parenscript gives you two great things:
1. Macros
2. Ability to run the same code in CL on the server and JS on the browser (if you write your code in the restricted set of PS and CL that overlap in behavior on a limited domain of objects that look and behave similarly in CL and JS, which in practice is useful enough for most things)
Reason 1 is the most compelling even aside from the usual macro stuff in that it lets you trivially instrument your code for things like profiling. This is important because as I'm sure you've realized by now a lot of the functionality in the popular JavaScript UI libraries is too slow to be useful. Except for Firebug for Firefox there exist no other half-decent profiling tools for other browsers. So you get to find out what is slow, and then because you have your Lisp and your macros you can easily explore the different approaches (should I change CSS class or set style or innerHTML or...) to make your code run faster than molasses.
Reason 2 is awesome because now your usual server-side code (making up HTML and CSS) is now exactly the same as your usual client-side code (making up HTML and CSS). It also lets you do tricks like doing some computations on the browser side or the server side depending on which would give better response.
The one problem with Parenscript is that until browser JavaScript interpreters get fast enough to be useful it will have to produce really straightforward JavaScript code. Right now writing for browser JS is kind of like programming an 8-bit microcomputer, you have to watch every statement. So that precludes both fancy features and clever tricks because now not only does the output code have to be efficient, you also need to be able to debug it in Firebug because you can't put in your own fancy debugging hooks because that would slow the code down. Otherwise it would be game on and PS would implement ANSI CL on the browser already and you'd be using SLIME to program directly in your browser. But today you have to settle for an ersatz Lisp (which is still way beyond what the other JS generators do in terms of actual usefulness), and I am planning on writing an ersatz browser-SLIME (which as far as I know will be a first for web development tools).
"Because we use Lisp so obviously we have better instincts when it comes to developing applications"
except for modesty !
I hate that lisper's attitude, they always think because they know Lisp language they are simply the best.
Comne on, open your mind to the rest of the world !
"except for modesty !"
I think you missed the name of the entire frickin blog. As for discovering the rest of the world, don't be silly. There are no Lisp jobs ergo every Lisp programmer when at work uses all the same languages used by The Great Unwashed. And we are better at them than you. By definition, good programmers find their way to Lisp. No Lisp, no good.
Vlad, OK, I'll see if PS can translate Cells, I have been doing that by hand. Thx for the further recommendation. As to performance, well, you might be right in part because I think I saw some slowness but I ususally tackle speed last and everything I looked at got tossed before that final concern came up. Then with qooxdoo, ok, you are right: one of the first things I noticed was how much faster it was. The app is mostly about datagrids and treeviews and qx's are radically more responsive. The only effort I have made so far on performance is on the backend.
Hello Kenny,
Thanks for interesting post, I like such kind of reading about peoples' experience.
I noticed that you mentioned QxTransformer in your post. I would like to clarify a situation a bit and say a few words about the project's state. I'm QxTransformer developer.
What you(and others) saw on our site is an old version of QxTransformer which supports only qooxdoo 0.7 syntax, so it's not very useful for people who started their projects with qooxdoo 0.8. But... I'm working hard on new, fully rewritten toolkit and tons of examples. I wrote it in Python (as generator and other tools for qooxdoo) and it has a solid integration with a qooxdoo build process and interesting new features.
I've almost finished the work and ready for initial release.
So, stay tuned if you are interested in declarative approach (or have you finished your application already? I heard something about a big release? ;)). I'm writing this comment just to let people know that QxTransformer is still alive and we are working on it.
Best regards,
Siarhei Barysiuk
P.S. I've just updated(or even rebuilt) the site before upcoming release. So, you can find some information on our page.
"except for modesty!"
Modesty and software development instincts are orthogonal.
Siarhei: Thanks for the update. I am delighted to hear QxTransformer lives on. We have tons more to do so perhaps we will be able to segue to that. I will check out the new release when it comes out. --k
Thanks for the great post! You must be single and/or without a social life to have the time to write such interesting stuff *in your spare time forchrisesakes*! Seriously, smuglispweeny gets an entry in my bookmark list.
-- smuglispwannabe
Kenny,
did you have a look at extjs at all? Phenomenally brushed feel to it, not very found of the commercial license though.
I have heard good things about the look of extJS, and another group in the enterprise is indeed using that. I am concerned by its pedigree (YUI, which has awful code inside) and anyway I like the full-stack model of qooxdoo. Yes, the commercial license is an issue but I have not been brainwashed by Stallman so I do pay for development tools.
That's strange! I can see no use for Lisp, at least not for what I do on a daily basis, but I came to the same conclusion about qooxdoo.
What I think are the three features that make qooxdoo stand out:
- richest widget list of all JS frameworks I know
- framework-provided structured error handling, logging, rpc calls, json serialization etc. - all or most of them you need to build by hand if you use another framework, or use lots of 3rd party additions, which usually don't play nice together
- slick but comprehensive toolchain, generating quite compact code for loading into the browser - it even has a lint-like tool
I don't mention support for several browsers because this is to me a prerequisite for any JS framework to be taken seriously.
@A_flj: haha, I had a lot of trouble parsing "same conclusion"! I thought you meant same as "see no use for it"! Anyway, yeah, qooxdoo rocks and it sounds like you know this domain better than me. Nice to hear a confirm from someone more hardcore. Meanwhile, you are probably wrong about Lisp no matter what your work is, but you won't know it until you know Lisp. Catch-22. :)
Post a Comment