Decker: A reincarnation of HyperCard with 1-bit graphics
beyondloom.com
beyondloom.com
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/
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.
Or, shudder, bookmark and visit from a desktop. Worth it.
That, combined with landscape mode seems to make it usable, at least on the Max models.
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.
XCMDs and XFCNs - see https://en.wikipedia.org/wiki/HyperTalk#Extending_HyperTalk
That said, it's stuck in 32-bits-land, so it must be in significant decline.
And amazingly seems to still be around!
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.
Almost anyone could get an awful lot done without knowing much about anything.
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 the time, they vetoed many things for that reason.
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.
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.
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.
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)
I do remember VB and Macromedia tools and feel like today's tools are harder to use!
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
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.
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.
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.
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.
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)