You’ve probably done it. You need a quick desktop tool, you’re writing in Python, and you reach for Tkinter. It just works. No massive downloads, no web-view bloat, no dependency hell. It just pops up a window on Windows, Mac, and Linux.
But the moment someone mentions “Tcl/Tk,” you roll your eyes. “The problem with Tcl/Tk,” you say, parroting the consensus, “is Tcl.” You write it off as a dead, quirky language not worth mastering.
We hate Tcl because it looks like shell scripting’s weird cousin, but we love Tk because it just runs.
Here is the twist you didn’t see coming: Tk is everywhere precisely because of Tcl.
For decades, the industry has treated Tcl and Tk as a package deal, judging the GUI toolkit by the syntax of its underlying language. But Tk’s ubiquity isn’t an accident. It is a direct downstream effect of Tcl’s original design as an interpreter-as-library. Tcl was built from day one to be embedded inside other applications. That design choice made Tk incredibly portable.
The very thing that makes Tcl a frustrating general-purpose language is the exact thing that made Tk the undisputed king of zero-dependency GUIs.
Decouple Tk from Tcl completely, and you lose the mechanism that got it bundled into Python, Ruby, and Scheme in the first place. You lose the embeddability. You lose the magic.
Look at the real-world tools using this today. macOS’s popular Hex Fiend uses Tcl for its templating language. Developers routinely share how they use Tk in Scheme or Ruby—without writing a single line of Tcl. They get the cross-platform GUI; they skip the language they dislike.
And yet, the critics still complain about footprint. “A 100MB footprint is still pretty big,” one commenter argued, comparing it to fasm or rebol. Are you kidding me? We live in an era where developers ship desktop apps wrapped in Chromium. Opening a blank window in Electron eats hundreds of megabytes of RAM.
In a world where opening a blank Electron window eats 200MB of RAM, complaining about a 1MB footprint isn’t engineering—it’s Stockholm syndrome.
Our perception of “small” has been completely warped by browser-everything bloat. Tk remains tiny, fast, and ships by default inside modern toolchains. It is a 35-year-old “boring” technology quietly powering real tools today, dismissed by a generation who never stopped to notice it.
If you’ve avoided Tcl/Tk because of Tcl, you’re leaving an incredibly lightweight tool on the table. You don’t have to master Tcl. You can leverage Tk’s cross-platform GUI via Python, Ruby, or Scheme and ship a desktop tool today without getting lost in a rewrite cycle chasing modern, bloated frameworks.
Sometimes the most resilient technology isn’t the shiny new framework. It’s the underdog that embedded itself so deeply into the stack, you forgot it was even there.
FAQ
Q: If Tcl is so disliked, why hasn't Tk been rewritten in a modern language?
A: Because rewriting Tk in a modern language destroys its core advantage: embeddability. Tcl's architecture as a library-first interpreter is exactly what allowed Tk to be ported into Python, Ruby, and Scheme. You can't just rip out the engine and expect the car to drive the same way.
Q: What's the practical takeaway for a developer today?
A: Stop reaching for Electron or massive web-wrapped frameworks for simple desktop tools. If you write Python, just use Tkinter. It ships by default, has zero dependencies, and works across all major OSs. You get the power of Tk without ever touching a line of Tcl.
Q: Isn't Tk's UI ugly and outdated?
A: The default theme is dated, but that's a superficial critique. The underlying toolkit is rock-solid, cross-platform, and uses a fraction of the resources of modern alternatives. You can theme it, but you can't fake its 35-year track record of just working.