Not exactly: https://groups.google.com/group/comp.sys.mac.hypercard/brows...
(That was 26 years ago, and HyperCard was far more accessible to non-computer scientists than the web is or has been).
It's a mistake to think that because the web is popular, that one can draw directly from it axioms regarding how technology should be implemented.
"HyperCard was far more accessible to non-computer scientists than the web is or has been."
A simple comparison of the total number of HyperCard stacks built versus the total number of Web sites built would argue otherwise. You can argue about whether HyperCard authoring is more intuitive than HTML authoring (I think it was), but as soon as the Web came along people decided for themselves which of the two they preferred to hack on.
Any computer was not cheap in 1987, much less one that sported a usable GUI environment that could run something on par with HyperCard. That had nothing to do with HyperCard.
> A simple comparison of the total number of HyperCard stacks built versus the total number of Web sites built would argue otherwise.
There were far, far fewer people actually running computers, much less collaborating on the internet, 26 years ago.
> You can argue about whether HyperCard authoring is more intuitive than HTML authoring (I think it was), but as soon as the Web came along people decided for themselves which of the two they preferred to hack on.
When the web came along, Apple had already made HyperCard inaccessible by charging a significant amount of money for the authoring tools, rather than shipping it with each Mac.
Even still, people were producing "My Favorite Links" and home pages, not apps.
True, but (1) PCs were significantly cheaper than Macs, and (2) many, many more people already had PCs on their desks than had Macs. So unless you were one of the few who already had a Mac, getting started with HyperCard meant plunking down money for new hardware.
"There were far, far fewer people actually running computers, much less collaborating on the internet, 26 years ago."
Again true, but irrelevant. We're talking about contemporary mindshare, and starting in the early '90s HyperCard and the Web were competing against each other in real time. HyperCard had a long head start and yet even by 1995 (the year Netscape 1.0 broke out) it was clear the Web had all the momentum.
"Even still, people were producing "My Favorite Links" and home pages, not apps."
And the buzzed-about HyperCard stacks were always more like presentations than apps. So?
I'm not trying to run down HyperCard here, it was a brilliant, revolutionary product. But I just can't fathom how anyone could think it more accessible to newbies than the Web was at the same time. And the Web has only gotten more accessible in the years since.
> True, but (1) PCs were significantly cheaper than Macs, and (2) many, many more people already had PCs on their desks than had Macs. So unless you were one of the few who already had a Mac, getting started with HyperCard meant plunking down money for new hardware.
In 1987, the web wasn't invented yet, and Windows 1.0 was the best the PC had to offer. This had some interesting results in the marketplace, but doesn't really explain much other than the fact that there's value in cross-platform implementations.
Apple wasn't interested in making HyperCard/Claris cross-platform, so they didn't.
> Again true, but irrelevant. We're talking about contemporary mindshare, and starting in the early '90s HyperCard and the Web were competing against each other in real time. HyperCard had a long head start and yet even by 1995 (the year Netscape 1.0 broke out) it was clear the Web had all the momentum.
I remember that time quite clearly, and until the mid-to-late 90s, HyperCard and the web were in COMPLETELY different spaces.
People were building complex enterprise database-backed applications on top of HyperCard; meanwhile, on the web, we had static pages, and post-1993, if you were lucky, CGI-based e-mail forms and visit counters.
Even with the introduction of JavaScript in 1995, we didn't see much other than rotating banners in the status bar until much later. Simply put, the web was not being used for applications at that time.
By the time the web did "break out" in 1995, Apple had moved HyperCard to their Claris subsidiary, stopped producing updates, and started charging for the authoring tools (a funny thing to do, given that HyperCard had always been Smalltalk-like in combining authoring and consumption).
Essentially, the lack of updates and unreasonable pricing led to its demise. These are market forces, not technological ones, and do nothing to disprove that 26 years ago, there were tools accessible to normal humans.
I first went online in 1991 (so that my friends and I could keep playing Shadowrun all winter) and got into the web in 1993 (I was 16, pictures were a big deal). Back then, there was this sense that the web could be really great, but I don't think many people grasped what it could be used for. Search technology wasn't great, so starting on someone's home page and surfing was how most people explored the web.
The first thing I ever built on the web was a homepage for a Shadowrun character. It was basically walls of text in which I talked about his complete history, and a whole lot of links to gaming resources. Needless to say, I got all the girls in high school....:)
Thanks for taking me down memory lane - sometimes I forget just how incredibly excited I was when I first discovered the online world. Without a hint of hyperbole, I wouldn't be who I am (in fact, I might not even be alive) if not for the web. :)
Really? Thirty years ago many of the most popular home computers booted directly into a BASIC interpreter.
Programming hasn't become more or less accessible with the web. You just write JavaScript instead of BASIC nowadays.
The landscape is littered with C frameworks, C++ frameworks, Java frameworks, .NET frameworks, and so on for every other language, that serves to abstract so much from the basics that it becomes so difficult to do basic things the <insert framework here>-way. The problem is that instead of being ancillary and supporting productivity, they are opinionated and try to do EVERYTHING for you, which just makes them really crappy DSLs.
This just happens to occur on the web a lot more because what we have to work with is inconsistent, sometimes poorly implemented, and confusing as hell to new players. So everyone and their dog tries to "solve" developing web applications by making you believe the DOM doesn't exist (jQuery, MooTools, etc). Some think HTML and CSS are too complicated and try to get you to believe those don't exist either (Ext, etc). Then some want you to forget that Javascript ever existed, or to make Javascript less Javascripty (GWT, Prototype/MooTools, etc).
The end result is a lot of opinionated dogma that rarely actually help us get things done (or get in the way more than help). If you pick a big framework, it's usually very good at whatever it was designed to build. But if you want to build something even slightly outside of that set, it becomes a massive cluster-fuck of WTF-inducing horrifying debugging and pain. Only the lightweight libraries that are massive value adds without enforcing a specific dogma on the user have been extremely successful.
The problem is that everyone is too opinionated and makes their software try to do your job for you. It's not really about the ease of use, it's about the ease of integration, extension, and whether they make our jobs easier or nightmarish. Yes, the web foundation is far from perfect, or even great, but most of these frameworks are far, far worse, since they massively and arbitrarily limit what you can do for the sake of some vision of simplicity.
The same problem exists in the native world. There is no consistent presentation layer that rivals the web, and even it isn't fully consistent (all browsers are different, and even the same browser on different platforms can behave differently). But it's a far cry from anything else.
As an aside, since JS isn't assembly, using it as a compile target to build applications foregoes a lot of the other fundamental technologies in a web browser. Sure, you might be able to compile <insert language here> into JS and have an application run in the browser, but that necessarily implies you're doing things like building the DOM manually, and sites like this tend to have significant performance issues. If you want it to work well, the best way currently is by using HTML/CSS/JS and by not letting a gigantic framework pretend that those things don't exist.
These people don't have computer science degrees, so they spend a lot of time reinventing wheels. But lots of it works well enough despite all that, and as time passes, they learn and get better.
The messiness is a good sign, not a bad one. Thirty years ago these people would have had no options other than to be passive consumers of software other people made. Now they're making things for themselves! And some of what they make is good enough to help other people with their problems, too. That's a positive development, even if the things they make aren't always pretty.