|
|
|
|
|
|
by sedachv
5828 days ago
|
|
|
I suppose I am being too hard on Weblocks because it is the most "successful" of the CL frameworks. If it wasn't Weblocks, it was going to be something like UCW, which is truly horrible. It's interesting that you think that the Weblocks ideas will continue to be relevant. I'm convinced that HTML5 canvas will make UI issues history, just as I'm convinced that AJAX makes using continuations for managing web app state a really bad idea. The real point here is that Lisp makes it possible to combine the tools you want to build web applications in ways that are appropriate. Almost all frameworks in other languages are there because that is something that is really hard to do with deficient tools otherwise. Almost all Lisp web frameworks are there because somehow some Lisp programmers became convinced that you need one to write a web application. We're just borrowing stupid ideas from stupid collections of hacks written to deal with stupid tools. "Framework" should be a dirty word. I don't think most people care about RoR. It's to PHP what PHP was to Perl. Next someone is going to choose another stupid personal language to build a framework with really nifty canvas widgets that interfaces to a no-SQL database and that will go big (hmm, time for me to abandon my principles and become a famous "framework" author?). The only real winner in all of this is O'Reilly, who get to publish 50 different books about all the stupid tools involved. |
|
|
I think UCW is bad for three reasons: trying to hide the fact that HTTP is stateless with continuations, introducing way too many concepts/mechanisms unrelated to actually serving pages, and I don't like Marco Baringer's (original UCW author) code very much.
The third reason is subjective, the first two somewhat less so. I actually have a blog post with some diagrams in the idea stage about why managing HTTP web app state with continuations is a terrible idea (it all comes down to the fact that it makes it much harder to test) - already noted criticisms include meaningless URLs (can't link/bookmark), and harder debugging. Since UCW uses CPS transformation to get continuations, it means the resulting code is almost impossible to debug.
Next, look at the documentation for UCW: http://common-lisp.net/project/ucw/repos/ucw-core/doc/gettin...
Entry points? Components that need the MOP? Frames? Actions? Just to understand how components get output to HTML and served you need to know the MOP. So you have the UCW component code, the UCW MOP code, the UCW entry/continuation code, the UCW interface on top of an HTTP server. Now you need to learn a whole new horribly complicated UI toolkit and still deal with all the regular web stuff.
This isn't any different that Weblocks. The difference between Weblocks "horrible" and UCW "truly horrible" is in things like the UCW system definition file: http://common-lisp.net/project/ucw/repos/ucw-core/ucw-core.a...
The eval-when, the useless (but confusing - how is it different than regular defclass?) defclass* macro, the defvars completely unrelated to system definition. And this is just the very first file!