I'm convinced that Weblocks is one of the worst things to have happened to web programming in Common Lisp. There are lots of very good CL libraries you can put together for developing web applications. Weblocks is a half-baked framework that adds needless constraints and complexity. I have seen (and had my hand in building a couple) technically (I'm not rich yet) successful CL web apps from these common libraries (Hunchentoot, CLSQL, etc). I have not seen any real-world Weblocks application, and the only one I've ever worked on is a mess.
I'm not sure what Slava's goal was when he started Weblocks (he never intended to start a web startup at that time as far as I know), and neither do most of the developers that came after him (Slava stopped working on Weblocks long before RethinkDB) do full-time commercial Lisp web work. And that's the problem.
Also, there is nothing about CLSQL that prevents writing race-free code. Sharing connections across threads without locks won't be race free (duh).
I'm not sure what Slava's goal was when he started Weblocks.
I had a lot of ideas about web development I wanted to try out because I believed (and still do) that given the right development environment we could make web applications responsive and interactive in a way that isn't manageable now because of complexity. I wanted a language that could support these ideas, and I picked Common Lisp. I think in practice Weblocks failed to make any of these ideas a reality because the design didn't account for a lot of complexity I didn't realize existed. I am still convinced that the original ideas were solid, and that someone, some day, will make them work in some form or another.
I actually think Ruby on Rails is the worst thing that happened to web development, because it convinced almost everyone that web development is now a solved problem and this is as far we go. It isn't - we've only scratched the surface of what's possible. In terms of Weblocks though, Lisp is well known for insane expectations and few real world applications that satisfy them, so I think blaming it all on Weblocks is giving it too much credit :)
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.
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.
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.
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!
I actually think Ruby on Rails is the worst thing that happened to web development, because it convinced almost everyone that web development is now a solved problem and this is as far we go.
I don't know any Rails devs that think this. I constantly get the feeling when building Rails apps that there are still plenty of opportunities for making things easier and simpler.
However, none of the alternatives are any better and most are far worse, particularly the current crop of half-hearted lisp & functional approaches. I'm still open to the idea that functional languages can be used as the basis of a superior framework but nobody's come close to demonstrating that yet. Redoing Sinatra in Clojure/Scala/Lisp/Haskell isn't going to get you even close.
I think most Rails developers would agree with you there, which is why we're still seeing interesting gems that make our work easier coming out every day. There is a real commitment in the Rails community to make web development more productive and enjoyable, and I would hope that that is the attitude shared by most devs, regardless of framework.
Still, there is something very true to the original comment. Most web frameworks are wed to an overall philosophy for creating web applications. Rails is unlikely to depart from the MVC pattern for example. If you agree with that you can see that Rails, and any other framework I can think of, can at best hope to strive for a local maximum, unless their overall approaches are eventually validated as the way to do things, but I find that very unlikely.
I like the idea of web frameworks using functional languages, largely because I believe a framework written in a functional language will be better capable of adapting to new advances. I definitely agree with you about Sinatra. Even if a lisp or other FP language is better suited to the task, the advance will be evolutionary at best, while what I'd like to see is something revolutionary.
I disagree. I think there are a lot of great ideas in Weblocks. True, there are some not-so-great ones, but designing complex web frameworks is hard. I think Slava did an impressive job with Weblocks, even though I later ripped out large parts of his design and replaced it with something else :-)
Web programming is not a solved problem. I haven't found a framework yet that I'd really like to use.
Also, there are real-world applications using Weblocks — read my post above. I am not entirely happy with the state of affairs, but it isn't really weblocks' fault, but the CL environment in general.
As another data point, I find the Clojure environment to be much more mature, because of the JVM and many widely-used Java libraries.
I'm not sure what Slava's goal was when he started Weblocks (he never intended to start a web startup at that time as far as I know), and neither do most of the developers that came after him (Slava stopped working on Weblocks long before RethinkDB) do full-time commercial Lisp web work. And that's the problem.
Also, there is nothing about CLSQL that prevents writing race-free code. Sharing connections across threads without locks won't be race free (duh).