A huge difference between HC and the web browser: almost anyone would make a HC stack, creating on the web is largely unavailable for most folks. HC was about creating not browsing.
Let us not forget that the very first web browsers had an edit button.
The WorldWideWeb entry in Wikipedia tells us that the first browsers which did not feature editing were known as ‘passive browsers’. Passive indeed.
This is the internet we nearly had.
> The "WorldWideWeb" application for the NeXT is a prototype Hypertext browser/editor. It allows direct access to Hypertext servers, files and news.
http://info.cern.ch/hypertext/WWW/NeXT/WorldWideWeb.html
> The team created so called "passive browsers" which do not have the ability to edit because it was hard to port this feature from the NeXT system to other operating systems. Porting to the X Window System was not possible as nobody on the team had experience with the X Window System.
https://en.wikipedia.org/wiki/WorldWideWeb
Edit: Ooh, I found a screenshot of the HyperMedia Browser/Editor version 0.13.
http://www.mirrorservice.org/sites/browsers.evolt.org/browse...
> Mosaic was the first browser to explore the concept of collaborative annotation in 1993 but never passed the test state.
It’s why I recommend anyone wanting to get into web dev start with vanilla everything unless they have very specific interest in certain technologies otherwise. Web dev is eminently learnable!
Maybe I’d feel the same way going back to HyperCard later in life, but it felt like an utter black box to me at the time.
- I wrote a software half-QWERTY keyboard in ObjC because I literally couldn’t work through an injury otherwise. It crashed a lot, so I wrote a daemon to restart it when it crashed. I was probably experiencing the C parts I didn’t understand as much as the dynamic parts that were unfamiliar.
- AppleScript, which um… I was a seasoned developer by this point and I couldn’t make heads or tails of the language or its documentation. I just gave up.
Both definitely shaped my perspective on programming though!
... often needlessly and even to the author's own detriment, given the need to configure (and then maintain the configuration of) the shoddy tooling that produces the blobs--and the inability to debug them directly, of course.
Edit: I’m just waking up and missed the point about debugging, but source maps work very well. Perhaps more sites should ship them to production though!
Aside from that, it remains to be shown for most projects that the downsides are outweighed by the upsides (which are often theoretical or aspirational even, rather than actual).
As far as what remains to be shown about upsides, smaller JS packages isn’t in question. I don’t even know what resources to link which show this because it’s so fundamental that I wouldn’t know which fundamental to begin with. You’re coming from the perspective of tooling complexity being a large downside (and I agree), but it takes approximately none to minify JS. And for an even meager payload on the wire, I know my users on spotty networks or low power devices aren’t just theoretically benefiting.
In other words, it's not immaterial (and even hinting that it might be by introducing the word in the first place is a red herring).
> it takes approximately none to minify JS
Simply untrue.
> And for an even meager payload on the wire, I know my users on spotty networks or low power devices aren’t just theoretically benefiting.
There are two issues here, both of which come down to the fact that the practice of minification doesn't exist in a vacuum:
1. HTTP payload compression is already a thing
2. There's a counterintuitive product of the industry that churns out minified JS bundles, which is that if you look at what people are actually doing, pretty much all these things end up being larger--this is approximately the same as the "low-fat/low-calorie snacks lead to overeating" phenomenon, but there's a fair bit of "lost knowledge/nobody knows how to do this stuff anymore" <https://www.youtube.com/watch?v=ZSRHeXYDLko> involved, too
https://news.ycombinator.com/item?id=22283045
DonHopkins on Feb 9, 2020 | parent | context | favorite | on: HyperCard: What Could Have Been (2002)
Check out this mind-blowing thing called "LiveCard" that somebody made by combining HyperCard with MacHTTP/WebStar (a Mac web server by Chuck Shotton that supported integration with other apps via Apple Events)! It was like implementing interactive graphical CGI scripts with HyperCard, without even programming (but also allowing you to script them in HyperTalk, and publish live HyperCard databases and graphics)! Normal HyperCard stacks would even work without modification. It was far ahead of its time, and inspired me to integrate WebStar with ScriptX to generate static and dynamic HTML web sites and services!
https://news.ycombinator.com/item?id=21783227
>In fact, one of the earliest tools that enabled anyone, even children, to author and publish their own interactive dynamic web applications with graphics, text, and even forms and persistent databases, was actually based on HyperCard and the MacHTTP/WebStar web server on the Mac:
https://news.ycombinator.com/item?id=16226209
>One of the coolest early applications of server side scripting was integrating HyperCard with MacHTTP/WebStar, such that you could publish live interactive HyperCard stacks on the web! Since it was based on good old HyperCard, it was one of the first scriptable web authoring tools that normal people and even children could actually use!
MacHTTP / WebStar from StarNine by Chuck Shotton, and LiveCard HyperCard stack publisher:
CGI and AppleScript:
http://www.drdobbs.com/web-development/cgi-and-applescript/1...
>Cal discusses the Macintosh as an Internet platform, then describes how you can use the AppleScript language for writing CGI applications that run on Macintosh servers.
https://news.ycombinator.com/item?id=7865263
MacHTTP / WebStar from StarNine by Chuck Shotton! He was also VP of Engineering at Quarterdeck, another pioneering company.
https://web.archive.org/web/20110705053055/http://www.astron...
http://infomotions.com/musings/tricks/manuscript/0800-machtt...
http://tidbits.com/article/6292
>It had an AppleScript / OSA API that let you write handlers for responding to web hits in other languages that supported AppleScript.
I used it to integrate ScriptX with the web:
http://www.art.net/~hopkins/Don/lang/scriptx/scriptx-www.htm...
https://medium.com/@donhopkins/1995-apple-world-wide-develop...
The coolest thing somebody did with WebStar was to integrate it with HyperCard so you could actually publish live INTERACTIVE HyperCard stacks on the web, that you could see as images you could click on to follow links, and followed by html form elements corresponding to the text fields, radio buttons, checkboxes, drop down menus, scrolling lists, etc in the HyperCard stack that you could use in the browser to interactive with live HyperCard pages!
That was the earliest easiest way that non-programmers and even kids could both not just create graphical web pages, but publish live interactive apps on the web!
Using HyperCard as a CGI application
https://web.archive.org/web/20060205023024/http://aaa-protei...
https://web.archive.org/web/20021013161709/http://pfhyper.co...
http://www.drdobbs.com/web-development/cgi-and-applescript/1...
https://web.archive.org/web/19990208235151/http://www.royals...
What was it actually ever used for? Saving kid's lives, for one thing:
>Livecard has exceeded all expectations and allows me to serve a stack 8 years in the making and previously confined to individual hospitals running Apples. A whole Childrens Hospital and University Department of Child Health should now swing in behind me and this product will become core curriculum for our medical course. Your product will save lives starting early 1997. Well done.
- Director, Emergency Medicine, Mater Childrens Hospital
----
Also (a historical note about web browsers with editors, not about HyperCard):
NetScape Gold had a built-in WYSIWYG HTML editor window. But it was a unique selling point -- earlier and other versions of browsers didn't support that. Now browsers have official APIs to support WYSIWYG HTML editing via the "contenteditable" attribute, execCommand function, and Selection class, but you have to implement the menus and toolbars of the user interface yourself, and there are a lot of libraries for that.
https://en.wikipedia.org/wiki/Netscape#Netscape_Navigator_(v...
>Netscape also released a Gold version of Navigator 3.0 that incorporated WYSIWYG editing with drag and drop between web editor and email components.[49]
https://en.wikipedia.org/wiki/Netscape_Composer
https://www.ou.edu/class/webstudy/n4/old/N_GOLD_Editor_Windo...
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
https://html.spec.whatwg.org/multipage/interaction.html#attr...
https://w3c.github.io/editing/docs/execCommand/#execcommand%...
I admit we had a Mac early on, so I was very familiar with interactions by that point, but I found HyperCard being shockingly intuitive.