← Back to context

Comment by dfabulich

2 years ago

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.

> On the Mac, the alternative to Hypercard was to layout UI widgets in code, with no GUI builder at all

Don't forget ResEdit, version 1.0 released December 1985.

  • 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.

  • ResEdit edited the resource fork, not code, right?

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