Smalljs: Smalltalk-80 That Compiles to Javascript
Posted4 months agoActive4 months ago
small-js.orgTechstory
supportivepositive
Debate
20/100
SmalltalkJavascriptProgramming Languages
Key topics
Smalltalk
Javascript
Programming Languages
SmallJS is a Smalltalk-80 implementation that compiles to JavaScript, sparking interest and discussion among HN users about its features and potential applications.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
23h
Peak period
33
Day 2
Avg / period
7.8
Comment distribution47 data points
Loading chart...
Based on 47 loaded comments
Key moments
- 01Story posted
Aug 24, 2025 at 5:29 AM EDT
4 months ago
Step 01 - 02First comment
Aug 25, 2025 at 4:07 AM EDT
23h after posting
Step 02 - 03Peak activity
33 comments in Day 2
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 5, 2025 at 3:49 AM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45002776Type: storyLast synced: 11/20/2025, 4:35:27 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Why the Romanian flag?
From https://lists.squeakfoundation.org/pipermail/squeak-dev/1998...
https://tashian.com/articles/dynamicland/byte-magazine-augus...
If I want to build a wooden chair, I don't want to start by learning to use a steel metal punch to create a panel saw first...
In Pharo your entire project along with its runtime, code, data and IDE is one long lived intertwined and dispersed state. I was never really sure if this is necessarily a problem or not.
But today I had an interesting idea. Pharo is Factorio of programming. You are evolving living, functioning system using itself. And we know most of Factorio games end up as ad-hoc tangled mess, where new things are added rather on the side than old things being properly refactored. So if your Factorio factories are always pristine examples of order you should be fine with Pharo. If not, you might be better off with something like PHP or Fermyon Spin which have app state living no longer than a single request-response. With long lived state neatly and separately held in the database and source files.
Richard Gabriel made some statement to that effect in his 50 languages talk, the debate between Lisp and Smalltalk being “is code state or is state code?”, both circling the same drain.
How is a docker container not a modern realization, in part, of what both camps were yammering on about years ago?
For metaprogramming, I think the ideas make a lot of sense. For bizapps in the 'real world', where the rubber meets the road, I think a division of data and action make a lot of sense. For example, on my last three or four business apps I started with data models (all of the persistent state) and walked backwards into the application.
I think -- I might be wrong -- in Scheme they have 'lambda uplift' or something like that to denote various levels of meta-programming "applied", IE, some level of abstraction is "applied" or "compiled" and the code is expanded.
Lambda lifting is more of a compiler design technique.
Docker is neither smalltalk vm nor lisp. It's unholy pragmatic thing, when you have ton of state but you want to cram it all in a bucket so it doesn't crawl out.
There's some overlap for sure, but I don't think one subsumes the other.
Though it's quite easy to make your application appear similar to a Factorio screen, since libraries like Roassal and Mondrian make it like a five to ten minute thing to create a custom visualisation of the involved packages. Static analysis tooling in other languages is usually not as malleable and easy to customise.
Where the image-based system does cause trouble is when you need to interact with stuff outside of SmallTalk. It basically doesn't play very well with others (in particular stateful stuff like database connections which can't straightforwardly be persisted when the image is saved and closed). But overall, I found developing in SmallTalk to be extremely productive, even in the antiquated implementation we were working with.
If we don't use a repeatable process that can be a problem.
So treat the long lived state as cache and check that does re-build from the versioned source code archive.
It's rather neat, and means you can extend your development environment in the same way you develop your applications. If you want to extend the inspector for a particular type of object you can do that. Compared to writing plugins for Eclipse or IntelliJ it's a trivial exercise.
GT does it too, though explicitly aimed at tool development rather than application development: https://gtoolkit.com/
In a sense it's the original vibe coding environment.
Nowadays that experience is only visible in LispWorks and Allegro Common Lisp.
[0] - https://interlisp.org/
Are there good tools that I'm overlooking for exploring the current image state? Smalltalk has that built-in but in CL I'm regularly loading my system into a fresh SBCL at least every couple days just because, at some point, some state is not what I expect it to be and I have no idea how to reconcile it.
Still, working with images in SBCL is a good technique. Command line utilities built as separate image files load very quickly, and then you get to write utilities in Lisp rather than bash or Python.
This project is nice, however if we don't have a specific, client-side IDE for interactive development, 70% of the power of Smalltalk is gone (one of the criticisms I give to Ruby)
How would one do to push changes to the web frontend (browser) without stopping the program ?
i would like the smalltalk code be loaded from files into the browser and interpreted/compiled there, without writing the resulting js back, but just running it in the browser.