Quality Open Source: Squeak 3.9 final and new Seaside 2.8
I don't use Smalltalk professionally but I wanted to try the new Seaside 2.8 release. I did a fresh Squeak 3.9 final installation on my MacBook running Leopard. Installing Seaside was as simple as starting the SqueakMap package loader, doing an upgrade to all installed packages, then do a Seaside install answering yes to all optional package offerings. Everything 'just works' and has a very polished feel to it - important when I am giving up an evening or two to play with something very cool.
One very important aspect of this "feeling of quality" is an active community that maintains a central package web site - good examples are SqueakMap (Squeak), Gems (Ruby), and CPAN (yuck, Perl :-) Having a central package repository is more than just a time saver: time spent dealing with too many installation and configuration options disrupts what I would call problem solving mode or thinking. I used to take great pleasure in staying on top of most J2EE technologies, but I got over that :-)
The way that Seaside gets around stateless HTTP issues is very cool but I suspect that the future of rich client applications may be something like Adobe AIR. For my work, I am happy enough for now just using Rails and AJAX. I have also experimented a lot with Dojo and Lisp on the back end and a little with OpenLazlo. The question to ask is how much "rich client" support do you need for a web portal - applications like GMail show how much can be done with Javascript/HTML/CSS.
One very important aspect of this "feeling of quality" is an active community that maintains a central package web site - good examples are SqueakMap (Squeak), Gems (Ruby), and CPAN (yuck, Perl :-) Having a central package repository is more than just a time saver: time spent dealing with too many installation and configuration options disrupts what I would call problem solving mode or thinking. I used to take great pleasure in staying on top of most J2EE technologies, but I got over that :-)
The way that Seaside gets around stateless HTTP issues is very cool but I suspect that the future of rich client applications may be something like Adobe AIR. For my work, I am happy enough for now just using Rails and AJAX. I have also experimented a lot with Dojo and Lisp on the back end and a little with OpenLazlo. The question to ask is how much "rich client" support do you need for a web portal - applications like GMail show how much can be done with Javascript/HTML/CSS.
Comments
Post a Comment