Friday, June 4th, 2021
Thursday, April 29th, 2021
Collection of common CSS mistakes, and how to fix them.
I like the way this is organised: it’s like “code smells” for CSS. Some of them will probably be familiar, in which case, you can dive in and find out what’s going on.
Sunday, April 18th, 2021
New technologies don’t have power; for that they’d need a community, documentation, and a thriving ecosystem of ancillary technology. What they have is potential, which resonates with the potential within the startup and the early adopter; perhaps they can all, over time, grow together.
This means startups don’t adopt new technologies despite their immaturity, they adopt them because of that immaturity. This drives a constant churn of novelty and obsolescence, which amplifies the importance of a technologist’s skillset, which drives startups to adopt new technologies.
This flywheel has been spinning for a long time, and won’t stop simply because I’ve pointed out that we’re conflating novelty with technological advancement. Hopefully we can slow it down, though, because I believe it’s causing real harm.
Tuesday, April 6th, 2021
It’s heavy on computer science, but this is a fascinating endeavour. It’s a work-in-progress book that not only describes how browsers work, but invites you to code along too. At the end, you get a minimum viable web browser (and more knowledge than you ever wanted about how browsers work).
As a black box, the browser is either magical or frustrating (depending on whether it is working correctly or not!). But that also make a browser a pretty unusual piece of software, with unique challenges, interesting algorithms, and clever optimizations. Browsers are worth studying for the pure pleasure of it.
See how the sausage is made and make your own sausage!
Wednesday, March 31st, 2021
Languages, platforms, and systems that break from the norms of computing.
Friday, March 12th, 2021
I never knew that the way I add other people’s code to my projects is called “vendoring.” I thought it was just copying and pasting.
Monday, December 21st, 2020
Web Audio API weirdness on iOS
I told you about how I’m using the Web Audio API on The Session to generate synthesised audio of each tune setting. I also said:
Except for some weirdness on iOS that I had to fix.
Here’s that weirdness…
Let me start by saying that this isn’t anything to do with requiring a user interaction (the Web Audio API insists on some kind of user interaction to prevent developers from having auto-playing sound on websites). All of my code related to the Web Audio API is inside a
click event handler. This is a different kind of weirdness.
First of all, I noticed that if you pressed play on the audio player when your iOS device is on mute, then you don’t hear any audio. Seems logical, right? Except if using the same device, still set to mute, you press play on a
audio element, the sound plays just fine. You can confirm this by going to Huffduffer and pressing play on any of the
audio elements there, even when your iOS device is set on mute.
So it seems that iOS has different criteria for the Web Audio API than it does for
video. Except it isn’t quite that straightforward.
On some pages of The Session, as well as the audio player for tunes (using the Web Audio API) there are also embedded YouTube videos (using the
video element). Press play on the audio player; no sound. Press play on the YouTube video; you get sound. Now go back to the audio player and suddenly you do get sound!
It’s almost like playing a
audio element “kicks” the browser into realising it should be playing the sound from the Web Audio API too.
This was happening on iOS devices set to mute, but I was also getting reports of it happening on devices with the sound on. But it’s that annoyingly intermittent kind of bug that’s really hard to reproduce consistently. Sometimes the sound doesn’t play. Sometimes it does.
Following my theory that the browser needs a “kick” to get into the right frame of mind for the Web Audio API, I resorted to a messy little hack.
var audio = new Audio('1-second-of-silence.mp3'); audio.play();
I’m not proud of that. It’s so hacky that I’ve even wrapped the code in some user-agent sniffing on the server, and I never do user-agent sniffing!
Still, if you ever find yourself getting weird but inconsistent behaviour on iOS using the Web Audio API, this nasty little hack could help.
Tuesday, November 10th, 2020
Sunday, September 27th, 2020
The title says it all, really. This is another great piece of writing from Paul Ford.
I’ve noticed that when software lets nonprogrammers do programmer things, it makes the programmers nervous. Suddenly they stop smiling indulgently and start talking about what “real programming” is. This has been the history of the World Wide Web, for example. Go ahead and tweet “HTML is real programming,” and watch programmers show up in your mentions to go, “As if.” Except when you write a web page in HTML, you are creating a data model that will be interpreted by the browser. This is what programming is.
Friday, July 31st, 2020
I probably need to upgrade the Huffduffer server but Maciej nails why that’s an intimidating prospect:
Doing this on a live system is like performing kidney transplants on a playing mariachi band. The best case is that no one notices a change in the music; you chloroform the players one at a time and try to keep a steady hand while the band plays on. The worst case scenario is that the music stops and there is no way to unfix what you broke, just an angry mob. It is very scary.
Saturday, July 11th, 2020
I decided to implement almost all of the UI by just adding & removing CSS classes, and using CSS transitions if I want to animate a transition.
Yup. It’s remarkable how much can be accomplished with that one DOM scripting pattern.
I was pretty surprised by how much I could get done with just plain JS. I ended up writing about 50 lines of JS to do everything I wanted to do.
Monday, June 22nd, 2020
But if I were going to bet on a web technology, it’s HTML. Always bet on HTML.
Monday, June 8th, 2020
Nice and straightforward. Locally:
git branch -m master main
git push -u origin main
Then on the server:
git branch -m master main
git branch -u origin/main
On github.com, go into the repo’s settings and update the default branch.
Thanks for this, Scott!
P.S. Don’t read the comments.
Saturday, May 30th, 2020
This is clever—using custom properties to enable if/else logic in CSS.
Tuesday, May 26th, 2020
Note that John is a computer scientist that knows a fair bit about the Web: He had Node & npm installed, he knew what MIME types are, he could start a localhost when needed. What hope do actual novices have?
I think it’s even worse than that. Not only are potential new devs being put off ever getting started, I know plenty of devs with experience who have pushed out by the overwhelming and needless complexity of the modern web’s toolchain. It’s like a constant gaslighting where any expression of unease is summarily dismissed as being the whinings of “the old guard” who just won’t get with the programme.
John gives up. Concludes never to touch Node, npm, or ES6 modules with a barge pole.
(Just watch as Lea’s post gets written off as an edge case.)
Sunday, May 17th, 2020
This is a very clear description of the differences between libraries and frameworks, along with the strengths and weaknesses of both.
A library is a set of building blocks that may share a common theme or work well together, but are largely independent.
A framework is a context in which someone writes their own code.
I very much agree with the conclusion:
If your framework can be a library without losing much, it probably should be.
Wednesday, May 13th, 2020
Ultimately, however, our decision to switch was driven by our difficulty in hiring new talent for $UNREMARKABLE_LANGUAGE, despite it being taught in dozens of universities across the United States. Our blog posts on $PRACTICAL_OPEN_SOURCE_FRAMEWORK seemed to get fewer upvotes when posted on Reddit as well, cementing our conviction that our technology stack was now legacy code.
This is all just mwah—chef’s kiss!—perfect:
Every metric that matters to us has increased substantially from the rewrite, and we even identified some that were no longer relevant to us, such as number of bugs, user frustration, and maintenance cost.
Monday, May 11th, 2020
Thursday, April 9th, 2020
On Monday, I linked to Tom’s latest video. It uses a clever trick whereby the title of the video is updated to match the number of views the video has had. But there’s a lot more to the video than that. Stick around and you’ll be treated to a meditation on the changing nature of APIs, from a shared open lake to a closed commercial drybed.
It reminds me of (other) Tom’s post from a couple of year’s ago called Pouring one out for the Boxmakers, wherein he talks about Twitter’s crackdown on fun bots:
Web 2.0 really, truly, is over. The public APIs, feeds to be consumed in a platform of your choice, services that had value beyond their own walls, mashups that merged content and services into new things… have all been replaced with heavyweight websites to ensure a consistent, single experience, no out-of-context content, and maximising the views of advertising. That’s it: back to single-serving websites for single-serving use cases.
A shame. A thing I had always loved about the internet was its juxtapositions, the way it supported so many use-cases all at once. At its heart, a fundamental one: it was a medium which you could both read and write to. From that flow others: it’s not only work and play that coexisted on it, but the real and the fictional; the useful and the useless; the human and the machine.
Both Toms echo the sentiment in Anil’s The Web We Lost, written back in 2012:
Five years ago, if you wanted to show content from one site or app on your own site or app, you could use a simple, documented format to do so, without requiring a business-development deal or contractual agreement between the sites. Thus, user experiences weren’t subject to the vagaries of the political battles between different companies, but instead were consistently based on the extensible architecture of the web itself.
I know, I know. We’re a bunch of old men shouting at The Cloud. But really, Anil is right:
This isn’t our web today. We’ve lost key features that we used to rely on, and worse, we’ve abandoned core values that used to be fundamental to the web world. To the credit of today’s social networks, they’ve brought in hundreds of millions of new participants to these networks, and they’ve certainly made a small number of people rich.
But they haven’t shown the web itself the respect and care it deserves, as a medium which has enabled them to succeed. And they’ve now narrowed the possibilites of the web for an entire generation of users who don’t realize how much more innovative and meaningful their experience could be.
In his video, Tom mentions Yahoo Pipes as an example of a service that has been shut down for commercial and idealogical reasons. In many ways, it was the epitome of what Anil was talking about—a sort of meta-API that allowed you to connect different services together. Kinda like IFTTT but with a visual interface that made it as empowering as something like the Scratch programming language.
There are services today that provide some of that functionality, but they’re more developer-focused. Trys pointed me to Pipedream, which looks good but you need to know how to write Node.js code and import npm packages. I’m sure it’s great if you’re into serverless Jamstack lambda thingamybobs but I don’t think it’s going to unlock the potential for non-coders to create cool stuff.
Cables is a tool for creating beautiful interactive content.
It isn’t about making mashups, but it does look something that non-coders could potentially use to make something that looks cool. It reminds me a bit of Bret Victor and his classic talk on Inventing On Principle—always worth revisting!