Did you try different browsers? The speed is very reasonable for me (considering the amount of BitBlt). I use SqueakJS to develop business software (using only Smalltalk). In these applications I am running SqueakJS headless and create a GUI using WebComponents (created through Smalltalk classes). This also runs very fast (tested on Firefox, Chrome and Safari).
Instead of having a Smalltalk image which contains the typical GUI (Morphic or otherwise being BitBlt on a HTML Canvas) I run a Smalltalk image which has a number of Classes representing WebComponents. These classes have a small interface with Javascript (implemented as primitive calls in case you are familiar, similar to other SqueakJS plugins). When instantiating such a WebComponent, it will also instantiate a DOM element (the WebComponent). Events in the browser are wrapped in Smalltalk event classes and will be given to an event handler process (Smalltalk process) which will do the relevant work. So for example drag and drop is implemented fully in Smalltalk. The Smalltalk image I run to have this Web UI (and run only a Web UI, no business logic in the browser) is very small. It is only a little over 200Kb.
My code is free to use. See https://github.com/ErikOnBike/CodeParadise
I need to add some more documentation and more demos. I have been very busy with developing software and have been lacking a bit in giving some love to those.
Edit: An explanation and demo can be found here: https://vimeo.com/457353130
Interesting. At 54:55 Tim Rowledge mentions Distributed Smalltalk by Chris Mala (not sure about the name). Is there any information about this? I could not find anything what seemed relevant or recent.
It's very slow for the initial revision, as it has to compile all its dependencies. From there, if you add in full async/await support with a web server framework, you're looking at ~6sec iteration time. If you bring in LLVM's LLD instead of GNU or MSVC, you can bring that down to ~3-4sec. They're working on adding support for their own LLVM competitor, Cranelift, that should further reduce those times. It's only intended for debug/development builds, though, so you'll still need longer compile times for release.
While the compile times are a bit slower, one of the advantages of the strict type system is you don't need to compile to an executable quite as often.
Most of the time your IDE's messages (or "cargo check" output) is sufficient to find all the things the compiler will complain about.
I usually find that once I've fixed all of those, I compile it once and it just works.
