So, let me cover three different things here: my attitude on Smalltalk the language; my thoughts on Seaside; and what would push you further into the Smalltalk

So, let me cover three different things here: my attitude on Smalltalk the language; my thoughts on Seaside; and what would push you further into the Smalltalk camp. Last one first. Smalltalk shines when you go native and really buy the idea that the Smalltalk IDE is going to be your one-stop shop for everything. I personally find that this happens naturally when I'm doing really rapid prototyping. Nowadays, I'm a fairly passionate strong typing proponent in general, and I generally find myself happier languages like Rust, TypeScript, F#, and Kotlin than in languages like Python, Ruby, Io, or JavaScript. But when I'm not entirely sure what I'm doing yet, when I'm exploring a space or trying to figure out how something ought to work, then I find that the power of Smalltalk's introspection, and the flexibility afforded by the browser, debugger, rewriting tool, and metaobejct protocol (similar to but different from Common Lisp's) more than make up for the loss of safety. So if you were going to play with it in order to get hooked, I'd suggest doing it in an area where you're not quite sure what you're doing yet. Maybe Cryptopals or something where you're out of your element. That all said, the strength of the tooling results in some odd patterns in Smalltalk that I am increasingly thinking are bad decisions. For example, there are no case or match statements. Instead, you're expected to make all the objects that you would be switching on all implement some method (maybe e.g. #handle:), and then you unconditionally call that method and rely on the object's differing behavior to cover the match statement. But that means that you're suddenly unclear who all can actually be affected by a given line of code. The tooling helps, but it's annoying. The language also shows its age in some other ways. There's not a real concept of immutability, for example, and the only real literals are numbers, strings, and arrays. (Pharo kind of skirts this issue by having an #asDictionary method on their runtime arrays that converts an association list to a hash table, but it's quite ugly for nested structures.) The threading story is green threads only. With all variables being private and no macros, there's a fair amount of boilerplate that shows up (although, like a modern Java IDE, Pharo's IDE can write the setters and getters for you) (I'll also confess to not being sure how the new slots system impacts this, so this may no longer be an issue.) In the real world, for production code, I don't think these have to all be issues, but they keep Smalltalk from being my general go-to language. That leaves your question about Seaside. I love prototyping in Seaside (see above) because it lets me basically ignore JavaScript and still code a fully stateful website, but I don't personally actually like designing server-local stateful web services these days. I'd personally probably use Teapot (a Sinatra/Flask/Dropwizard-like REST server) and a straight single-page JavaScript app (or maybe Amber, if I wanted to use Smalltalk all the way down) instead. I think Seaside was an absolutely amazing idea when it came out, and I have a very high opinion of its quality, but I don't honestly think it's a great way to design services these days.