Skip to main content

Mike Sugarbaker

The eternal stumble continues

3 min read

First, I don't judge myself, or any other web developer, for getting pulled into the single-page application way of building to begin with. We all said it resulted in better developer experience, and it did, for a while; we said it resulted in faster apps, and sometimes it did, but really we just weren't checking. It felt fast to us on our fancy, up-to-date dev machines, but I don't think I was alone in thinking it just felt cooler, and that that was enough.

The ol' hipness pendulum seems to be swinging away from SPAs now, and back to building pages on the server, augmenting them with a touch of client-side code. A library called htmx is becoming popular enough for that augmentation that it's become emblematic of the approach; other brands for this new model of the old ways include "hypermedia" (a sure way to get my attention), HOWL, and the truly awful acronym HATEOAS. (Whenever I see this acronym I want to pronounce it "Hatey-O's." Have you eaten yours today?)

My personal reasons for getting on this train are pretty big: I crashed out of the React scene for a few reasons, but the biggest was complexity. The jungle of files you had to hack through by the end there, with GraphQL and Apollo and Redux - holy gods, Redux - and server-side shells for everything (I'm not talking about good code here) and JSX through build steps and all the configs. I would feel dizzy whenever I started to think about changing anything. The call of YouTube from the other tab got louder and louder. So no, when people get radical about the present state of things and say to chuck it all in history's fire, I don't judge.

But I don't have to judge - someone will do it for me. People are rolling their eyes saying "oh boy, guess it was time for a new hype cycle, guess there was too much money to be made on contrarian takes," and like, thanks for inching closer to a critique of capitalism, comrade. It's not as if there's any money to be made with complexity!

But would we have made everything much too complicated anyway, before the train managed to turn around? I think so. I think it is okay, natural, and maybe inevitable that the field of computing lurches back and forth like a giant, busted strandbeest in its search for the best way to build information systems. How could our thinking ever not have been socially influenced, to the point of herd behavior? How could we not have let the implications of machines that you write into being carry us off toward endless complexity?

This post isn't really about technology, but I will end by saying that like Ursula Le Guin did, I think hard times are coming. So efficiency in computing is going to become a lot more important than it is now, but at the same time, the severe C++ priests who demand it at every turn are also not the keepers of the one true path forward. When it comes to machines that are written into being, we will always have to think about tools, they'll never be a settled question. But we will have to learn what it really means to think about people first.

Mike Sugarbaker

And then he started writing a whimsical-ass web site again

2 min read

Because every medium that dies just becomes art, right? Although my messianic drive to save the web or something is also back in play, thanks to Robin Sloan's exhortation to fuck around and find out in 2023. It is certainly an opportune time to experiment with this platform, as existing platforms-on-the-platform begin to collapse, losing their grip on our thinking. But mostly, I just wanted to program again - but to do it in exactly the way that brings me joy. This includes using Clojure, the Lisp I find coziest, and... not only no JavaScript but precious little other client-side code. (Were we rooked?)

I think Mr. Sloan's manifesto is right that it's not time for "products" but for weird tendencies; for development processes that are lived in the open and in social context, not teaser campaigns and invite-only rollouts. But right now I'm wary of writing too much about what I'm doing, rather than doing it, which I think has contributed to other projects petering out. Plus I am 100% back on my bullshit with regard not just to independent web development but to both the weird hypertext systems I used in college, and HyperCard again for god's sake. As a middle-aged man it is naturally embarrassing to be so precisely middle-aged. So maybe I'll say more next time. (Unless you find the secret posts.)

Mike Sugarbaker

I dropped a couple of hints about this, but here's v0.1 of my Beaker app, a contemporary take on HyperCard. https://github.com/misuba/Danny

Mike Sugarbaker

Fuck you, logins!

5 min read

First, hands up if you remember Yacht Rock.

Second, when my old WordPress site got thoroughly hacked, I had the opportunity during the recovery process to reread every post I've ever made here at Gibberish. There are a few common threads, but the predominant one jumped out at me because posts I made about it as much as fourteen years ago are still current: why is it still so much damned work to do certain bits of web development that literally every site does? Why hasn't any layer of the tech infrastructure grown to handle them, or at least help?

Take as an example my number one nemesis, user authentication. Whether you're doing OAuth for logging in via Twitter and Facebook, and therefore doing intense multistep tangoes of cryptographic token trading, or just trying to let people recover their forgotten passwords without creating security holes, getting auth right is so hard that you can't even trust it to a library. Half the time, the libraries for your chosen platform are incomplete or have major security bugs; the rest of the time, their authors throw up their hands and say (...not really wrongly) that individuals should take responsibility for understanding such sensitive areas of their code.

But apps of any seriousness need to have logins... right?

Sometimes, when something is a hard problem to solve, that's because it's the wrong problem to solve. The web wasn't designed to support single-page applications, and it certainly wasn't particularly designed for what are essentially single-user applications. Canva is the example that springs to mind right now, but there are plenty of others: tools that are centered on individuals creating things, that happen to run in a web browser. Collaboration features sometimes come in, but those are only salient for a handful of apps; features that support discovering and sharing content from other users are often kind of a joke and always a bolt-on that could be entirely separate. Apart from those, these apps could have been written as native apps. Many argue that they should be.

The first single-user web app was the web itself - making a page of your own, before anyone dreamed that a service would ever do it for you. Everyone talked about how great and revolutionary "view source" was; it democratized creation, and so forth. But then things got a lot more complicated, and despite code-sharing services like CodePen and (on a lower level) StackOverflow, the web's default openness became increasingly meaningless. When so much of the meaning in the web was in its connections, why not do your publishing through connections? Why have anything of your own?

"View source" is not enough, hasn't been enough for a long time, was never really enough. The lack of a full, secure set of in-browser tools for trading and sharing code, and the resulting need for server-based services to pick up the slack, is possibly the fundamental flaw that led us to our current state of total cultural capture by a handful of huge corporations, mainly Facebook in my country. The CEO of Facebook is widely expected to run for president sometime soon.

Well, I'm working on a single-user web application, because the languages we build the web with are languages I speak, and because it's still so powerful to just turn up in the user's browser without their having to download and install anything. But I'm building it against APIs that are only available in Beaker, an experimental web browser that adds support for the peer-to-peer protocol known as Dat. Dat implies a whole new way of doing multi-user web apps, as distributed networks of compatible files on various Dat sites, brought together via JavaScript and augmented by more traditional web services. But that stuff's not even what I care about: when you're browsing a site via Dat, Beaker gives you a "fork this site" button.

If you find something you like, you can clone it, and just start making changes to your own copy. Like it's a HyperCard stack you got off a BBS in 1989.

That leaves out the importance of the web's connections - Beaker doesn't track or share these forkings, the way GitHub does - and the multi-user side of Beaker's capabilities is definitely going to be its main selling point. But I think this simple, SneakerNet-style brand of sharing could be more important than anyone guesses, perhaps even Beaker's own creators, for the simple reason that nobody has to log into anything. Sharing and collaboration can still be done, but those are separate applications, finally snapped clean. And no, Beaker isn't the first browser to do things like this - it's just modern, insightfully designed, and built on an IPFS-like base that does plenty of cool tricks. Since it's built with Webkit, you could make it your go-to web browser and scarcely notice you were doing it (It Happened To Me!). Unless you're on Windows - they're still working on that - I strongly recommend picking it up and exploring.

Mike Sugarbaker

The loneliness of the wrong-system chooser

4 min read

First it was Betamax. Our household didn’t choose it, but if it had been up to me, we would have. I was ten years old. My dad had just announced we’d be getting a VHS deck, and I remember looking up at him – not many memories of that, we were already close to the same height – and arguing that all sorts of people said that Beta had better picture quality and was more durable. I felt confused and powerless when he wouldn’t listen. Within months the available Beta rentals at Five Star started to thin; within a year they were gone. I felt kind of at peace with that, probably because I had no trouble renting anything.

Then it was the Mac. In 1986 you either had a PC and could play all the games, or had an Amiga and could play mysteriously awesome games no one’d heard of, or you had some other shit and were a loser who hung out at friends’ houses a lot. Don’t get me wrong, we had great stuff at home – we had HyperCard – but we didn’t have status. The arguments didn’t happen to us so much, because there “wasn’t” an Internet yet, but on one notable occasion a friend and I had finagled an invite to the home of a girl I had a crush on, so we could set up her stereo; some other kid who was there started talking smack about Macs for no real reason, and somehow I got sucked into fighting over it feebly with him while my undistracted friend accomplished all the useful, girl-impressing tasks. Yes, I learned to program, sort of, with HyperCard; yes, Defender of the Crown had a certain majesty in black and white when it (finally) showed up. Yes, the Mac II made things a lot better. Still, none of us Mac users of a certain age ever forgot – our superiority was not a real thing. We cooked it up ourselves; when we went out in the world, it had no currency.

Then it was the Sega Master System. I hope I don’t even need to say more. (Space Harrier, though: yeah. And Great Volleyball, out of which my brother and I wrung a truly odd amount of fun.)

Now it’s the T-Mobile G1. All I see is iPhone app announcements and developer opportunities, in the music blogs, the game blogs, the web-dev blogs. The Android platform gets some dap too – it’s evident that this time I have at least picked Sega, not 3DO – but that doesn’t help me when I have to fight with the G1’s camera again, or stumble through the Market looking for something, anything that doesn’t suck ass (illiterate app comments scrawled on the listings like they’re bad YouTube videos), or watch performance slow and slow as I get further from my last hard phone reset. Yes, it’s not that much longer until the apps will get better, but let’s be honest: they’ll never catch up. I abandoned all my noble open-source principles as soon as they failed to reward me. I want an iPhone so bad.

Last month I was at the mall finishing holiday shopping and saw that my shiny new phone was out of power again – I must have left GPS on by accident, damn my eyes – so I stopped into a T-Mobile store to borrow a cup of the ol’ juice. They kindly offered me a power adapter by the G1 display, and I soon found myself in conversation with a prospective buyer, talking the phone up. The social pressure of being in a T-Mobile retail store that was doing me a favor is only a partial explanation. I suddenly recovered all my moral dudgeon against the locked-down, anti-user iPhone and its monopolistic store full of 99-cent farting applications. I told this guy about the $400 unlocked dev version of the phone when the sales guy’s back was turned. I talked about the coming paid apps. I talked up all the promise that I wanted so much to believe in again.

In summary: OMG I HAVE SUCH TERRIBLE PROBLEMS (soon we will all be checking Twitter from the fucking bread line)

Mike Sugarbaker

Worlds and words

1 min read

No, seriously: Inform 7.

Back when I was tooling around the streets of my childhood in a tricked-out HyperCard, one of the supposed big deals about it was that HyperTalk was like English – it was going to make programming approachable for the masses, because the masses could read it. The same gets said about Ruby these days.

But no: Inform 7. Look at it. If you care about language, if you like games or fictive worlds, or if you’re a literate person with even a tiny shred of interest in coding: look at Inform 7.

Yes, I feel strongly about this. INFORM 7. Thank you.

Mike Sugarbaker

I've been working on the railroad

4 min read

I’ve taken up a new language, Ruby, for my programming efforts, along with a new web-app framework called Ruby on Rails. Why should you give a flying beaver crap? Here.

See, this whole programming thing was accidental for me. I expected to do this for a living while I really invested myself in something else. I wrote little programs in grade school and had a good time with it, always wished I had the power to make something that was really in the league of the software we bought in boxes, then kind of got absorbed into graphic design for a while. That led to HTML, then for some reason to JavaScript, and suddenly the urge was back. I wanted the power to make these web-application things. And now here I am, writing code in my free time.

I talked a bit about the whole power thing back when I eulogized HyperCard. Here’s what that’s about for me: when I undertake making something, it’s often pretty important to me that I can get the results out of it that I envision in my head when I start dreaming things up. Or to get in the ballpark, anyway. It’s probably a gifted-child thing. You know, you get used to being awesome at a certain set of things, and when you find that you aren’t, you get frustrated and quit almost immediately. That leads you to tend to stick with what you’re already good at, and if you’re not careful, you can find yourself eventually putting a lot of your time and energy – that is, your free time and energy – into something that, while fun, is maybe not as fun (or otherwise rewarding) as something else.

So, why Ruby and Ruby on Rails? Look at Rails’ front page. “With joy and less code.” I don’t remember exactly how I first stumbled across Rails, but I do know that as soon as I read those five words I wanted to believe. The same kinds of claims were made about Ruby itself: more results with less typing, a language closer to the pseudocode you write in your head. And in my limited experience so far, I’ve found those claims about Ruby to be true to some degree. For once in my computing career, I’ve found something that doesn’t tantalize me with the ability to do new things, thereby leading me to invest more of my time on more projects. Instead, I’ve found something that lets me do what I do now, but faster. And less time in front of a computer is a net gain, no question about it (although for the moment, I will likely still fill the gap with web surfing).

But is the joy there? Well, I’m still having fun. Learning Ruby is the kind (and degree) of challenge that I seem to like. Rails is not as well-documented as it could be; lots of people want to give you step-by-step examples of how to build stuff, but I haven’t seen anything that really teaches you the structure of this domain, that really tells you why things are laid out the way they are. To paraphrase Alton Brown, we’ve got plenty of sets of directions, but when you want to end up at your own endpoint, what you need is a map. I don’t see any maps of Rails out there yet. So there’s some frustration still.

But I will tell you this: Fictionsuit is go-big-or-go-home for me. If all it ever does is limp along with a few users, most of whom are my buddies, then I won’t pull the plug on it, but neither will I really continue much further with Cornucopt, or with free-time web development of any kind. When it comes to this project (yes, we will be describing the project in detail soon, likely on April 1 because the perversity of that seems apropos), I am motivated by success. Call me shallow. So if Fictionsuit doesn’t take off, and to some degree if it does, expect to hear less about coding on my blog(s), and more about how audio software is too damn expensive and complicated. And if it’s a hit, then it’ll be thanks in part to joy, and less code. One way or another, there is an exit door ahead.

Mike Sugarbaker

Stack to the future

7 min read

You don’t remember the dust-up a little while back over Apple’s announcement of a new OS X feature called Dashboard, and its similarity to the third-party product Konfabulator. I know you don’t remember this, because if you don’t read tech blogs obsessively, you never heard about it to begin with, and if you do, well, who remembers back a whole two months ago?

Two things are/were notable about this little skirmish. The first is that the highest-profile argument that Apple wasn’t ripping Konfabulator off was about how Dashboard was totally different – because it used HTML instead of Illustrator files. See? Totally different. Same look, extremely similar default widgets, similar functionality for the user, but because the interiors worked differently, charges of “ripoff” were supposedly off base. What it does is less important than how it does it: a classic example of the engineer’s mindset.

To be fair, though, that article also discusses some common ancestors of exhibits D and K alike. As far as the techie stuff, while I think the look and standard functionality of Dashboard will mean enough to the average user that Apple should acknowledge some kind of debt to Konfab, the technical differences do contribute to a potential tipping-point effect that matters.

Which leads me to the second point: Apple’s power to A) tie Konfab-like functionality deeply into the OS, and B) give it away free with the OS, gives Macs something they haven’t had for a long, long time: a way for moderately sophisticated users to create apps that look as slick as the real deal, and share them.

