Rails vs Seaside
By Ramon Leon - 22 January 2007 under Programming, Ruby, Seaside, Smalltalk
Sometimes a small sample is really helpful in showing the differences between two approaches. Ruby on Rails is a slick web framework for building web applications the old way. When I say the old way, I mean building URLs manually and passing parameters through query strings manually, i.e. marshaling session data manually.
Rails automatically maps URLs to controllers and methods in those controllers to set up the appropriate models, and automatically binds the correct view for that method, based on naming conventions of the files. It's a great method and saves much of the hassle of writing a web app while enforcing a nice model view controller paradigm. Here's a sample any Rails programmer will probably recognize, first list.rhtml...
<% @recipes.each do |recipe| %> <tr> <td><%= link_to recipe.title, :action => "edit", :id => recipe.id %></td> <td><%= recipe.category.name %></td> <td><%= recipe.date %></td> </tr> <% end %> <p><%= link_to "Create new recipe", :action => "new" %></p>
and its controller...
class RecipieController < ApplicationController
def list
@recipies = Recipie.find(:all)
end
def edit
@recipie = Recipie.find(@params[:id])
end
end
Nice and clean, but the programmer is still working in a template language, requiring constant context switching between Ruby and HTML, and still manually building anchor tag URLs by calling a method and passing in the recipe's id. Passing around ids requires that the next view, bound to the edit method in the controller, needs to look up the object from the database with that id from reading the request parameters. You can see this in the edit method of the controller, it sets up data in an instance variable in the controller so the view will have access to it.
This is classic web development done very cleanly, and honestly very Smalltalk'ish, however, passing around an object id isn't very object-oriented (it's rather relational actually), and context switching between two languages while working in the view isn't very fun. Instead of passing around an object's id why not pass around the object instead?
Enter Seaside, same code, a different approach, more object-oriented...
renderListOn: html
self recipes do: [:recipe |
self renderRecipe: recipe on: html ].
html paragraph:
[html anchor
callback:[self editRecipe: Recipe new];
with: 'Create new Recipe']
renderRecipe: aRecipe on: html
html tableRow id: #recipie, aRecipe id; with:
[html tableData:
[html anchor
callback:[self editRecipe: aRecipe];
with: aRecipe title];
tableData: aRecipe category name;
tableData: aRecipe date ]
and the controller code...
recipies
^recipes ifNil:[recipes := Recipe findAll]
editRecipe: aRecipe
self call: (RecipeEditor for: aRecipe)
Seaside puts the view and controller together in one class, the component, and it can do so cleanly because there is no templating language, rendering views are simply method calls in pure Smalltalk. So instead of having a controller, with a bunch of RHTML files and partials, we have components (aka view/controllers), with rendering methods (aka partial views).
It's important to note however, that view code and controller code are still normally kept quite separate and organized using Smalltalk's method categories. View methods are normally categorized as "rendering", or something more specific like "rendering ajax", while controller code is categorized in categories like "actions", "queries", "accessing", or whatever categories you make up to keep your code organized. This is one of those Smalltalk things that no other language really has and only exists in its environment so it doesn't translate to sample code.
Now, the main thing to note here, is that objects are passed between views as actual objects using a constructor on the view (RecipeEditor for: recipe). One component simply creates and calls another. The components are also rendered in pure Smalltalk, which means they can be factored into smaller more reusable methods (aka partials), using all of Smalltalk's existing tools, i.e. the refactoring browser. This is amazingly productive.
The anchor tag has a closure attached to it via its #callback: method, containing the actual code we want to execute when the user clicks the link. This closure, or block as Smalltalkers call them, gets turned into a URL automatically by Seaside and stored as a continuation on the current session. This means that RecipieEditor view doesn't need to go back to the database and look up the recipe by its id, because it was given the actual recipe object directly (less load on the database). In essence, instead of passing a bunch of state through a URL manually, you simply say when this link is pressed, execute this code. This is a technique discussed by Paul Graham in his essay Beating the Averages that he used in ViaWeb. This one change drastically changes the way one thinks about, and builds web applications and makes programming much simpler.
Notice how I've factored out the rendering of a single row into its own method. This sets me up to do some nice simple Ajax updates of individual row by being able to pass an Ajax rendering canvas through that same #renderRecipeOn: method. For example, I could re-render just that row, via Ajax, when a hyperlink is clicked with just this...
html anchor
onClick: (html updater id: #recipe, self randomRecipe id;
callback:[:ajax | self renderRecipe: self randomRecipe on: ajax]);
with: 'Replace random recipe with another random recipe'
So when I write a page, I break it up into rendering methods based on which parts of the screen I want to update via Ajax. This is similar to what Rails does with partials, except Seaside does it with ordinary objects and methods. Top to bottom, objects and method calls in pure Smalltalk, no web stuff.
This is what Seaside gives you, a complete abstraction of the HTTP request-response cycle so you can program normally, as you would any desktop application, without all the extra hassles that web development introduced. Even abstracting away JavaScript for the most part. This translates into much faster application development, yes, even faster than Rails. It also means if you have to port a desktop application to the web, Seaside may allow you to do so without having to completely rework the existing design.
The price you pay... sessions and a little memory on the server. Yes it's harder to scale than a session-less approach like Rails, but it will scale, and memory is cheap these days, far cheaper than programmers. Seaside, like Rails, is a very opinionated framework. Seaside's opinion is that programming is the most expensive part of application development, so let's optimize development time instead of CPU memory and cycles and throw out the (stateless/templated HTML) model of web development in favor of simpler web development in one language, where you have all of your tools available and aren't constantly context switching between several languages.
Comments (automatically disabled after 1 year)
Rails is MUCH more clear and beutiful than that.
I understand you point of view, but it comes from not understanding Smalltalk.
Markaby is very much like Seasides rendering canvas, thanks for the pointer. However, in Smalltalk there are no files. Smalltalk runs in an image and you work on live class objects through an object browser.
Bloat, in the fashion you're referring to, can't happen in Smalltalk, not like it does in file based languages. You can easily have dozens and dozens of view methods and keep them perfectly organized and categorized because of how Smalltalk's code browsers works. And as I said, what it offers is a level of abstraction and factoring that isn't available in html. I can't use my refactoring browser on html, I can't cut up html in small reusable chunks in a way that allows intellisense, like I can in code. Html doesn't offer much abstraction, code allows me to abstract however I want. Try to see behond the simplistic example.
Also, everyone thinks Smalltalk is hard to read at first, just like Lisp, but once it clicks, most prefer it to stay as is. Smalltalk syntax rocks. However, as you say, to each his own, Seaside isn't for everyone. Rails is a fine framework, if it works for you, stick with it.
I must admit, though I am familiar with Smalltalk's syntax, I have never used its code browsers or IDEs, which I'm told are second to none - in fact, I've even heard some Smalltalkers say that they are the best part about the language, the icing on the cake if you will.
As someone familiar with Smalltalk and Ruby, what do you think is stopping Ruby from having as powerful a development environment as Smalltalk?
Although I see the benefit of using this style of html generation, I think it has two shortcomings: 1) it's impossible for non-programmers to read and manipulate, and 2) you bind session data to a physical server, which makes load balancing difficult and you risk losing session data if the server crashes (but there may be ways around this that I don't know)
If you absolutely want, you can build html like that in Rails too, using the XML Builder. But, as previously mentioned, that would be stupid since it makes everything so much harder to read and manage.
That's simple, files. Nothing can even come close to Smalltalk's development environment. But that environment exists and works because Smalltalk abandoned files and chose to be a runtime system all the time.
In Ruby, you work on files, which compile into classes at runtime. In Smalltalk, you work on live objects which happen to be classes, it's always runtime, there are no files. Java can do all the fancy refactoring stuff because of the extra type information in the code, Smalltalk can do it because it's runtime, and it can simply look at the actual runtime type while you're programming. Ruby is stuck halfway between, and doesn't have enough information to assist in creating nice IDEs in the code, and no runtime image to look at, so I'm not sure it ever will have the refactoring tools like Smalltalk and Java can have. I'm sure someone will figure out how to do simple stuff, but it won't come close to Smalltalk or Java unless it either adopts types, or abandons files.
Not sure if it's already been done, but a blog describing the way Smalltalk works in terms of these images as opposed to other file based languages would definitely be an interesting read - I consider myself fairly well versed in the world of programming, but I wasn't aware that Smalltalk followed such a unique file-less programming paradigm.
Bob...
"1) it's impossible for non-programmers to read and manipulate"
A benefit as we see it, because programmers should be generating the html, and non-programmers should be using CSS to make it pretty.
"2) you bind session data to a physical server, which makes load balancing difficult and you risk losing session data if the server crashes"
Absolutely true, however, it's quite simple to pin a session to one server, every load balancer supports that as an option, as quite a few web frameworks "can" and do use sessions, even if they don't require sessions. And losing the occasional session in the rare event of an actual server crash, is an acceptable risk for the amount of effort sessions save in programming.
Thomas, it's not stupid, it's simply a trade off one makes. Many, myself included, prefer programmatically generated html to templates, we can get much more work done that way, and layout should be done with CSS anyway.
Oops, "but a blog describing" should have been "but a blog POST describing". Stupid typos :)
David, I've done a post on the image before, but maybe I'll do another more detailed one for those who didn't know about Smalltalk and it's image.
That would be awesome Ramon
Nice comparison!
Is there any use of having anyone code html, who is not able to write it using the builder pattern? Would that person be able to cope with xhtml css in a nice way?
One nice thing about the builder pattern is, that it does all the cumbersome escaping for you. I've seen so much invalid html containing unescaped ampersands etc.
The separation of concerns is usually achieved by putting the methods in different categories.
Rails has builders (RXML) that do the same thing but better actually.
xml.instruct! #
xml.comment! "a comment" #
xml.feed "xmlns" => "http://www.w3.org/2005/Atom" do
xml.title "My Atom Feed"
xml.subtitle h(@feed.subtitle), "type" => 'html'
xml.link url_for( :only_path => false,
:controller => 'feed',
:action => 'atom' )
xml.updated @updated.iso8601
xml.author do
xml.name "Jens-Christian Fischer"
xml.email "jcfischer@gmail.com"
end
@entries.each do |entry|
xml.entry do
xml.title entry.title
xml.link "href" => url_for ( :only_path => false,
:controller => 'entries',
:action => 'show',
:id => entry )
xml.id entry.urn
xml.updated entry.updated.iso8601
xml.summary h(entry.summary)
end
end
end
Same thing, certainly, better, hardly.
Rails use of associative arrays to fake Smalltalk style named parameters is hackish at best, yet necessary for setting parameters on tags while using the block for contents of the tag. It's a pattern attempting to cover up a flaw in Ruby, unnamed positional arguments.
Its inability to pass more than one block cleanly also limits the expressiveness possible in any DSL like this. It works, but it's not as nice as the Smalltalk equivalent.
I must admit I'm in the pro-template camp as well. I think the idea that "programmers should be generating the html, and non-programmers should be using CSS to make it pretty", though certainly workable in some cases, has some pretty severe limitations. Consider the steps necessary to convert your nice Andreas-Viklund-themed blog to a Seaside-powered version a la your examples here. The HTML is quite clean, but I'm not sure I'd want to produce (or maintain) the Smalltalk version. If you do it, though, I will read your report on the process with great interest. Actual case studies and deployed sites, even simple ones like blogs, carry a lot more persuasive force than toy examples.
Also: Recipe! Recipes!
If I really liked a theme and wanted to do this, I'd simply pump the XHTML through an XSLT template that transforms XHTML into Smalltalk. Someone already wrote one somewhere, I recall seeing it. It'd be one giant render method, but then I'd use the refactoring browser and extract method until I had it broken down cleanly.
5 years ago, I used to program in PHP. I noticed how difficult it was for me to remember what tag is currently opened and what are the available properties of this tag while I was trying to refactor my code. Then, I discovered XML and used it to generate my pages. No need to remember about what is currently open. Each rendering function returned a node which I added to the current XML tree. At the end, I was sure to have a valid XML page. However, I was still missing the XHTML semantic (does this tag accepts this property ?).
Then I learned Seaside and I really liked it. No need to close tags, this is done by Smalltalk syntax. No need to remember which properties are available, they are just messages to objects.
The only thing I miss is the encapsulation validation : can I put a new paragraph here ?
Paul, http://dabbledb.com and http://www.reservetravel.com/v6 are two public Seaside apps, take a look.
It's not about the programmatic HTML generation!
I wrote a whole post about this, it's here:
http://gilesbowkett.blogspot.com/2007/01/uh-oh-he-went-there.html
But if you don't read it, just understand this much: it's not about the programmatic HTML generation. Seaside only generates HTML programmatically because that approach enables other features, and those other features are very compelling.
About memory use, I think we need numbers. The Ruby processes for my typo installation take 20-40 MB, which is more than a basic Squeak image. Granted, what's important for scalability is how the server behaves with many users, not where it starts from...
Also I don't know about the speed, but I suspect that Squeak is way faster than Ruby, even though its VM doesn't compile to native code like the one of VisualWorks. And since a Smalltalk image is basically just mmap'ed from disk, there is no template parsing, or file including, etc.
then what the hell are the web designers supposed to do? for chrissakes, do we really want all the software/websites that we use to look like the ones we create.
Don't like view templates in Rails? Why not try HAML? http://haml.hamptoncatlin.com/
The thing about "vs. articles" is that there is never a distinct winner. If you love Seaside, get your seaside on. If you love Rails, then use that. These language/framework wars are so pointless that I'm constantly surprised to see intelligent developers drawn into them. (myself included!) Digression aside, HAML is not nearly as clean as your Seaside example but it's pretty close and if you're forced to use Rails (I mean, why else would you even have this complaint?) then perhaps it can help make your day a little brighter when using Rails. :)
Go read Giles blog post from above, he seems to be the only Rails guy here that realizes it's not about the templates. Rails is a great framework, I'm not dissing it, hell, I compliment it quite a bit. However, no framework is above being compared to another, and that's all this is, a side by side comparison of two great web frameworks. The "vs" thing is just a good way to make sure the article gets read, it's not about a framework war. ;)
I'd be perfectly happy to see Rails and Seaside displace .Net, Java, and PHP, but there's always room in the game for a "better" web framework.
John, web designers, should be styling programmatic HTML via CSS, it's as simple as that.
The guys who complain about web designers need to wake up. Are you telling me those web designers are using your templates (which is just HTML with code dumped in)? If so then they are learning programming. How else can they be sure their HTML change will do what they expect if they have no idea what the code does.
Doesn't this also mean they are editing HTML by hand? You may find a web tool that can ignore the templates but I don't think you will find one that picks out the HTML parts from the loops and let's you style that as well.
Come on out of the 90's. Templates have always been the wrong solution. If everyone would stop using templates and using HTML tables for visual layout then maybe browsers would support CSS better (well I mean IE :) and CSS tools would start to get off the ground.
You can look at my seaside site when I put it up. I do everything with styles. If you use Firefox and turn off the styles you get a pure text site with no styling hints at all. Just look at CSS Zen Garden to see what is possible even today. All you have to do is provide div tags for the designers to use.
I hadn't thought of it quite this way before... I agree with Ramon: programmers should handle the HTML, designers should handle the CSS. It's a good way to enforce a separation between structure and presentation. Programmers can generate logical, semantically sound HTML structures (a task that, as programmers, they should be good at), and designers can build their stylesheets on top of them. If everyone involved has some sense, this should create a nice, clean, maintainable, accessible site.
Exactly, you couldn't ask for a better separation of work between designers and programmers. Any designer who still wants to use the HTML for layout, isn't a designer I want to work with. HTML is for semantic markup, not visual layout, designers have no business touching it. Their job is to make our applications look pretty, nothing more. Besides, have you seen the HTML designers tend produce(especially the ones who like drag and drop page builders)... nuff said.
An interesting post. I see severe practical limitations in using code to generate code, especially in teams. Producing HTML from code and insisting that designers use CSS is commendable if one's aim is to enforce rules. In practice, this is the strategic placing of barriers between parties. If you are unfortunate enough to be a designer or programmer who never has cause, reason or permission to venture across the boundary, then you have my sympathies... :)
The task of generating HTML, and styling it with CSS, are separate regardless of who you allow to do it. Templates were never the right answer. The HTML is the model, the CSS is the view, they shouldn't be mixed, so the designer has no reason to even want to mess with HTML, once you agree upon the basic format.
Regardless, the issue isn't templates, it's what you can't do when you use templates, and that's abstract the hard stuff out of web programming. Streaming programmatic HTML through a builder enables abstraction of both HTML and JavaScript/Ajax, and code reuse at a level that isn't possible with the template approach. It also allows you to refactor HTML using the refactoring browser.
It's just like the separation of XML and XSLT. XML comes from the programmer, XSLT from the web guy, or one guy can do both. However, they're still separate tasks and should be treated as such.
Ramon, Giles: Thanks for the responses, they were helpful. Of course like every web app developer and junkie I had played with DabbleDB, but until I re-read the post here (and Giles' post) I hadn't realized that programmatic generation is the only way that Seaside generates HTML.
I do think it would be instructive to see the process for "simply" transforming an XHTML page template into Smalltalk via XSLT, then refactoring down to whatever level of page-component granularity the app requires.
[...] Building an application in an environment where everything is runtime and programmable is amazing. The garbage collection, parts of the VM, the UI, your code, network code, everything. I kind of knew about this. What didn’t really occur to me (until I read the comments in this blog entry) was one side effect of this: No Source files. Wow! No source files. And since everything is runtime all the time, refactoring in Squeak must be great. And debugging, don’t forget about debugging… [...]
Interesting discussions...
In the last several years I created two web frameworks.
The first one was generating HTML from Smalltalk (like Seaside but without continuations). The Web context was serialized in way that the debugging IDE was only one click away. The team was highly productive. We measured a 10x compared to a Java/Oracle group. The drawbacks were that the web applications did not look good and that usability was relegated as an after-thought. The application was driven by the developers and this was showing... We then started to integrate people with graphics talents through naming conventions (not hard to have conventions in docroot/graphics/..). But this was 'lipstick on a pig'. I am not sure that I agree with the statement that CSS will solve your problems.
We then tried to bring in people with more usability background. They have a different skill set than graphic artists. They needed to change our pages layout but also the flow of the whole system. Having the Smalltalk developers controlling the code felt like a bottleneck. Furthermore commercial Smalltalk developers are expensive.
So the second instantiation of our framework was to introduce templates. Now there are templates and templates. Our implementation is to not have a single piece of logic in the framework. Actually there is no code in our templates, besides Javascript for fancy UI artifacts (WYSIWYG editor, menus, etc). Some JSP/PhP implementations are really scaring me when I see the logic implemented in the template. The whole thing relies on six custom tags. IDs are hidden and managed through implicit context. The pro was that we opened up our development to non-Smalltalk talents (graphic artist, javascript, etc). The application started to be much more user friendly. The code became also a little bit cleaner in terms of interface, the Smalltalk part being responsible for providing building blocks for the rest of the team. The drawback we are now seeing is that it is not that trivial to maintain a home grown framework while taking care of the application itself. In particular integrating Ajax or Web services ideas was not initially designed into the Framework. Another issue is that we lost some of the direct debugging capability, but it should possible, it just a problem of granularity (and time).
I like the seaside approach, in particular the IDE integration. But it feels like it is using HTML as an interface definition while using XML (or something less verbose) could be more neutral. And open the architecture to template oriented approach if one chooses too.
Interesting experience you had. A few comments...
"They needed to change our pages layout but also the flow of the whole system"
Seaside excels at this because you build an app from loosely coupled components, and manage the flow of those components separately with "tasks", a special component that has no UI and manages the sequencing of display components in a way only possible with continuation based servers (though I saw a Ruby guy "sort of" fake it well recently).
Templates are a big ball of spaghetti where work flow is spread out over all the pages and pages are very tightly coupled to other pages in the flow.
I doubt the "usability" people could restructure a template based app anywhere near the speed a Smalltalk developer could restructure a Seaside app.
"Furthermore commercial Smalltalk developers are expensive"
Talented people are expensive, and worth every penny, because one or two of them are actually cheaper than a team full of average talent, and can usually outwork them as well. So the money thing isn't really a valid reason to avoid Smalltalk.
"The drawback we are now seeing is that it is not that trivial to maintain a home grown framework while taking care of the application itself."
No, it's not, so unless you have tons of money to blow, don't ever home grow a web framework. There are too many good free and open source ones available to ever consider doing this. You can always modify an existing one to get any special features you need far easier than building one from scratch.
Seaside produces XHTML, which is valid XML, and is easily pluggable to produce "any" kind of rendered output, such as RSS for example. Templates are just not a good solution, they're the Blub solution.
HTML is "a" syntax to produce nestable tags with attributes, it's not the "only" syntax that can do that. Smalltalk's syntax can directly supports the exact same structure.
html div class: 'Title'; style: 'border:1px;';
with:[html paragraph: 'Hello World']
<div class='Title' style='border:1px;'>
<p>Hello World</p>
</div>
Smalltalk's syntax is just as simple as HTML, and very similar to CSS, and can be picked up in a few minutes, and it has far better support for debugging, refactoring, and abstraction than HTML does. There's just no good reason to add templates in light of this. In fact, Seaside had templates in the beginning, they were removed, and IMHO, that was a good decision.
Interesting template experience you had. A few more comments.
"I doubt the "usability" people could restructure a template based app anywhere near the speed a Smalltalk developer could restructure a Seaside app."
Actually they can! Our templates have no business logic (in the 2nd tier sense), only layout and page flow. Changing a flow to one page to another requires only a page name change and save the file. That's all. Quite comparable to changing a Smalltalk method and accepting the change.
"Talented people are expensive, and worth every penny"
I fully agree but that is not the point here. The issue is that there is no real reason to have Smalltalk developers do the same work as classic web developer who are paid for only half the salary. Talented Web developers do exist too ;-)
"So the money thing isn't really a valid reason to avoid Smalltalk."
I did not say that. I have been using Smalltalk for 15 years+. The issue is resource and budget management.
"Seaside produces XHTML, which is valid XML."
But it is still HTML. Ultimately it depends on who you want to be responsible for the HTML generation. I do understand the Seaside approach. I did exactly that in one of my frameworks! But I have been in situations where not all the staff is Smalltalk savvy. Let's say that I want to display a list of books. With Seaside, the Smalltalk developer has to decide on the HTML representation, for example an HTML table. The CSS artist might try to make this table pretty. It is still an HTML table. What if the same information had been returned in XML? You could then decide to use HTML table, or Drop downs, or whatever you want.
"Actually they can!"
Oh, I wasn't aware there were automated refactoring tools available for HTML templates?
"The issue is that there is no real reason to have Smalltalk developers do the same work as classic web developer who are paid for only half the salary."
Sure there is, if they can do it in less then half the time.
As for producing HTML, seaside can just as easily produce XML, the original rendering canvas was implemented by using #doesNotUnderstand: to generate tags on the fly. You can also plug in your own canvas by overriding a factory method, and generate any desired output in any format you like.
As for being Smalltalk savvy, anyone capable of understanding and working with HTML, can learn the equivalent Smalltalk in minutes, it's a trivial syntax change for a huge gain in productivity.
Yes, to reiterate what Ramon said: In seaside, your components are calling methods to render themselves. The only coupling between the seaside component and the rendering is the methods supported by the renderer.
So what that means is, you can write a renderer that produces HTML, XHTML, XML, PDF, plain Text, etc., etc. and nothing else will need to be changed.
Learning more and more about Seaside, it does look like you can change the renderer. That's great. For some report like pages, we have been experimenting with some success with exporting XML and let the UI developer play with XSLT. The only downside is the XSLT language itself. Great but can be confusing.
About the 'huge' productivity gain: while I agree on the Business Logic side (and that's why I use Smalltalk), where is the gain of changing an HTML tag in Smalltalk vs. in a template.
Let's say that I want to change a tag from bold to italic. This is in the Seaside default HTML rendering library. In Seaside, I open the image, find the rendering method, change the code, accept, done. In a template, I find the file, change the html code, save the file, done. In both cases no need to restart the server. Where is the productivity gain?
Thierry: I don't think you would see a any gain for such a simple change. I think we'd have to imagine a change that would be good for the refactoring browser or the rewrite tool. For example, if you changed your approach site wide to shift from tables (for layout) to divs would be an excellent candidate. I used a similar generation framework in Smalltalk years ago and used to refactor the code that generated HTML, XML, etc. with the refactoring tools.
It's amazing to read all the crap that spouts out of peoples mouths when you begin to question their interpretation/view point.
"OMG THATS SO INELLGANT RAILS IS 10 TIMES MORE MANLY THAN YOUR SMALLTALK CRAP"
There was one guy who was so sure that the smalltalk way of rendering was going to cause excess code bloat. My god. I almost stopped reading right there. Code bloat from excess methods? Uhhh, unlike templates you can write REUSABLE methods across your entire application.
I'm really surprised to find people so quick to attack Smalltalk/Seaside when they know very little about it ("Oh I was unaware of its file-less paradigm") or just straight rubbishing because they think Rails/Ruby invented everything (including the universe)
ugh. I'm really hating on Rails people now. The last year has seen a steady decline in the IQs of programmers every where. "Hey you should have a look at Smalltalk, its like ruby, only better" - ofcourse, better is totally subjective.. "WHAT? BETTER? NOTHING IS BETTER THAN RUBY"
Ruby is a cruddy language with cruddy syntax, cruddy performance, and a community of cruddy half-witted people trying to sell it because their first experience of web development (or any development for that matter) was Java+Struts.
Oh BTW Ramon, great site - I'm also a .NET developer who stumbled across Smalltalk after getting sucked up into Becks XP books/Fowlers refactoring/patterns books. Since finding Smalltalk I've found it a struggle to continue my day job (.NET dev) - Maybe one day I'll get lucky enough to do Smalltalk dev fulltime. Until then, I can continue to hate on the rails (barmy) army.
Thanks, appreciate the comments, as for the job, QUIT. Find a job that allows you to work with your preferred technology. It's not worth going mad working in a framework you don't enjoy any more. Find a smaller company that values people more than technology, take a cut in pay even, you'll not regret it.
If Smalltalk doest not use files, can I still use my favorite text editor with it? And, more importantly, how can I integrate it with a source code management system?
In general, no, you don't use text editors with Smalltalk. There have been experiments to allow that to be done, but it's not something I'd recommend. You could not be very productive in your text editor in Smalltalk, the Smalltalk IDE is far superior and aware of the language in a way your text editor could never be.
There are several version control systems for Smalltalk, they are also language aware of the code in a way that file based source code management systems can't be, and have abilities beyond what file based systems allow. Automatic diffing and merging at the method level for instance, rather than file level.
If you want to do Smalltalk, you have to drink the cool-aid, and live in Smalltalk completely. If you want a file based Smalltalk, use Ruby.
Ramon Leon: Thanks for this informations. Version control (and actually not source code management in this case) based on the "logic" of the code rather than lines of source code sounds interesting. Having to give up my text editor sounds way less pleasant, but I guess the coding paradigm is so different that it justifies it. I hope I'll find time and motivation to give Smalltalk a try.
Sean M: See? All rails coders are not that close-minded :)
Text editors are for editing files, not running instances of objects. Smalltalk is a system of living objects where it's always runtime. The code browser doesn't browse files, it browses running classes and objects. So yea, you have to give up the text editor, but I know of no one who groks a Smalltalk browser, and wants to go back to a text editor.
As always - a great article Ramon. To all non-Smalltalkers - beware that once you get into Smalltalk it gets very hard to go back. To Alex - there are also a few packages for Squeak (other Smalltalks may have similar stuff) making the text areas in Squeak grok vi-bindings and/or emacs too I think.
But as Ramon says - Smalltalk is a "place" where objects live - it is not your average "IDE". You almost never edit texts longer than can fit on the screen in a browser so most normal text editor features are much less needed. The environment then offers a plethora of different browsers and cross-referencing mechanisms to navigate code - and many Smalltalkers tend to write more and more code in the debugger "on the fly".
Btw, here is a thought provoking and funny post about the difference of Smalltalk and regular languages/IDEs: http://wiki.squeak.org/squeak/2950
regards, Göran]
Thanks, and that email was a great read as well. The cult of the dead, I like that.
I just thought I'd drop in a line on this relatively heated and righteous discussion about template systems.
Frankly, something which I have been dilligent with for an awful long time in web development is the correct definition of 'corrent'.
XML will have you believe that correctness with regard to (X)HTML implementation comes from proper form. Factors such as ordering and presentational tags are -supposedly- removed.
Back in reality though, the fact is, that ordering of HTML tags is of deep importance for correct compatibility. Here however, I am defining correct by looking at a specification of 'what works in most places', rather than being correct to a standard only recently introduced.
Moreover, hacking into code, support for presentational bugs such as div content padding ( 's or empty divs/spans), simply don't belong in program code. It is utterly impossible to build a truely world class web application without this kind of fix, if your designer insists on certain designs.
You can play political games all you want regarding whether or not such a fix should be required, however, the fact is, these kinds of quirks are everywhere, and are Design issues, not server programming issues.
If you really want such an argument to stand up, it's time to deliver a truly capable web browser, without parser bugs, or incorrect implementations of w3 standards. Of course, that wouldn't render most pages on the internet though...
The lesson is, you can be as righteous as you want, but in the end, the real world will slam you for it: When your CSS designer comes to you and says "can you just put an nbsp there for me".
P.S. WAP sites anyone? :-P, Happy Flaming, this is just an opinion.
The designers job is to style the markup as best he can. That's it, as best he can, not to perfection. Flexible skinnable css designs are worth more than pixel perfect and inflexible designs that rely on html hacks for layout. As far as I'm concerned, that is the real world. I just won't work with anyone who thinks otherwise, it's not worth the hassle.
How do you make, say, a flowing three row site with a fixed header and footer, without excess line height padding in Firefox 2?
Or do you say this is bad design and we shouldn't do it?
I say the mistaking is coming up with a design first, and then trying to make CSS do it. This happens when people mock up designs in Photoshop first. The mistake is in wanting perfection. CSS places some constraints on what you can do, you must learn to live within those constraints by designing from within them.
Take raw HTML and style it up, one change at a time, until you end up with something decent. You shouldn't already have a mock up of the final look designed from some tool like Photoshop that doesn't have those same constraints. You'll only set yourself up for failure by striving to achieve something that isn't possible.
HTML should remain as semantic markup, period, with the exception of maybe some extra empty divs tossed in somewhere for the designer. CSS Zen Garden is a good example of CSS done right. The designers were not allowed to tweak the HTML to suit them, rather, they had to work with it as is, and come up with the best designs possible within those constraints. This is what makes a site skinnable, not compromising the HTML to suit any one particular layout.
Skinnability IMHO is far more valuable than pixel perfection on one particular design. The CSS should and may change constantly, where the HTML should pretty much remain static and unchanging. HTML is for programmers, CSS is for designers, this is as it should be. If you can't get "exactly" the look you want, live with it, your users don't care as much as you might think.
Very useful! Both of them are great and very modern frameworks.
Ramon, do you have the complete Seaside recipe example that's posted above?
Thanks in advance.
There is only what's posted above, I wrote it just for the article, I didn't actually create a Seaside project or anything.
I'll attempt to create a project from the snippet above to formulate a screencast.
-Conrad
Let me know if you do, I'll certainly link to it.
[...] came across an interesting post about SmallTalk’s Seaside versus Ruby’s [...]
[...] IDE, the ‘doit’ concept and Seaside, a Smalltalk web framework which I discovered from this post onsmalltalk.com which is an interesting read. Seaside itself is quite interesting. Anyway, to get a [...]
[...] read more | digg story [...]
I know I'm late to this discussion, but...
I'm a huge Rails advocate. And I've spent the past year fighting -- successfully -- for its adoption at the Java/J2EE shop I work.
But all the defensive, close-minded, and generally hostile responses from many of the Rails folks here is really disappointing and embarrassing.
If there's one framework us Rails fan boys should be paying attention too, it's Seaside. It's profoundly different enough from the request-response/MVC world the web development world has been stuck in for too long now to 1) actually be a "threat" to Rails; and 2) actually be worth the time studying.
At the least, if I'm looking for a competitive advantage, I don't really get that from Rails anymore. I mean, if everybody is using it now, than we get any secret sauce from using RoR.
The only reason I myself haven't jumped into Seaside and Smalltalk too deep yet is I'm scared of getting hooked. ;-)
Don't be scared, it's fun being different. And using Seaside doesn't mean not using Rails, they are suited for slightly different tasks and could compliment each other well, even being mixed in the same site. You'll have much better luck with Rails in a J2EE shop, Smalltalk, especially Squeak, is a harder sell, it's just weird.
At home, or on the side, use Seaside, you'll like it, a lot, you'll wonder why you ever wasted so much time naming fields, manually passing parameters between pages, worrying about urls, not having real components, futzing with templates and not being able to do complex multistep workflow without just like any other code, in a single procedure of normal code.
If you really dig Rails so much, you might even be crazy enough to use Rails as a RESTful application model using the new ActiveResources and ActiveRecord and write yourself a Smalltalk ActiveResource client so you can use Seaside for the front end. Do what's fun, that's always a good approach!
My problem with seaside and Smalltalk VM is the fact that you always need to manipulate this "full VM image". I have used ST in the past when studying and I'm very interested by Seaside but if rails or php framework are widely used is too because you have some choices about how you will serve page (mongrel, apache, cgi, ...). In smalltalk, if you have a Squeak VM for example, it will need Squeak... How can we change VM in ST ? If my VM run on a server can I access the GUI remotly ? How can I develop my application locally and then put it on the server ? Replacing the image ?
For the HTML generation discussion, I fully agree with the fact that programmers do HTML and designer CSS. But in my life I need to live everyday with designers that do HTML and hacks and CSS based on photoshop designed sites...
But, I want do add to the discussion that for me the web has 2 concepts: web sites and web applications. The first one, need to be indexed, urls can be shared and perform very well. The second one can be programmed like an application and with frameworks that do things like continuation. A (web)site is generally a mix of the 2.
Smalltalks are image based languages, it's a feature, not a failing. You can't use Rails without using a Ruby VM just like you can't use Seaside without using a Smalltalk VM, there's no difference.
Rails doesn't run in Apache, it requires something like Mongrel, same with Seaside needing something like Commanche, a native web server that Apache can proxy to. Yes you can connect to a remote image or you can just replace the image and restart the service, it's no different in Rails, it's just a file. If you could serialize a running Mongrel instance and start it up later, you'd have a Ruby image, that's all a Squeak image is.
Web sites and web apps are different, and there's nothing preventing you from using PHP for the web site part and Seaside for the web app part, if you like.
What a neat blog - thanks. Its sort of deja-vu reading the discussion. I made quite a bit of money in the 80's introducing Smalltalk to big corporations, and I think I heard every argument against it you could imagine. In the end though, Smalltalk always "won". Then I spent many years with Java, all the time missing ST. Lately I've been playing with ROR and Ruby felt a lot like ST. I didn't realize that there was still anything going on with my second true love (C was the first) until now.
So Damn, I guess I have to download Squeak.
Ramon, thanks for all the time and thought you have put into this.
You're welcome.
[...] and then style it using CSS. Not too designer friendly, but they do give an explanation about why it is this way.. How delightfully sadistic! And yet, strangely [...]
I have a couple of comments on this thread.
About building first and designing later-- I don't know of any companies that do this. Conventionally, the design passes through numerous iterations, sometimes 20 or 30, before it is signed off. Even agile development, which allows for quicker iterations and changing designs mid-stream, still has a design to work from and 'sign off' gates (user acceptance testing, etc). Maybe you'd make a quick HTML or Flash prototype with limited design direction, but I can't imagine building a site incrementally and "winging" the design.
Also, it is completely realistic to get pixel-perfect precision from your Photoshop design to a webpage. And you can do so with a minimum of added mark-up, though you will certainly need special case scenarios to be accounted for from time to time. For instance, you may need the "last" class added to the final element in a list, or you may need "clear fix" elements to cause parent containers to expand. This is just a fact of life, but the good web developer will keep hacks like this to the minimum and will clearly comment each hack explaining why it's needed.
As for who should own the HTML, I firmly believe that the front-end developer should own the HTML, JavaScript and CSS code and and any code which generates it. In that case, the front-end developer would also have to use Smalltalk/Seaside and be comfortable editing its HTML generating methods.
I've done the front end code for sites built with PHP, Java/JSP, Perl/Mason, and a couple of personal projects in RoR. In some cases, a back-end developer will build a functional 'shell' first and then I'll edit it to meet the needs of the design. But in all cases, I've had access to whatever HTML-producing code there is, be it PHP, JSP, Perl or what-have-you. There has never been a case where a back-end developer just 'nails' the HTML output perfectly, at least for me. Plus you will oftentimes want to change the HTML code for other reasons, such as SEO (changing the order of elements and what tags you use).
I've never tried Seaside but from looking at the examples in this post, it seems very easy to pick up, at least the HTML generation methods. So, I see no real problem in having a Seaside developer make a functional site and then give access to the HTML generation methods to the front end developer (who works with the designer to do all visual layout and JS functionality of the site, and may wear other hats that require modifying the front end code as well, such as security, SEO and accessibility).
So, to re-cap, I don't think I would choose Seaside for a new project because of the learning curve, but if someone brought me on board as the front end developer for a Seaside project, I'd have no problem using the HTML generation methods. And I may re-think this later if I find significant shortcomings in other frameworks that Seaside solves.
Though I don't agree with you, I appreciate your point of view. Seaside makes it clear, HTML belongs to a programmer, though once done, a careful designer could easily modify render methods if he's careful. The problem is and always has been, designers tend to mess up code and programmers can't stand the mess, repetition, and lack of abstraction in HTML templates.
Seaside is aimed squarely at programmers who think templates are just a bad idea, designer be damed. To work effectively, the programmer and designer need a good relationship and they need to settle on an HTML style that both are happy with because most programmers, myself included, won't let the designer anywhere near the Seaside code. I make all HTML changes and when possible force the designer to solve his issues with CSS only.
By the way, when I say designer, I explicitly mean someone who doesn't know how to write code. For a designer who has some basic front end coding ability, they should have no problem working in Seaside render methods, it's quite easy.
Personally, I think those view methods are as ugly as hell. Difficult to read, difficult to maintain and having them all in the same file means that your files get EXTREMELY bloated EXTREMELY quickly. Personally, I like having them in different areas to mentally enforce the concept of MVC.
It's interesting to note that there is an implementation of this style of "Language as a markup" for Ruby on Rails, which is Markaby: http://redhanded.hobix.com/inspect/markabyForRails.html
It's not garnered much of a following though, as in my opinion, it doesn't make much sense - you're defining one dialect (HTML) in another (Smalltalk/Ruby) which I feel is an uncecessary level of abstratction. It doesn't preclude the author from having to understand HTML, and doesn't really offer much in the way of readability.
Each to their own though - it's not for me, as I don't believe it offers any great advantage, but if it's what works for you, that's great :)