Warned off Weblocks on StackOverflow?
Duncan Bayne
I'm in the process of learning Common Lisp, & I've chosen Weblocks as
a framework to build a small-ish web app. Things look good so far -
installation was easy with Quicklisp, and I've got a running skeleton
app.
However, I've been warned off Weblocks by this post on StackOverflow:
http://stackoverflow.com/questions/6366774/selected-tech-stack-for-web-application-criticism-comments/6376312#6376312
> Weblocks is a continuations-based web framework - it is a very old approach, it should not be
> used for developing modern web-applications.
One person's comment isn't enough to make me switch frameworks; I've
asked him for clarification & recommendations, & otherwise left it at
that.
However I thought I'd ask here: at a high level, what are the
_disadvantages_ of continuation-passing? I presume the poster had
some reservations or he wouldn't have posted what he did ... unless
it's a fashion thing, in which case I certainly don't care.
My real concern is that I'm hoping the app I'm building will be in
service for many years, but it will probably have no more than 100K
users with ~ 100 concurrent. So I'm in for the long haul rather than
massive scalability or performance. But if he's right & Weblocks is
an 'on the out' technology then maybe I _should_ change.
Thanks in advance for any advice or feedback.
Yours,
Duncan Bayne
George Oliver
On Jun 16, 3:37 pm, Duncan Bayne <dhgba...@gmail.com> wrote:
> Hi,
>
> I'm in the process of learning Common Lisp, & I've chosen Weblocks as
> a framework to build a small-ish web app. Things look good so far -
> installation was easy with Quicklisp, and I've got a running skeleton
> app.
>
> However, I've been warned off Weblocks by this post on StackOverflow:
also find this thread interesting
http://news.ycombinator.com/item?id=1482405
(note the commenter 'coffeemug' is the Slava referred to by the top
comment).
I'm also very interested to hear the opinions of the list on the
question, as I'm in the same boat as Duncan at the moment.
Ian Eslick
Weblocks has alot of overhead (learning curve) and frankly the CPS facilities are rarely useful to me. I mostly used widgets, dialogs, actions, and dynamic ajax widget updates.
Ian
Sent from my iPhone
> --
> You received this message because you are subscribed to the Google Groups "weblocks" group.
> To post to this group, send email to webl...@googlegroups.com.
> To unsubscribe from this group, send email to weblocks+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/weblocks?hl=en.
>
Scott L. Burson
> I've been warned off Weblocks by this post on StackOverflow:
>
>> used for developing modern web-applications.
>
> One person's comment isn't enough to make me switch frameworks; I've
> asked him for clarification & recommendations, & otherwise left it at
> that.
Indeed; a one-sentence pot shot on SO shouldn't be considered an
adequate basis for any decision.
> However I thought I'd ask here: at a high level, what are the
> _disadvantages_ of continuation-passing? I presume the poster had
> some reservations or he wouldn't have posted what he did ... unless
> it's a fashion thing, in which case I certainly don't care.
There are certain kinds of things some web apps do that are made
easier, I think, by using firstclass continuations. When the app
needs to take the user through a sequence of pages -- in order to
complete a purchase, say -- where they need to be able to back up to
any point, that structure is elegantly expressed in a
continuation-based framework. That said, most web sites consist
primarily of pages that don't form sequences like that. The
complexity of both the framework and the app is thus driven primarily
by other considerations.
In short, I don't think having continuations available is a
disadvantage, since you don't have to use them. But they arguably
don't solve a particularly important problem. The Weblocks widget
tree architecture, by way of contrast, is a much bigger deal;
everything in a Weblocks app deals with that.
> My real concern is that I'm hoping the app I'm building will be in
> service for many years, but it will probably have no more than 100K
> users with ~ 100 concurrent. So I'm in for the long haul rather than
> massive scalability or performance. But if he's right & Weblocks is
> an 'on the out' technology then maybe I _should_ change.
I think that in order for something to be on the way out, it has to
have been in at some point :-)
The issues I've had with Weblocks revolve primarily around the paucity
of documentation. This shows up in two ways. First, often to figure
out exactly how something works, I've had to read the code. Second,
there aren't a lot of examples to follow to figure out how to do
things "the Weblocks way". And since Weblocks is not being used by a
lot of people, the situation isn't likely to change.
I can live with both of these problems. I'm already expert in CL, so
reading the code is not too difficult (and sometimes even pretty
interesting). I don't mind having to invent my own ways to do things.
It's worth all this to me to be able to work in Lisp.
I think the questions you should ask yourself are: () How interested
are you in getting really good at CL? Do you want to get to be a
wizard, or are you content with just writing your app? () How
interested are you in puzzling out how to get Weblocks to do what you
want? () Do you have the time and inclination to help grow the
Weblocks ecosystem, to attract more users?
I am somewhat handicapped in this discussion because, in fact,
Weblocks is the only web app framework I have attempted to use. I
really don't know how it compares to Rails, Django, Spring, etc. etc.
etc. So I can't answer your question about how the technologies
compare. As I'm trying to say, though, that may not be the most
important question anyway.
-- Scott
Leslie P. Polzer
some more quick comments from me.
I've used and studied a lot of web frameworks over many years.
Weblocks is just the one toolbox that I happen to like best.
Weblocks is not a continuation-based framework. You can program
all your stuff using continuations, or none. What's more, most people
seem to be confusing continuations (a general concept in programming)
with actions (only in network programming; functions on the server
side
identified by a unique id. A kind of RPC.).
I hardly use continuations. In this context it's interesting to see
that Slava, the original author of Weblocks, heavily touted a
continuation-based approach and now prefers other frameworks.
Continuations have very specialized applications, but are
confusing to new users and make debugging more complex
because there's a lot of implicit state involved. I prefer
explicit state, and so should newbies.
Widgets, actions and the thin JS layer are the central
concepts in Weblocks.
Continuations and views are not.
I cannot recommend using the current view system
in new code.
Thus, Slava's articles about Weblocks and what he thinks
is so great about it are somewhat outdated.
Documentation is spotty at best, so be prepared to
ask questions and use the source.
Be wary of people making blanket statements. Always
evaluate yourself and try to judge how balanced someone
else's view is.
Leslie
Duncan Bayne
it's very different, but _very_ light on boilerplate. I much prefer
the scaffolding-by-metaprogramming approach to Rails' scaffolding-by-
file-generation.
George Oliver
On Jun 17, 2:01 am, "Leslie P. Polzer" <leslie.pol...@gmx.net> wrote:
> Widgets, actions and the thin JS layer are the central
> concepts in Weblocks.
>
> Continuations and views are not.
>
> I cannot recommend using the current view system
> in new code.
>
last week (I really appreciated this reply btw). If you don't
recommend the view system, what is the best practice to replace what
the view system does?
Leslie P. Polzer
> I've been thinking about this while working with Weblocks over the
> last week (I really appreciated this reply btw). If you don't
> recommend the view system, what is the best practice to replace what
> the view system does?
table-based display and form display/processing.
Replacements I have found most sensible in practice:
* custom widgets or rendering functions for data display.
* custom rendering code for non-sortable tables; for sortable tables I
have a new (unreleased as of yet) widget that makes this pretty
painless while preserving a great deal of flexibility.
* new form widget that is decoupled from the store database and lets
you still use defview if you like. You can find it in contrib/lpolzer.
YMMV, questions welcome. :)
Leslie