Decker: Applying HyperCard's Object Model to the Web

HyperCard was a weird, beautiful anomaly. It treated everything as an object, blurring the line between the tool you used to build a project and the project itself. For a long time, that philosophy felt like a relic of the 90s, something we traded for the rigid separation of "development" and "production." Decker brings that mindset back to the modern web.

It's a multimedia platform for interactive documents. You get sound, images, and scripted behavior, all running in your browser. I've spent a few hours with it, and the most interesting part isn't the media support, but how it handles widgets. You can define a custom interface element and then just copy and paste the definition using your system clipboard.

That's a strange, tactile way to share code. Instead of pushing a package to a registry or linking a GitHub gist, you're just moving a piece of a living document from one place to another. It makes the act of building feel less like engineering and more like sketching.

The question is whether this "everything-is-an-object" approach actually scales, or if it's just a nostalgic exercise in digital scrapbooking.

The HyperCard lineage

Decker is a direct descendant of HyperCard. It replaces the standard linear text editor with a spatial canvas where you organize information into "stacks" and "cards." In a typical IDE, you navigate a file tree; in Decker, you navigate a physical layout. This shift is a move from temporal software design—where things happen in a sequence—to spatial design, where the relationship between two pieces of logic is defined by their proximity on a screen.

This approach removes the friction between thinking of an idea and actually building it. You aren't jumping between a design tool and a code editor. You're just placing a script on a card and triggering it. It's a strange way to work if you're used to modern frameworks, but it's faster for prototyping because the visual layout is the source of truth.

Since Decker uses Lua for its logic, you can trigger actions based on spatial events. For example, if you want a card to change color or move when a user clicks it, you write a small script directly tied to that object:

-- Change the card background to red when clicked
function onClick()
  card.backgroundColor = "#FF0000"
  print("Card clicked!")
end

The result is a tool that feels more like a sketchbook than a compiler. It's not a replacement for a full-scale production environment, but it's a great way to map out a complex system before you commit to a rigid directory structure.

Creating with the Decker language

Decker uses a custom scripting language that treats the card as a state machine. Instead of managing a complex DOM or writing boilerplate event listeners, you define logic directly on the elements. It's a throwback to HyperCard, where the "intelligence" of the page is baked into the objects themselves.

The state management is surprisingly lean. You don't need to initialize a store or call a reducer; you just manipulate variables and trigger transitions. This part is genuinely confusing at first because it ignores most modern web conventions, but once you stop trying to write it like React, it's fast.

// Change the card background and update a counter when clicked
on click {
  bg = bg == "white" ? "black" : "white";
  count = count + 1;
  redraw();
}

The toolset is intentionally limited. You get basic logic and drawing commands, which prevents the cards from becoming bloated software projects. It's a tight balance: you can't build a full-scale CRM, but you can build an interactive toy or a digital zine in an afternoon.

To get started, you don't even need a build step. You can run the environment directly from a CDN or install the CLI tool:

npm install -g decker-cli

The Decker environment

Decker isn't trying to be a productive IDE for the modern web; it's a digital toy box. By mimicking the constraints of the 1980s, it manages to bypass the "blank page" anxiety that usually comes with modern software development. The appeal here isn't just nostalgia—it's that the card-based interface forces a specific, tactile way of organizing information that we've largely lost in the era of infinite scrolling and nested folders.

I see people online treating this as a "HyperCard clone," but that framing misses the point. Clones are about replication. Decker is more of an exploration into why those old constraints actually felt intuitive. I suspect the real value isn't in the tools themselves, but in the realization that we've over-engineered our creative environments to the point where they feel sterile.

Still, I'm not convinced this translates into a viable workflow for anything beyond art projects or small-scale experiments. The friction of moving from a "card" mindset back into a standard production pipeline is high. I wonder if we're just flirting with a specific aesthetic of "simplicity" without actually wanting to give up the power of modern tooling.

The implications of a "toy" platform

The push toward "toy" platforms like Decker suggests a growing fatigue with the professionalization of software. Most of our tools are now designed for "productivity," which is usually just code for maximizing output within a corporate workflow. When people gravitate toward card-based interfaces or HyperCard clones, they aren't looking for a more efficient way to manage a database. They're looking for a place where the cost of failure is zero and the goal is just to see what happens when you connect two random pieces of logic.

I think the community's excitement over these retro-inspired tools is a reaction to the "walled garden" nature of modern no-code platforms. Those tools claim to be accessible, but they're actually rigid; they force you into a specific mental model of how a business app should work. Decker and its peers do the opposite. They provide a primitive set of bricks and get out of the way. It's not about nostalgia for 1987—it's about the desire for a development environment that doesn't feel like a job.

That said, I'm skeptical that this movement will actually shift how we build "real" software. The friction of moving from a toy platform to a production environment is still massive. We're seeing a gap widen between tools we use to think and tools we use to ship.

The question is whether we can actually integrate "toy" mentalities into professional tooling without stripping away the playfulness that makes them useful in the first place.

Conclusion

Decker is a curiosity, and mostly, it's a toy. But there is something honest about a platform where you can copy a custom widget to your clipboard and paste it into a friend's document without worrying about dependencies or build pipelines. It strips away the overhead of modern web development to see if the actual act of creating is still fun.

I'm still not sure if the "toy" model can survive outside of a niche enthusiast circle, but the fact that the source is on GitHub under an MIT license means it doesn't have to be a commercial success to be useful.

If you're tired of the current state of the web, go open it in your browser and see if you actually enjoy building something when the tools stop trying to be "professional."