In other words, it gives them HyperCard.

It turns out that others with more juice than myself have pointed this out recently – and there was a small of interest a few years ago – but HyperCard has been on my mind a lot lately. I was going to write an article about it, but the boiled-down essence of that is below.

Why not write an article? Because most of the weight I felt this all had was the weight of my personal memories. Of being twelve years old and hearing about this new thing from my dad that MacUser said would let anyone create real Mac-looking programs. Of reading Vannevar Bush’s essay “As We May Think” for the first time because it was reprinted in HyperAge magazine. Of reading Danny Goodman’s Complete HyperCard Handbook from cover to cover, starting an ambitious suite of stacks to manage Dungeons and Dragons games with my brother while we were both out of school sick for two weeks, and building a sound-looping stack that I distributed on local BBSes. Of building interfaces that looked like interfaces for the first time, and things that worked.

HyperCard was when I caught the bug. Not only did it make programming easy enough for me to actually do, but it made it a creative act, just the same as using MacPaint. Or building with Legos. HyperCard was what first made me really, really want to put some kind of stamp on the world of software, besides all the other creative arenas I already had dreams of affecting. I think that was because it gave me a direct taste of perfection: I might not have been able to make a xerox of a PageMaker doc look like a magazine, or an overdubbed cassette-deck recording of a Casio sound like a rock album, but in HC, a button looked like a button and a menu looked like a menu.

