Why I have migrated from Ruby on Rails to Seaside | Hacker News Reader

Why I have migrated from Ruby on Rails to Seaside

codingforhire.com

57 pointsduck28 comments

One of the things that troubles me is that even Seaside's creator (Avi Bryant, who sold his company to twitter recently) mentioned how this way of doing web apps is old: http://python.mirocommunity.org/video/1186/djangocon-2009-dj...

He went overboard and implemented smalltalk in javascript (named clamato): http://stackoverflow.com/questions/2116348/does-anybody-use-...

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.

A post later: Rails to Seaside – Some things I missed from Rails http://www.codingforhire.com/2010/11/rails-to-seaside-some-t...

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.

Even Python is more pleasant to debug in.

I use NetBeans to code Ruby and the debugging is great. You can set breakpoints, step through, set watch variables etc.

I don't have a ton of experience debugging with other languages (prob Java is the only other one), but what is Ruby missing?

Here's the experience of debugging in Seaside:

1. You reload a buggy app in the browser.

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.

(Edited for formatting)

Right, that is super hot. Takes some VM calisthenics to pull it off, let alone expose it for frameworks to use.

From a quick glance this sounds similar to the debugging provided by paste/pylons? I've only played briefly with pylons so I may be way off though...

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.

"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.

Or, you could pony up for VisualWorks server licences and get even better performance. (And swap out the hot paths with DLLs implemented in C.)

I do keep an eye on Squeak and Pharo (hoping for JIT performance someday getting fast like the commercial VisualWorks product).

What about CogVM? I thought you could run Pharo on it already? (Granted, it's in something like Beta.)

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.

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.

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?

That's an excellent example. I've been a bit skeptical about continuation-based web services, but that makes a lot of sense.

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.

Is there a current hotbed of Squeak/Pharo/Seaside development? I'm wondering where I should move in the US?

There's been an active Smalltalk community in Vancouver, BC. If you want to stay in the U.S., then Seattle or Portland may work.

Seaside seems interesting but how is the smalltalk library support? Does it have a robust way to call libraries in other languages?

It has FFI, so you can call other libs as long as they are C-compatible.

Reply on news.ycombinator.com