[davsti4]

Nice - I like the interface, and its easy to navigate. I don't see a way to test the demo apps, but maybe I missed that?

One thing that stands out is where does the app reside? It seems like it perpetually lives within your ecosystem/servers.

For customers that have contracts with me, I'd then need to disclose Breadboard as a subprocessor given the level of integration in the supply chain, IF the apps aren't downloadable and independently auditable.

You've also probably seen SaaS stocks taking a hit lately...

[simquat]

Thanks, really appreciate the feedback!

In the playground the apps can only be previewed in the canvas. Exported/live apps are available here:

Weather App: https://late-cat-2043.breadboards.app

Swiss Public Transit: https://long-wind-1522.breadboards.app

Live apps are hosted on Cloudflare, when an app is published it’s stored and served from R2. Exports are not yet downloadable, but we’ll add downloadable exports soon.

[davsti4]

Thanks for the links - at first they didn't load. But allowing connections in my firewall to unpkg.com, open-meteo.com and opendata.ch allowed them to work. They're simple, but I could see taking that weather example to another level.

Open-meteo and opendata.ch are understandable for the weather and transit information, but unpkg is a third-party vendor dependency that would additionally need to be disclosed. For an enterprise tier of service you'll need to only ship audited dependency libraries.

[simquat]

Thanks for digging into the network requests :) That's a valid point, we can bundle or serve this dependency – hyperscript – from the domain where the app lives. The same goes for fonts, at the moment we're using Google Fonts for convenience, but they can easily be served on the same domain as the app.

[DonHopkins]

I thought the whole point of HyperCard is that the editor is the live app, that live apps can flip into editor mode at any time, and you THE USER can edit them live, mash them up with other apps, create your own unique apps, that there is no difference between app developer and app user, between the editor and the live app, because they are one and the same. Anything less totally misses the entire point of HyperCard. Otherwise it's just another version of Flash.

https://news.ycombinator.com/item?id=44212267

DonHopkins 8 months ago | parent | context | favorite | on: Bill Atkinson has died

Flash completely missed the most important point of HyperCard, which was that end users could put it into edit mode, explore the source code, learn from it, extend it, copy parts of it out, and build their own user interfaces with it. It's not just "View Source", but "Edit Source" with a built-in, easy to use, scriptable, graphical, interactive WYSIWYG editor that anyone can use.

HyperCard did all that and more long before the web existed, was fully scriptable years before JavaScript existed, was extensible with plug-in XCMDs long before COM/OLE/ActiveX or even OpenDoc/CyberDog or Java/HotJava/Applets, and was widely available and embraced by millions of end-users, was used for games, storytelling, art, business, personal productivity, app development, education, publishing, porn, and so much more, way before merely static web page WYSIWYG editors (let alone live interactive scriptable extensible web application editors) ever existed.

LiveCard (HyperCard as a live HTTP web app server back-end via WebStar/MacHTTP) was probably the first tool that made it possible to create live web pages with graphics and forms with an interactive WYSIWYG editor that even kids could use to publish live HyperCard apps, databases, and clickable graphics on the web.

HyperCard deeply inspired HyperLook for NeWS, which was scripted, drawn, and modeled with PostScript, that I used to port SimCity to Unix:

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...

>"Apple’s Hypercard was a terrific and highly successful end-user authoring system whose media was scripted, WYSIWYG, and “symmetric” (in the sense that the “reader” could turn around and “author” in the same high-level terms and forms). It should be the start of — and the guide for — the “User Experience” of encountering and dealing with web content.

>"The underlying system for a browser should not be that of an “app” but of an Operating System whose job would be to protectively and safely run encapsulated systems (i.e. “real objects”) gotten from the web. It should be the way that web content could be open-ended, and not tied to functional subsets in the browser." -Alan Kay

>[...] This work is so good — for any time — and especially for its time — that I don’t want to sully it with any criticisms in the same reply that contains this praise.

>I will confess to not knowing about most of this work until your comments here — and this lack of knowledge was a minus in a number of ways wrt some of the work that we did at Viewpoints since ca 2000.

>(Separate reply) My only real regret about this terrific work is that your group missed the significance for personal computing of the design of Hypertalk in Hypercard.

>It’s not even that Hypertalk is the very best possible way to solve the problems and goals it took on — hard to say one way or another — but I think it is the best example ever actually done and given to millions of end users. And by quite a distance.

>Dan Winkler and Bill Atkinson violated a lot of important principles of “good programming language design”, but they achieved the first overall system in which end-users “could see their own faces”, and could do many projects, and learn as they went.

>For many reasons, a second pass at the end-user programming problem — that takes advantage of what was learned from Hypercard and Hypertalk — has never been done (AFAIK). The Etoys system in Squeak Smalltalk in the early 2000s was very successful, but the design was purposely limited to 8–11 year olds (in part because of constraints from working at Disney).

>It’s interesting to contemplate that the follow on system might not have a close resemblance to Hypertalk — perhaps only a vague one [...]

[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/

[phendrenad2]

> I thought the whole point of HyperCard is that the editor is the live app, that live apps can flip into editor mode at any time, and you THE USER can edit them live

That may have been the initial point of HyperCard, but what really propelled HyperCard to greatness was the intentional breaking of that model. I.E. adding "locked" status to HyperCard stacks so that people couldn't (easily) modify them, they could only run them. HyperCard would have been a footnote in history if it hadn't been for that flag. Nobody would have handed stacks to end users if they were a few clicks away from deleting buttons or reordering pages or something (causing frustrated users to complain that the "application" was broken).

[RodgerTheGreat]

I agree. I wrote an essay which contrasts the "visualbasic-like" vision that most visual app-builder tools take with the pliable, user-modifiable stack-of-cards approach in HyperCard: https://beyondloom.com/blog/sketchpad.html