Now, the question. While I thought I was being ignored, I did some
playing with Weblocks. I'd love it if someone could do a
compare-and-contrast for it like you did with UCW.
Thanks a bunch!
-Robin
--
Lojban Reason #17: http://en.wikipedia.org/wiki/Buffalo_buffalo
Proud Supporter of the Singularity Institute - http://singinst.org/
http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/
I haven't used Weblocks in a project. My comments could be wrong and
subjective. It would be very enlightening if someone using Weblocks can
correct my mail wherever I'm wrong.
- Weblocks and Core Server both utilizes Continuations.
Weblocks has complied fast continuations but lacks several lisp2 forms.
Core Server utilizes arnesi interpreted continuations. It covers most of
the lisp2 forms but they are slow. We plan to implement compiled
continuations in near future.
- Weblocks uses Hunchentoot, Core Server has its own HTTP server.
Hunchentoot is a very reliable web server. Most of the lisp projects
depend on it. It also supports chunked encoding via Chunga library. I'm
not sure, whether Hunchentoot support multiple applications over a
single server.
Core Server has it's own HTTP protocol parser and renderer built on top
of Core Streams. Most of the protocol is covered in parser unlike other
HTTP decoders. Current implementation does not support chunked encoding,
but it is planned. Core Server support multiple seperate applications on
a single server.
- Core Server has installer, Weblocks hasn't
We tried to implement a clean installer so that nobody has to tackle
with dependency problems. Also, we plan to maintain all dependencies so
that, no core server instance is broken due to dependency updates. (ie.
making official releases, stable/devel). Finally, Core Server does
support management of several Unix services like Apache, Tinydns etc
which eases web/project hosting. (ie. it automatically generates
virtual host configurations , adds mx records etc.)
- Core Server has its own Lisp to Javascript renderer.
Afaik, Weblocks users can utilize Parenscript.
Core Server has it's own fast lisp to javascript renderer which is
efficient than Parenscript. *warning* we'r currently fixing bugs along
with component framework.
- Support for other protocols
Core Server has built in protocol parsers and renderers for several rfcs
like imap/smtp/mime/http etc. This eases burden over developers while
communicating with external systems.
- Support for other Lisp Implementations
Core Server currently does support only SBCL. This can be overcomed by
implementing compiled continuations over epoll sockets which we planned
to implement in near future to ensure speed requirements.
I don't have information about on which lisp implementations Weblocks
can run.
- Weblocks has class based components, Core Server has functional PLT
like Web Framework
Afaik, Weblocks has mop based components in which developers do IoC to
form a web page which reminds me a OO version of Java Spring.
Core Server has functional web framework like PLT Scheme.
- Core Server Javascript Components Framework
To implement browser based services, Core Server has unique Javascript
component library which automatically generates javascript RPC proxies
which utilizes continuations. Stateful remote session beans and
stateless session beans can be implemented very fast.
*notes*: Current implementation is broken due to switching from
Parenscript. I'm trying to fix it soon in order to upgrade our own
servers on which we serve our Coretal product. In fact, Coretal is just
a combination of several stateless and stateful remote services (or
beans, if you like the name)
That's all for now. I think, both project has pros and cons. We'r trying
to get more feedback to make Core Server easy to use. I hope, we are
going to accomplish this crucial task.
Have a nice day.
Evrim.
So this is the main thing that interests me about Core Server, just
FYI.
> That's all for now. I think, both project has pros and cons. We'r
> trying to get more feedback to make Core Server easy to use. I
> hope, we are going to accomplish this crucial task.
Many of the other things you mentioned aren't of much importance to
me as a user. In the interests of trying to be helpful
(seriously!), let me tell you the things that I've seen that might
make me want to use Weblocks instead of Core Server. I'm not saying
"You must fix these things to keep me! Bwahaha!"; it's not a race.
I'm just trying to help, since you asked.
- http://common-lisp.net/project/cl-weblocks/docs/weblocks-package/index.html
is a big one; the Core Server documentation that exists is pretty
excellent; I like the style a lot. However, nothing can take the
place of genuine API docs, no matter how crappy, because without
them I have no idea what abilities might be lurking in the code
somewhere, unseen by me.
- http://72.249.76.121/ -- it's a demo application that's fast, easy
to understand, is pretty, and has very clean and simple code that
one can learn a lot from about how to use the system.
For the rest here, I will talk about actual abilities of the system
rather than documentation and such, but because the core-server docs
are so sparse, you should pretend everything I say is wrapped in "as
far as I've been able to determine as an outsider, core server
doesn't have this". If core server *does* have these things, I'd
love to hear about it.
- Weblocks deals with common cases really, really well. If I want
to present the user with the ability to edit a set of data, I just
define the class and say "Here, let the user edit this". Not
counting the class definitions, it's one line of code. I've read
enough Core Server docs to respect that it probably handles
complicated cases better, but there's something to be said for
cleanly handling the common cases.
- Weblocks comes with decent CSS that works well with its default,
common-case widgets. I know it doesn't sound like much, but it
really speeds up initial development.
- Weblocks can use basically any database system as its backing
store for its editing widgets. Letting the user edit an instance
of a class is one line of code; letting the user edit all
instances of a class stored in my MySQL database is maybe 5 lines.
- The whole "start a darcs project" thing is both useless to me (I
don't use darcs, nor git, nor do I want to) and really quite
incomprehensible. All the documentation seems to say is "run this
and something nice will happen". Furthermore, it is repulsive to
me (sorry) that my web framework would have anything to say about,
or any interaction with, my SCM. That's my job, not the web
framework's job. Seriously. There's nothing in the docs to
indicate that having Core Server manage my SCM gains me any real
benefit, either. In contrast, Weblocks has similar new project
command that gives me some nice CSS and javascript, in well laid
out directories, with a clean default "Hey, it's working!" page
all set to go. It makes no attempt to interface with any SCM.
That's what's coming to mind right now. Hope it's helpful.
I missed an important one; oops.
- Since Weblocks abstracts away edit forms and such into widgets, it
is able to, and does, automatically use AJAX or regular POST/GET
depending on client capabilities, which means I essentially get
AJAX for free, which is really excellent as an end user.
> - Weblocks deals with common cases really, really well. If I want
> to present the user with the ability to edit a set of data, I just
> define the class and say "Here, let the user edit this". Not
> counting the class definitions, it's one line of code. I've read
> enough Core Server docs to respect that it probably handles
> complicated cases better, but there's something to be said for
> cleanly handling the common cases.
>
> - Weblocks comes with decent CSS that works well with its default,
> common-case widgets. I know it doesn't sound like much, but it
> really speeds up initial development.
>
> - Weblocks can use basically any database system as its backing
> store for its editing widgets. Letting the user edit an instance
> of a class is one line of code; letting the user edit all
> instances of a class stored in my MySQL database is maybe 5 lines.
I want to speak to this as a group a bit more. It seems to me that
a central goal for Core Server is "being able to program web
applications just like regular Lisp code". In (somewhat) contrast,
Weblocks has as a central goal "never having to write HTML or
Javascript as an end user".
This has led, it seems to me, to their two very different styles.
In Weblocks, unless you're very steeped in its system I guess, you
have to use its built-in widgets. The built-in widgets are awesome,
and do very much the things I want them to do, but the program ends
up looking nothing like normal Lisp. In fact, it's not even
procedural; it's somewhere half way between event driven and data
driven programming, AFAICT.
In contrast, Core Server has things (looking at the examples here)
that look very much like normal Lisp program flow; "get some
information from the user like so, and do this with it".
My problem is I want both. :D
I suspect this would not be terribly difficult to achieve in Core
Server; it's "just" a matter of writing templating code that
understands classes and database back ends and AJAX and "just
works", which is what I've been so impressed by with Weblocks; it
"just works".
Adding to Core Server the ideal of never having to write HTML (well,
serious HTML anyways; obviously one needs to break out the "p" tag
now and again) a la Weblocks would certainly be quite a bit of work,
but it seems a worthy goal to me, and not at all at odds with Core
Server's philosophy as I've seen it so far.
Whether I have the time to get involved in that effort is a whole
different matter; I have enough on my plate with my current project
that the impetus to just grab the tool that is closest to working
out of the box is quite strong; I'm afraid right now that's almost
certainly Weblocks.
Anyways, like I said, this is all trying to be helpful. :) Hope
it's worth something.
-Robin
Actually we've never thought to force users to use SCM or to use a
*specific* SCM. Accordingly, darcs-application and git-application are
extentions of serializable -application. If you do not want to use any
SCM, please use make-serializable-application constructor.
That applications generally represent how we develop projects, however,
as Nico pointed, applications can be loaded just from a single file. (ie
blog example)
I wish this helps.
evrim.