Not much of a comparison, but JTalk aims for code compatibility with Pharo Smalltalk, whereas Clamato is a distinct dialect. Perhaps partly because of this, I f

Not much of a comparison, but JTalk aims for code compatibility with Pharo Smalltalk, whereas Clamato is a distinct dialect. Perhaps partly because of this, I felt able to work with immediately in a way I never did with Clamato, or any other in-browser Smalltalk-like software I've seen. My past experience with Smalltalk transfers well into JTalk, not so well into Clamato. When I first ran JTalk (months back), one of the expressions I tried was to get the sum of even numbers between 1 and 5, and it doesn't work, because JTalk is missing various things, like 'even' and 'odd'. I had a Pharo Smalltalk system to hand, and was able to look up the implementation for 'even', and deeper requirements like '//' (divide without remainder), and type them into the browser until I got the answer. Since then, JTalk now has the very beginnings of exception handling. When Smalltalk is asked to evaluate a non-existent method, it raises a MessageNotUnderstood (MNU) exception. It's interesting to think about the idea of having a web service running on Pharo, which answer chunks of it's own source code, and JTalk's MNU behaviour being to send out an http request to try to load that source code, and then continue running. (I don't know nearly enough about Javascript or JTalk internals - this may be wildly impractical.) In any case, the idea of code compatibility between front-end and back-end is very appealing: re-use domain model classes, write input validation in one place and have it run in both places, and such. (I seem to have gone off on a tangent. Hopefully an interesting one.)