I think this blog post is overly caught up on the word “card” – HyperCard “cards” weren’t particularly like the cards inside android or twitter or facebook. Indeed, if HyperCard cards were like anything, it’s web pages, except designed for the limitations of the hardware of the time and targeting only one hardware platform (standard display, etc.) and running on a single non-networked computer.
Also, why “way too early”? Too early for what?
The most important feature of HyperCard, in my opinion, was that it gave end-users powerful general-purpose tools for programming and solving their own problems, in a way that was easy to get started with. Instead of being locked into someone’s existing program designed with an idealized customer’s needs, any HyperCard user could create or customize a HyperCard stack to suit their own preferences.
Unfortunately, tools requiring customer learning and mastery are very difficult to design and implement, and even more difficult to demo and sell. And so our software is designed in a very narrow and limiting fashion. The “cards” in android and facebook and twitter &c. are doing nothing to combat this, and to compare them favorably to HyperCard is in my opinion to completely (and tragically) miss the point of HyperCard.
I don’t see any particular signs of this trend toward closed systems reversing; indeed, as more people come online, and giant corporations spend billions of dollars hiring all the smartest people to work on developing software that gives them (the corporations) as much control as possible over uses of computer hardware/software, the popular machines and software systems are only getting more closed and locked down. The web itself is an open and flexible platform, but increasingly people are spending their time in a few centralized and controlled parts of it.
Yeah, I didn't get that either. To me Hypercard was really basic web with super-simple HTML holding the stacks together. I don't code much these days but I remember fondly all the little games and tools I could make with a little ingenuity and experimentation in Hypercard.
I thought the same when I read the article -- they missed the point of the programmability, and some of the downfall of hypercard (it was an unholy mess to sort out a badly written stack.) Sometimes I wonder if the spiritual successor of hypercard was in fact Visual Basic.
Remember that HyperCard was introduced in 1987 or so, the GUI/WIMP era was just getting started. The learning curve of writing a Macintosh application was incredibly steep - nearly impossible IMO - but here was a way to make a simple point-and-click app that actually did something (write to a file, do some calculations, show information, even talk out the serial port, etc) with a minimal amount of lifting. My first paid piece of software was a point-of-sale application written in HyperCard. And it worked just fine.
VB was pretty much the equivalent for Windows, once it came along.
The web is close in some respects (HTML is easy) and not in others (servers and single-page apps are not).
I suppose, in another respect, Excel is a successor for many, though it isn't a good solution for making apps of any sort.
Surprisingly, the closest I've seen has been Microsoft's Project Siena[1]. I've not used it extensively, but my 5 or 10 minute made it look like it had the dirt-simple-to-get-started appeal of HyperCard and VB.
Anyone know of other "spiritual successors" out there?
VB was clearly influenced by Hypercard. Likewise HTML. In many ways (including performance) VB was a huge regression from Hypercard (I was working on a multimedia project in VB3 in 1994 and a 25MHz 68040 running HyperCard simply blew away a 486DX66 with more of everything running VB3).
HyperCard was probably one of the most influential pieces of software ever written. It still has one direct clone ("Livecode") being sold commercially, and I believe Director (whose programming language started as an inferior clone of HyperTalk) is still being sold by Adobe.
It was also an incredibly stable programming environment. Back in an era when computers in general were as flaky as hell, you could work on it all day and experience nary a crash (and since it saved everything by default you tended not to lose anything even when it did crash).
If HyperCard had had a good network API, things would have been a lot different. The thing that steamrollered HyperCard was Visual BASIC, which could talk to all kinds of system services, and once it had COM support, could talk to just about anything on the planet. Also, everyone understood BASIC, and HyperTalk, though interesting and easy to use, was very closed and pretty much a toy.
Apple's networking APIs weren't very well designed. In fact, you couldn't even get to AppleShare volumes; there wasn't an official API to mount 'em. So I wrote one, and I was still getting occasional email about the Mount XCMD a decade later. Apple just didn't have much vision or follow-through back in the late 80s and early 90s.
I think it's difficult to point at any one, two or three things about Hypercard that caused it to slowly die. It very much died a death of a thousand cuts.
a) It was written quickly by one programmer (Bill Atkinson) who left Apple shortly after and (if rumors are believed) no one else really understood his code.
b) It never really adapted to colour displays
c) It never adapted to variable size displays
d) It had no networking so it couldn't compete with the web
e) It didn't run on Windows or Unix so it couldn't compete with the web
f) It was closed source and proprietary so it couldn't compete with the web
g) The free version of Hypercard was made read-only and lost the ability to write and edit stacks (taking away the entire point of Hypercard)
h) XCMDs were a pain to write but required for almost anything (Hypercard's API were never really extended to include new features as the Mac added them)
i) Apple themselves stopped using it for all help and tutorials on the Mac so people stopped experiencing its metaphors when they first used their Macs
j) Apple moved it to Claris (who killed everything they touched)
> The thing that steamrollered HyperCard was Visual BASIC
True from a market standpoint, I recall one of the Mac magazines had an article about jerry-rigging a database front-end in HyperCard, and it was clear it was no VB.
However, more similar in spirit to HyperCard was Lotus Notes, with its networked hypertext document databases where data storage was largely abstracted away. That was a proprietary web before there was the web. (However with an awful UI and ugly templates.)
Lotus Notes was an awful way to do anything. It allowed people with little to no programming skill to destroy the IT capabilities of small business and non-profits. If that had been backed by anyone except Lotus it would have died on the drawing board (as it should have).
That was the entire appeal of Notes/Hypercard, people could throw together a small database application and it wasn't any more difficult than creating a spreadsheet. (The big difference was that Notes apps were automatically network client-server.) I think it's rather cynical and elitist to say that something which empowered users "destroyed IT capabilities", and it's not like many of those small orgs really had IT capabilities.
But like HC, the Notes designer software was turned into an added-cost product, and after that both Notes and HC became the domain of 'IT experts' that knew how to work around the limitations of a rinky-dink platform.
This was all long ago, for most people now Notes is just a terrible email application.
You are right about the level of IT capability of most small shops, maybe I "crippled" would have been better than "destroyed".
But elitist?
Have you ever considered working on your home furnace? There are people who can do these things. The ones who THINK they can do it are Darwin Award winners.
The downside of an amateur rolling their own solution in Notes was not life threatening but it certainly wasn't smart.
Notes gave people who had no idea what they were doing the confidence to build solutions that were fine for personal use but completely unsustainable at even small office scale.
The "experts" who adopted HC and Notes were the ones who did the real damage though. These folks (and I knew a few) were just a step above the guy in the office who refilled the toner in the photocopier. They created half-working systems and then moved on. They didn't have to live with the technical debt they left in their wake.
They set unrealistic expectations for what good IT solutions should cost and left guys like me trying to clean up their mess for years.
> Sorry, I wrote a fairly long reply and HN told me my link had expired and the text was lost.
Some suggestions. First, if you've typed longer than a minute, make a backup copy of your reply, even go so far as to compose it in a separate text editor, then paste the result into HN. Second, if you encounter the dreaded "link expired" message, select all (Ctrl+A) then copy (Ctrl+C) the content of the entry window, then press browser refresh, then paste (Ctrl+V) the text you just copied. Then click "Reply."
Hypothetically, if you stumbled upon some folks arguing about Lotus Notes R3, wouldn't you assume they knew the standard windows shortcuts?
(Trick question, R3 only had ctrl-insert etc OS/2 shortcuts!)
In any case I apologize my paste-buffer foibles denied you my three paragraphs of immense wisdom regarding the good & bad of an obsolete end-user friendly distributed database system that went out of style a couple decades ago.
Every time I had to use Notes, I died a little inside.
Fortunately the company I was working for that used it had other "bad environment" issues (e.g., running awful antivirus software on dev machines, resulting in a 4X slowdown of compiles), and I ragequit to do coffee shops and bookstores for a summer.
A card is more like a screen, not necessarily an app unto itself. Each card can be linked to other cards; buttons can be used to perform transitions between them.
The card in HyperCard was not an app, but rather served multiple purposes:
First, it was a container for widgets, or, in other words, a canvas for the user interface. If the user interface would not fit in the fixed size screen of the card (it was 640x480px in the beginning and became resizable later on), it could be organized into multiple cards, each containing parts of the ui and with some navigation ui elements to browse between the cards.
Second, the card could serve as a database record. In that case the card would contain editable widgets to make a form (for example for addresses), then the card was declared to be a template (in HyperCard notation a "background") and then as many cards were created from that background as database records were required. In that case field-widgets served as database columns, cards as records and backgrounds as tables.
Third, the card (and its template-variant, the background) could contain code. Events (like a mousedown etc) were sent by the engine first to the respective widget on the card, then, when not handled, to the card itself, then to its template, then to the stack.
The HyperCard stack was the app, and a stack was a collection of cards and cards served as user interface canvas, and, very much depending on the application logic, additionally as code or data containers.
Hmm, could be. I first used HyperCard on a Mac IIfx and I cannot remember to have it used on my Mac SE/30 before. Will check - the original HyperCard manual from Atkinson is still somewhere in my shelves.
You are right! To quote the HyperTalk 2.0 reference by Dan Winkler and Scot Kamins: "Locations 0,0 through 511,341 are within a standard card's area and are therefore visible on all Macintosh displays. Points outside those boundaries might or might not be visible, depending upon the size of the display you're using." Page 872 defines the Standard card pixel size as 512 horizontal, 342 vertical.
HyperCard 2.0 allowed already to make custom sizes for stacks and my screen at that time was 640x480.
There is nothing new about the card metaphor in mobile.
The very earliest mobile web app standard, HDML (later WML), used a deck-of-cards metaphor. This was around the mid-90s.
"The fundamental building block of HDML content is the card. The user agent displays and allows the user to interact with cards of information. Logically, a user navigates through a series of HDML cards, reviews the contents of each, enters requested information, makes choices, and moves on to another or returns to a previously visited card." - HDML spec [1]
I'm not sure what Fred Wilson is getting at with "cards" today (he seems to be lamenting restricted APIs more than anything with the UI paradigm?). But in the HDML era they served a specific purpose: decks could be downloaded over high-latency networks in one shot and navigated offline, instead of waiting for each "page" to load.
Watching this demo of what Hypercard could do in 1987, it seems like there are a lot of things that would be great if they were translated into a modern context right now.
Hypercard was never too early. I remember some 'dot com' guys building a 'business management suite' in hypercard, maid fortune which evaporated after two years. Hypercard was a mere joke, like applescript.
HyperCard lives on in LiveCode - with card metaphor, HyperTalk and all. Plus color, images (with alpha channels), regex, (limited) sockets, resolution independence, XML-parsing, IDE for Mac/Win/Nix, compiles to OSX, Win, Nix, iOS, Android.
And it is OpenSource, thanks to Kickstarter (Store deployment requires commercial closed source license though).
http://livecode.com/
It is a dual license model. They offer a commercial license for those developers, who want to distribute their products as closed source (as it seems, exactly this is required by the Apple store).
In 1994, when I was in fifth grade, I used HyperCard to make a demo of a program that would allow you to fax a grocery order to a store using a modem after you checked off the items you wanted to buy. Then the store would deliver your order to you. I didn't actually know how to make use of hardware devices like modems, but it was possible to make the user interface work reasonably well on a Macintosh LC II. I was of course bummed that there was no color. (HyperCard was black and white only unless you used proprietary extensions, which could sometimes make things run very slowly.)
The author of this post seems to think that HyperCard was "before its time," but it wasn't. It defined its time, and ours. It was a huge part of what made the Mac so appealing to so many people--the ability to sculpt new technology in a custom manner. There was no comparably easy-to-use tool on the PC--Visual Basic didn't come close--and there never would be. The result was that all kinds of Mac owners developed their own stacks that solved exactly whatever problem they thought needed solving; PC owners had to hope that a software company would make something for them.
What's sad is that now our computers are so much faster than the LC II I used in fifth grade, but even if they're a hundred times faster, they're certainly not a hundred times easier to develop for. Most fifth graders, even smart ones, probably couldn't write an app in Objective-C that does today the same things a HyperCard stack did in 1994. HTML5 is the next best option, but it's still not as easy.
I worked on a prototype of a modern-era web-based HyperCard with a friend, but we stopped working on it because there was no VC interest and it wasn't clear if there would be a good business model. It's a shame, because HyperCard is one of the things that most excited me about computers when I was a kid. I still miss it.
Do you think the world has changed such that a modern HyperCard is just not something people would use? Or has the massive influx of "there's an app for that" papered-over the hole in the market?
I think it might be used, but I wonder if anyone would pay.
If Apple were run with a different mindset, they might turn XCode into HyperCard again. If Google were run with a different mindset and Android were something other than Java, you might see them build their own HyperCard-style development environment instead of relying on the abomination that is Eclipse.
> Do you think the world has changed such that a modern HyperCard is just not something people would use?
I think people would—its biggest strength is that tons of people could make their own "apps" using it, and I don't think that ability will ever become obsolete.
I think what HyperCard got right was easy structured form based editing. You could insert fields into cards and use those as a template. When inputting a field you actually edited a property of an object directly. I can't remember if fields allowed rich text editing nor programmatic access to it, so replacing Word was probably not possible. Creating complex forms and interfaces for data was certainly easier than with web browser. You could start your own solution by simply copying a suitable card. One knowledgeable user could create a powerful app tailored to company's needs and others could build on that.
In the browser the presentation, runtime and persistence layers (otherwise known as DOM, JavaScript and the web/LocalStorage) are completely separate. So, you need loads of code to bootstrap your particular version of editable web that HyperCard gave you for free, without any save buttons, serialization protocols or web server and database installs. This seems so basic thing, yet it's so hard to get there in the modern browser. Forms have in their own, peculiar data structure completely unusable for all but simple cases without a clever encoding system and JS data binding. Rich text editing is so unreliable across implementations that you need to get a library like CodeMirror to turn textarea into transformation pipeline simulating the process of input. Saddest part is that the priorities of developers are elsewhere, in building the browser into best consuming platform and a fastest tool to send little snippets of text to social network silos.
One of these days I might turn LigthTable into the past version of HyperCard, with the future build in. Since it comes with a browser, server and the JVM there should be more than enough code to replicate functionality of few megabytes of 68000 assembler ;)
Meanwhile, before Hypercard, there is a notable product: Guide by OWL in Scotland, who were approached by Tim Berners-Lee as his desired candidate for the world wide web.
Matsushita had then in an 80s Japanese shopping frenzy bought up OWL (lawyers on the same trip to Scotland went on to buy a couple of distilleries and golf courses in the same week). Japanese management of OWL then turned down Berners-Lee.
Speaking of Android, there's a neat hacker dude at GOOG that has an unreleased Android-based visual environment based on Squeak complete with animated 3D and 2D examples. It's pretty neat that basically anything in it can be changed, and other bits of code can be imported from the web. Would be a fun environment to build a game in.
I spend a lot of time creating hypercard (and supercard) applications 20 years ago, before moving on to web development. HyperCard could not adapt to different screen sizes, and html+css+js is just way more advanced. But the idea of having a development platform that everybody can learn in a few minutes is very good, and could be used inside web sites today.
Hypercard was my first real programming exposure. Going back and looking at my stacks (which I found many years after forgetting about them) was a humbling lesson in "holy crap, I can't believe I was that terrible at programming." But it definitely did get me interested, and it was really freaking powerful for something we treated like a toy.
Ugh... I worked with a guy who kept complaining that the web of today is "just Hypercard."
I did a lot of stuff with Hypercard back in the day and it's such a ridiculous statement that I ended up writing the guy off completely. He was real big on generated code and full of BS in general.
Like several other commenters, Hypercard was my first programming-like experience. I don't think I made anything more complex than a series of pages linked together with buttons. It was a great learning tool, easier than HTML where you still have to worry about embedded images and it's difficult to vertically center something.
I think the important difference between Hypercard and the web is the all-in-one approach to Hypercard. You ship a stack and it works. Single environment and not a huge number of different technologies.
I don't think VB killed Hypercard. Apple never got color, networking, etc. working and put no effort into it. Hypercard would have died with or without VB.
57 comments
[ 2.7 ms ] story [ 116 ms ] threadAlso, why “way too early”? Too early for what?
The most important feature of HyperCard, in my opinion, was that it gave end-users powerful general-purpose tools for programming and solving their own problems, in a way that was easy to get started with. Instead of being locked into someone’s existing program designed with an idealized customer’s needs, any HyperCard user could create or customize a HyperCard stack to suit their own preferences.
Unfortunately, tools requiring customer learning and mastery are very difficult to design and implement, and even more difficult to demo and sell. And so our software is designed in a very narrow and limiting fashion. The “cards” in android and facebook and twitter &c. are doing nothing to combat this, and to compare them favorably to HyperCard is in my opinion to completely (and tragically) miss the point of HyperCard.
I don’t see any particular signs of this trend toward closed systems reversing; indeed, as more people come online, and giant corporations spend billions of dollars hiring all the smartest people to work on developing software that gives them (the corporations) as much control as possible over uses of computer hardware/software, the popular machines and software systems are only getting more closed and locked down. The web itself is an open and flexible platform, but increasingly people are spending their time in a few centralized and controlled parts of it.
Remember that HyperCard was introduced in 1987 or so, the GUI/WIMP era was just getting started. The learning curve of writing a Macintosh application was incredibly steep - nearly impossible IMO - but here was a way to make a simple point-and-click app that actually did something (write to a file, do some calculations, show information, even talk out the serial port, etc) with a minimal amount of lifting. My first paid piece of software was a point-of-sale application written in HyperCard. And it worked just fine.
VB was pretty much the equivalent for Windows, once it came along.
The web is close in some respects (HTML is easy) and not in others (servers and single-page apps are not).
I suppose, in another respect, Excel is a successor for many, though it isn't a good solution for making apps of any sort.
Surprisingly, the closest I've seen has been Microsoft's Project Siena[1]. I've not used it extensively, but my 5 or 10 minute made it look like it had the dirt-simple-to-get-started appeal of HyperCard and VB.
Anyone know of other "spiritual successors" out there?
[1] http://apps.microsoft.com/windows/en-us/app/microsoft-projec...
I'm hoping Mozilla's AppMaker[3] comes to something, but I haven't been able to actually make it work yet.
I can't say that I find any of these really (yet) hitting the sweet spot that HyperCard did, but that may be my own ignorance. :-D
[1] http://livecode.com/
[2] http://alphasoftware.com/
[3] https://appmaker.mozillalabs.com/
HyperCard was probably one of the most influential pieces of software ever written. It still has one direct clone ("Livecode") being sold commercially, and I believe Director (whose programming language started as an inferior clone of HyperTalk) is still being sold by Adobe.
It was also an incredibly stable programming environment. Back in an era when computers in general were as flaky as hell, you could work on it all day and experience nary a crash (and since it saved everything by default you tended not to lose anything even when it did crash).
Apple's networking APIs weren't very well designed. In fact, you couldn't even get to AppleShare volumes; there wasn't an official API to mount 'em. So I wrote one, and I was still getting occasional email about the Mount XCMD a decade later. Apple just didn't have much vision or follow-through back in the late 80s and early 90s.
a) It was written quickly by one programmer (Bill Atkinson) who left Apple shortly after and (if rumors are believed) no one else really understood his code.
b) It never really adapted to colour displays
c) It never adapted to variable size displays
d) It had no networking so it couldn't compete with the web
e) It didn't run on Windows or Unix so it couldn't compete with the web
f) It was closed source and proprietary so it couldn't compete with the web
g) The free version of Hypercard was made read-only and lost the ability to write and edit stacks (taking away the entire point of Hypercard)
h) XCMDs were a pain to write but required for almost anything (Hypercard's API were never really extended to include new features as the Mac added them)
i) Apple themselves stopped using it for all help and tutorials on the Mac so people stopped experiencing its metaphors when they first used their Macs
j) Apple moved it to Claris (who killed everything they touched)
True from a market standpoint, I recall one of the Mac magazines had an article about jerry-rigging a database front-end in HyperCard, and it was clear it was no VB.
However, more similar in spirit to HyperCard was Lotus Notes, with its networked hypertext document databases where data storage was largely abstracted away. That was a proprietary web before there was the web. (However with an awful UI and ugly templates.)
But like HC, the Notes designer software was turned into an added-cost product, and after that both Notes and HC became the domain of 'IT experts' that knew how to work around the limitations of a rinky-dink platform.
This was all long ago, for most people now Notes is just a terrible email application.
You are right about the level of IT capability of most small shops, maybe I "crippled" would have been better than "destroyed".
But elitist?
Have you ever considered working on your home furnace? There are people who can do these things. The ones who THINK they can do it are Darwin Award winners.
The downside of an amateur rolling their own solution in Notes was not life threatening but it certainly wasn't smart.
Notes gave people who had no idea what they were doing the confidence to build solutions that were fine for personal use but completely unsustainable at even small office scale.
The "experts" who adopted HC and Notes were the ones who did the real damage though. These folks (and I knew a few) were just a step above the guy in the office who refilled the toner in the photocopier. They created half-working systems and then moved on. They didn't have to live with the technical debt they left in their wake.
They set unrealistic expectations for what good IT solutions should cost and left guys like me trying to clean up their mess for years.
In any case, Notes ended up sucking, anyone who saw what happened can toast to that.
Some suggestions. First, if you've typed longer than a minute, make a backup copy of your reply, even go so far as to compose it in a separate text editor, then paste the result into HN. Second, if you encounter the dreaded "link expired" message, select all (Ctrl+A) then copy (Ctrl+C) the content of the entry window, then press browser refresh, then paste (Ctrl+V) the text you just copied. Then click "Reply."
(Trick question, R3 only had ctrl-insert etc OS/2 shortcuts!)
In any case I apologize my paste-buffer foibles denied you my three paragraphs of immense wisdom regarding the good & bad of an obsolete end-user friendly distributed database system that went out of style a couple decades ago.
Lowest common denominator, as they say. When I encounter someone who loses his content on the HN interface, I make some simplifying assumptions. :)
Fortunately the company I was working for that used it had other "bad environment" issues (e.g., running awful antivirus software on dev machines, resulting in a 4X slowdown of compiles), and I ragequit to do coffee shops and bookstores for a summer.
Notes: both a symptom and a disease :-)
It is an IDE to build small visual Mac apps. A card is basically an app.
Less than that. Must have been 512x342; as I remember using it on 9" Mac Plus and Classic BW screens?
The very earliest mobile web app standard, HDML (later WML), used a deck-of-cards metaphor. This was around the mid-90s.
"The fundamental building block of HDML content is the card. The user agent displays and allows the user to interact with cards of information. Logically, a user navigates through a series of HDML cards, reviews the contents of each, enters requested information, makes choices, and moves on to another or returns to a previously visited card." - HDML spec [1]
I'm not sure what Fred Wilson is getting at with "cards" today (he seems to be lamenting restricted APIs more than anything with the UI paradigm?). But in the HDML era they served a specific purpose: decks could be downloaded over high-latency networks in one shot and navigated offline, instead of waiting for each "page" to load.
[1] http://en.wikipedia.org/wiki/Handheld_Device_Markup_Language
http://www.wirelessdevnet.com/columns/mar2000/mobdev05.html
That doesn't mean the author built something like Myst, though.
http://www.youtube.com/watch?v=EMFscTOazS0
http://opensource.org/osd-annotated
In 1994, when I was in fifth grade, I used HyperCard to make a demo of a program that would allow you to fax a grocery order to a store using a modem after you checked off the items you wanted to buy. Then the store would deliver your order to you. I didn't actually know how to make use of hardware devices like modems, but it was possible to make the user interface work reasonably well on a Macintosh LC II. I was of course bummed that there was no color. (HyperCard was black and white only unless you used proprietary extensions, which could sometimes make things run very slowly.)
The author of this post seems to think that HyperCard was "before its time," but it wasn't. It defined its time, and ours. It was a huge part of what made the Mac so appealing to so many people--the ability to sculpt new technology in a custom manner. There was no comparably easy-to-use tool on the PC--Visual Basic didn't come close--and there never would be. The result was that all kinds of Mac owners developed their own stacks that solved exactly whatever problem they thought needed solving; PC owners had to hope that a software company would make something for them.
What's sad is that now our computers are so much faster than the LC II I used in fifth grade, but even if they're a hundred times faster, they're certainly not a hundred times easier to develop for. Most fifth graders, even smart ones, probably couldn't write an app in Objective-C that does today the same things a HyperCard stack did in 1994. HTML5 is the next best option, but it's still not as easy.
I worked on a prototype of a modern-era web-based HyperCard with a friend, but we stopped working on it because there was no VC interest and it wasn't clear if there would be a good business model. It's a shame, because HyperCard is one of the things that most excited me about computers when I was a kid. I still miss it.
If Apple were run with a different mindset, they might turn XCode into HyperCard again. If Google were run with a different mindset and Android were something other than Java, you might see them build their own HyperCard-style development environment instead of relying on the abomination that is Eclipse.
I think people would—its biggest strength is that tons of people could make their own "apps" using it, and I don't think that ability will ever become obsolete.
In the browser the presentation, runtime and persistence layers (otherwise known as DOM, JavaScript and the web/LocalStorage) are completely separate. So, you need loads of code to bootstrap your particular version of editable web that HyperCard gave you for free, without any save buttons, serialization protocols or web server and database installs. This seems so basic thing, yet it's so hard to get there in the modern browser. Forms have in their own, peculiar data structure completely unusable for all but simple cases without a clever encoding system and JS data binding. Rich text editing is so unreliable across implementations that you need to get a library like CodeMirror to turn textarea into transformation pipeline simulating the process of input. Saddest part is that the priorities of developers are elsewhere, in building the browser into best consuming platform and a fastest tool to send little snippets of text to social network silos.
One of these days I might turn LigthTable into the past version of HyperCard, with the future build in. Since it comes with a browser, server and the JVM there should be more than enough code to replicate functionality of few megabytes of 68000 assembler ;)
Meanwhile, before Hypercard, there is a notable product: Guide by OWL in Scotland, who were approached by Tim Berners-Lee as his desired candidate for the world wide web. Matsushita had then in an 80s Japanese shopping frenzy bought up OWL (lawyers on the same trip to Scotland went on to buy a couple of distilleries and golf courses in the same week). Japanese management of OWL then turned down Berners-Lee.
A design style? Individual screens rather than a scrolling document?
I did a lot of stuff with Hypercard back in the day and it's such a ridiculous statement that I ended up writing the guy off completely. He was real big on generated code and full of BS in general.
I don't think VB killed Hypercard. Apple never got color, networking, etc. working and put no effort into it. Hypercard would have died with or without VB.
Maybe it was just bad technology or a bad implementation.
If it was really that good (it wasn't) then it would have survived. The fact that nothing of any consequence works this way today is telling.
You could only go so far with HyperCard before running into limitations and that's deadly.
It was easy for beginners but offered no advantage to experts. Once you graduated beyond HyperCard you could never go back.
Market death.