Is this the WikiWikiTalkPage?

DabbleDb inspired me to review SeasideFramework once again. Like anyone who gives it more than a glance, I like it a lot - it would be a RubyOnRails killer if it could scale.

But continuations are too memory-expensive to put in the server.

Which got me to thinking, why not put 'em in the client? You'd need a good language there though ... and if SeasideFramework is your aim how about AjaxSmalltalk? Smalltalk interpreters are tiny, right? Writing one in JavaScript, you've already got most of the basics taken care of. There's already JsLisp and JsScheme as examples of adaptation idioms. SpoonSmalltalk is probably overkill. Then:

* You'd want to bridge AjaxSmalltalk to the DocumentObjectModel and the JS APIs so you could leverage all the ScriptAculous goodness modern AjaxWebApplications do.
* Smalltalk objects would only run in the client-side interpreter.
* You'd XmlHttpRequest to pull clean ST objects from your server and push dirty ones back again.
* This would provide the ability to move the SeasideFramework semantics directly into the client, where they can scale however you like.
* Never write another line of anything but Smalltalk so long as you live.

I have resisted learning Smalltalk properly for years. But RubyLanguage has seduced me and this seems to be a readily realizable step toward a real SymphonicArchitecture. My first question is, why hasn't some bright young smalltalker already done this? Given the enablement of WebThreePointZero, I guess my next question is, who wants to help out? -- PeterMerel

If the control is in the client, do you even *need* continuations.  You're back to the good old rich client, stateless server  architecture that we all learned during the early 90s.

''Yes. For ControlFlow, WorkFlow and for versioning maybe. Some of these can be done with good old LexicalClosure''''''s. But as for the impact of WpFe, yes, EverythingOldIsNewAgain.''

----

Ah, Pete, always behind the times, will you never catch up? VistaSmalltalk is already doing all this ... but without the javascript. See, the way of the future (this week ...) is XaMl. You're not going to have a really rich user experience with that old JS/CSS crap, are you?

''Now Pete, simmer down, I'm doing my best to catch up. It's not easy living in the WikiNow you know ...''

----
CategoryWebThreePointZero