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.
Friday, March 29th, 2019
Friday, March 22nd, 2019
I think I physically winced on more than one occassion as I read through Jake’s report here.
He makes an interesting observation at the end:
However, none of the teams used any of the big modern frameworks. They’re mostly Wordpress & Drupal, with a lot of jQuery. It makes me feel like I’ve been in a bubble in terms of the technologies that make up the bulk of the web.
Yes! This! Contrary to what you might think reading through the latest and greatest tips and tricks from the front-end community, the vast majority of sites out there on the web are not being built with React, Vue, webpack or any other “modern” tools.
Tuesday, January 22nd, 2019
This is yet another great explainer from Ire. Tree shaking is one of those things that I thought I understood, but always had the nagging doubt that I was missing something. This article really helped clear things up for me.
Monday, January 7th, 2019
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.
Tuesday, May 29th, 2018
Push notifications explained using astrology. But don’t worry, there’s also some code, just in case you prefer your explanations to also include models that actually work.
Friday, May 18th, 2018
I had some problems with my bouzouki recently. Now, I know my bouzouki pretty well. I can navigate the strings and frets to make music. But this was a problem with the pickup under the saddle of the bouzouki’s bridge. So it wasn’t so much a musical problem as it was an electronics problem. I know nothing about electronics.
I found it incredibly frustrating. Not only did I have no idea how to fix the problem, but I also had no idea of the scope of the problem. Would it take five minutes or five days? Who knows? Not me.
My solution to a problem like this is to pay someone else to fix it. Even then I have to go through the process of having the problem explained to me by someone who understands and cares about electronics much more than me. I nod my head and try my best to look like I’m taking it all in, even though the truth is I have no particular desire to get to grips with the inner workings of pickups—I just want to make some music.
That feeling of frustration I get from having wiring issues with a musical instrument is the same feeling I get whenever something goes awry with my web server. I know just enough about servers to be dangerous. When something goes wrong, I feel very out of my depth, and again, I have no idea how long it will take the fix the problem: minutes, hours, days, or weeks.
I had a very bad day yesterday. I wanted to make a small change to the Clearleft website—one extra line of CSS. But the build process for the website is quite convoluted (and clever), automatically pulling in components from the site’s pattern library. Something somewhere in the pipeline went wrong—I still haven’t figured out what—and for a while there, the Clearleft website was down, thanks to me. (Luckily for me, Danielle saved the day …again. I’d be lost without her.)
I was feeling pretty down after that stressful day. I felt like an idiot for not knowing or understanding the wiring beneath the site.
But, on the other hand, considering I was only trying to edit a little bit of CSS, maybe the problem didn’t lie entirely with me.
choose the least powerful language suitable for a given purpose.
Still, most of the time, the build process isn’t a hindrance, it’s a help: concatenation, minification, linting and all that good stuff. Most of my frustration when something in the wiring goes wrong is because of how it makes me feel …just like with the pickup in my bouzouki, or the server powering my website. It’s not just that I find this stuff hard, but that I also feel like it’s stuff I’m supposed to know, rather than stuff I want to know.
On that note…
Friday, February 9th, 2018
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.
Monday, October 2nd, 2017
Thursday, April 27th, 2017
This is a great free service for doing a bit of performance monitoring on your site. It uses WebPageTest and you do all the set up via a Github repo that then displays the results using Github Pages.
Sunday, March 12th, 2017
A Mac app for converting PNGs and JPEGs to WebP.
Wednesday, September 21st, 2016
Sunday, November 30th, 2014
This strikes me as an eminently sensible idea by Emil: using the picture element to begin providing WebP alternatives to JPG.
Of course, picture-supporting browsers will have to adjust their decision-making algorithm to support this pattern.