The Elevator Pitch for Seaside
I'm at BarCampPortland this weekend, scheduled to introduce a whole new batch of folks to Seaside this afternoon.
But as we were organizing the "unconference" last night, I found myself having to repeatedly describe Seaside and why I'm so excited about it. This is good practice for me, and I'm happy that I did a bit of that for the interview a few days ago.
But I think I've come up with a good elevator pitch for "why Seaside and not [insert other framework here]", that centers on three key items: abstracted control flows, live debugging, and persistence without ORMs.
Because Seaside has a continuation-based framework, I can write a single method that captures the flow of my application in a natural way: "show page 1", "show page 2 until the data validates", "show page 3". My local variables and state of execution persist transparently between page hits, so I don't have to spend a lot of time figuring out how to leave myself notes for the next hit. This also means I can build a reusable library of control flows ("login page", "validated multipage form", "paging through a dataset", "breadcrumb trail") and save myself development time in the long run. Without continuations, this is a difficult thing to do, and I know, having coded control flows in Perl webapps for many years.
Seaside is Smalltalk, and inherits Smalltalk's live debugging feature. When something breaks, I get a stack backtrace that is live, and I can find the problem, edit the code, and proceed from that point, returning to the same hit done correctly, instead of restarting my testing from scratch. (I hear the folks at GemStone are even persisting failures from test suites overnight: the bug report has a link that takes them right to the precise broken state, and they can fix it and continue the suite from there. Incredible.)
Through GemStone/S, or the open source Magma tools, I can tell Smalltalk to simply "persist these objects", meaning that I don't have to build complicated and computationally expensive strategies to take my naturally-shaped objects and map them through a narrow SQL bottleneck to a database and back again. The objects are shared in their natural shape using Smalltalk-aware strategies.
These are the three key points. If the elevator ride is a long one, I would also include that Seaside is supported by two commercial vendors (Cincom and GemStone) and two open source Smalltalks (Squeak and GNU Smalltalk), providing lots of options for support, scaling, and philosophy of development.
So, I'm going to quickly be writing up some slides that look like these talking points, since I found out I have only 45 minutes for this talk, and my 60-minutes of material won't fit, nor will the audience sit still for a longer talk, I suspect.
Comments