I started out with HyperCard and when I outgrew it, upgraded to REALbasic, a cross-platform Visual Basic clone (now Xojo). When I started college I switched to writing C++, which I perceived as a more "professional" language, but in doing so left the GUI behind and started producing almost exclusively command-line tools.
When I try to write a GUI app these days, I'm stunned by how much harder it seems. As an elementary school student I could churn out HyperCard stacks without being able to search Google, ask on StackOverflow, or watch a YouTube tutorial.
One of the things modern tools left behind is how the code and UI were bound together. In HyperCard or REALbasic, the code for what a button does is "inside" the button, so if you want to know how it works or modify its behavior, you just "open it up" it in the editor. Stringing together IBActions or attaching event handlers to DOM elements may be a more general solution, but most of the time the distance it introduces between the button and its effect is just extra cognitive overhead.
One of the things modern tools left behind is how the code and UI were bound together.
For a while, Flash had this, and it was one of the things that made it fun and easy to hack stuff together with. Then Actionscript 3 happened and that wasn't allowed any more because AS3 was a Serious Language for Serious Developers.
(Actionscript 1 was a horrible thing you could only enter by selecting keywords from a dropdown menu, it was really terrible for doing anything more than basic interactivity. AS2 hit a real sweet spot of being something you could quickly type into a text box and tie closely to the objects in the editor.)
what you describe was 'actions' prior to flash 5, which introduced actionscript1 which was a normal text-based scripting language.
edit: i just had to check (thanks -- i now got to enjoy flash 5 on my windows 2000 install). the 'object actions' editor in flash 5 has a 'normal/expert mode' toggle, where 'normal' (the default) is the menu-based interface as you describe and 'expert' is the normal text editor.
You are correct. In fact, pre-AS1, Flash Actions were a dramatically different VM. If you wanted to store a property on an object you had to use slash paths. "../hero:gun/bullet" would go up one clip, look for something called hero, look for a gun on the hero, and then a bullet in the gun.
Macromedia beat Actions into something that could vaguely-resemble an ECMA-262 3ed language runtime if you squinted hard enough. However, all of the old warts still remain, probably because otherwise you couldn't upgrade from Flash 4 and compile to newer SWF versions. Thus, Actions, ActionScript, and ActionScript 2.0 all compile to the same VM. The only difference in semantics come if you compile to a newer or older Flash Player version.
AS3 is an entirely different VM that actually was designed to serve as the runtime for the 4th edition of ECMAScript, which never actually came out because web developers thought it was way too complicated. However, the only features that never actually made it into modern JS are namespaces, interfaces, and prototype-free classes. Everything else did eventually make it back into ES5 or ES6, albeit in dramatically different ways[0] sometimes.
[0] For example, when you declare a `class` in modern JavaScript, you are actually invoking syntactic sugar (mostly) for declaring a constructor function, setting the prototype to an instance of the parent, and then populating methods on the prototype. This is also how AS2 did it, too.
In ES4, they instead decided to completely junk prototypes in favor of Java-style inheritance. When you declare a class, you're creating an actual Class with a vtable and everything. It's instances actually get copies of their methods with `this` properly bound, which you can shove directly into `addEventListener` and `removeEventListener` and expect to work.
As other commenters have pointed out, there are a bunch of simple GUI builders out there that embed button code "inside" the button, including GUI builders for the web, but none of them are popular.
Hypercard became popular because it hit a sweet spot of supply and demand that can't be reproduced today.
When Hypercard launched, it came with every Mac, it was free, and there was nothing else like it available on the Mac. On the Mac, the alternative to Hypercard was to layout UI widgets in code, with no GUI builder at all, or eventually to pay $$$ for a professional-grade IDE like CodeWarrior. As an entry-level user with no budget, if you wanted a GUI builder for the Mac, you got Hypercard, or nothing. This created a community of Hypercard enthusiasts.
Furthermore, when Hypercard launched, Macs had a standard screen resolution. Every Mac sold had a screen resolution of 512x342 pixels, so you could know for sure how your cards would look on any Mac. Supporting resizable GUIs is one of the hardest things to do in any GUI builder. (How should the buttons layout when the screen gets very small, like a phone? Or very wide, like a 16:9 monitor?) Today, Xcode uses a sophisticated constraint solver / theorem prover to allow developers to build resizable UIs in a GUI; it works pretty well, I think, but it's never going to be as easy to learn as "drag the button onto the screen and it's going to look exactly like that everywhere."
The last issue is the real killer for modern Hypercard wannabes: it's a small step from a web GUI builder to raw HTML/CSS. You don't have to pay big bucks to have access to professional-grade HTML, CSS, and JavaScript. Sure, they're not that easy to learn, but you can teach a kid to write interactive web pages, no problem.
As a result, the demand for a simple GUI builder is lower than it was for Hypercard, and even when you do capture a user, they tend to outgrow your product, and there are a zillion competitors, so none of them can build a community with real traction.
The problem with this model is that it ends up being an invitation to mix "business" logic with the UI. I look at some of the PHP code I wrote (back when it was still PHP3) or some of the JSP stuff I've had to work with and this model of development always ends up an unholy mess.
I wonder if there could be some "gradual" approach here where perhaps you'd have levels of maturity that you can evolve a project thorough over time. Perhaps something such as:
0: no separation of concerns whatsoever, just quickly hacking at it.
1: no separation of concerns required, but you have to label each component as having one or more concerns. This would still allow for mixed "business+presentation", but you can add constraints such as "a pure business component is not allowed to depend on a pure presentation component".
2: No mixed-concerns components allowed. So you have to split them somehow, but they can still interact in arbitrary ways.
3: All interaction across concerns has to go through specific interfaces, such that it's easy to replace implementations (e.g. using dependency injection).
> One of the things modern tools left behind is how the code and UI were bound together
That seems wrong to me, unless I've misunderstood your comment. It's more like there's a saturated market full of such tools.
Microsot Power Apps, Quickbase, Mendix, Salesforce Platform all provide "no-code solutions" that let you drag and drop and customise with code. Then there are Bootstrap generators that you let you control layout. I've seen plugins that integrate React components into a WYSIWYG editor. Even PowerPoint has easy to attach custom actions for desktop presentations.
None of these apps are really priced in a way that allows me to build an app and share it with people as a personal project though.
Let's assume that I want to build a simple app for my local theater troupe, which will have 20 users:
* Quickbase starts at $600 a month
* PowerApps costs me £7 for every user I want to give access to the app
* Salesforce again costs me £20 per user per month
* Mendix costs me £10 per user
All these are priced at enterprises that have deeper pockets than a personal project or small community org can stomach.
If you just want to make a cool app and share it with some people online, none of these products have commercial models which are compatible when you compare it against the 'old fashioned' ways to build apps like WinForms, Flash etc.
I would love to find an alternative to these products with a commercial structure that means if I build something cool I can share it on HN without it bankrupting me.
I don't personally think any of those start to scratch the capabilities of WinForms or an old-school Access DB - These are just the ability to create a static site, or at most submit some data through a form, not build an actual application.
I know Hypercard wasn't multi-user, but you could make something and then send it to someone without incurring fees.
Regardless of the technology and requirements though, which will be specific to each project, I just wanna be able to make stuff and show it to people :) (and not just a static site with a form).
And if I need to make certain apps quickly, why is Access still a compelling choice? (PLEASE someone tell me an alternative if there is one for the sort of app you would build in an Access DB, I genuinely want to know!)
IMO, the problem is that many of those tools are really not that reliable in the sense that they may go away soon.
It all takes a company to be acquired by M$, GOOG etc and then taken offline.
For example, I lived through Google Appmaker (absolutely fantastic!) which was retired with 6 months notice.
It's really risky to build larger app on no-code platforms that you don't fully control via self-hosting. And I don't know great open-source/open-core low/no-code stacks that are easy to use and expressive enough. It would be great to get pointers.
I guess a the height of hypercard, that really wasn't really on people's radar.
>I guess a the height of hypercard, that really wasn't really on people's radar.
It didn't matter yet. People were shipping the software they made in HyperCard to customers on floppies or CDs. IIRC these were self-contained executables, so you didn't need to have HyperCard installed for it to run. One of the most famous examples of this was Myst: https://en.wikipedia.org/wiki/Myst.
Myst is an interesting example… while it’s definitely a HyperCard stack, it relies heavily on XCMDs and XFCNs… which let you call into native code. So while it’s certainly the most famous example of a program written in HyperCard, it’s not a typical or representative example of how people made HyperCard programs.
Sounds like you're worried about what happens if you embed and tightly couple a lot of your business logic to something you don't have full control over? That's a totally valid concern, and probably one of the reasons we've tended to move away from these tools and towards doing everything in stable programming languages.
It's a classic set of trade-offs - quality, features, stability, security, price. There are lots of solutions on the market offering one configuration of those trade-offs.
If it existed today, some people would push for HyperCard to support mobile apps, multi-user access, web-based and native apps, all of which would make the solution 'worse" for others.
With Lazarus[0] you can basically get the same experience as REALbasic/Xojo. Here is a video[1] i made a few years ago, making a simple 2D tilemap editor using it.
For me, React and SwiftUI definitely fill this niche. React requires more googling but it’s still fairly simple to throw together a functional UI. SwiftUI is even easier, but when you want to customise away from the Apple provided appearance it gets considerably harder than with React.
Well, to each their own, but I find the starter plan with a single platform deployment at 7.99 per month pretty OK.
I must say that I see a lot of value in LiveCode. I have a standard plan with lots of deployment options, enabling me to ship software for macOS, Linux, Windows, Android and iOS. It is not cheap, but I'm OK with it as I use it for professional work. LiveCode is a small company and making money on niche software development languages is quite hard. Sometimes selling cheap licenses is not a good option when your market is quite small.
Who cares about competitors when you barely have any market share for yourself? You can be the greatest IDE in the world, but if barely anybody is using you how great are you really?
The fact that their lowest pricing tier ties the apps to the account is bonkers too. If that account lapses in payment, any apps built by the account cease functioning. Not even Apple is that brazen if your developer account lapses.
That is because that account is for learning and building stuff for your own usage. If your objective is to ship software, you're supposed to go with a standard license. Apps built with them don't have such checks in place.
Everyone in this thread reminiscing about hypercard and how more modern no-code tools still have not matched its amazing functionality and UI.
So, what's to stop someone today from making a modern hypercard clone? I imagine something which has the exact same UI logic as hypercard and allows projects to be exported as JavaScript WebApps. Is it not possible?
Seems like it should exist! Inviting any volunteers...
:-D I’m the developer of this, and particularly proud that not only can you Import stacks, icons and all, but you can Export single page web apps that end in .stack.html and run in any modern browser! It’s all in the hamburger menu.
Bravo! But, I picked a stack at random from archive.org, probably one that was too complex, and it just threw an error when I tried to import it. What are some limitations to be aware of?
The importer will open StuffIt and old OS disk images just like archive.org gives you, but something unexpected could have gone wrong. I’ll probably do a few bug fixes tonight.
was just digging to find more about this/you -- and noticed it's similar to that WildCard thing from not so long ago?? Did you just expand/shift it over to the new domain or?
> So, what's to stop someone today from making a modern hypercard clone?
One issue is the HyperCard fit holistically with Macs of the 80s and early 90s. A straight clone doesn't quite make sense today -- perhaps we need slightly different metaphors.
Last year I was a part of a research team that explored some of this. We ended up producing a system called Simpletalk [1], which is essentially a web-based system and scripting language inspired by Smalltalk and Hypercard. If you are interested, I also gave a talk [2] on some of the motivations and design behind the system.
still have not matched its amazing functionality and UI
This isn't because people just ignored or forgot Hypercard - similar tools just evolved in many different directions and many of them were much more popular than Hypercard. FileMaker, Access, Visual Basic and their ilk come to mind; the current crop of 'no code' tools are also distant descendants. A key difficulty isn't replicating the UI, it's coming up with a tool/system that's both accessible to non-experts while also providing a smooth 'power curve' to the more sophisticated features of the platform. Without that, motivated beginners quickly run up against the limitations of the built-in functionality or a big jump in conceptual and practical complexity.
There is a bunch of them out there. Many died in the last twenty years. The only ones that I am aware of that are in active development are LiveCode and SuperCard.
Recently I’ve been on something of a HyperCard kick despite being too young to have ever used it. The impression I’ve gotten of it, as a tool that was radically simple to use and create with, leads me to believe there is some spark of genius within it. Within the greater purview of end-user development it still shines as one of the greatest successes. Still waiting for the dream to be realized.
Kudos on HyperCard Simulator, brings back good memories.
HyperCard was brilliant but as others mentioned, partly this was enabled by limiting the scope. You still had to learn the scripting language though.
While dramatically different, MIT's Scratch enables kids (and older "kids", ahem) to experience the same immediacy and ease of use and having witness the output of my 10 yo, I dare say he could produce anything I could do with HyperCard and more with Scratch.
Was reading about Bill after seeing this post and found this quote:
“Inspired by a mind-expanding LSD journey in 1985, I designed the HyperCard authoring system…”
- Bill Atkinson
The seamless transition between editing and interaction modes is still unparalleled.
There's basically no difference between using something and creating it. I recall this was a very empowering feeling on the original Mac when I was a child.
Aside from Bill Atkinson simply being a genius, a shining trait of HC is that it didn't try to do everything.
There was a successor to HC called SuperCard (which I used to create a printed circuit board drawing app). SC added all of the features "missing" from HC, such as a large variety of different window types. In the process, it became harder to use, for not very much gain. Having both HC and SC on my computer, I invariably reached for HC, even when it meant that my programs didn't look quite as snappy.
For me, HC was what made it tolerable to use a Mac. I did some pretty outrageous things with it, such as controlling a primitive custom machine tool. I did have to create some "code resources" in Pascal or C to access my hardware interfaces, but those codes were often on the order of a couple dozen lines, and rarely needed to be maintained.
Visual Basic made the same mistake. The more "professional" it became, the harder it was for the people who were actually interested in using it. I stuck with VB5 long after VB.NET came out.
This reminded me of the comments i've read online from modders about the modding tools for Neverwinter Nights 1 vs those of Neverwinter Nights 2. Both are very moddable games but the NWN1 tools were actually designed as part of the product (for many the official campaign was just a demo for the tools) and were very simple to use - but also very limited (e.g. areas could only be made by placing prefabricated tiles - though you could make your own tiles with external tools and also add additional objects on top of them, most of the area work was placing tiles together). On the other hand NWN2 was more freeform, had better visuals and features, allowed arbitrary terrain sculpting, etc but that also made it much more complicated to use.
As a result NWN1 has a ton more modules (campaigns/mods) for it than NWN2 and many people who spent considerable time on NWN1 never moved to NWN2 due to the increased complexity. To this day i often find comments about how simple and easy the NWN1 tools were, but i don't remember ever reading anything like that for NWN2 :-P.
That's an interesting point about not doing everything. Livecode is a more powerful, capable tool very much based on HC, and while it has a great power-to-complexity ratio, I don't think it's (made up numbers) 5x more powerful, but 8x more complex. https://livecode.com/
Flash seemed like an evolved form of HyperCard, and the proprietary nature of both were ultimately their demise. I retain some hope that somebody will redo / updo this family of tools on top of a cross-platform game engine like Unity.
> the proprietary nature of both were ultimately their demise
Agree.
> I retain some hope that somebody will redo / updo this family of tools
Hard agree.
> on top of a cross-platform game engine like Unity.
Wait what? Wouldn't you want it to be implemented at the very least on something like Godot, which is open source?
Aside from that, I think we are in full agreement on this - though my dream would be something like this on uxn (because I love the concept of uxn, I don't know that it would actually be feasible to do so - I suspect it wouldn't.)
Sorry, Unity was the first that came to mind, I forgot it was closed. Good call.
Though, I should clarify... the missed opportunity with Flash is that there was no good reason for the .swf format to be closed. IIRC, there were a few attempts made at making non-Adobe Flash players, but they were always terrible because of the necessary overhead of reversing the format.
Even if the initial version was built on Unity, as long as the creations were saved to an open and well-documented file format, alternative players could be written which would be a boon to the ecosystem.
Honestly, I think open formats and protocols are more important in general than open code -- which is of course why we see them less and less these days :( .
Uxn should be able to host something like Hypercard, the hypertalk language would probably look something like akin to Postscript.
Uxn's Noodle software is inching toward something like Macpaint. A software that ties it all together as a game making tool would in Uxn would be very nice indeed!
It's been a while since I checked in on Uxn, I should look again! Last time I checked there wasn't much in the way of docs, but it looks like there's more now - there goes a couple of evenings in the near future!
Edit: Looking at your username and then comment history, it looks as if you are possibly actually one or both of the 100 rabbits?
If so, thanks for being one of my personal inspirations to keep learning about both computing and sustainable lifestyle!
We've been trying to write some documentation as things are finally stabilizing. If you're interested in learning uxnasm to write something like hypercard, I'd love to help.
I'd definitely be interested in that, I actually started the tutorial about an hour or two before seeing this comment.
I'm thinking I'll run through this tutorial and then try to implement a couple basic ideas I've had bouncing around, is there way I should contact you when I get there? I'll try to check back here for any updates, an email address is in my profile as well if that works for you.
I'll probably need to work with Hypercard itself more first as well - at this point I only know how it works in theory plus a couple minutes of demo video.
GTK3 with Glade was a really great (albeit considerably more complicated) tool to do more or less the same thing with modern design paradigms and more complicated, capable widgets. Unfortunately, the GTK devs seem to be moving away from simple UI design with GTK4, making it pretty undesirable for building anything other than complex, hulking apps.
I still have a plethora of weekend projects made with GTK2/3 sitting around on my drives. Little MPRIS controllers, simple icon viewers, petname generators, hashing applications... I've got half a mind to fork GTK3 into a simpler UI design tool if I had the time for it.
Didn't know that, but not surprised. When I got to play with Hypercard in elementary school, I drew houses and paths and put buttons on the paths to navigate between the screens, with some text to tell a very simple story (wish I still had it, but it's long gone. I only vaguely remember what a couple of screens looked like).
If I had more time with it maybe I might have been able to turn it into a proper game. Not on the same level as Myst, though, of course.
It should go to the next card. Can you tell me what is your device type and the name of your browser? Unfortunately most bugs of a web page are just other browsers doing unexpected things that I find out about later.
I had heard that the sources were donated to the Computer History Museum along with MacPaint and QuickDraw, also invented by Atkinson. However they have not released it.
"Simulator", the term, is misused in this post. In common usage, an implementation of a programming system is not called a "simulation". For example, the"cross-platform Visual Basic clone" mentioned by rgovostes in the comments is not called a "Visual Basic simulation". For common usage, see https://en.wikipedia.org/wiki/Simulation and the associated disambiguation page. Consult Google for alternative usage. Language is dynamic, fluid, and occasionally fickle, but for effective communication we need to stick with commonly accepted usage unless there is good reason to depart from same.
When I try to write a GUI app these days, I'm stunned by how much harder it seems. As an elementary school student I could churn out HyperCard stacks without being able to search Google, ask on StackOverflow, or watch a YouTube tutorial.
One of the things modern tools left behind is how the code and UI were bound together. In HyperCard or REALbasic, the code for what a button does is "inside" the button, so if you want to know how it works or modify its behavior, you just "open it up" it in the editor. Stringing together IBActions or attaching event handlers to DOM elements may be a more general solution, but most of the time the distance it introduces between the button and its effect is just extra cognitive overhead.