Pollak On Seaside
Found on a Rails blog…
“IMHO Seaside is the benchmark by which all web frameworks should be measured” — David Pollak
My thoughts exactly. It’s not about the language, it’s about the approach. Seaside is the right recipe for writing real applications, not just fancy websites. No other framework can do what Seaside does, as easily as Seaside does it. Real components with their own state, real objects, no pages, no templates, Ajax in pure Smalltalk by simply wiring events together on the server side, calls to other components are actual method calls rather than hacked up URL conventions.
For Rails fans (myself included), don’t compare Seaside to Rails, rather compare Seaside to ActionPack, the view controller layer within Rails. If you want to see an apples to apples comparison of the entire stack, it’d be something like…
ActionMailer == Existing Squeak services
ActionPack == Seaside
ActionWebservice == SoapCore
ActiveRecord == Glorp
ActiveSupport == Existing Squeak code, the image is full of DSL mini languages to make everything pretty
Seaside isn’t the well integrated full stack solution that Rails is, but all the parts are there, you can mix and match your own perfect framework.
at: "No related posts";
Mutter. Grumble. Chunter.
Just because you took the time to find the right method names doesn’t make it a DSL. It’s merely the least you should do.
But you’re bang on about what Seaside is, and why that makes for such a rich programming environment.
No idea what you’re grumbling about, but Smalltalk code, in general, is written in a DSL style, so much so that it’s not worth an extra support layer to make Smalltalk prettier.
I think you’ve hit the nail on the head. It’s definitely the approach. While certain language facilities (e.g., closures) make certain approaches easier, I think it’s the vision that drives the reality.
Interestingly, the most productive desktop development environment I’ve ever programmed in (and I’ve programmed in a lot) is Interface Builder (now known as XCode.) WebObjects grew on top of NextStep and was a cousin code-wise and design-wise to Interface Builder. Avi claims a lot of his inspiration for Seaside from WebObjects. But I ramble.
David,
if you find Xcode very productive, you might want to check VA Smalltalk’s composition editor which takes many of the concepts a step further.
And Instantiations is working on getting VA Smalltalk ready for seaside…
Seen Borges? http://rubyforge.org/projects/borges/
IIRC, Avi worked on Borges for a while. No?
@Dave, ramble on, I quite enjoy your ramblings.
I know about Borges, but I was under the impression it was abandoned. Does it have a community, is it in active user? Might be fun to play with.
Ah, sorry Ramon; just a hobby horse of mine. My complaint about the whole “It’s a DSL” style of talking about a well designed message protocol is that, by calling it a language we’re implying that it’s somehow rocket science, when really it’s a matter of using your implementation language effectively.
I try to avoid writing DSLs (parsers scare me), but I’m all for sweating to get a message protocol just right, and I think it’s worth drawing the distinction. YMMV.
Piers: You only need a parser for an external DSL (what less powerful languages like C/C++/Java/Perl would need). For a powerful language like Smalltalk or Lisp you can do a DSL inside your language.
For example, there is no branching defined in Smalltalk. But of course someone would want branching so they added it (DSL style) into the libraries.
Of course some people will say that because the VM treats #ifTrue:ifFalse different that it is really part of the language. But that’s a silly argument. Once Exupery gets to cranking out fast Squeak code such optimizations (hopefully) wont be needed anymore.
Piers, I don’t disagree, I just consider a well designed message protocol a DSL, they’re one and the same (in the right languages). Parsing is not a necessary attribute of a DSLs but rather a step required of “some” DSLs that require completely novel syntax. Lisp/Smalltalk/Ruby all do DSLs without parsing.
Piers may actually have a point, without knowing it ;-)
In the current Squeak image we have something like “10 minutes” to get a Duration, but not something like “10 minutes ago” to get a point in time. In fact, one of the Squeak Summer of Code proposed projects was to get the base image on par with ActiveSupport.
Not really a fair comparison, ActiveSupport is an add on library. I’d bet the Squeak base image is more expressive than the Ruby standard library in most respects. Toss in libraries like Chronos if you want to compare apples to apples.
While I really like Squeak and the ideas represented in Seaside, I personally found it quite difficult to get start writing a real web app with it due to the complete lack of any significant documentation. Some of the tutorials are great, but I’m completely baffled about how to use Glorp and Magritte. So I had to fall back to symfony & php, which I’m not terribly happy about, but at least I do manage to get my projects moving forward. I *love* to see a really good book about how to do professional Seaside web apps. :)
I’ve written on those topics, browser around the blog a bit and you find some examples.
@Alexis:
What you’re saying is true. There are books on the Smalltalk language, and on Squeak proper, but none (to my knowledge) on Seaside, or any of the other technologies Ramon talked about. Lukas Renggli has written up some excellent stuff on Seaside. He also wrote Magritte (I think). He has some PDF tutorial slides on it as well.
You can see his tutorial slides at http://www.lukas-renggli.ch/smalltalk/seaside. Over on the right sidebar you can select other sections of this site that cover Magritte and Pier. I know he wrote up a tutorial for Magritte.
Very interesting, thanks for sharing with us.