[Seaside] Anybody see this?

[Eagle Offshore]

Its funny but I'm hearing seasiders dismiss this technology using many  
of the same arguments that non-seasiders use to dismiss seaside.  You  
sound exactly the same as your detractors.

There are multiple backends for capuccino - including php.  PHP scales  
like crazy.  Not worried.  It is not hard to imagine writing a single  
data access handler to bridge database requests and forgetting about  
it.  There's a nice little minimal ActiveRecord for PHP I just used on  
a prototype that kicks any database access technology I've used in  
Squeak in simplicity, usability, and speed.

They've essentially implemented Cocoa in Javascript (Capuccino) and a  
commercial product using that (http://280slides.com/), and now they're  
using that to implement Interface Builder and XCode.  They say it  
works in all common browsers identically including IE6.

To me it looks very "turtles all the way down" but abstracts away the  
whole web trash heap.  For applications, not websites.  I see a lot in  
common with lively kernel.  SproutCore looks nice but it is very much  
a web technology.

As to the comment about the complex part of applications not being the  
interface - on web apps I spend 95% of my time tweaking UI - fiddling  
CSS rules usually or typing endless nestings of builder methods to  
generate taggage to implement simple things.  UI is all I do on the web.

Anyhow, their demo is better than any gui builder that has appeared  
for squeak - morphic or web.

I'm not here to trash seaside - I think it rocks.  But I find the  
render/canvas extremely tiresome to work with because at the end of  
the day its still building web noise and I think lively kernel/ html5  
canvas and cappucino/atlas are hinting at a major shift and some deep  
thinking and reexamination is in order.  That's my point.

-Todd Blanchard

On Apr 8, 2009, at 7:57 AM, Sebastian Sastre wrote:

> It says nothing about how good is to build the application itself.  
> Not to
> mention scaling complexity.
> So far I see no signal of that being better than a modern version of  
> visual
> basic for the web.


On Apr 8, 2009, at 7:12 AM, Boris Popov wrote:
> a) any design choices beyond what they offer might be hard to  
> implement
> b) the complex part of today's applications isn't the interface, it's
> whatever is behind it