From: https://developer.mozilla.org/en-US/docs/Web/API/WebUSB_API
"WebUSB provides a way for these non-standardized USB device services to be exposed to the web. This means that hardware manufacturers will be able to provide a way for their device to be accessed from the web, without having to provide their own API."
Firefox's non-reasons are just as lame as Apple's non-reasons. These APIs aren't security risks, the user has to explicitly opt-in on every website that requests USB access, just like every other privacy-risky API that a website requests, like microphone and camera access. WebUSB is no different.
The only thing that has changed since camera and microphone access was allowed is that Apple now considers web apps to cut into their app store business, so they are unwilling to let any new APIs get approved that would make a web app as capable as a native app. This includes WebBluetooth and other APIs.
Apple is also getting sued by the DOJ for exactly this type of shady business practice.
And I don't really think what Firefox says is relevant, they are so cash-strapped I would not doubt that Apple pays them to have a negative opinion about new web APIs just so people like you can say "Firefox doesn't want it either".
The truth is there is no good reason to block WebUSB and WebBluetooth from becoming standards.
The user gets spammed with a million permissions popups a day and has no idea what they are actually accepting or what the risks are. The same looking permissions popup usually means something incredibly trivial like notifications or camera, while the webusb spec is exposing you to potentially high risks of damage to hardware or data theft.
>The user gets spammed with a million permissions popups a day and has no idea what they are actually accepting or what the risks are.
"A million" is quite the hyperbole. So let's just not do anything anymore because it might cause a permission popup? Or because some idiot might trust a scam website? That's your argument? Sorry, it's not a good argument.
>while the webusb spec is exposing you to potentially high risks of damage to hardware or data theft.
Please explain a realistic scenario where a website >that someone trusts< is going to "damage hardware or cause data theft".
I'll wait.
I don't care about someone's stupid grandfather that is going to find a way to get hacked one way or another - he's not a good reason to hold the rest of us back.
That’s the source of the issue. Apple sells products that are safe for someone’s stupid grandfather. WebUSB is not safe for people who don’t understand the implications. Which is most people.
>Apple sells products that are safe for someone’s stupid grandfather.
Then then they should be selling it in "grandfather mode". The rest of the non-stupid people that have iPhones (there are non-stupid people with iPhones, aren't there?) should be able to do what they want with their devices. But they can't because Apple puts profit over progress.
>The rest can choose a different browser.
Except on iOS you can't choose a different browser. Apple has blocked all other browsers on their mobile platform, so if you try to install Chrome, you're really just getting a Safari webview with a wrapper around it. It's just another example of abusive business tactics that the DOJ is suing Apple for.
On iOS you can’t use usb anyway. Even an actual app can’t use usb outside of the wrapper APIs for file access and stuff. So it doesn’t really matter what safari supports here. And on macOS you can use any browser you want.
That's nonsense. You have to opt-in on any website that is requesting USB access, just like every other useful but potentially privacy-risky browser API.
Plenty of sites ask for camera access, and that is typically a USB device. Plenty of sites ask for microphone accesss, which can be a USB device. And even if those aren't always USB devices, they are still very much a privacy risk that browsers all allow. USB access is no different, a website can't just do whatever it wants, you have to give it permission to use it first. And it doesn't have to be all-or-nothing either, it could be implemented to allow the browser to access only specific USB devices.
Apple is holding back progress in favor of profit. They profit when developers are forced to create a native app where Apple can extract 30% of revenue through the app.
It's not about if the camera is a USB device or not, it's about what the capabilities being exposed is. Web browsers aren't just handing over the webcam as an arbitrary USB device, they are presenting a media stream from them. Which means they can't for example send arbitrary commands, flash firmware, or do any of the infinite things a USB device might present.
I'm not giving any old website access to all of my USB devices. I'd expect to give a website I trust access to a specific USB device. I'm not sure why you think this has to be a willy-nilly free-access-to-everything feature.
Yes, I want to give access to site XYZ to a product purchased from site XYZ to do amazing things over WebUSB.
If that isn't the current spec, then change the spec so it's good.
But Apple just doesn't give a single shit to propose any changes because doing so would hurt their precious app store just a little bit.
So you're saying, it's legal to teach AI using illegally sourced copyrighted material, because it's for educational purposes only - interesting argument... ;)
Intent (should) be what matters. If you want to learn how to train AI and use copyrighted material in your learning - I don’t care in the slightest at all.
In fact if you do this as a nonprofit or at an educational institution in a teaching context it’s explicitly allowed by fair use already.
If you do it individually, idk I’m not a lawyer. But it should be allowed on principle.
But if you then go take your trained AI and deploy it for commercial purposes that’s a different story and should have protections for the original rights holders.
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...
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.
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.
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.
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.
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
>"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 [...]
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.
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.
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:
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.
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!
>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.
> 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).
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
"Email is tough", software development is tough, IT is tough, walking and talking at the same time is tough, mailing a letter is tough.
When orgs frame problems like this, it erodes trust in the message they try to convey. Email isn't a tough problem, but its a problem nobody wants to really deal with. Email is simple - its a text based protocol, that started out open, but now you need to add security to ensure your email is delivered.
Similarly, I'm using it to write apps in non-native languages, like rust. My first foray into it led to finding poor documentation examples. AI allows me to create without spending large swaths of time learning minutia.
I'm enjoying it to a point, but yes, it does eliminate that sense of accomplishment - when you've spent many late nights working on something complex, and finally finish it. That's pretty much gone.
Not all of those have "Ships from and sold by Amazon.com" below the shipping timeframe line. It changes depending on inventory stock. The first monitor in the "plus" list says "Ships from and sold by computersale". Some third party sellers can register a device's sale with Dell.
The invoice on my order history says Dell was the seller, and I specifically remember that the label on the unopened box showed that it was shipped directly from Dell’s warehouse.
I went through this like 100 ways when it happened. I bought the monitor from Dell. They shipped it from their hands straight to mine. And when it broke, they refused to make good on it.
That doesn't sound secure at all!
reply