[simquat]

Thanks, I completely agree with what you say.

That is actually how the "playgrounds"[0][1] I shared work under the hood. In the playground, the preview isn't a simulation, it is the exported app –plus a shim for handling screen routing–.

A user can alter the style, create new components, or tweak the logic to better fit their needs. For example, in the Swiss Public Transit playground[1], you can edit the fetch instructions to access transport data from a different place –of course it would need some tweaks to suit the structure coming from the different API–, then the project can be forked to be independently used live in the Breadboard environment or published.

At the moment, the functionality to make a user project openly shareable as a playground is not available yet, but I think this effectively blur the line between the user and the developer.

[0] https://app.breadboards.io/playgrounds/weather

[1] https://app.breadboards.io/playgrounds/public_transit

[DonHopkins]

That sounds like a good way to structure it, so you have the best of both worlds.

There are actually practical and commercial reasons to disable stack editing (authoring), to make turnkey products whose user interfaces are not editable, but still incorporate graphics editors and other features.

Apple shipped a non-editable HyperCard stack player, that didn't allow you to open the script editor, modify card or background objects, change stack structure, etc. It was intended for distributing finished applications without requiring the full authoring environment.

Even in the full authoring version of HyperCard, you could protect a stack, protect scripts, set user levels to restrict editing, etc. So a stack could be viewable but not editable, script-locked, and restricted to browsing only. It wasn't cryptographically strong protection, but it was practical for commercial distribution.

The key insight wasn't removing power -- it was modularizing it so commercial distribution and deep editability could coexist.

HyperLook took a different approach by making the user interface editor a separate removable object, and not shipping it with runtime products, so you could remove the editor of any stack, or even replace it with a different style of editor.

The other difference was that HyperLook's entire user interface (its popup dialogs, editors, and property sheets) was all made out of editable HyperLook Stacks -- unlike HyperCard, which used uneditable Mac UIs for editors and dialogs. So you could even swap in simple "kid friendly" or advanced "developer friendly" editors and dialogs.

HyperLook Product Announcement:

https://donhopkins.com/home/catalog/hyperlook/HyperLook.READ...

  FREE HYPERLOOK RUNTIME
  ======================

  The HyperLook runtime system lets you run uneditable HyperLook
  applications. It includes many interesting demos, presentations and
  useful stacks, including a fully functional drawing tool.

HyperLook is like HyperCard in PostScript for NeWS, which I was describing to Alan Kay in this discussion:

Alan Kay on “Should web browsers have stuck to being document viewers?” and a discussion of Smalltalk, HyperCard, NeWS, and HyperLook:

https://donhopkins.medium.com/alan-kay-on-should-web-browser...

HyperLook actually did have a non-editable runtime system. The editor was factored out as a separate component you could plug into a stack, remove, or replace with a different style.

Also all the dialogs and property sheets were editable stacks (unlike HyperCard which used the non-editable Mac UI for its dialogs and property sheets). You can make a non-editable runtime version of an app simply by stripping out the editor components from each stack.

The full HyperLook system with the editor was a commercial product, and we made a free runtime demo of it with many stacks including a PostScript drawing editor that anyone could use for free. The drawing editor was actually a component you could plug into your own stacks, customize, and use in your own applications.

The free non-editable demo demonstrated HyperLook's practical features, in the hopes of persuading people to buy the full featured authoring system to develop their own personal and commercial applications.

At the same time we were developing HyperLook, I was also eating my own dog food by developing SimCity for HyperLook, which incorporated the drawing editor so you could take image snapshots of your city, and PostScript snapshots of the graph stacks and user interface, edit and annotate them, print them out, etc.

SimCity included the HyperLook runtime, and we released both at once: a free HyperLook runtime demo with a useful PostScript drawing editor, and a free playable SimCity demo you could unlock by buying a license over the phone (pre-https, 1992).

It showcased SimCity as an example of what you could do with HyperLook, which was a viral driver to download and play with the free HyperLook runtime demo. They both helped promote and demonstrate each other.

SimCity for HyperLook Product Announcement:

https://donhopkins.com/home/catalog/hyperlook/SimCity.README

  This version of SimCity was built using the HyperLook user
  interface design system, and is shipped with a HyperLook run
  time system. It includes an demonstration of HyperLook,
  featuring a fully functional PostScript graphics editor, that
  was used to draw parts of the SimCity user interface.

