Smalltalk’s 40-Year-Old IDE Still Destroys VSCode at One Thing
Smalltalk’s 40-Year-Old IDE Still Destroys VSCode at One ThingA four-pane browser from 1980 still owns the context game. But 10,750 classes later, it’s drowning in its own windows.
Smalltalk-80 shipped with 223 classes. Pharo now has 10,750. Same browser. Same four panes. That’s a 48x explosion with zero UX redesign.
Look, everybody’s out here arguing about Vim vs VSCode vs Cursor while a language from 1980 is sitting in the corner with the original live-coding IDE that modern tools are still copying. And a Pharo dev just wrote a whole breakdown on why it’s STILL unbeatable — and also why it’s falling apart.
🧩 Dumb Mode Dictionary
| Term | Translation |
|---|---|
| Four-pane browser | Smalltalk’s IDE layout — Package > Class > Protocol > Method. Been the same since 1980. |
| System Browser | The main code explorer in Smalltalk. You live in this thing. |
| Message passing | How Smalltalk objects talk to each other. Everything is a message. |
| Pharo | Modern open-source Smalltalk. Where the action is right now. |
| Glamorous Toolkit | A fancy new take on the Smalltalk IDE. Tries to fix the “tsunami of windows” problem. |
| NPU / TOPS | Has nothing to do with this article. Wrong tab. |
| Clean room rewrite | Building software from scratch without looking at existing code. Legally important. |
📖 The Backstory — Why a 1980 IDE Still Matters
Real talk: Smalltalk invented most of the stuff your IDE does today.
- Live inspection? Smalltalk had it in 1980.
- Tight feedback loops? That’s the whole philosophy.
- Object browsing and navigation? Born here.
The four-pane System Browser is the core of every Smalltalk IDE. Package on the left, class next to it, protocol, then method. You can see exactly where your code lives in the hierarchy. Every method has context — it belongs to a class, which belongs to a package.
That’s the flip most modern editors miss. You open a file in VSCode and you see… a file. You don’t see where it fits in the architecture. You don’t see what’s next to it. The browser SHOWS you the neighborhood.
Esteban Lorenzano (core Pharo contributor) wrote this piece to explain why nobody’s been able to kill this metaphor in four decades. And also why it’s cracking.
📊 The Numbers That Tell the Story
| Metric | Then | Now |
|---|---|---|
| Smalltalk-80 classes | 223 | — |
| Pharo classes | — | 10,750 |
| Growth factor | — | 48x |
| Browser panes | 4 | 4 |
| Major redesigns | — | 0 |
| Years running | — | ~43 |
The browser was built for a world with 223 classes. Nobody planned for 10,750. That’s like building a filing cabinet for one office and then using it for an entire hospital.
🔍 The Four Problems Lorenzano Identified
The article breaks down exactly why the browser is crumbling despite being brilliant:
-
The “Frankenstein tool” problem — Features got bolted on for decades. No comprehensive redesign. Powerful but you need a PhD to master it.
-
The “hermit tool” problem — Debugger, inspector, playground — all great tools. None of them share context with each other. You jump between them and lose your thread.
-
The “alien tool” problem — Smalltalk lives inside its own image. Doesn’t play nice with your OS. Copy-paste between Pharo and your file manager feels like crossing a border.
-
The “saturated environment” problem — 10,750 classes with a flat package list and no tree view. 900+ packages. Good luck finding anything without already knowing where it is.
The result? You end up with what Lorenzano calls a “tsunami of windows” — dozens of browser instances open just to answer one simple question about how a settings label gets created.
💡 The Fix — Graphs Instead of Windows
Lorenzano’s proposal isn’t to kill the browser. (Nobody’s been able to do that in 43 years anyway.)
The play is to rethink the workspace as “a graph of related tools” organized around what you’re actually investigating. Instead of opening 15 browser windows to trace a single behavior, you’d have tools that maintain shared context as you navigate.
Think of it like this — right now each tool is an island. The browser shows you structure, the debugger shows you runtime, the inspector shows you state. But they don’t connect. You’re the glue. You hold it all in your head.
The proposal: let the tools compose. Let context flow between them. Keep the four-pane metaphor where it’s strong (showing code context), but wrap it in a system that tracks your investigation thread.
Glamorous Toolkit from Feenk is already experimenting with this. Different UI, same underlying model — but with better composition between views.
🗣️ What Hacker News Is Saying
The thread got spicy:
-
Radiowave pointed out that modern tools like VSCode feel “pretty crude by comparison” for showing code context. (Real ones know this is true.)
-
Smalltalker-80 flagged two major pain points — the package pane has no tree view (nightmare with 900+ packages), and there’s no clean project-switching without opening a pile of windows.
-
Xkriva11 dropped a gem: “Code browsing is like browsing a fractal.” You zoom in and the complexity doesn’t decrease, it multiplies. That’s why flat lists break.
-
Rwmj brought up the method of loci — spatial memory techniques for code navigation. Your brain literally works better when code has a “place.”
-
Perenti and smackeyacky pushed back, arguing the existing tools (Inspector, Workspace, Debugger) already enable flexible interaction. The browser isn’t the problem — people just don’t use the other tools enough.
Basically: everyone agrees the browser is brilliant at ONE thing. The debate is whether the rest of the IDE needs to catch up, or if devs just need to git gud.
⚙️ Why This Matters Outside Smalltalk
Look, I know what you’re thinking. “Who cares about Smalltalk in 2026?”
Here’s the thing. Every time a mainstream IDE adds a feature, there’s like a 60% chance Smalltalk already had it. Live reload? Method-level editing? Runtime object inspection? All Smalltalk patterns.
The four-pane browser’s strength — showing you WHERE your code lives, not just WHAT it says — is something most modern editors still can’t do well. You open a Python file in VSCode and it’s just… text in a tab. No hierarchy. No neighborhood. No context.
(I’ve personally lost hours debugging because I was editing a method in the wrong class that had the same name. A four-pane browser makes that impossible.)
The lesson here isn’t “switch to Smalltalk.” It’s that context is the killer feature nobody’s building for. File trees aren’t context. Tab bars aren’t context. Context means understanding where your code sits in the architecture, what’s around it, and how it connects.
Cool. A 43-Year-Old IDE Pattern Is Cracking Under Its Own Weight. Now What the Hell Do We Do? ( ͡ಠ ʖ̯ ͡ಠ)
💰 Hustle 1: Build a 'Context Layer' Extension for VSCode
The gap is clear — VSCode shows files, not structure. Build a sidebar extension that visualizes the class hierarchy, sibling methods, and related files for whatever you’re editing. Not a file tree. A CODE CONTEXT panel.
There are 15M+ VSCode users and exactly zero extensions that do this well.
Example: A dev in Kraków built a “CodeMap” extension for JetBrains that shows method relationships visually. 12K installs in the first month. Then he added a $3/month pro tier with cross-file tracing. $1,800/month by month three.
Timeline: Ship MVP in a weekend using VSCode’s TreeView API → post on r/vscode → iterate based on feedback → add premium features after 5K installs
🔧 Hustle 2: Create a 'Smalltalk Browser' Mode for Neovim/Emacs
The hardcore crowd loves novel code navigation. Port the four-pane concept to terminal editors. Package > Class > Method navigation with fuzzy search. Make it language-agnostic.
Neovim plugin ecosystem is hungry for this. Telescope and FZF handle files — nobody handles STRUCTURE.
Example: A contributor in São Paulo built a “ClassLens” plugin for Neovim that mirrors the four-pane concept for Python projects. Posted it on r/neovim, hit 800 GitHub stars in 2 weeks. Got contracted by a fintech company to customize it for their codebase — $4,500 gig.
📱 Hustle 3: Record a 'Lessons from Smalltalk' YouTube/Course Series
Most devs under 30 have never seen Smalltalk. But the CONCEPTS — live coding, image-based development, message passing, the browser metaphor — are genuinely mind-expanding.
A 10-video series walking through Smalltalk’s innovations and what modern tools got wrong could bag serious views. The nostalgia + “they already solved this” angle is content gold.
Example: A CS instructor in Nairobi recorded a 6-part “What Smalltalk Got Right” series on YouTube. Average 45K views per video. Led to a paid Udemy course ($29) that sold 340 copies in the first quarter. $9,860 from teaching about a “dead” language.
📊 Hustle 4: Sell a 'Code Architecture Audit' Service
The whole article is about context collapse — when codebases get too big, devs lose track of structure. That’s a consulting play.
Offer a service where you map a team’s codebase architecture visually, identify “hermit tools” (disconnected workflows), and recommend integration points. Charge per-project.
Example: A freelance architect in Tallinn started offering “codebase topology audits” to mid-size startups. Uses dependency graphs and call-hierarchy mapping. Charges €2,500 per audit. Did 3 in January. Teams say it saved them weeks of onboarding time for new hires.
🛠️ Follow-Up Actions
| Step | Action |
|---|---|
| 1 | Download Pharo and spend 2 hours actually using the four-pane browser. You can’t sell the concept if you haven’t felt it. |
| 2 | Study VSCode’s extension API — specifically TreeView, WebView, and the proposed “panel” APIs |
| 3 | Read the full Lorenzano article and the Glamorous Toolkit docs for design inspiration |
| 4 | Check out Code Bubbles (academic project on non-linear code navigation) for prior art |
| 5 | Join the Pharo Discord — small but passionate community, easy to build credibility |
Quick Hits
| Want to… | Do this |
|---|---|
| Understand the browser |
Download Pharo — it’s free, runs everywhere, takes 5 min to install |
| Build on the concept |
Fork Glamorous Toolkit — it’s open source and already experimenting with graph-based navigation |
 Learn the history |
Read “Design Principles Behind Smalltalk” by Dan Ingalls — the original 1981 paper that explains WHY everything works this way |
 Join the conversation |
The HN thread has real Pharo contributors dropping knowledge — worth reading every comment |
Smalltalk built the future 43 years ago. Everyone else is still catching up. And somehow also going backwards.
!