[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

[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

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