So Damn, I guess I have to download Squeak.

Ramon, thanks for all the time and thought you have put into this.

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.

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.

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!

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. ;-)

-Conrad

Thanks in advance.

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.

Or do you say this is bad design and we shouldn’t do it?

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 (&nbsp’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.

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

Sean M: See? All rails coders are not that close-minded :)

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.

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

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?

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.

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.