I think what HyperCard got right was easy structured form based editing. You could insert fields into cards and use those as a template. When inputting a field

I think what HyperCard got right was easy structured form based editing. You could insert fields into cards and use those as a template. When inputting a field you actually edited a property of an object directly. I can't remember if fields allowed rich text editing nor programmatic access to it, so replacing Word was probably not possible. Creating complex forms and interfaces for data was certainly easier than with web browser. You could start your own solution by simply copying a suitable card. One knowledgeable user could create a powerful app tailored to company's needs and others could build on that. In the browser the presentation, runtime and persistence layers (otherwise known as DOM, JavaScript and the web/LocalStorage) are completely separate. So, you need loads of code to bootstrap your particular version of editable web that HyperCard gave you for free, without any save buttons, serialization protocols or web server and database installs. This seems so basic thing, yet it's so hard to get there in the modern browser. Forms have in their own, peculiar data structure completely unusable for all but simple cases without a clever encoding system and JS data binding. Rich text editing is so unreliable across implementations that you need to get a library like CodeMirror to turn textarea into transformation pipeline simulating the process of input. Saddest part is that the priorities of developers are elsewhere, in building the browser into best consuming platform and a fastest tool to send little snippets of text to social network silos. One of these days I might turn LigthTable into the past version of HyperCard, with the future build in. Since it comes with a browser, server and the JVM there should be more than enough code to replicate functionality of few megabytes of 68000 assembler ;)