Flex == Hypercard?

Posted on by

I like to consider myself a student of technology but I only barely remember Hypercard after looking at the screenshots on Wikipedia. The reason it came up today was because Scott forwarded me a link to a post by Andrew Wooldridge that talked about the similarities between Flex and Hypercard:

I was almost too young for Hypercard, but I know that it represented a huge leap for non-programmers. They could actually create “apps” (or “stacks”) With just a few bits of data and some drag-drop action you could create something that does something useful like organize your CD collection or generate a Star Trek quote. I believe that this quality is what is making Flex take off like it is.

Andrew really does an excellent job of both understanding and explaining some of the value propositions behind Apollo. I wish I was smart enough to really learn the ins and outs of C++, but I’m not. I come from a web development background. There are a lot of people like that, who got into programming from digging into HTML pages and figuring out how to build things for the web. One of the coolest parts of Rich Internet Applications is being able to take that knowledge and play in the deep end.

No related posts.

  • http://www.karbonized.com Simon

    I had made a similar argument a few times over the last few months on JD’s blog and others as I grew to understand Apollo a little more. Although my arguments were not that Flex == Hypercard but that Apollo == Hypercard player. Hypercard was an amazing application that carries on today in apps like MetaCard and SuperCard. However, the comparission for me comes in how Hypercard was delivered. Hypercard projects were typically called “stacks” and could essentially be compared to what we know today as a SWF. Stacks, like SWFs, had all your resources, graphics, scripts embedded but could not actually execute without a runtime app located somewhere on the system. This runtime app for Hypercard stacks was called the Hypercard Player and is nearly identical in purpose to Apollo – and it was not well liked.

    Authors of Hypercard LOATHED haing to ship a copy of the Hypercard Player with their projects because it meant their works were not really worthy of being considered an application. That’s why we all moved over to MetaCard and SuperCard, those apps (which were 90% HyperCard compatible) allowed users to create truely standalone runtimes and even assign our apps their own TYPE so that they appeared, for all intents and purposes, to be truely standalone.

    I can only assume that Andrew has the same issue with Apollo as I do, and that issue is the growing trend for people for people to refer to Apollo as a way to deliver a desktop application from your Flex project. A statement which is completely false. Apollo will NOT allow you to release an application of any kind. Apollo is just a HyperCard player that treats everyone the same whether they create amazing works or easy to forget garbage. It also introduces the possibility that one gifted hacker writes something for Apollo that will smear ALL Apollo authors just by association (I have no idea what that could be yet).

    All that said, when Apollo was announced I truely had hoped we would be able to build standalone apps (like ZINC), but instead we got a HyperCard Player.

  • http://www.web-relevant.com/blogs/cfobjective Jared Rypka-Hauer

    Simon,

    I think you have a skewed perception of things. There is an apollo runtime, yes, as there is a Javascript runtime in your browser, a Java runtim on your computer, etc., as pretty much anything that runs needs an environment in which to run. So having the HyperCard runtime built-in to your application doesn’t mean the runtime isn’t there, it’s just that instead of sharing one runtime across a bunch of applications you have the runtime built-in to the “application”. You havent’ changed anything except taken up a ton of disk space by deploying a copy of the runtime for every single application you’ve installed.

    So your argument is leaky.

    Also, Apollo allows local disk access, allows you to incorporate HTML, PDF, Flash/Flex and image/audio/video content into a single application. So it’s not fair to say “You can’t build standalone applications” with it… that’s just plain untrue. It has the ability to access the local file system, interact with remote systems, has an online/offline network state detection system, and a whole ton of other features.

    If Adobe adds things like integrated database support, the ability to launch local executables and/or access to USB devices, you’re going to see a whole new family of Apollo-based applications that will r0x0r your b0x0rs.

    Forgive the lame bit of 1337.

  • http://www.karbonized.com simon

    Hi Jared, I fully understand the issue. However, as a company looking to sell a standalone app we are interested in “embedding” the Apollo runtime app and to *not* be part of the “1 runtime for all” solution. So I stand by my claim that users can’t actually build applications because there is a major dependancy on Adobe. To us, ZINC is a true representation of a service that allows companies to create applications even though each ZINC app contains the same runtime. We don’t want to have to explain to our users what Apollo is and why they have to download it and why they have to agree to Adobe’s agreements and why they are being shown dialogs that tell them the app they are installing may not be trustworthy etc etc. From an internal cost center issue, there is a lot about Adobe and Apollo that we have to document so the user knows what’s going on.

    As for diskspace, well, Hypercard is gone and there are easily hundreds of solutions that took it’s place that embed an identical runtime. Imagine if Apple insisted on shipping a “Webkit” runtime service on OS X and then insisting that everyone tie into it rather than build Webkit into their apps. Safari, iTunes, Apollo etc would just *feel* different, and Adobe sure as hell would have issues with Webkit being open to changes to Webkit it can’t adapt for overnight.

    I admit my reaction is possibly a knee-jerk one, but I went through all this already a decade ago and updates to Hypercard Player frequently broke stacks and I can’t help but imagine that a runtime that is constantly being modified **is** going to break mission critical Apollo apps (hell, I’ve seen SWF’s break from 1 version to the next).

    I’ll say this though, as a 40yr old guy I’m starting to see why I though old people complained so much when I was younger. It’s because they lived through similar conditions and saw the result. In this case I can’t help but map my experiences with Hypercard Player onto Apollo. So I spollogize to all the young hot shots out there that just never got to know Hypercard.

  • http://www.web-relevant.com/blogs/cfobjective Jared Rypka-Hauer

    Actually I was a Hypercard developer too. I wrote several projects that were actually pretty intense and remind me of some of the software you can get today for various things, and I heavily used poweruser features and/or advanced topics.

    The only things I never got around to doing were writing any of the extensions that required knowledge of C/C++ and an authoring tool (like Borland) to be able to do… I was doing this from 10PM till 4AM as a 16 year old. Then again I wrote my first BASIC program at 9, so I “get it”.

    I just very much disagree with your conclusions. After working with HyperCard, PowerBuilder, and InstallShield at various times over the years, I’ve gained some experience myself… and since I’m 34, your 40 isn’t all that further along than I am, especially since I started in the industry at 15…

    I can understand your pessimism, but I think it’s unrealistic and unfair and I really hope you give Apollo a fair shake as it moves toward the first full release.