Then HC 2.0 went pay, the furor died down and I forgot all about it. I was too busy toying with Director 1.0, typesetting high school newspapers, and making fonts. With all of that I think I was looking for that same taste of untouched-by-human-hands visual perfection. After HyperCard hit the wall I don’t think I did any programming again until JavaScript… but when I did, I of course found writing function calls into buttons and fields totally natural.

Roughly concurrent with the Dashboard foofaraw, I found a couple of interesting bits in the press. One dates back to last October: John Sculley, who led Apple through the late ’80s, claimed in a Cnet interview that the biggest missed opportunity on his watch was HyperCard. Given how many other opportunities Apple missed in that timeframe, that’s huge. Then HyperCard’s creator Bill Atkinson echoed the sentiment in a somewhat silly panel discussion at Macworld Boston.

All this talk about what HyperCard could have been, I thought, and we don’t even have what it was. I looked around for it – there’s still a version of SuperCard floating around out there, and there’s Runtime Revolution, and I guess those are worthwhile if you can spend $300. But if you were a curious user and had that money, wouldn’t you spend it on something you could put on your resume, like Flash? Or Visual Basic? As Paul Graham says, “Companies will pay for software, but individual hackers won’t, and it’s the hackers you need to attract.”

Being free matters. The main cause of HyperCard’s death was the leap in its price tag when it became a commercial Claris product as of version 2.0. The outcry was, well, a lot like the Movable Type licensing scandal, also of a couple months ago. (Which you also have no memory of if you have anything resembling a life.) Some folks were working on Apple to open-source HyperCard for a while, and got a final “no” recently (perhaps because someone at Apple knows the implications of Dashboard). There’s PythonCard, and other, lower-profile shots at reengineering the whole thing as free software… but they’re about as polished as you’d imagine (hint: not very).

Why do I want a new HyperCard when I have my years of JavaScript and the domain knowledge that comes with them? I don’t know. I think part of me still wants that perfection, that instant visual hit of authenticity, even though they’re saying that native GUIs are enjoying their last days. I know too much about web pages, even great ones, to believe that they’re touched by the gods. I just know they’re a shitload of work – work that I don’t even really want in my life. So why is the ghost of HyperCard still haunting me, 17 years later? What do I really have to do to get free?

I remember that when HyperCard first came out, there was some talk about end-user programming, about how people who used to just take what they could get on their computers and use it (not quite passively, but with hard limits on their power that the original hackers never dreamt of) might gain a new kind of literacy. Not much had been heard about that before – not about GUI computing, at least. Not that much has been heard about it since, either. These days, it seems that we’ve given up on trying to get that kind of power to people, in favor of figuring out whether they should have it, or need it, or even what it is. I can’t claim to have answers, but maybe if we could embody that ghost again, we might learn a thing or two.