That's a great talk, thanks for sharing. It seems like clean separation between a JavaScript client app and a server-side data/controller layer is the way forward.
But I'll still content that web development as a whole is broken, because web dev is a teetering mile-high tower of abstractions and when something leaks, it tends to trickle all the way down and stink up the whole stack.
A great story about the kinds payoffs when you actually take the time to learn very unfamiliar tools. This drive to learn rich and deep and unfamiliar systems is the source of any real counterforce to the pop culture CS that Alan Kay talks about.
Quite interesting. It does seems most of the advantages of Seaside are from using the Smalltalk environment. One thing is definitely clear: Ruby needs much stronger debugging support.
2. Oh noes, you hit an error: the browser shows you the stack trace.
3. At the top of the stack trace, there's a "debug" link: if you click that, the HTTP request causes your dev environment to pop up a debugger. No response comes back to the browser yet.
4. In the debugger, it's as if you had a breakpoint right before the error occurred: you can walk back through the stack and inspect the state of each frame, etc.
5. If you see the problem, you can edit the code - right in the debugger UI - and hit save. The stack will unwind to whatever frame you are editing the code in, and restart from the top of that method or block.
6. As execution continues, the HTTP response finally goes out, and you see the (newly fixed) web page come into the browser.
As someone noted in another comment: although I was the main developer and evangelist of Seaside for a while, I no longer use it or contribute to it (though many others have taken up the torch) but I can't tell you how much I miss this workflow.
Although I use Lisp+Ruby+Java for just about everything I do, I do keep an eye on Squeak and Pharo (hoping for JIT performance someday getting fast like the commercial VisualWorks product).
I periodically run through a Seaside tutorial - really neat stuff, and very easy to deploy on Linux servers (I blogged about how to do this several years ago).
One thing that attracts me to Seaside is that (unfortunately) most of the web apps I write are low volume sites so I would not have to worry too much about scaling. I make this same argument for using Rails rather than Java.
Your data persistence and retrieval strategy is much much more important for scalability than language choice. Rails application servers are trivially horizontally scalable. Obviously raw performance matters if you're doing a lot of heavy data crunching, and even then it's easy to spot-optimize things unless all your code is truly performance critical.
"I make this same argument for using Rails rather than Java." -- JRuby is pretty cool, no need to choose! It isn't as fast as raw java, but you can easily swap out the hot paths with java to get additional performance.
I have Pharo 1.1.1 final with Cog installed on my MacBook. Cog really helps. James Robertson benchmarked VisualWorks (he is the VW evangelist), Cog_Pharo, and Squeak, and his benchmark show Cog generally doing much better than Squeak. The situation will get even better when parts of Pharo are rewritten for Cog. Anyway, give Cog and Pharo a try: qualitatively, it seems very snappy.
Conceptually, I like Seaside. But I simply can't get past the hideous abstraction-leaking URL scheme it insists on. They aren't resource locators; they're session IDs, with all the info stored in the session state. Users should be able to copy and paste URLs to things. They expect it, and that's not an unreasonable expectation.
Absolutely true for some apps (and for those apps, in Seaside as in any other framework you can do the extra work to get bookmarkable URLs). For other apps, it's nice not to have to worry about this. For example, when did you last email someone a URL from your Gmail session?
Every time a component in seaside is rendered there is an opportunity to set the url. It can be useful for some apps to not have to worry about this either during some phases of dev or ever. seaside is continuation centric. You have to fight the system to get around for those occasions when it really won't suit. It would be nice to see a next-gen seaside like framework that gave the programmer flexibility in when continuations are used. There are aspects of the framework that show a wear and cruft and would benefit from a clean-room rewrite a la rails3/merb2.
That said, Smalltalk and the latest Pharo is a joy to work with.
Interesting but I was constantly distracted by the X bullet points next to the list items that you liked. Perhaps you could add a class to put checkmark icons instead when writing an article like this.
I'm pitching Seaside as a contender for the platform to build a new app on tomorrow. I'm completely and utterly sold on it. The experience is really just unparalleled in the world of software and web development, and I think the Smalltalk tools it is built on is a huge part of that.
I'm intrigued by Monticello. Is that a source control tool ? Or is it far more than that. The author seems to alude to Monticello as part of the smalltalk package.
Yes, it's a source control tool. Smalltalk doesn't store source code in text files, so you can't really use tools like git or svn to version Smalltalk. Monticello is a DVCS written specifically for versioning Smalltalk code.
He went overboard and implemented smalltalk in javascript (named clamato): http://stackoverflow.com/questions/2116348/does-anybody-use-...