It's Eric Woodward (dotcom)

Ever since the early days of JavaScript (remember document.layers?), I’ve been interested in building web applications, from the complex to the trivial. In that time, I’ve built more signature generators, magic 8-balls, and die rollers than I care to mention. But, apart from the tools at Planar Vagabond, most of these #WebToys are lost to time (or sitting on some 3/4 full hard drive waiting to be rediscovered).

Until now!

I’ve decided to start archiving them here, in my lightly-tended digital garden, under the heading of WebToys (a moniker chosen based on their dubious utility). And the first #WebToy is a project I’ve had in mind for over 25 years, but that I’ve just finally put the 4-ish hours in to complete: .

The BPS (Bill Paxton Soundboard)

Back when I was in college (circa 1997), a friend of mine and I would often discuss ideas for “fun” (and typically useless) computer programs. One night, one of us suggested a virtual See-and-Say themed around quotes from the great character actor, the late Bill Paxton. Of course, writing such a program wasn’t worth the effort (especially circa 1997), so we just kind of chuckled and forgot about it.

Fast-forward to 2024: the company I work for has a “UI Developers Guild” (for those interested in bettering their development skills), and they recently started running coding challenges, both to drive engagement with the guild and to give the coders a chance to do something non-work related. This particular challenge had 3 simple rules (copied verbatim below):

1. Play some kind of music / sound
2. Be viewable
3. Don’t work over 4hrs!!!

After briefly contemplating what to offer as my entry for the challenge, the idea from college bubbled back to the front of my brain, and I thought, “this is my chance!”

The rest, as they say, is history.

Work Breakdown

• One hour thinking through the concept and writing the rough draft player.js and main.js modules;
• One hour to turn draft into MVP, addressing layout and audio issues;
• One hour to add images and expand the audio selection; and
• One final hour^[1] to add mobile support and some light documentation.

Now, this is obviously not the first Bill Paxton soundboard on the #interwebs, nor is it the most comprehensive. But, unlike the ones in the App or Play stores, mine doesn’t require any scary permissions, and won’t track you relentlessly. And, unlike other web-based soundboards, mine has no advertising, and… won’t track you relentlessly. So maybe mine is better, at least in some ways. 😄

Plus, releasing it here doubles as my entry into the aforementioned coding challenge, so win-win!

With a few more hours work, I’d probably turn it into a PWA and add full offline support (caching the sounds and images in localstorage), or maybe disable the buttons until the previous sound is done, but… that’s for another day.

I suspect I’ll wind up creating (or finding) other similar small #WebToys in the future, and when I do, I’ll add them here. In the meantime, I’m open to suggestions: what other tiny, useless programs does the world need more of?

