This is clever—using custom properties to enable if/else logic in CSS.
Saturday, May 30th, 2020
Tuesday, May 26th, 2020
This is a lovely little interview with Cassie—it really is an honour and a privilege to work with her!
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.)
Tuesday, May 19th, 2020
Five moments in the lifecycle of a design system. They grow up so fast!
- Formation of the Design System Team
- First Page Shipped
- Consumable Outside the Main Product
- First Non-System Team Consumer
- First Breaking Change
Dave makes the observation that design systems are less like open source software and more like enterprise software—software you didn’t choose to use:
Often, in my experience, for an internal Design System to have widespread adoption it requires a literal executive mandate from the top floor of the building.
Also: apparently design systems have achieved personhood now and we’re capitalising them as proper names. First name Design, last name System.
“Please, call me Design. Mr. System was my father.”
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.
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!
Monday, April 6th, 2020
Tom’s videos are so good! Did you see his excellent in-depth piece on copyright?
This one is all about APIs and the golden age of Web 2.0 when we were free to create mashups.
It pairs nicely with a piece by another Tom from a couple of years back on the joy of Twitterbots.
Monday, March 30th, 2020
This is a great way to organise code snippets—listed by use case, and searchable too!
Next time you’re stuck on some DOM scripting, before reaching for a framework or library, check here first.
I love this little to-do app! Every time you tick something off your list, something grows in your virtual terrarium. Lovely!
Tuesday, March 17th, 2020
I’m constantly forgetting the difference between the
async attribute and the
defer attribute on
script elements—this is a handy explanation.
Thursday, March 12th, 2020
Wednesday, March 11th, 2020
A curl in every port
A few years back, Zach Bloom wrote The History of the URL: Path, Fragment, Query, and Auth. He recently expanded on it and republished it on the Cloudflare blog as The History of the URL. It’s well worth the time to read the whole thing. It’s packed full of fascinating tidbits.
In the section on ports, Zach says:
The timeline of Gopher and HTTP can be evidenced by their default port numbers. Gopher is 70, HTTP 80. The HTTP port was assigned (likely by Jon Postel at the IANA) at the request of Tim Berners-Lee sometime between 1990 and 1992.
Kimberly was spelunking down the original source code, when she came across this line in the
#define TCP_PORT 80 /* Allocated to http by Jon Postel/ISI 24-Jan-92 */
We showed this to Jean-François Groff, who worked on the original web technologies like
libwww, the forerunner to
libcurl. He remembers that day. It felt like they had “made it”, receiving the official blessing of Jon Postel (in the same RFC, incidentally, that gave port 70 to Gopher).
Then he told us something interesting about the next line of code:
#define OLD_TCP_PORT 2784 /* Try the old one if no answer on 80 */
Port 2784? That seems like an odd choice. Most of us would choose something easy to remember.
Well, it turns out that 2784 is easy to remember if you’re Tim Berners-Lee.
Those were the last four digits of his parents’ phone number.
Sunday, March 8th, 2020
“Serverless”, is a buzzword. We can’t seem to agree on what it actaully means, so it ends up meaning nothing at all. Much like “cloud” or “dynamic” or “synergy”. You just wait for the right time in a meeting to drop it, walk to the board and draw a Venn Diagram, and then just sit back and wait for your well-deserved promotion.
That’s very true, and I do not like the term “serverless” for the rather obvious reason that it’s all about servers (someone else’s servers, that is). But these three principles are handy for figuring out if you’re building with in a serverlessy kind of way:
- You have no knowledge of the underlying system where your code runs.
- Scaling is an intrinsic attribute of the technology; so much so that it just happens automatically.
- You only pay for what you use.
Abstraction; scale; consumption.
Saturday, March 7th, 2020
Tuesday, February 18th, 2020
I am the programming equivalent of a home cook.
The exhortation “learn to code!” has its foundations in market value. “Learn to code” is suggested as a way up, a way out. “Learn to code” offers economic leverage, a squirt of power. “Learn to code” goes on your resume.
But let’s substitute a different phrase: “learn to cook.” People don’t only learn to cook so they can become chefs. Some do! But far more people learn to cook so they can eat better, or more affordably, or in a specific way.
Wednesday, January 29th, 2020
The web is far from perfect, but I think we underrate how resilient it can be.
If you thought maintaining a web project was hard, just wait till you try keeping an app in the app store…
Just before the 2019 holidays, I received an email from Apple notifying me that the app “does not follow one or more of the App Store Review Guidelines.” I signed in to Apple’s Resource Center, where it elaborated that the app had gone too long without an update. There were no greater specifics, no broken rules or deprecated dependencies, they just wanted some sort of update to prove that it was still being maintained or they’d pull the app from the store in December.
Here’s what it took to keep that project up and running…
Thursday, January 9th, 2020
This is a great proposal that would make the Cache API even more powerful by adding metadata to cached items, like when it was cached, how big it is, and how many times it’s been retrieved.
Tuesday, December 31st, 2019
We should think of our code, even our designs, as running for decades, and alter our work to match.
Thursday, December 12th, 2019