| Someone asked me to explain why I think UCW is "truly horrible": 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! |