Way back in 1997, I released my first (and, so far, only) computer game, Camp Happy Island Massacre (hereafter referred to as #CHIM), a comedy-horror text game for the DOS operating system. Originally written while I was still in college, the game is about a cursed summer camp and the 3 surviving counselors who try to stop a horrific force before it claims them. I put it out for free (more-or-less) on the internet of 1997, and though it was never a huge success, I’ve always been proud of it.

Fast forward to 2018: although I’ve known about the Internet Archive’s MS-DOS Software Library for some time, I’d never really thought about the specifics of how it works until I read an article which talked about the Em-DOSBox project. Em-DOSBox is a port of DOSBox emulator which runs in the browser via the Emscripten JavaScript library. As I was reading the article, a thought struck me: could I get CHIM running in the browser?

I decided it was at least worth a shot, so I began with step 1, building Emscripten from source. That went off without an issue, so I moved on to the next step, building the DOSBox JS files, and that’s where I ran into my first snag: the only way I was able to get it to build was by disabling the “emterpreter sync” function (emconfigure --disable-sync ./configure). It complained about the lack of empterpreter sync, but it built, and that lead me to the next step, packaging the dosbox.js file for use in a browser via the ./packager.py command. Even though this seemed to work great, there was obviously something wrong with my resulting files, as the JavaScript engine in my browser kept throwing an error (“missing function in Module”). After toying around with it for a while, I found that, if I used ./repackager.py (the Emscripten-less version of the packager) to package my files, I could get an empty DOSBox window to come up, but it still wouldn’t load the actual EXE.

By this point, I was flummoxed, and was about to give up. And that’s when I found the answer: js-dos!

After 30 minutes with this tutorial (and some source viewing on a couple of js-dos game pages), I was able to get CHIM working.

But my work wasn’t finished yet. Even though I’d kept nearly all of the files for CHIM for the last 21 years (with the exception of the game’s original C++ source files, which were lost in a hard drive crash shortly after it was released), I hadn’t really messed with them much in the last decade, so there was some cleaning up to be done. I updated some of the questions (and answers) in the FAQ, replaced the license, and generally tried to clean up the supporting text files. And that’s when I ran into one last unexpected issue: text encoding.

You see, I had forgotten that, when I first wrote the game and the supporting files, I had used some primitive ANSI graphic characters in an attempt to enhance the look of it. And now, when I tried to view those files on my Linux laptop, those graphics came out… weird.

The fix was to convert the files from the “IBM-862” format to the modern UTF-8 format:

> iconv -f IBM862 -t UTF8 INTRO.TXT -o INTRO.UTF.TXT

This allowed me to edit the files in Mousepad (and serve them up with Nginx), while still keeping the graphics intact. Finally, I added the Unicode Byte Order Mark, which makes it display correctly in the browser, even when served from a file:// URL (you can add the BOM via Mousepad, under “Document -> Write Unicode BOM”).

So, if you’d like to try the game out, check it out here, and good luck - you’re gonna need it!

Tero Parviainen has a nice piece about Overcoming Javascript Framework Fatigue, but don’t let the title fool you - much of the advice can be applied those who work (and live) in most any rapidly-evolving field. Plus, it contains one of the best quotes from Rich Hickey (the creator of Clojure) about what skills a developer really needs to have (and those skills have nothing to do with preferred language or framework):

Programming mastery has little to do with languages, paradigms, platforms, building blocks, open source, conferences etc. These things change all the time and are not fundamental. Knowledge acquisition skills allow you to grok them as needed. I’d take a developer (or even non-developer!) with deep knowledge acquisition and problem solving skills over a programmer with a smorgasbord of shallow experiences any day.

Via JavaScript Weekly

Baldur Bjarnason thinks he knows why RSS and Atom have come back into vogue, powering both Apple News and Facebook Instant Articles after years of disuse:

There’s one thing that’s very different this time around for RSS and Atom and it’s the reason why this time it might be different. Back then ‘just the HTML, no CSS, JS, or Flash’ meant nothing more than rich text with images.

Now, ‘just the HTML’ means rich text, video, audio, SVG, and more. While at the same time ‘HTML with CSS and JS’ has come to mean slow loading websites full of annoying ads and broken functionality (i.e. scroll-jacking).

It’s that last point (again) that’s the most important, IMHO, but it’s also the one that seems to be falling on deaf ears.

The great Remy Sharp (@rem) wrote a piece about what it means to be a web developer, as opposed to an engineer, and the difference a title does (or doesn’t) make. In the end, he settles on the title of “web developer”:

I don’t know why I thought it was uncool to be a “web developer”. Perhaps because it’s utterly vague.

What “web developer” does mean to me though, is this:

Someone who writes code for browsers. Likely from the school of view source, is comfortable with drop-in libraries, understands standards and best practice techniques. But mostly, a tinkerer.

I like his definition (especially the part about tinkering), but I think that it’s incomplete, being merely functional.

I suggest that the term “web developer”, by its definition, carries a philosophical imperative: to develop the web. That is to say, a web developer should visualize how they would like the web to be (as a whole), and build their own projects in a way that reflects that vision.

This is something I’ve tried to do myself, both in my professional and personal projects (albeit with varying degrees of success). To me, being a web developer means that I should use responsive design principles, ensure accessibility, and follow the standards wherever possible. It also means using only open source software, be it in the server stack, the service layer, or even as a client browser.

As a web developer, I want to participate in a decentralized web, and would rather use a self-hosted, fully-open social media platform than a corporate data silo. Likewise, I support the use of standards-based communication protocols (IRC, e-mail, etc.) over proprietary solutions. Finally, as a web developer, I believe in a more secure web, and support initiatives like HTTPS everywhere.

All in all, I think this definition adds an air of legitimacy to the “web developer” title. As I noted in a comment: based on this criteria, one could say that Sir Tim Berners-Lee is the definitive Web Developer (a title he himself uses, as Remy pointed out), and that’s not bad company to be in. In fact, I think I’m going to go get some business cards with “Web Developer” on them.