The "HyperLook Runtime" section of this article shows a screen snapshot of SimCity suffering from "user interface vandalism":

SimCity, Cellular Automata, and Happy Tool for HyperLook (nee HyperNeWS (nee GoodNeWS)): HyperLook was like HyperCard for NeWS, with PostScript graphics and scripting plus networking. Here are three unique and wacky examples that plug together to show what HyperNeWS was all about, and where we could go in the future!

https://donhopkins.medium.com/hyperlook-nee-hypernews-nee-go...

>HyperLook Runtime

>HyperLook supported a “runtime” version that was slimmed down and compressed, source code stripped and obfuscated as binary, with the stack editor removed (it was also just a component you plug into the stack, which could be replaced with a different editor).

>[illustration: Why We Need a Runtime System -- "This is what happens when hooligan users vandalize the interface in edit mode."]

>But with the HyperLook editor installed, you could even edit and deconstruct SimCity while it was running!

>You could edit the menus, script your own buttons and pie menus that sent messages to the simulation to help you play or cheat, and copy and paste live SimCity views into your own stacks!

>That sure made development fun and easy, but I sure didn't want to support casual users doing that! That's why we needed a runtime system.

>I shipped SimCity for NeWS as a free demo that you could FTP over the internet, buy over the phone with a credit card, and unlock the full featured game. It included the HyperLook runtime, so users couldn't actually edit its user interface unless they had the full HyperLook editor.

>The stripped-down obfuscated runtime made it possible to develop full commercial products like SimCity with HyperLook. And SimCity served as a promotion and practical example of the capabilities of HyperLook, and the other way around, too.

What I really like about what you're doing with Breadboard is that you're aiming for clarity and control, not black-box "vibes". That's exactly the right instinct, and it's very much in the spirit of HyperCard.

If you want a few directions that could push it past "modern HyperCard" and into something distinctly yours, I'd look for deeper symmetry. Making the editor a component is a great start -- the next step is letting the tool edit itself. HyperLook's big leap wasn't just a removable stack editor, it was that the environment's own dialogs, property sheets, and editors were made out of the same editable stuff as the apps. On the web you can take that further: treat the style editor, logic builder, publish flow, and even the AI helper as first-class, inspectable artifacts -- not fixed UI.

I'd strongly consider making sharing mean forking, not just viewing. A "Remix" button that preserves structure -- UI, logic, data bindings -- is the web-native version of HyperCard's copy/paste culture, and it's how you get an ecosystem instead of a gallery. The browser changes the constraints in frustrating ways, but it also gives you distribution, sandboxing, and linkability for free, so runtime vs authoring can become a deliberate continuum: lock things down when you need to ship, but keep the path back to understanding and learning available.

And consider making export and self-hosting first-class, so publishing does not imply platform lock-in. Git and GitHub are already a de facto distribution and versioning mechanism for software -- let customers own their projects and data, store them in their own repos, and plug them into your service when they want hosted convenience. That reinforces the symmetry you're aiming for: users aren't tenants, they're authors.

Most of all, keep leaning into explainable building. You're already avoiding opaque generated code -- that's huge. If AI is in the loop, have it produce the same blocks humans edit, and make its choices legible and traceable so it teaches architecture instead of performing magic.

This feels very close to something important. If Breadboard keeps pushing toward symmetry (the tool is made of itself), remixability (forkable apps, not just published apps), and transparency (AI as explainer, not illusionist), you won’t just be "reviving HyperCard" -- you’ll be carrying its unfinished ideas forward into the networked medium Alan Kay always imagined.

If you ever wanted a compelling technical demonstration, nothing shows structural clarity like wiring a real simulation into it. Micropolis -- the free GPL-3 SimCity core -- already runs in the browser via WASM and WebGL.

Since it's GPL-3 (not AGPL), the main issue is distributing a combined work that links against it, so keeping it modular and clearly separated avoids creating a derivative proprietary work.

Architecturally, you'd want to keep it as a clearly separated GPL demo module -- not bundled into Breadboard's proprietary runtime, but interacting through a clean API boundary -- while Breadboard provides the inspectable UI layer around it.

If Breadboard can sit on top of a living city simulator and make its controls readable, remixable, and teachable, that's not nostalgia -- that's evolving the 1987 vision with 2026 tools.

MicropolisCore Repo:

https://github.com/SimHacker/MicropolisCore

Micropolis in WebAssembly:

https://micropolisweb.com/