Resurrecting _why's Dream

In 2008, why the lucky stiff released Shoes—a toolkit for writing tiny graphical programs in Ruby. The pitch was simple: GUI programming didn't have to be painful.

Shoes.app do
  button "Push me" do
    alert "Ow!"
  end
end

That's a complete, runnable application. A window with a button. Click it, get an alert. No boilerplate, no imports, no build system. Just Ruby being Ruby.

Then in 2009, _why deleted everything and vanished from the internet. The Shoes repositories went dark. The tutorials disappeared. A community was left holding half-finished code and memories of something that almost was.

What Shoes Got Right

The insight behind Shoes wasn't technical—it was emotional. _why understood that the gap between "I have an idea" and "I have a running program" should be as small as possible. Every line of boilerplate is friction. Every import statement is a context switch. Every framework concept is something you have to hold in your head instead of your actual problem.

Shoes made that gap tiny:

Shoes.app(width: 300, height: 200) do
  background gradient(blue, white)

  stack(margin: 20) do
    para "Hello, world!", size: 20
    flow do
      button("Red") { @p.style(stroke: red) }
      button("Blue") { @p.style(stroke: blue) }
    end
    @p = para "Click a button above"
  end
end

That's a gradient background, styled text, buttons that change things. You can read it. You can teach it to someone who's never programmed. That matters.

The Problem With Shoes

Shoes was built on native GUI toolkits—GTK on Linux, Cocoa on Mac, Win32 on Windows. This was a reasonable choice in 2008. It was also the thing that killed the project.

Native GUIs are hard. Really hard. You're fighting three different platform APIs, three different event models, three different ways of laying out widgets. Every feature has to be implemented three times. Every bug exists in three different forms.

_why was good, but he was one person. When he left, no one could maintain it. The codebase rotted. Ruby moved on. The native toolkits changed. By 2015, Shoes barely ran on modern systems.

The Attempts That Followed

The Shoes dream didn't die with _why's disappearance. Good engineers poured serious effort into keeping it alive.

Shoes3 carried the native approach forward, maintaining compatibility with the original vision. Shoes4 was an ambitious rewrite on JRuby, backed by years of dedicated work—it reached release candidate status before the complexity of cross-platform native GUIs proved too much to sustain.

These weren't failures. They were necessary experiments. Each attempt taught the community something about what would and wouldn't work. The constraint was always the same: native GUI toolkits are a maintenance burden that volunteer teams can't carry indefinitely.

Scarpe: A Different Approach

Scarpe takes a different approach. Instead of fighting native GUIs, it renders to HTML via a local webview. Your Shoes code becomes a single-page application running in a lightweight browser window.

This might sound like cheating. It isn't—it's recognizing where the platform is going.

Every desktop OS now ships a capable HTML renderer. Webviews are maintained by massive browser teams. CSS layouts work consistently across platforms. JavaScript handles events the same way everywhere.

We get all of that for free. We just have to translate Shoes calls into DOM manipulations.

# This Shoes code...
stack do
  para "Hello"
  button("Click") { alert "Hi" }
end

# Becomes roughly this HTML...
<div class="stack">
  <p>Hello</p>
  <button onclick="...">Click</button>
</div>

The translation isn't always one-to-one. Shoes has concepts that don't map cleanly to HTML—flow layouts, the way para handles multiple arguments, the art drawing primitives. But the hard problems are solvable hard problems, not "convince Apple to document their private APIs" hard problems.

The Hackety Hack Test

_why didn't just build Shoes. He built Hackety Hack, a complete programming environment for teaching kids Ruby. It had a sidebar with lessons. A code editor. An art canvas. Interactive challenges.

If Scarpe can run Hackety Hack, we've succeeded. That's our compatibility bar.

We're close. The sidebar renders. The lessons load. Most of the art primitives work—star, oval, rect, line, arc, shape. We have animate and every for timers. We have background and border and gradient.

What's broken? Event chaining on certain widget combinations. We're working on it.

The Packaging Breakthrough

Here's the dirty secret of Ruby desktop apps: getting them onto someone else's computer has always been a nightmare.

Your user doesn't have Ruby installed. Even if they do, it's the wrong version. They definitely don't have your gems. Bundler might help, if you can explain what Bundler is to someone who just wants to run a program.

_why solved this with custom installers that bundled everything. It worked, barely, for the platforms of 2008. The approach didn't scale to modern code signing requirements and app store sandboxing.

We've cracked this. Using Traveling Ruby—a portable Ruby distribution—we can bundle a complete Scarpe application into a standalone macOS .app bundle. The current prototype produces a 13MB package that runs without any system Ruby installation.

The command is simple:

scarpe package myapp.rb
# outputs: MyApp.app

It works today. What remains is battle-testing across more applications, adding Windows and Linux targets, and polishing the developer experience. The hard architectural problem—embedding a Ruby runtime with gems into a distributable package—is solved.

Why This Matters

Ruby is mostly a server language now. Rails dominates the mindshare. The command line gets some love. But desktop GUI programming in Ruby is a niche that never fully developed.

That's not for lack of trying. Glimmer has built impressive cross-platform GUI capabilities with serious engineering behind it. But the Shoes approach—optimizing for simplicity and teachability over power—fills a different gap.

Not everyone is building complex applications. Kids learning to program want to see windows open and buttons click. Artists want to sketch ideas without deploying to Heroku. Teachers want to demonstrate concepts without explaining what a browser's developer console is.

The gap is: I wrote eight lines of Ruby, and now there's a window with my thing in it.

That's _why's dream. We're trying to make it work again.

---

Scarpe is open source and actively developed. We welcome contributors at the GitHub repository.

This post is dedicated to the memory of Noah Gibbs, who believed in Shoes and worked on Scarpe.