I realize there's a certain aesthetic you're going for here, and what I'm about to propose is a prime example of a slippery slope, but if you're willing to go juuuuust a little further from 1-bit graphics to 2-bit graphics, you might actually get legible photographs.
Here's a website that I love that has a similar aesthetic; every image here has at most six colors (although each image has its own color palette): https://solar.lowtechmagazine.com/
Decker's UI is primarily black-and-white, but it actually uses a customizable 16-color palette. On the community forum[0] there's some discussion about dithering and importing colored photos. Users have taken advantage of color to make some really gorgeous projects[1].
For some reason that uses about 20% of my iphone screen. Its so tiny I can’t read the text, and they’ve disabled pinch zooming so I can’t get in closer.
With respect to this project’s choices, I feel like HyperCards greatest flaw was failing to implement color when the Mac had begun to embrace it. By the time I was in high school, all the Macs in my school were color machines. But HyperCard never got true, native, built-color.
That's largely my recollection too. HyperCard was hugely popular, especially as an introduction to programming for kids, but the Quadra Macs and their kin introduced color and everyone wanted color. HyperCard never got a native update for it and it was the number one feature everyone wanted.
There was a related product (SuperCard?) that offered color. I remember trying it but it was clunky. I don't remember why, but in any case, it never took off.
There was also the matter of HyperTalk's limited API. There was a market for ... extensions, I think they were called? Some developers really dominated that space for a while. (I wonder whatever happened to J5erson? He was brilliant.)
Extensions were commonly written in Pascal and could add a lot of capability to HyperTalk, and were a great stepping-stone for people that wanted to explore programming beyond HyperCard.
Decker looks like it has a lot of the good things from HyperCard -- simplicity, portability. Kind of a shame it isn't using something closer to HyperTalk though. It really was a nice language, for what it was.
One of my early computing regrets is not focusing enough to learn HyperTalk. I was aware of it, but my attention and focus were just a little too wild to allow me to explore it properly. I made lots of stacks that were basic games, but I struggled with sticking with it long enough to finish any. I think if I’d understood what was possible with HyperTalk I could’ve gotten into organizing programming a lot sooner.
Absolutely, but HyperCard was the first place I was exposed to creating anything close to a program. I wasn't otherwise really exposed to anything related to programming until I was in my 20s.
Decker is superficially similar to HyperCard because it's primarily 1-bit, but it's different enough to require a totally new learning curve. It's quite difficult to use, requires learning "Lil" a new and unique language, and is missing many HyperCard/MacPaint affordances you might be looking for if you're expecting HyperCard.
The upshot is that HyperCard artists can't switch and continue to use HyperCard in a browser thanks to Infinite Mac.
It's not. There's isn't a single most important thing. HyperCard was an almost perfect blend of many things. That's why it's easy to spot when they're missing, like some omissions or differences in Decker.
There was a NASA laserdisc at school with loads of shuttle information. It was hooked up to a Mac running HyperCard, for navigation and displaying info.
It was pretty cool, although I think at the time I didn't appreciate it as much.
I have no idea why apple or Microsoft don't spend more effort making something like this for their OS for casual developers. VB and Python are fine, but sometimes I want something that is really tailor made for building small applications.
There's so much love for HyperCard. I missed out on this, but it seems like it empowered people to make lots of small useful utilities. It somewhat seems similar in versatility to spreadsheets, but with a different utility.
For the people that were around for this, I'm curious what kind of modern tools captures this feeling for you?
I'm slightly younger, and I feel some nostalgic love for tools like Delphi/VB and Macromedia Flash. Imperfect tools, but they sparked creativity.
Our tools got so much better, but we lost something along the way.
Flash got close, but was too complex and expensive for the average user (HyperCard was initially free, but was not bundled with the Performa line of Macs). HTML captured a lot of what HyperCard offered, but web authoring tools never got as easy and still don't offer one feature that HyperCard did--consistency of the look and feel of the UI, which can be a good thing or a bad thing, but some users liked the fact that they could create a flipbook by adding two buttons (previous, next) to a page. Some even started businesses selling educational material bundled as HyperCard stacks. The HyperTalk programming language was not great though and was one of those languages that hippies liked but the average user was as lost with it as with C or Pascal. I always had a feeling that Apple tried to control what you could do with it too much, which is the opposite of what I expect a programming language and the tooling around it to do for me. If you want to get a feel of what it was like to code in it try coding something in AppleScript, you will see what I mean.
In a nutshell: HyperCard democratised software development, making it available and accessible to the masses, for free.
In fact, many users were not even aware they were developing software. That's how easy and accessible it was.
Early web browsers, like NCSA Mosaic, enabled people to change the page - you could edit and publish HTML right there in the same tool that you were using to view it! That was the closest we got, and it was taken away from us.
HyperCard was what made me fall in love with computers and programming.
My specific "moment" was when I was a kid (probably 11 or 12 at the time) and went to see a presentation by a science professor about his work (my mom worked at the university, so I kinda had to go to this particular talk, because, well, she was my ride home)... It's hard to imagine, but presentation software like PowerPoint back then was in its infancy. Using computers to do presentations was a new thing (vs using slides developed on film or overhead projectors).
So to make his presentation, the professor created a HyperCard deck of all the slides he wanted to present. And, more importantly, he had to create little forward and back buttons on each slide to go forward or back in the presentation (again, he basically was creating a version of PowerPoint in that moment)...
But that's not what got my attention... Halfway through the presentation, one of the buttons on screen didn't work. He apologized, quickly switched to code edit mode, fixed the bug by adding a line of code, then went back to normal mode and continued his presentation. I can't remember anything else that happened other than being completelydumbfounded that you could change/edit a program's code like that whileusingthesamesoftware.
After that, I was hooked. I immediately got a book on HyperCard and learned how to recreate the miracle I saw in that presentation.
Long story long, HyperCard was PowerPoint or Keynote before slide deck software existed. And it blewmymind and launched my interest in a software career.
I recommend binge watching old computer chronicles episodes if you're interested in startups and how software gets built, thrives and dies. If this is genuinely new to you, the guy with the beard created the CP/M operating system and had a tragic early death https://en.m.wikipedia.org/wiki/Gary_Kildall . The other guy is still around but seems to have fallen off posting online in the last few years. (https://twitter.com/cheifet/status/1642364464564510720 last update)
Flash was an excellent tool for building things quickly and delivering them to a broad audience, and in many ways delivered on that promise to an even greater extent than HyperCard did in its day by being browser-based and multi-platform. The unfortunate part, though, was the vast gulf it created between Flash authors and Flash consumers. A sufficiently motivated tinkerer might be able to decompile a .swf and modify it, but this was a far cry from HyperCard's model of giving every user editing tools and making every stack a collection of parts to re-use.
Decker can export "locked" standalone decks which suppress the editors, but it's a trivial process to re-enable them. I've even seen a few games designed to "unlock" themselves once you complete them, which I think is a pretty neat reward.
There are a bunch of simple GUI builders, including GUI builders for the web, but none of them are popular, due to the sweet spot of supply and demand that Hypercard hit.
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.
Although as someone who recently developed a brand new System 7 program (for #MARCHintosh this year), I can't really recommend using ResEdit to create your dialogs. It is missing so many conveniences such as snapping that it's actually easier to lay out your dialogs in Rez files.
Right, but... the resource fork could contain code, as well as window definitions, graphics, icons, dialog boxes, menus, language translations, strings, and more.
Of course, generally you'd write source code as text and hook up your interface. Resource definitions could be written as text or laid out using a GUI tool, of which ResEdit was just one. And everything would be compiled during development. But none of that was strictly necessary.
Interestingly, early Palm OS worked exactly the same way - using resources. They took the concept and implemented their own version based on how the classic Mac system worked.
So, you could fix a bug in an app using only a resource editor without having access to the source code. I've done this on both systems!
What I miss is the ability to throw together a simple stand-alone (denormalized) relational database application in minutes. When Uncle Roy wanted something to track his LPs and search them by artist, musician, whatever, it was literally just an hour from concept to sending him a stack he could use. Same when Mom wanted a recipe database she could search by ingredient.
Could I build them a web app today? Of course! And the database would be properly 3rd normal form and all that. But it would take a many hours, it would not be stand-alone (I’d need to host it somewhere for them), and they couldn’t change it to meet their needs.
There are a lot of “toy” standalone database applications that people would like to have, but the barrier to creating them means they don’t get built. I miss the ability to throw together something with very little effort.
(Of course, modern expectations are higher too. A standalone desktop app user will also want a phone version with database sync. Now we’re talking about a much more substantial technical problem.)
I think something like Unity or Gamemaker or even Scratch fills that niche now. They are a bit more game-focused than Hypercard (which was really more of an early iteration on the web), but, I think, capture a similar feeling of empowerment and creativity among nerdy young people as Hypercard did for nerdy young me.
HyperCard was the right tool at the right time, but times change. HyperCard was super powerful with a medium learning curve, but at a time when personal computers were expensive and still an enthusiast (or school) device, users were willing to go further to do more. As adoption increases and prices decrease, there were fewer who wished to produce with the machine and more who wished to consume. HyperCard's market became unprofitable, and it went away.
People mention Flash, and that's a fair replacement, but I would argue it had a similarly steep curve, and the driver there was money - making Flash animations would make you money. Then Apple decided we were done with Flash, and here we are.
The difference between HyperCard and Flash was that HyperCard was for "computer users" who could take the demo card file stacks or whatever and customize them. Flash was for artists and animators who realized "wait I can link this to this" and suddenly they were game/multimedia developers.
Now everything is just for professionals who have already decided what they want to do.
I think PowerPoint or Keynote are better analogs for HyperCard. They all use a "deck of cards" metaphor at their core. HyperCard came on the scene when making GUI applications was still "new". There was so much low-hanging fruit. HyperCard doesn't exactly exist today because the "winners" in each category now exist as full-featured apps, like PowerPoint or Keynote for presentations.
Every "simple app builder" I saw ended up with the problem that it grew with its audience.
All their feedback came from the top 5% of their users who were always pushing its limits and clamoring for more, which ended up making the product too complicated and blocking it off for new users. See also the evolution from VB6 to VB.NET
(HyperCard's problem was that Apple was a completely dysfunctional organization. At one point it was being rewritten to be embedded into QuickTime, which could have saved it and made it work online, doing what Flash did, but alas)
Partly because its world ceased to exist. HyperCard flourished in a world where ‘all’ Macs had a 512×342 monochrome screen, and always ran full-screen. That makes drawing and laying out an UI fairly easy. You didn’t have to wonder how your colors would look in black and white, or how window size would affect the location of an UI element.
This isn't true, you're looking at Flash as a monolith when really it was a bunch of things.
To it's users it was a place many teenagers learned how to be creative with computers, building games and animations and expressing themselves in online communities which had more in common with a proto-youtube/tiktok than what you think of online web games today.
Worth pointing out Adobe didn't care about that part of Flash in the slightest and almost all their dev work post-Macromedia was building systems that community couldn't really understand or see a need to use.
What Adobe saw it as was a video player and a cross platform application tool, but to be honest it just seemed like the team in charge of the cross platform frameworks were just not talented enough to make something at all performant, air/flex UIs always just felt incredibly janky and slow, the Mac team as well just never bothered optimizing Flash on a Mac until Jobs kicked off then suddenly it ran close to Windows speed 2 months later after running literally 30%-60% Windows speed for years.
Jobs was definitely right to kill the latter of what I'm describing but unfortunately the former was collateral damage.
Apple’s App Store is filled with ugly apps that have poor performance. People will write that kind of software on anything that has enough programmability.
So it’s not that Jobs killed Flash to save users from bad taste. It was because Flash was the most widely deployed cross-platform runtime of the desktop web era (at one time on 96% of computers!) and he didn’t want Adobe or anyone else to have that kind of power anymore.
At that point it wasn't as much about control[0] but as that the runtime really was bad. I used it when they released Flash on Android and it was completely unusable. Extremely laggy, the mouse events did not map to touch events well at all, and it would out of memory crash all the time.
Replacing flash on the web with HTML5 was actually a good thing. It's just unfortunate that nobody has built any good web authoring tools for "mere mortals" to use.
[0]Remember the iPhone was launched with no App Store, and Steve Jobs just thought that everyone should write PWAs in HTML5. It took developers jailbreaking the phone, making native apps, and massive internal pressure from Apple people to make him go ahead with the store. But it was partially about control because at the time Flash was a huge source of security bugs and drive-by virus infections from just loading a flash ad. Apple would have to release emergency OS updates if they had bundled flash and they never wanted to be tied to someone else's schedule.
True, Jobs did not want Adobe to have that kind of power, but I am also glad he killed it, Flash apps were fugly, heavy, and the runtime created security problems.
But the main reason, I think, was the flash runtime was an energy hog, and at the time (up until iPhone 4 or so), that meant using a Flash website on an iPhone would shorten battery life and put the blame on Apple.
At the time, they vetoed many things for that reason.
The results were fantastic, actually. The Flash era was a great time, and lots of important and influential software came out of it.
The problem Steve Jobs had was that Flash was too resource/power hungry to run on the first iPhone, so his decision to disallow it was a defensive one.
Interestingly, you could make iPhone apps with Adobe Air (a descendent of Flash) and such apps still run today! So there have more longevity and compatibility than apps written with the official Apple tools. Pickle's Book is one such app you might like to try out.
Today's iPhones are capable of running Flash much better, and iOS is now a resource (CPU/RAM/battery) hog all by itself. So what was really achieved in the long run?
> empowered people to make lots of small useful utilities
Specifically related to this aspect, currently the closest thing I'm aware of that comes to mind is the Godot "game" engine: https://godotengine.org
While it's not an exact match for Hypercard in many aspects, three of the related areas where it is a particularly strong contender are:
* A small initial download size (<100MB) and short load/launch load time.
* Supports an "iterative"/hacky development process well--GDScript is very well suited to the initial "exploratory development stage" of "making something that works". (As GDScript itself evolves it's also getting better at being robust over time via recent additions such as gradual typing.)
* Godot's distribution/installation story is very strong--I would posit that it is light years ahead of any other ecosystem[0] in this area: Download the export templates (which are generic platform-specific binary executables) for the platforms you want to support and then export your project (which packages your project-specific code/resources for use with the executable)[1].
Currently, I would say the place where Godot is currently most lacking (somewhat surprisingly) in comparison to something like Hypercard or ("classic") Visual Basic is in relation to a lack of "drag and drop UI" creation. Godot has a quite powerful UI system (albeit at times... opaque) but the current UX for building the UI forces one to be very conscious of the scene's node tree rather than being able to just drag and drop widgets from a toolbar, or similar, onto a window.
(This UX is also an aspect that seems could be improved "relatively easily" via an Editor Plugin and maybe one day I'll get around to prototyping something for that particular rabbit hole. :) )
Obviously, it's not a perfect solution for numerous reasons I won't go into now but it's certainly my default choice for any GUI-based utilities these days--some of which I actually finish enough to "release". :D
[0] This aspect is where Python in particular falls down catastrophically.
[1] This also extends to being able to produce WASM exports for the web which opens a two-pronged distribution approach where people can initially use a web-based version of your utility and, if it's useful enough to them, they can also download an executable for local use.
One area general-purpose game engines tend to fall flat is HTML exports, which are particularly important for things like Game Jam entries or short-form art pieces that would be a hassle to download and install. Unity and Godot can both create web builds, but they tend to be dozens of megabytes, taking tens of seconds to load on a web page, and often simply crash on non-Chrome browsers. These aren't unsolvable problems, but they've consistently been a low priority, and in my opinion this is why neither engine has become a modern Flash equivalent.
Meanwhile, a baseline Decker web build weighs less than 400kb (which includes all the editing tools, if enabled), loads instantly, and will work fine on older releases of Firefox or Safari. Bitsy[1] is another example of a lightweight, simple game-making tool, and a great deal of its popularity comes from how easy it is to share and try out Bitsy games on sites like itch.io.
I guess my main point is there's tons of "room at the bottom" for lightweight development platforms.
I was around, and seeing what others did with HyperCard - in specific, my Hebrew teacher, because MacOS could do Hebrew - the thing that is lost is low friction between creation and execution. I sort of feel some of that with SwiftUI and Compose now, as long as we don't bulk the apps up with too much architecture. What they lack, though, is true drag and drop UI with arbitrary locations. It's easier to make apps for those platforms, but HyperCard felt like it could make /anything/. I mean, Myst was a HyperCard stack, so maybe it could make anything.
I got into Decker when it was mentioned last week in the discussion about HyperCard replacements.
I’m really wondering about packaging of decks. I really like Redbean and how its all in one file with Lua, SQLite, etc. and you just open up with a zip tool, put all the HTML and Lua code, rename it and its good to deploy.
I’m wondering if Decker is considering that kind of deployment to make it easier.
Everything aside, Decker is such a great name. I know that one of the hardest problems in computer science is naming, and I don’t want to call out any projects with hard working maintainers but it is refreshing not to read about another project named “X”.
I've been playing with this on and off for a couple of years. If you remember early HyperCard, this will push all your nostalgia buttons. But it's good for more than that and it's really worth taking a look at for new work.
People have different opinions, and all can be fine, I don't claim to have the definite answer.
IMHO coding is about thinking, not about the knowledge of a programming language. How do you split the problem into smaller problems? And then in even smaller ones to the level you can express solutons in code? Then what can be abstracted for future changes?
I would not provide documentation, but explain how the candidate can write some code if they tell me what they want to do, perhaps write the code sketch for them.
The language is so simple that any candidate can get the basics in a few minutes. And I'm interested in their thinking, not in their mastery of a programming language. If you're a good Python coder, I'd also hire you for writing Go.
(To understand where I came from: This is perhaps from my personal background, I have done hundreds of interviews, I wrote code in 20+ languages and was paid for in 10+ languages over the last four decades. So I value thinking and problem solving more than the correct syntax in an interview - e.g. if you write Java code, I don't care about braces and semicolons)
I agree coding is about thinking. I've worked for Apple, and written a GOTY game, but I don't know how I'd react if asked to write code in such an esoteric system. I could talk through the concepts, and you could write the code. Cheers!
Then perhaps we don't fit each other, which is fine, and isn't finding that out a good result of an inteview (that you don't want to work with me? - instead of starting and then beeing unhappy - IMHO not enough candidates evaluate the company and their future manager in interviews)
I realize there's a certain aesthetic you're going for here, and what I'm about to propose is a prime example of a slippery slope, but if you're willing to go juuuuust a little further from 1-bit graphics to 2-bit graphics, you might actually get legible photographs.
Here's a website that I love that has a similar aesthetic; every image here has at most six colors (although each image has its own color palette): https://solar.lowtechmagazine.com/
[0]: https://itch.io/t/2668739/16-color-dithered
[1]: https://crowmorbid.itch.io/desker-deckmonth
https://www.beyondloom.com/decker/tour.html
This triggered amazingly sweet memories for me, am I alone?
My only wish would be to have pinch-zooming on mobile.
That, combined with landscape mode seems to make it usable, at least on the Max models.
Or, shudder, bookmark and visit from a desktop. Worth it.
[0]: https://news.ycombinator.com/item?id=33377964
[1]: https://news.ycombinator.com/item?id=38985409
There was a related product (SuperCard?) that offered color. I remember trying it but it was clunky. I don't remember why, but in any case, it never took off.
There was also the matter of HyperTalk's limited API. There was a market for ... extensions, I think they were called? Some developers really dominated that space for a while. (I wonder whatever happened to J5erson? He was brilliant.)
Extensions were commonly written in Pascal and could add a lot of capability to HyperTalk, and were a great stepping-stone for people that wanted to explore programming beyond HyperCard.
Decker looks like it has a lot of the good things from HyperCard -- simplicity, portability. Kind of a shame it isn't using something closer to HyperTalk though. It really was a nice language, for what it was.
That said, it's stuck in 32-bits-land, so it must be in significant decline.
XCMDs and XFCNs - see https://en.wikipedia.org/wiki/HyperTalk#Extending_HyperTalk
And amazingly seems to still be around!
https://supercard.us/
The upshot is that HyperCard artists can't switch and continue to use HyperCard in a browser thanks to Infinite Mac.
So close, yet so far.
Similar, but different.
Dont think I ever saw that one, but I'm sure there were some HyperCard Stacks floating around that were mini databases of cool things with images.
Sort of an early Multimedia before the 90s Multimedia bubble :-)
And SwiftUI is about as easy as it gets!
Although using Xcode and setting yourself up in the App Store still requires some understanding of arcane settings and Xcode IDE familiarity :-)
But today there are different problems to solve, like dynamic screen sizes, which it make relatively easy.
For the people that were around for this, I'm curious what kind of modern tools captures this feeling for you?
I'm slightly younger, and I feel some nostalgic love for tools like Delphi/VB and Macromedia Flash. Imperfect tools, but they sparked creativity.
Our tools got so much better, but we lost something along the way.
I do remember VB and Macromedia tools and feel like today's tools are harder to use!
In fact, many users were not even aware they were developing software. That's how easy and accessible it was.
Early web browsers, like NCSA Mosaic, enabled people to change the page - you could edit and publish HTML right there in the same tool that you were using to view it! That was the closest we got, and it was taken away from us.
My specific "moment" was when I was a kid (probably 11 or 12 at the time) and went to see a presentation by a science professor about his work (my mom worked at the university, so I kinda had to go to this particular talk, because, well, she was my ride home)... It's hard to imagine, but presentation software like PowerPoint back then was in its infancy. Using computers to do presentations was a new thing (vs using slides developed on film or overhead projectors).
So to make his presentation, the professor created a HyperCard deck of all the slides he wanted to present. And, more importantly, he had to create little forward and back buttons on each slide to go forward or back in the presentation (again, he basically was creating a version of PowerPoint in that moment)...
But that's not what got my attention... Halfway through the presentation, one of the buttons on screen didn't work. He apologized, quickly switched to code edit mode, fixed the bug by adding a line of code, then went back to normal mode and continued his presentation. I can't remember anything else that happened other than being completely dumbfounded that you could change/edit a program's code like that while using the same software.
After that, I was hooked. I immediately got a book on HyperCard and learned how to recreate the miracle I saw in that presentation.
Long story long, HyperCard was PowerPoint or Keynote before slide deck software existed. And it blew my mind and launched my interest in a software career.
This Computer Chronicles episode from 1990 should help explain it.
They did a number of episodes on it. Here's one with laserdiscs https://youtu.be/v9o5Ld8hpug?si=hBaB8MHBdMOKQsUE&t=979
I recommend binge watching old computer chronicles episodes if you're interested in startups and how software gets built, thrives and dies. If this is genuinely new to you, the guy with the beard created the CP/M operating system and had a tragic early death https://en.m.wikipedia.org/wiki/Gary_Kildall . The other guy is still around but seems to have fallen off posting online in the last few years. (https://twitter.com/cheifet/status/1642364464564510720 last update)
Here are the episodes chronologically https://archive.org/details/computerchronicles?sort=date
Decker can export "locked" standalone decks which suppress the editors, but it's a trivial process to re-enable them. I've even seen a few games designed to "unlock" themselves once you complete them, which I think is a pretty neat reward.
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.
Don't forget ResEdit, version 1.0 released December 1985.
Of course, generally you'd write source code as text and hook up your interface. Resource definitions could be written as text or laid out using a GUI tool, of which ResEdit was just one. And everything would be compiled during development. But none of that was strictly necessary.
Interestingly, early Palm OS worked exactly the same way - using resources. They took the concept and implemented their own version based on how the classic Mac system worked.
So, you could fix a bug in an app using only a resource editor without having access to the source code. I've done this on both systems!
People mention Flash, and that's a fair replacement, but I would argue it had a similarly steep curve, and the driver there was money - making Flash animations would make you money. Then Apple decided we were done with Flash, and here we are.
Now everything is just for professionals who have already decided what they want to do.
All their feedback came from the top 5% of their users who were always pushing its limits and clamoring for more, which ended up making the product too complicated and blocking it off for new users. See also the evolution from VB6 to VB.NET
(HyperCard's problem was that Apple was a completely dysfunctional organization. At one point it was being rewritten to be embedded into QuickTime, which could have saved it and made it work online, doing what Flash did, but alas)
Almost anyone could get an awful lot done without knowing much about anything.
This isn't true, you're looking at Flash as a monolith when really it was a bunch of things.
To it's users it was a place many teenagers learned how to be creative with computers, building games and animations and expressing themselves in online communities which had more in common with a proto-youtube/tiktok than what you think of online web games today.
Worth pointing out Adobe didn't care about that part of Flash in the slightest and almost all their dev work post-Macromedia was building systems that community couldn't really understand or see a need to use.
What Adobe saw it as was a video player and a cross platform application tool, but to be honest it just seemed like the team in charge of the cross platform frameworks were just not talented enough to make something at all performant, air/flex UIs always just felt incredibly janky and slow, the Mac team as well just never bothered optimizing Flash on a Mac until Jobs kicked off then suddenly it ran close to Windows speed 2 months later after running literally 30%-60% Windows speed for years.
Jobs was definitely right to kill the latter of what I'm describing but unfortunately the former was collateral damage.
So it’s not that Jobs killed Flash to save users from bad taste. It was because Flash was the most widely deployed cross-platform runtime of the desktop web era (at one time on 96% of computers!) and he didn’t want Adobe or anyone else to have that kind of power anymore.
Replacing flash on the web with HTML5 was actually a good thing. It's just unfortunate that nobody has built any good web authoring tools for "mere mortals" to use.
[0]Remember the iPhone was launched with no App Store, and Steve Jobs just thought that everyone should write PWAs in HTML5. It took developers jailbreaking the phone, making native apps, and massive internal pressure from Apple people to make him go ahead with the store. But it was partially about control because at the time Flash was a huge source of security bugs and drive-by virus infections from just loading a flash ad. Apple would have to release emergency OS updates if they had bundled flash and they never wanted to be tied to someone else's schedule.
At the time, they vetoed many things for that reason.
The problem Steve Jobs had was that Flash was too resource/power hungry to run on the first iPhone, so his decision to disallow it was a defensive one.
Interestingly, you could make iPhone apps with Adobe Air (a descendent of Flash) and such apps still run today! So there have more longevity and compatibility than apps written with the official Apple tools. Pickle's Book is one such app you might like to try out.
Today's iPhones are capable of running Flash much better, and iOS is now a resource (CPU/RAM/battery) hog all by itself. So what was really achieved in the long run?
IIRC, at one point it accounted for something like 50% of the incoming bug reports.
Specifically related to this aspect, currently the closest thing I'm aware of that comes to mind is the Godot "game" engine: https://godotengine.org
While it's not an exact match for Hypercard in many aspects, three of the related areas where it is a particularly strong contender are:
* A small initial download size (<100MB) and short load/launch load time.
* Supports an "iterative"/hacky development process well--GDScript is very well suited to the initial "exploratory development stage" of "making something that works". (As GDScript itself evolves it's also getting better at being robust over time via recent additions such as gradual typing.)
* Godot's distribution/installation story is very strong--I would posit that it is light years ahead of any other ecosystem[0] in this area: Download the export templates (which are generic platform-specific binary executables) for the platforms you want to support and then export your project (which packages your project-specific code/resources for use with the executable)[1].
Currently, I would say the place where Godot is currently most lacking (somewhat surprisingly) in comparison to something like Hypercard or ("classic") Visual Basic is in relation to a lack of "drag and drop UI" creation. Godot has a quite powerful UI system (albeit at times... opaque) but the current UX for building the UI forces one to be very conscious of the scene's node tree rather than being able to just drag and drop widgets from a toolbar, or similar, onto a window.
(This UX is also an aspect that seems could be improved "relatively easily" via an Editor Plugin and maybe one day I'll get around to prototyping something for that particular rabbit hole. :) )
Obviously, it's not a perfect solution for numerous reasons I won't go into now but it's certainly my default choice for any GUI-based utilities these days--some of which I actually finish enough to "release". :D
[0] This aspect is where Python in particular falls down catastrophically.
[1] This also extends to being able to produce WASM exports for the web which opens a two-pronged distribution approach where people can initially use a web-based version of your utility and, if it's useful enough to them, they can also download an executable for local use.
Meanwhile, a baseline Decker web build weighs less than 400kb (which includes all the editing tools, if enabled), loads instantly, and will work fine on older releases of Firefox or Safari. Bitsy[1] is another example of a lightweight, simple game-making tool, and a great deal of its popularity comes from how easy it is to share and try out Bitsy games on sites like itch.io.
I guess my main point is there's tons of "room at the bottom" for lightweight development platforms.
[1] https://bitsy.org
https://github.com/defano/wyldcard
I’m really wondering about packaging of decks. I really like Redbean and how its all in one file with Lua, SQLite, etc. and you just open up with a zip tool, put all the HTML and Lua code, rename it and its good to deploy.
I’m wondering if Decker is considering that kind of deployment to make it easier.
https://news.ycombinator.com/item?id=40289036
[0] https://github.com/JohnEarnest/ok
Any idea how to share the HTML in realtime?
IMHO coding is about thinking, not about the knowledge of a programming language. How do you split the problem into smaller problems? And then in even smaller ones to the level you can express solutons in code? Then what can be abstracted for future changes?
I would not provide documentation, but explain how the candidate can write some code if they tell me what they want to do, perhaps write the code sketch for them.
The language is so simple that any candidate can get the basics in a few minutes. And I'm interested in their thinking, not in their mastery of a programming language. If you're a good Python coder, I'd also hire you for writing Go.
(To understand where I came from: This is perhaps from my personal background, I have done hundreds of interviews, I wrote code in 20+ languages and was paid for in 10+ languages over the last four decades. So I value thinking and problem solving more than the correct syntax in an interview - e.g. if you write Java code, I don't care about braces and semicolons)