Hoping HyperWebCard Could Regain the HyperCard Glory Days

This post is a ‘call to arms’ for developers to rally round and help create the HyperWebCard environment to allow a wide audience to generate powerful database applications that were possible in the glory days of HyperCard.

I would go so far as to say that when Apple’s HyperCard appeared in 1987 it was a disruptive innovation. It should be added I was a Mac fanatic from 1984 to the release of Windows 95. HyperCard is a rapid application development (RAD) environment that ‘combines database capabilities with a graphical, flexible, user-modifiable interface’ based on the metaphor of index cards with dynamic, interactive content. Developing for Mac OS 9 was notoriously hard (whinging OSX and iOS4 developers please note). So the convenient dynamic language programming offered by built-in HyperTalk scripting and the superb GUI development environment of HyperCard was hugely attractive to programmers and non-programmers alike.

A common phrase used for HyperCard was ‘programming for the rest of us’. Sophisticated, responsive Mac apps with local databases could be built with HyperCard even though HyperTalk was interpreted. My HyperCard bible became the HyperProgramming book by George Coulouris and Harold Thimbleby.

HyperCard has a small set of integrated components:

  1. A local database of card stacks with a designated home stack; a stack is like a table in a database, and each card is equivalent to a table row or record; unlike a database a card can inherit content from a background card
  2. User interface elements such as buttons, text boxes, dropdown lists, menus and so on
  3. A object model based on stacks, cards and user interface elements placed on the cards with an associated event model
  4. A loosely typed scripting language, HyperTalk, for writing event handlers and initialisation actions tied to the object model
  5. A run-time environment with display mode (app execution) and edit mode (integrated development environment)

In the 1989-1991 timescale I used HyperCard to implement a Mac application for email called BRUITmail with HyperCard. BRUIT stood for Bond Research in User Interface Technologies and BRUITmail provided the HyperCard equivalent to Gmail, ie a graphical user interface to the command-based email service at Bond at the time. Sadly the source for BRUITmail disappeared with my Macs when I switched to Windows 95 in 1995.

So why this post? Well it started at BarCamp Brisbane V while I was stroking my newly arrived iPad during a talk where the speaker held the strong view that we should be writing HTML5 apps for iPhone/iPad not native apps. I asked myself why should we not be able to create HTML5 apps using the iPad itself? This started bells ringing (especially after a later talk by @spidie on the same!) about how easy HyperCard used to be. Surely iPad Safari could host an HTML5 app generation and execution environment?

I have finally managed to find time to put my thoughts into this post after finishing the one on iPad presentations. It should be possible to carry forward the HyperCard philosophy into these days of the web application. For the sake of discussion I refer to this new web-based rapid application development environment as HyperWebCard. It requires little thought to discover that most of the components needed by HyperWebCard are already with us:

  1. HTML5 local database storage, usually implemented with Sqlite, will be more than adequate to store stacks and cards. See Web SQL Database.
  2. jQuery and jQuery UI will provide the user interface elements together with exciting additions
  3. HTML5 DOM is a more than adequate replacement for the HyperCard object model; a card maps directly to a web page, and card contents map to a variety of HTML5 tags. See the HTML5 working draft
  4. JavaScript, the lingua franca of the web, is the natural replacement for HyperTalk
  5. The HyperWebCard run-time environment is the missing component, but surely this is just a relatively simple JavaScript library providing a visualisation of the stack/card database with the two modes of display and edit? Obviously a drag-n-drop interface for creating/editing card contents is needed and JavaScript editing/storage must be supported in the database.

This post is a plea to software develops to take up the call of HyperWebCard as I don’t have the time commitment or expertise to implement this fully. Hopefully the promise of wide applicability across all platforms not just the iPad will provide the inspiration for a team of open source HyperWebCard developers and designers. Won’t the prospect of developing apps on the iPad itself be super attractive? At the time of writing all hyperwebcard.* domains are still available. Who will be first to grab the domain and run with the project?

At this point I had a quick look on stackoverflow for more HyperCard information and found the question by Gabriel Cuvillier aptly entitled ‘Is there a web application equivalent of Hypercard?’ so I am not the only one thinking along these lines. One answer to this question was Google App Engine but this is currently definitely not a RAD.

I surely hope the developer community can recreate the glory days of HyperCard again in the new HyperWebCard project or equivalent.


About Michael Rees
Academic in IT interested in Web 2.0 and social media

3 Responses to Hoping HyperWebCard Could Regain the HyperCard Glory Days

  1. Pingback: Will Apple Respond To Google With “HyperCard For iPhone” App Tool? | Apple On The Longtail

  2. Hey,

    Interesting idea! I too have been casting around to see what can be done to simplify the task of constructing Web 2.0 apps.

    Initially I came up with this analysis of the problem:
    From RPC to Web Apps: Trends in Client-Server Systems
    http://talks.cam.ac.uk/talk/index/23888 (see the attached slides)

    further investigation has led me to look at the very interesting HOP integrated web programming language (which compiles parts of a single program for both client and server): http://hop.inria.fr/

    Your comments about HTML 5 are interesting too.

    One area that isn’t yet clear to me is how to handle the inherent potential for disconnection that mobile devices are prone to. It seems to me that any really useful development system must include the ability to migrate active objects between clients and servers and to ensure their consistency in the face of intermittent disconnections.


  3. Gabriel Cuvillier says:

    I am pleased to know that I am not the only one wondering about the next Hyper(web)Card.

    I have posted an answer to the question I asked on StackOverflow, quoting one of the inventor of Smalltalk wondering too about that.

    So this is really an open question..

%d bloggers like this: