Sunday, January 28, 2007

Seaside Screencasts

So I followed a great example and cooked up a couple screencasts.

The first presents Seaside as a Web app IDE, one of the very cool things about it which sometimes gets overlooked in the discussion about it -- and I sometimes suspect the number of people talking about Seaside is larger than the number of people using it -- and the second addresses that whole Rails vs. Seaside thing in much greater detail. (I promise it isn't another language war.)

First screencast: 4 minutes:
Seaside is a framework and an IDE

Second screencast: 12 minutes:
Seaside and Rails

Update: turns out I'm wrong -- you can do REST in Seaside.

Update 2: I moved the screencasts to S3.


  1. Nice screencasts man. Also, the blog is much more readable with the new color scheme, thanks for losing the black, it always hurt my eyes.

  2. I dug the screencasts.

    I've been tinkering w/ Seaside for a while now, and can't wait to learn more about it.

    Thanks for getting the word out and the good analysis.

  3. I really enjoyed both screencasts, but there's something that troubles me - I think that Seaside uses GOTOs as well.

    Now, you'll have to forgive me because I haven't actually used Seaside any more extensively than playing with the tutorial VM and getting confused at the distinct workflow differences...but this was my experience.

    In Seaside you use HREFs just as is done in Rails. In Rails, a URL is typically stateless and the state of your current users' interaction is determined within the application. Once you execute a GOTO, the path through your application is built based on the session of the user (or disregarding sessions all together). Alternatively in Seaside, a GOTO will hit the continuations implementation first (hence, no session discovery is required), and from there the path is built (or resumed).

    Is there a difference? What exactly are you complaining about? I'm not having a go, but you haven't really explained *why* GOTOs are considered harmful in the context of HREFs. Could you explain that to me because I don't think I quite get it yet.

  4. Apologies, I'm in the process of relocation, this is going to be short. You might be totally right -- Seaside uses "anchor" to generate hrefs manually in a way that isn't so different from the link_to() or url_for() in Rails. To some extent both systems automate link generation but not fully in either case.

    The original "goto considered harmful":

    Both Seaside and Rails are eliminating the explicit goto; I don't think either one has entirely succeeded yet. One possibility for the future is that href never disappears, another is that it does. I think it will; I think more and more, coding literal hrefs will probably be seen as a bad thing.

    I'm really not trying to say "X is better than Y" here -- I just think that the popularity of Rails kind of overshadows what's really going on, and that overlooking Seaside's advantages is a bad idea.

    It's really the clumsiness of goto that you want to avoid. With Seaside you get an awful lot of that elminated, via the continuations approach to session; I think within Rails the same thing could be done, except it'd involve packing a **lot** of information directly into links, or the session on the server side. Rails tracks session automatically too, that much doesn't make Seaside unique. It's the completeness and grace of Seaside's sessions that are unusual.

    Sorry, not sure I even answered the question there.

  5. That's funny, I use Live for recording my music as well

  6. Hi,

    if you want an up-to-date Squeak 3.9 image with Seaside, completion, syntax highlighting... you might want to use
    the squeak-web image.

  7. Alan Kay was talking about the RESTish objects-as-resources idea some time ago: witness 42:54 of his 1997 OOPSLA talk.

  8. In my opinion, GOTO == href is a flawed notion. Goto is about jumping around inside a program on a per-line level. Makes code hard to follow, thus it's considered hard-ful.

    hrefs are about referencing resources. Resources are black boxes, high-level interfaces to whatever you have on the inside. Presented through a uniform interface of four standard verbs.

    You can't reference line X of the implementation from a link. You can't see the inside of the implementation from a link.

    It's operating at a completely different level from both a practical and conceptual level. So I don't think that equation is meaningful.

    Also, the "Rails 0wns seaside / Seaside 0wns Rails" debate presented here appears a tad anemic. I'm not saying it's not the case, I'm just saying that no argument for the case is being presented, thus no enlightening of the viewer is happening.

    I think Seaside would probably be pretty damn cool for something like a web-version of that turn-table layout. High interaction, all temporal state, etc. Although I'm not even really sure, because I haven't actually tried to make such a thing in either.

    What I'd love to see is someone doing some real comparisons on some real apps. Not to prove one or the other better, just to enlighten people of their differences. I think Seaside is fantastic by shear merit of being different than the request-driven world that Rails inhabits. But that's a very high-level distinction. Let's see something more practical.

  9. Very interesting screencasts. The parts about training wheels and speed limits seemed slightly one-sided however (although by no means I am disagreeing; I officially left PHP for Rails a while back and am currently flirting with Seaside.) I realize you're projecting an objective view of the situation, but just sayin'.

  10. These comments have been invaluable to me as is this whole site. I thank you for your comment.

  11. I get 404's on both of these screencasts.

  12. I can't get to the screencasts. I get a 404 error.

  13. Well done. Keep up the great work. Best regards!

  14. I like it a lot! Nice site, I will bookmark!

  15. Thanks to author! I like articles like this, very interesting.

  16. Disaster is likely to wreak havoc in the life of an individual as soon as he becomes victim to erectile dysfunction and the most significant dreadful consequence of erectile dysfunction is that the afflicted man becomes incapable of facilitating erections required for sexual intercourse. The sexual vacuum resulted from erectile dysfunction prompts the sufferer to opt for anti-impotency pills, most especially the viagra medication that was approved by FDA (Food and Drugs Administration) as a clinically effective drug to cure erectile dysfunction in men. Viagra is meant to be administered by patients only after availing of viagra prescription from the doctor. The prescription for Viagra provided by the doctor spells out that the patient suffering from erectile dysfunction seriously need Viagra to treat his disorder and further authorizes the patient to avail of Viagra from the pharmacist.

  17. Discount Pharmacy online pharmacy serving your needs for prescriptions

  18. Viagra
    Generic Viagra


Note: Only a member of this blog may post a comment.