It’s fantastic that our web plumbing has gotten more powerful—tooling today is capable of so much. But all too often, that power comes with increased complexity that negatively impacts developer efficiency. Sometimes that’s unavoidable. The simplest approach doesn’t always win. But that should be the goal—to make things as simple as possible while still accomplishing what needs to be done. Like excellent plumbing, these systems should be as mostly invisible—chugging along, doing what we need them to do without getting in our way.
Today was a good day …and here are the very good photos.
Isn’t this just lovely?
Cassie made a visualisation of the power we’re getting from the solar panels we installed on the roof of the Clearleft building.
I highly recommend reading her blog post about the process too. She does such a great job of explaining how she made API calls, created SVGs, and calculated animations.
I think we’re often guilty of assuming that because our tools are great solutions for some things, they’re automatically the solution for everything.
A really terrific piece from Garrett on the nature of the web:
Markup written almost 30 years ago runs exactly the same today as it did then without a single modification. At the same time, the platform has expanded to accommodate countless enhancements. And you don’t need a degree in computer science to understand or use the vast majority of it. Moreover, a well-constructed web page today would still be accessible on any browser ever made. Much of the newer functionality wouldn’t be supported, but the content would be accessible.
I share his concerns about the maintainability overhead introduced by new tools and frameworks:
I’d argue that for every hour these new technologies have saved me, they’ve cost me another in troubleshooting or upgrading the tool due to a web of invisible dependencies.
Here are the slides for the opening keynote I delivered at the New Adventures conference in Nottingham on Thursday. They make no sense out of context like this. You kinda had to be there (or suggest to some other conference that I should deliver this talk again—hint, hint).
Dave on the opaqueness of toolchains:
As toolchains grow and become more complex, unless you are expertly familiar with them, it’s very unclear what transformations are happening in our code. Tracking the differences between the input and output and the processes that code underwent can be overwhelming. When there’s a problem, it’s increasingly difficult to hop into the assembly line and diagnose the issue.
There’s a connection here to one of the biggest issues with what’s currently being labelled “AI”:
In the same way AI needs some design to show its work in how it came to its final answer, I feel that our automated build tools could use some help as well.
I really like this suggestion for making the invisble visible:
I sometimes wonder if Webpack or Gulp or [Insert Your Build Tool Here] could benefit from a Scratch-like interface for buildchains.
The sentiment is that front-end development is a problem to be solved: “if we just have the right tools and frameworks, then we might never have to write another line of HTML or CSS ever again!” And oh boy what a dream that would be, right?
Well, no, actually. I certainly don’t think that front-end development is a problem at all.
What Robin said.
I reckon HTML and CSS deserve better than to be processed, compiled, and spat out into the browser, whether that’s through some build process, app export, or gigantic framework library of stuff that we half understand. HTML and CSS are two languages that deserve our care and attention to detail. Writing them is a skill.
This looks like a really interesting two-day event here in Brighton in November. Like Indie Web Camp, it features one day of talks followed by one day of making.
After a day of tech talks from project teams using their skills for social good, you’ll have the chance to take part in workshops and hackathons to use your own talents for a worthy cause.
And you get to go up the i360.
Rachel goes into detail on how she uses pattern libraries—built with Fractal to build interfaces. I know it sounds like we paid her to say all the nice things about Fractal, but honestly, we didn’t even know she was writing this article!
After discovering Fractal two years ago, we have moved every new project — large and small — into Fractal.
It is common to refer to universally popular social media sites like Facebook, Instagram, Snapchat, and Pinterest as “walled gardens.” But they are not gardens; they are walled industrial sites, within which users, for no financial compensation, produce data which the owners of the factories sift and then sell. Some of these factories (Twitter, Tumblr, and more recently Instagram) have transparent walls, by which I mean that you need an account to post anything but can view what has been posted on the open Web; others (Facebook, Snapchat) keep their walls mostly or wholly opaque. But they all exercise the same disciplinary control over those who create or share content on their domain.
Professor Alan Jacobs makes the case for the indie web:
We need to revivify the open Web and teach others—especially those who have never known the open Web—to learn to live extramurally: outside the walls.
What do I mean by “the open Web”? I mean the World Wide Web as created by Tim Berners-Lee and extended by later coders. The open Web is effectively a set of protocols that allows the creating, sharing, and experiencing of text, sounds, and images on any computer that is connected to the Internet and has installed on it a browser that can interpret information encoded in conformity with these protocols.
This resonated strongly with me:
To teach children how to own their own domains and make their own websites might seem a small thing. In many cases it will be a small thing. Yet it serves as a reminder that the online world does not merely exist, but is built, and built to meet the desires of certain very powerful people—but could be built differently.
Although design gets conflated with creation, its the act of improving what already exists — organising a room, editing a text, refining an interface, refactoring a codebase — that I enjoy the most.
I still find the landscape of build tools completely overwhelming, but I found this distinction to be a useful way of categorising the different kinds of build tools:
Build tools do two things:
- Install things
- Do things
So bower, npm and yarn install things, whereas grunt, gulp, and webpack do things.
I wonder if I have twenty years of experience making websites, or if it is really five years of experience, repeated four times.
I saw Frank give this talk at Mirror Conf last year and it resonated with me so so much. I’ve been looking forward to him publishing the transcript ever since. If you’re anything like me, this will read as though it’s coming from directly inside your head.
In one way, it is easier to be inexperienced: you don’t have to learn what is no longer relevant. Experience, on the other hand, creates two distinct struggles: the first is to identify and unlearn what is no longer necessary (that’s work, too). The second is to remain open-minded, patient, and willing to engage with what’s new, even if it resembles a new take on something you decided against a long time ago.
I could just keep quoting the whole thing, because it’s all brilliant, but I’ll stop with one more bit about the increasing complexity of build processes and the decreasing availability of a simple view source:
Illegibility comes from complexity without clarity. I believe that the legibility of the source is one of the most important properties of the web. It’s the main thing that keeps the door open to independent, unmediated contributions to the network. If you can write markup, you don’t need Medium or Twitter or Instagram (though they’re nice to have). And the best way to help someone write markup is to make sure they can read markup.
A fascinating bit of cartographic reverse engineering, looking at how Google has an incredible level of satellite-delivered building detail that then goes into solving the design problem of marking “commercial corridors” (or Areas Of Interest) on their maps.
Ben points to a new product aiming to ease the pain of connected devices bumping up against the harsh realities of shearing layers:
By exposing the ‘hardwiring’ of our electrical systems, Conduct emphasises how much we rely on existing systems to power our ‘new’ technology – the rate of change and advancement in our traditional technologies moves at a much slower pace than our mobile app-based world and there are physical limitations as a result of this hardwired legacy.
I am—unsurprisingly—in favour of exposing the seams like this.