Why Hypercard had to die (2011)

Jobs had the balls to do to Hypercard what Adobe didn't do to Flash. If Hypercard was so amazing then why did products like Supercard fail. It matched Hypercard's feature set and was able to run on Windows and Macs.

I mean, there's a lot of potential reasons, maybe because it didn't have the marketing budget of a multi-[million|billion|trillion] dollar company behind it? Maybe it tried to be too much? It's tough to say.

I commented the same sentiment a while back and someone pointed me to Construct [1] as a spiritual successor to Flash!

[1] https://www.construct.net/

Not convinced by the author's theory.

If you extend Hypercard to its logical conclusion you get either Flash or a browser running HTML locally. In any case you get a security nightmare, a lot of duplicated efforts, and the need to solve hard problems which didn't exist back then such as adapting UI to different screen sizes, accessibility, internationalization, publishing stacks on the web, etc.

Also, there were some commercial products developed with Hypercard back in the day... but these days you'd need a different development environment that supports things like versioning to entertain that possibility.

You still can build reasonable sites in the circa-2005 style - I'm actually helping one of my mentees work through doing just that, as a way to learn the basic concepts of web dev without having to fight through all the added abstraction that more modern tools involve.

(If anything, it's easier today to build a circa-2005 style site than it was in 2005! The native API has grown up enough that you don't need jQuery any more, and honestly good riddance.)

The trouble with the circa-2005 web is that it wasn't actually all that simple. You still had similar complexity to what people do today, but not very many ways to make that complexity manageable. So it was very easy to create situations in which things went wrong a lot and you couldn't really figure out why - something I think the rosy glow of nostalgia easily obscures, these days.

My early career, in hindsight, really was built on dealing with that kind of "unfixable" complexity, finding ways to reduce or replace it or at least make it more manageable - if often just in self-defense, as I typically was also largely responsible for maintaining the same stuff I built. The "capstone project" of that phase was something that we would today describe as an SPA, built in 2011 when the concept barely existed - I hadn't set out to (re)invent that wheel, nor did I even understand until a few years later that that was what I had done, but I found my way to it as the only reasonable option for coping with the essential complexity of the user interaction it expressed, and it worked really well!

That work was for one of our biggest contracts, which we were at risk of losing if I didn't find a way to fix their broken and unusable registration process. It would probably have sunk the company if I'd failed. Reworking it into an SPA avant la lettre solved the problem and saved the contract, and it was some of the hardest work I've ever done precisely because, at that time, there were no tools to help manage all that complexity. It's only gotten easier since then, as successive frameworks have built on prior work in removing accidental complexity and making essential complexity easier to express and manage.

Yes, today's tools are themselves more complicated than jQuery or whatever, sure. That's fair. You need to spend more time learning how to get the most out of them, that's also true. But the tools also do more, and largely do it in ways that are worth having.

A Bridgeport mill takes a lot more learning than a chisel, too, and you can do a lot more damage with a Bridgeport mill used wrongly. Used rightly, though, you can achieve far more with a Bridgeport mill, far more quickly and easily, than any chisel in the history of the world could ever let you do.