6 ms·

Why I have migrated from Ruby on Rails to Seaside

57 points by duck 16y ago

nek4life 16y ago
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.
mark_l_watson 16y ago
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.
- aaronblohowiak 16y ago
  "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.
  - stcredzero 16y ago
    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.)
- stcredzero 16y ago
  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.)
  - mark_l_watson 16y ago
    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.
- dasil003 16y ago
  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.
stcredzero 16y ago
Is there a current hotbed of Squeak/Pharo/Seaside development? I'm wondering where I should move in the US?
- mattrepl 16y ago
  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.
swannodette 16y ago
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.
ghotli 16y ago
Seaside seems interesting but how is the smalltalk library support? Does it have a robust way to call libraries in other languages?
- jcromartie 16y ago
  It has FFI, so you can call other libs as long as they are C-compatible.
rbranson 16y ago
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.
- alnayyir 16y ago
  Even Python is more pleasant to debug in.
- barmstrong 16y ago
  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?
  - avibryant 16y ago
    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)
    - rbranson 16y ago
      Right, that is super hot. Takes some VM calisthenics to pull it off, let alone expose it for frameworks to use.
DanielRibeiro 16y ago
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-django-is-obsol 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-clamato/3714081#3714081 http://stackoverflow.com/questions/2116348/does-anybody-use-...
- jcromartie 16y ago
  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.
  - deleted 16y ago
    [deleted]
jcromartie 16y ago
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.
jasonlotito 16y ago
A post later: Rails to Seaside – Some things I missed from Rails http://www.codingforhire.com/2010/11/rails-to-seaside-some-things-i-missed-from-rails/ http://www.codingforhire.com/2010/11/rails-to-seaside-some-t...
chc 16y ago
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.
- avibryant 16y ago
  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?
  - silentbicycle 16y ago
    That's an excellent example. I've been a bit skeptical about continuation-based web services, but that makes a lot of sense.
- jhancock 16y ago
  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.
kuahyeow 16y ago
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.
- cwp 16y ago
  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.

57 points by duck 16y ago

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.

mark_l_watson 16y ago

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.

aaronblohowiak 16y ago
"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.
- stcredzero 16y ago
  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.)
stcredzero 16y ago
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.)
- mark_l_watson 16y ago
  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.
dasil003 16y ago
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.

stcredzero 16y ago

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

mattrepl 16y ago
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.

swannodette 16y ago

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.

ghotli 16y ago

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

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

rbranson 16y ago

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.

alnayyir 16y ago
Even Python is more pleasant to debug in.
barmstrong 16y ago
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?
- avibryant 16y ago
  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)
  - rbranson 16y ago
    Right, that is super hot. Takes some VM calisthenics to pull it off, let alone expose it for frameworks to use.

DanielRibeiro 16y ago

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-django-is-obsol 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-clamato/3714081#3714081 http://stackoverflow.com/questions/2116348/does-anybody-use-...

jcromartie 16y ago
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.
- deleted 16y ago
  [deleted]

jcromartie 16y ago

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.

jasonlotito 16y ago

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

chc 16y ago

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.

avibryant 16y ago
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?
- silentbicycle 16y ago
  That's an excellent example. I've been a bit skeptical about continuation-based web services, but that makes a lot of sense.
jhancock 16y ago
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.

kuahyeow 16y ago

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.

cwp 16y ago
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.