Robb Owen Digital

Looking elsewhere

2025-06-01T00:00:00-00:00

There’s a word in the Welsh language that you might have come across, part of that wonderful class of words that defy direct one-to-one translation into English: Hiraeth.

Broadly speaking, hiraeth is a deep sense of longing for some other time, people or place where you felt at home. It has been described as the lingering presence of absence; not really nostalgia, but a sort of gnawing, idealised homesickness to be somewhere else and be part of something else that no longer exists or, perhaps, has yet to come.

Hype-driven development

I—as I suspect was the case for many of us—entered the industry wide-eyed and optimistic. Finding my feet in tech in the early 2010s was exciting and everybody talked with naïve passion and a pioneering spirit about building positive change for the future. There seemed to be a real drive to hone our craft, to work tirelessly for the benefit of our users, for our work to be taken seriously as more than just programmers and designers. We were makers. Web Artisans. Shit, it seems almost laughably pretentious now. Somewhere along the way though, with a few success stories under the industry's belt, the profits just got too big and something fundamental shifted. Turns out that there's no time for craft when there's another round of funding to secure.

Now, at the mid point of the 2020s, it's as if the big-tech manifesto of "move fast and break things" has reconditioned an entire generation of makers to prioritise speed and efficiency over quality and care. With our standards lowered, the shift inwards has also become more pronounced. Where industry peers were once chatting about what they were making and for whom, we now seem fixated solely on what we're building with. We have sleepwalked into becoming an industry that makes tools for toolmakers; an unending tech-bro-robourus of solutions in search of problems, masking purpose with hype for the next big thing. And that hype-cycle is only getting faster. In just a few short years we've seen the crest and crash of countless industry darlings from JavaScript frameworks, to Blockchain and NFTs, right up to the current flavour-of-the-week: AI. But, as with every well-intentioned new product or clever solution, that-which-wasn't-considered becomes a vector for harm and AI finally sees the tech industry going after its own workers. Not content to have disrupted hospitality, taxis and delivery-drivers-as-a-service, companies are now axing their contractor budgets or laying off record numbers of staff as they chase the spoils of generative AI.

I want to make it clear that I am not against AI, much in the same way as I am not against hammers—they are both tools—but I am equally not going to advocate that you use your hammer to demolish the work of another artist for personal financial gain. It's how these tools are being used makes the difference and, currently, the industry is drunkenly swinging its ill-gotten sledgehammer at the foundations of our societies. In the face of this reckless pursuit of hype-over-craft, I can't help but find myself longing to be part of something that makes good on the industry's early promise of responsible change. Thankfully, I know I am not alone in this. This time last month I attended All Day Hey in Leeds and talk tended towards how we might change the course of the industry. As I've been gathering my thoughts in the days since, discussion online has also turned to many of same issues. At times it can feel like these conversations are eulogising our careers but I don't see any lack of desire to put the work in, rather a deep cultural burnout at the circumstances and motivations currently driving change in the industry. Despite it all, we still care.

It all begs the question, what might the future look like for those of us who still commit ourselves to craft? Fortunately for us, tech is not the first industry forced to defend itself against dubious practices and it likely won't be the last. Perhaps those industries that survived could be an example. What could we learn if we were to look elsewhere?

Raising the standard

When it comes to painstakingly technical, user-centred work there are few industries more famous than the tailor-made fashion houses of Paris. Training for years with traditional methods, pushing the boundaries of their craft, making individual garments with great precision and with only the finest materials; for many, they represent the archetypal "Artisan". But, for every artisan who cares about the craft, there's always someone else willing to compromise it for a quick buck. Throughout its storied history, the high-fashion industry has seen it all: corner cutting, poor quality materials, labour threats from mechanisation and rampant design piracy. Nowadays, we know many of these practices as fast-fashion, but they have been a thorn in the side of the fashion industry since the 1700s. That's not to say that the industry didn't fight back. Originally managed by a mercantile guild system these guilds would grow into an association who, by the late 1800s, would require that ateliers meet a baseline technical and material standard to be able to sell their garments within the city. Later, when piracy got out of hand, the heads of the industry implemented a further system of copy-protection by meticulously photographing and cataloguing each new design. Time after time the ateliers saw off threats to their livelihoods, but the industry's biggest challenge would come with the fall of Paris to Nazi Germany during World War II.

Seeing the strong reputation of tailor-made fashion within France, the fascist occupiers immediately sought to seize the industry's design documentation, dismantle the ateliers for raw materials and forcibly relocate those involved in production to Berlin, or far worse. In the face of the new regime, some ateliers immediately capitulated and dismissed their workforces. Many others did whatever they were able to safeguard their industry and those working within it. When liberation eventually came in 1945, the surviving ateliers of Paris, led by Lucien Lelong, came together again to codify their practices and ethics into law. In contrast to the association rules of the 1800s, this new legal standard would prevent any further attempts to undermine their craft by formally separating their work from fast-fashion practices. The law would not only ensure that only garments produced with certified materials and to exacting technical standards would be allowed to bear the name "Haute Couture", but they would also stipulate the location and number of employees an atelier must have, thereby safeguarding many of the ancilliary professions and practitioners that contributed to their work.

Fast-software

Chasing trends and profits, cutting corners and undermining skilled workforces whilst providing ill-fitting, broken products with no regard for longevity; the modern software world sounds a whole lot like fast-fashion. With that in mind, two aspects of the ateliers' pushback are particularly interesting to me - the first is the role of standards.

So far I have made many references to "craft" and "quality", but those terms can be hard to define. Motivations are more tangible. Compiling their accumulated knowledge in service of the customer allowed the ateliers of Paris to define precisely what "good work" meant for their industry. With such a baseline in place, should the primary motivation for producing work be anything other than meeting the customer's needs, the work fails by default. By also treating their standard as a living document, ateliers are able to focus on the betterment of their output, adapting and evolving their practice to meet the changing challenges of their industry.

It should hopefully come as no surprise that web industry is already home to several evolving standards for the semantic use of HTML and Accessibility. The web-standards movement and WCAG are the cumulative work of years of user-focused research and provide us with a jumping off point for doing work in service of our users. Meeting standards must be intentional though and for a long time developers have neglected them. This presents us with an opportunity. Though AI has access to a vast dragons-hoard of code, much of that code does not follow standards and, by consequence, the output of LLMs and design-tooling tends to be a chaotic rat-king of <div>s with no regard for semantics or accessibility. In this context it becomes clear that standards are a vital point of differentiation for craft-led practice. By design, these initiatives put the user experience above the developer experience. Following standards immediately shifts emphasis back to the "why" over the "how" and recentres the user within our work. If we collectively commit to following standards, we commit to "good work" by default.

There is a common rebuttal to the use of standards, in that it is simply too hard and too time consuming for one maker to amass the level of knowledge to follow these rules end-to-end. The problem with this idea though, is that it assumes that only one maker should hold knowledge. This is the second aspect of the ateliers' pushback - solidarity with adjacent professions. The heads of the industry understood that respect and accountability to one another would enforce their standards. To understand a bit more about how accountability to adjacent disciplines can enrich craft, let's take a look at another industry.

The case for blurred specialisms

To be honest, it's hard to keep mentioning the idea of web artisans without addressing all of the millenial-hipster jokes about organic, free-range TypeScript, artisanal hyperlinks and farm-to-<table> layouts. The thing is though, the farm-to-table movement and its reinterpretation of the restaurant industry is a genuine example of how solidarity feeds craft. With that in mind, let's just lean into it for a moment.

Widely attributed to the work of Alice Waters at Chez Panisse, farm-to-table dining presents cooperation as industry counterculture. In the face of questionable low-quality-high-profit practices overtaking the restaurant industry, the movement instead asked what might happen if they focused on sustainability, quality and shared knowledge. The big picture looks a little like this:

In order to provide their diners with the best experience, a chef will spend years honing their technical skills. At the same time however, the chef understands that their execution is reliant on a foundation of quality ingredients, so seeks out growers with deep knowledge of their terroir. Each knows their own limitations but, as their domains overlap, the chef and grower might then work together to enhance flavour or develop new cultivars that can stand up to different cooking techniques. With time, the process becomes reciprocal. The qualities of the grower's produce inspires the chef's work which influences the grower to apply their skills, which further elevates the chef. In this kind of scenario, it is not uncommon to see a grower's name featured prominently on a menu alongside the ingredients that they have worked hard to cultivate. The grower is not just a supplier, but respected as an equal artisan.

My takeaway from this concept is that, in order to master your own domain, the boundaries of your specialism will often blur with specialists in other domains. With a mindset of mutual respect, the whole process of making is not a cycle of hype, but one of intentionality and growth.

But should designers code, though?

At this point you might quite rightly be thinking that blurred-specialisms sounds a lot like the T-shaped skillset touted by corporate leadership. You might also be thinking, "we've already tried that, how can that be a future for the industry?"

The difference, again, is one of intentionality.

A top-down, KPI-driven approach rarely cares about craft over profits. This means, sadly, that the common implementation of T-shaped workers expects them to carry out the roles of other specialists in addition to their own. Take full-stack development or the age-old "should designers code" debate as examples - From a c-suite perspective, these are matters of efficiency; surplus roles can be eliminated if one worker can step up to do two or three functions within the organisation. By that same logic, if AI tooling can be trained well enough, it has the potential to replace all roles. Remember, line goes up if wages go down.

The fundamental difference for the artisan model is that it operates in parallel, driven by the workers themselves. Each artisan retains full autonomy of their own specialism, but chooses to supplement their knowledge about how adjacent disciplines relate to theirs. Most importantly, this is done not with the intent to replace the other specialist, but to inform and elevate the quality of one's own work. This comes with a mutual accountability on doing what is right for the end-user rather than on convenience and expediency. Being an artisan is less about hoarding and regurgitating 'acquired' knowledge, and more about being part of a distributed support network of talented individuals. Success is a matter of community. To focus on craft is to stand on the shoulders of those who came before and lift those who come after.

Craft is community

When reading into these examples and others, I quickly came to see a common thread of respect, intent, ethical standards and community. These human qualities, as I see it, are key to differentiating the craft from the hype-machine - They simply cannot be replaced or replicated by LLMs or design tooling. In her fantastic post, "The promise that wasn't kept", Salma writes:

Real value is delivered through vision, creativity, experimentation, and using human brains to solve human-centred problems.

This really resonates with me. To dehumanise the craft is to remove the value of the work.

As an industry we often talk about 'the supply chain' in terms of code packages and modules that we depend upon, but I believe there is value in refocusing on the people who support us. Much like the couturiers and culinarians we've already talked about, the web industry was built on the skill, care and labour of people and what makes it great is those people. In the face of mass layoffs, it is no longer enough to show up and sweat the details of your own work. It's the time to champion each other. Taking inspiration from the examples above, that might look something like this:

Prioritise working to standards. Standards aren't a restraint, they're a peer-reviewed baseline against which you can determine the quality of your work, especially when the people who use your works may depend on them.
Take full ownership of what you control and freely share knowledge with those around you so that they may build upon your work and elevate it.
At the same time, look elsewhere and allow youself to be inspired by your contemporaries in adjacent (or even unrelated) disciplines.
Remember that your network is a strength. Give people their dues and allow them credit where their work has lifted your own.
Stand up for adjacent disciplines when you see their knowledge and autonomy being infringed upon and, where work is directly affected in the form of layoffs, form unions and push back against unreasonable demands.

More than anything, go out find like-minded people. Where you can, go to meetups or local events and support initiatives such as Piccalilli's open collective that aim to give back to the community. For those readers in the UK, here are a few fantastic community-led events to get you started:

All Day Hey in Leeds
Frontend North in Sheffield
WDC and Pixel Pioneers in Bristol
State of the Browser in London
FF Conf in Brighton

Hype Hope-driven development

Despite the questionable stewardship of our industry, the continued resilience of artisans in other fields gives me hope that the devaluation of crafting for the web is not inevitable, rather a matter of framing. Do I believe that any of the ideas presented here will be the miraculous savior of the web industry? Likely not, but then I equally do not believe that there is a single saviour to be found. Whatever the course, I do believe that we need to put in the work together, share our specialisms and then, perhaps, something will happen.

I'm in little doubt that, as long as there is big money to be made, the exploitative, VC-appeasing hype-cycle will rumble ever onwards. However, much in the same way that artisan-tailors and farm-to-table dining continue to work separately from the exploitative worlds of fast-fashion and fast-food, I have to believe that there can be another place—another market—for those of us who still care about the people and the craft. Not really a hard-reset, but a parallel fork of the industry that does right by its users and by the people working in it. Maybe it's misplaced idealism or perhaps it's foolishness, but I can't shake the hope of that place; some odd kind of hiraeth.

Getting something from Nothing

2024-02-28T00:00:00-00:00

In the last couple of years I have developed a complicated relationship with my phone. Whether it's scrolling past an endless wall of hate on Twitter or feeling my mood buckle under the weight of every TikTok or Reel that I push skywards, the tiny computer in my pocket has started to feel a bit like that box from Dune – there's nothing but pain in there.

Increasingly though, it's not just "in there" that's the problem. Over-reliance on my phone has often left me feeling like I'm not being forced to remember things as much as I'd like and the addictive nature of notifications means that I'm less present when my pocket starts to buzz. My hobbies have taken a hit too. Whilst I've always been keen on travel photography, I've noticed that on my recent trips I've been taking fewer and fewer photos with my camera. At the same time, I've taken hundreds of mediocre smartphone photos. The convenience of the phone in my pocket has started to outweigh the joy that I get from composing and shooting with the camera in my bag. Honestly, it's made me sad for all of the missed opportunities.

As much as I joke about disconnecting and running off to a cabin in the woods though, I'm still quite realistic that I do need a phone for modern life and work. There are many fantastic and necessary things that I love about having a smartphone to hand, I'd just like to use it a little less compulsively.

When my Samsung S21 literally and unceremoniously fell apart back in January of this year, I was confronted with the reality that I was going to have buy a new phone. But what do you buy when you want to use something capable, but much less frequently? Well, it turns out that there is a UK-based company called Nothing who pitch exactly that. As a "midrange" device the Nothing Phone 2 isn't as powerful as the latest iPhone or Samsung devices, but something that came up time and time again in reviews was that Nothing aim to help people to make more intentional use of their phones. That claim, along with the industrial design, sufficiently piqued my interest. After finding a great deal on the 512gb model, I decided to take a punt on it.

Tech has a real issue with chasing statistics and I'm always aware that, working in the industry, there can be a pressure to always have the latest and greatest device. After four weeks of use, I thought I'd share a few thoughts on taking a side-step.

Software that makes you want to stop

Nothing's "use your phone less" ethos was undeniably appealing in choosing their device, but it remains questionable when a company is ultimately still in the market of selling phones. With that in mind, I'm pleasantly surprised that the Nothing Phone 2's OS actually makes good on some of the company's claims about minimising distractions.

Nothing OS is a light-touch skin over stock Android that adds just enough personality without reinventing the wheel. No emphasis on AI-driven nonsense and no pre-installed app bloatware; just a dot-matrix font and icons, some smart app-grouping options and a few useful widgets, all tied together with custom UI animations. Amusingly, those animations and transitions have a decent heft and easing to them which, despite the supposedly inferior chipset powering this phone, leaves the phone feeling snappy or, dare I say it, blazingly fast. It's all very refreshing to use.

The most important change for me though, is the focus on minimalism baked into the OS. You'll find a few accent colours dotted here and there, but my homescreen is now sparse to the point of being almost-monochrome. This design choice isn't just for the vibe though - instead of a multi-coloured wall of app icons and notifications bubbles just waiting to distract me, I now have a list of discreet black and white icons. Where a dedicated app icon isn't available, the OS applies a contrasty greyscale filter that, so far, hits more than it misses (check out the Elk icon in the photo above).

In practice, removing the colour from the icons means that the list of apps is harder to scan and the net result is that I'm spending less time compulsively hopping between apps. When the UI forces me to stop and read, my usage starts to feel more intentional. Chuck in a screen-time widget on the always-on display and I am genuinely finding that I'm unlocking my phone less frequently. Admittedly these are all subtle tweaks to the software but, given how much I've struggled to use my phone less, they come together to feel like a win.

So, a win for the software. But what about the hardware?

Business in front, party in the back

In my opinion, Android phone designs in 2024 are wholly uninspiring. For a company that once released a phone in Thanos-chic purple and gold, Samsung's latest phones have been reduced to characterless monotone slabs. Then there's the latest Pixel phones from Google which look like a from-memory sketch of Daft Punk and are equally loaded with enough AI intrusions to make them seem Human After All.

The Phone 2 stuck out to me as doing things a little differently. With its sharp screen, uniform bezel and hole-punched camera the front looks a lot like an iPhone 15, but flip it over and the back is a different story.

The back of the Nothing Phone 2 is a glass panel that shows through to a design that hints at the interior components without actually showing them. The end result is a finish that is shiny and smooth yet, at the same time, the components underneath create a surprising amount of texture (something that made more sense when I learned that Teenage Engineering had a hand in Nothing's design language). The whole thing is surrounded by matte metal rails and yet remains surprisingly lightweight, given how solid the materials feel.

Then there are also the lights – sorry, the "Glyph".

The back glass of the phone is home to an excessive number of white LED lights that etch out a pattern which looks like it could have been part of some glitchy Channel 4 ident from 2001. Coincidentally, that's exactly what it sounds like too as the phone's sound design (by Swedish House Mafia) is straight out of the 56k modem school of music. Think: lots of glitchy pops, buzzes, cracks and clicks.

Look, I'll be real: these lights are an absolute gimmick and I'm so unconvinced by their actual utility as "distraction free" notification lights that I swiftly disabled them in the settings. At the same time though, I'm really glad they're here.

You see, comparing stats like chip speed, resolution and screen brightness will only get you so far but there's another side to any design that is much more unquantifiable - how the thing makes you feel. It's entirely subjective, but one of things that drew me to this phone is that the design reminds me of a very specific era of consumer electronics when hardware could be fun and wasn't so beholden to market expectations. I'm talking about the transparent Gameboy Color or the smoke-grey N64; Apple's first iMac and the legendary G4 Cube; Sony's burgundy-lacquered MZ-E620 MiniDisc Walkman and the aqua-camouflage Neo Geo Pocket; The goddamn WonderSwan.

The back of this device is leaning into the early-2000s transparent aesthetic and, to be honest, I'm here for it. Hardware design used to be weird, creative and exciting to me and the Nothing Phone taps back into that long-dormant part of my brain quite nicely. The first time I saw the back of my phone light up like a football pitch, I just had to smile at the absurdity. Somehow, it feels good.

Final thoughts

So, should you buy this phone if you were already planning on getting the latest iPhone or Samsung? Probably not. I got this phone after deciding that it was right for my needs. If it seems like it might be right for you too then go for it.

I want to be realistic and step away from any brand Kool-aid though: This phone is far from perfect and the design won't speak to everyone. The back glass is slightly pillowed which makes it feel a lot thicker in the hand than it actually is. With a 6.7" screen, the phone sadly remains the size of a small horse. The camera (as every review quite fairly warned) has the distinction of being bang average in anything other than good light. And lastly, let's not forget that Nothing themselves are such a new company that there's no guarantee they'll still be around in 5-10 years.

One month in, though, and I'm really happy with my move to Nothing Phone 2. For my needs, the hardware has just enough charm that I'm feeling happy to reach for my phone again and, at the same time, the thought that has gone into the software is helping me to break my phone addiction. Despite the industry's obsession with comparable stats, I haven't personally noticed any lack of power either. In fact, when I look at the reasons for upgrading my previous phones it has always been because of battery degradation or running out of storage and never because of a lack of power. In that regard – with 2 days on a single charge and 4 times the storage of my last phone – the Nothing Phone has actually been something of an upgrade.

The jury is out on whether or not my usage will creep back up over time, or if the battery-life will stay steady, but I'm already feeling less negativity about my phone. I'm also happy to report that the lacklustre camera is making sure that my Fujifilm isn't staying in its bag anymore. So far, at least, I'm pleased I went with Nothing.

It's OK to abandon your side-project

2024-02-22T00:00:00-00:00

The web industry is full to the brim with tales of side-projects that grew into successful businesses and, like many of us, I'll often find myself tinkering away on an idea or three after I've finished with my day-job. Whilst it's definitely an enticing prospect, working on a side-project is not always sunshine and Lambos though – sometimes they just don't work out. If you're reading this, there's a chance that you might have recently abandoned (or are considering abandoning) a side-project. Many of us have been there. Hell, the neglected side-project has become something of a developer-meme at this point.

That said, I often get emails from beginner developers looking for advice and one of the growing themes I've noticed recently is concern that they they aren't shipping their side-projects as quickly or numerously as they would like. That anxiousness is totally understandable. When the prevailing wisdom of developer hustle-culture is "always be shipping" and tech-interviewers will routinely measure candidates by the output of their extra-curricular coding, those abandoned side-projects might not feel so funny anymore. That doesn't sit right with me. We hear about all the side-project success stories, but what if we talked more openly about the ones that tanked? Many of us do retrospectives at work, but personal projects don't get the same treatment. Instead, why don't we shine a light on all the time we spent on projects that didn't go anywhere? The seemed-like-a-good-idea-at-the-time abandonware; the graveyard of node_modules folders still haunting our development environments.

I'd like to talk about a side-project I worked on a while ago; one that I abandoned the same day it was deployed.

The background

My partner is Latvian and, a few years back, I set out to learn her language. Being from a small country, detailed learning resources for the Latvian language are a bit sparse but I made decent progress regardless. That was, until I discovered that Latvian has grammatical cases. If you've never encountered a "case" before, here's a little primer:

A language like English uses word order and prepositions such as "for", "to" or "in" to add meaning to each word in a sentence. If the order is wrong, or you miss a preposition, the sentence might no longer makes sense. For example, "Tom gives the book to Anna" sounds natural whereas, "Tom the book to Anna gives" doesn't. Cases change this up a bit. Instead of relying on word order and helper words, the end of each word itself changes to show what it is doing within the sentence. To return to the same example sentences in Latvian, "Toms dod grāmatu Annai" (emphasis added to highlight the functional endings). Literally translated back to English, this sentence would be something like "Tom-subject gives book-object Anna-towards".

Linguistically, cases are a pretty cool system because you no longer need to care about word order. As a learner though, this is a problem because you do need to care about all of the various endings for each word you learn. Latvian has seven cases in total, two grammatical genders (each with three separate conjugation patterns), and nouns can be singular and plural. The TL;DR is that's something like 84 possible endings to memorize.

So, cases can be a lot for a first-language English speaker. Thankfully though, I'm also a developer and therefore I'm hardwired to think that I can solve everything with code. What if I could build a quiz app to help me learn noun endings? This smelled like a side-project 🚀

The approach

I wanted to keep my app simple. Whilst I had a lot of other grammar to learn, I was only focusing on noun conjugations and that would help me whittle the initial concept down to an MVP. The quiz mechanism would present a series of Latvian nouns and the user would be required to conjugate the noun to the appropriate ending. To keep things interesting, the quiz would allow the user to make three mistakes before ending and I'd throw in a simple high-score system to keep track of how I'd performed in past quizzes.

The tech stack would be simple too. At the time of planning, Svelte 3.0 was the new shiny so I decided to use it for my UI. I knew that I wanted to host everything on Netlify, so for the backend I'd write a couple serverless functions to present the questions and check the answers. The main list of nouns could be served from a static JSON file and, as I'd be the only user, I could safely persist previous quiz results and a high-score to local storage. I wouldn't need a database right now.

As for how I would actually check answers, that would take a bit of research. After extensively reading about the conjugation patterns and how the various types of nouns are classified, I decided that my simplest option would be to build a system that leaned heavily on Regex to strip noun stems and append the appropriate suffixes.

With a decent plan in place, I started to code.

The realisation

After a full week of evenings working on the project, I put the finishing touches to the MVP. I deployed everything to Netlify and started my initial testing.

The UI was simple but passable and worked well on mobile devices. Quiz questions progressed smoothly and the session would end after three wrong answers, as designed. In between quizzes, the dashboard was correctly displaying stats for hits and misses on each word and the overall high-score was persisting between sessions. Happy that everything was working as planned, I cracked a beer and started training word endings.

It quickly became clear that my app had a really big problem that I hadn't anticipated. The quiz was far too easy. Worse still, if I didn't make 3 mistakes, the quiz would keep going indefinitely. It just wasn't fun to use.

I racked my brain for possible ways to make the quiz more fun but, eventually, the penny dropped: The issue couldn't actually be solved in code. It turns out that, in devising and coding all of the logic needed to test the various noun endings, I had passively learned the rules needed to form them.

Over the last week I had worked long evenings to research and build an app – with a target audience of one person – and I didn't really need to use it anymore. Oops.

Maybe the real treasure is the code we wrote along the way

Out of all of my abandoned side-projects, this was the one that made me think differently. Even if I would never actually use the end 'deliverable', working on the project still indirectly achieved what I'd set out to do. That led me to an important realisation: we talk a lot about abandoned side-projects as "failed", but their success is really a matter of perspective.

Despite what some tech recruiters might have you believe, the success of a side-project doesn't need to be defined by a beautiful, shipped product. We work in a practical medium and any build experience, good, bad or abandoned, is still valid experience. If you are able to remove the pressure to ship and instead approach them like throwaway prototypes, side-projects become a great scratch pad for experimentation. As I found when building my Latvian app, even the act of writing code itself can be a successful tool for solving problems.

This is not all to say that we should dismiss the reasons these projects get abandoned – introspection is still important – but I find that focusing on the progress made can feel more constructive in the long-term. After abandoning my Latvian project, I dipped back into some of the other stalled side-projects languishing on my laptop. Where I'd previously grumbled over a string of failures and wasted time, I could now refocus on what had gone well. On one project, I could see where I'd first learned how to make an API in Go. Elsewhere I was impressed at how I had figured out how to work with GIS map data in Postgres. In another derelict directory, I saw not much more than a broken animation - one that I would later revisit and evolve into this website.

Wrapping up

I still regularly work on side-projects but my perspective and motivations are different now. My advice to a beginner dev struggling with their side-projects would be to always make sure that you're doing them for yourself, and for the right reasons. Instead of approaching your first project purely as a means to make it big or to impress recruiters, see it firstly as a means to learn and explore what's possible. Once you've built up enough experience (i.e. abandoned a few projects) the rest usually follows. Side-projects should be creative and fun. If you find that shipping your project is starting to cause you stress or, worse yet, leaving you feeling burned out, then don't hesitate to cut it loose. Chances are that, if you look close enough, it has already brought you plenty of value.

2023 Wrapped

2023-12-31T00:00:00-00:00

For the past few years I've tried to do a little retrospective post on the year that was. This year, inspired by the endless "such-and-such wrapped" tracking-data-as-entertainment emails that I've been getting, I'm going to mix up the format a bit and throw in an extra rundown of some of the media I enjoyed this year.

So, let's go. Here's my 2023 Wrapped (replete with overly-excitable subheadings)

"This year, your contracts were eclectic"

I had a really varied year of freelancing in 2023 - I've worked on a bunch of brochure sites, a full design system, an app dashboard, I refactored part of a project written in Elm, I built a PWA with lots of time and timezone-dependent features and so much more that I struggle to recall.

2023 also marked the milestone of being five-years-freelance and I worked extra hard this year. If I'm honest, I worked too hard and burnout is once again knocking at my door. I still love the flexibility of the freelance life, but I'm starting to get the itch to do my own thing. I'm not sure what "my own thing" will be yet, but in 2024 I'm going to take time out of client work to try my hand at a few personal projects.

"This year, the words came easier"

Every year I try to blog more and, whilst my drafts folder is still pretty well stocked, this year I published a tiny bit more than I did in previous years. This year I also challenged myself to write a little less technically and a little more conceptually. I think I just-about pulled it off.

Here's a quick rundown of links:

"Another year, another framework"

In 2023 I did a hell of a lot of work with Nuxt and Vue. Moreso than any other framework or programming language. I really enjoy using Nuxt and will continue to do so, but this year the fragmentation of Nuxt 2/3 compatibility has caused me quite a few serious headaches. In fact (and this is absolutely not intended as a slight on the work of the Nuxt team) this year I started questioning the use of frameworks altogether.

But then, I did a couple of projects with Astro.

Over the years I've slowly come to the realisation that the thing I like most about front-end frameworks is not encapsulating JavaScript or declarative code or any of the usual DX suspects. I like the componentisation of reusable HTML. Simply, I like not having to copy-paste a bunch of template code like we did in the old days. Because of that, Astro has been a great fit for me - Astro components allow me to assemble chunks of HTML and CSS and opt-in to all the benefits of a framework like React or Vue if and when I need them. No client-side JS by default? That's pretty damn cool and I'm looking forward to more Astro projects in 2024.

"This year, you left the UK for the first time in 3 years"

For someone who loves to travel, I haven't been out of the UK since I returned from Japan in March of 2020. To be frank, it has been an absolute slog. Thankfully, this summer, I was finally able to break the streak (and the Great British Depression that came with it).

My partner is Latvian and every five years Latvia holds a huge cultural celebration of traditional songs, dancing and costume – Dziesmu un deju svētki. In July we flew out for two weeks of seeing her family and friends, eating great food and listening to fantastic musical performances.

The highlight for me was the final concert, deep in a forest park and featuring a choir of 16,000 people. Add to that the crowd and you have close to 40,000 people singing long into the night. The next event is in 2028 and I can't recommend it enough. Just look at the size of this stage; you don't so much hear the songs as feel them in your chest. Magic.

It's hard to understate the positive effect that travel has on my mental health, so I'm really looking forward to travelling more in 2024.

"This year you got super sick of superheroes"

My extreme burnout from the endless Marvel content-machine peaked this year (Hi-and-bye, Quantumania) but thankfully there has been a wealth of decent alternatives this year. Here are my top film & tv picks from the last year:

The Bear: season 2 - I loved the first season and tbh, the ending of season one was so well handled that I'd have been happy if it was a one-and-done show. Against my initials fears though, season two was better in almost every way (and not least because I'm an absolute sucker for a redemption arc). My standout episodes were Honeydew and, of course, Forks.

Past Lives - Beautifully acted, absolutely gorgeous to look at, and with an ambiguous and nuanced plot. When it finished, my partner and I sat and discussed our interpretations for quite a while afterwards. I still can't get over how this was director Celine Song's first movie. Phenomenal talent.

Godzilla Minus One - This one slipped into my list right before Christmas. Some people grow up with Star Wars or Lord of the Rings or whatever, but for my brother and I we had the Godzilla movies. The recent US-made 'zilla flicks have been of diminishing quality but they still provide me some small amount of satisfaction for the lizard-brain. Minus One is a very different and very character-driven movie. Normally I'd be rooting for the big lad, but here he was so intimidating and the characters so well drawn that I was cheering them on instead.

Even if you're not a fan of kaiju movies, I'd recommend giving this one a watch. It's a brilliant anti-war allegory and absolutely the best Godzilla has been since the 1954 original. On a personal level, hearing the original Godzilla theme blasting out in a cinema was a real treat too.

"In 2023 you played a whole bunch of games...or did you?"

I thought I played a lot of games this year, but statistics don't lie. As I wrote on Mastodon:

Of all the "isn't how we track you fun!!" Wrapped things this year, I enjoyed the Xbox Gamepass one the most because it showed that my girlfriend has basically worked a second job playing Age of Empires II

That said, I did fit a couple of gems in the gaps between AOE2:

Zelda: Tears of the Kingdom – I've been a Zelda fanboy since the LttP days so, if that means anything to you, I probably don't need to elabourate much more on why I loved this game. I'm completely in awe of how Nintendo managed to reuse so much of the game world from Breath of the Wild and still make it feel fresh and innovative. The level of creativity and fore-planning in this game is genuinely inspiring (web industry take note).

Also, the music. OMG the music.

Alan Wake II - This was a curveball; the sequel I never knew I wanted. I played the original game back when it came out and I was honestly lukewarm about it. When AWII launched around Halloween, I knew very little about it, but decided to take a punt on it. Oh damn, is it good. It has a pulpy and totally overblown story, parts of it are genuinely scary and its blending of game and live-action looks phenomenal even if it creaks a little bit on my Xbox Series S. Seriously, the game crashes very frequently on Series S and yet I couldn't even be mad at it. I needed to see what fresh madness would happen next.

Wrapping up

So that was my 2023. If I'm entirely honest, it feels a little bit like I only just wrote one of these posts. This year has absolutely flown by for me, but I'm feeling ready for the changes that the new year will bring.

Cheers for reading this far, and here's to a happy and healthy new year in 2024! 🍻

Locking scroll with :has()

2023-12-20T00:00:00-00:00

It's finally happened – with the release of Firefox 121.0 :has() has landed in all browsers (though writing ":has() has" is sadly no less awkward). In celebration, I thought it a good time to share one of my favourite practical uses of :has() so far – scroll locks.

Imagine that you need to open a modal window, or flyout menu. To prevent from losing the user's place in the page whilst that modal is open – particularly on mobile devices – it's good practice to prevent the page behind it from scrolling. That's a scroll lock.

Let's take a look at how we might implement one.

Locking scroll

Probably the simplest way to lock the user from scrolling a document is to add overflow: hidden to the document body.

body.lock-scroll {
  overflow: hidden;
}

This class will totally disable scrolling, so we can't just leave it in our HTML. It will need to be conditionally added and removed whenever a modal, flyout or scroll-locking element is active within the page.

One way to solve this might be to adjust the body class when opening or closing the scroll-locking element:

const openModal = () => {
  // ...some code to open the modal
  // then lock the scroll
  document.body.classList.add('lock-scroll');
}

const closeModal = () => {
  // ...some code to close the modal
  // then unlock the scroll
  document.body.classList.remove('lock-scroll');
}

This method is generally fine, but there are some complications.

What happens if you have multiple screen locks at the same time, for example? Let's say that our user clicks a hamburger menu to open a flyout whilst a modal is already open; both UI elements will lock the scrolling but, using the approach above, closing either the modal or the flyout would remove the .lock-scroll class from the body and unlock the scrolling whilst the other element is still active.

Similarly, if you're in a framework with clientside routing then navigating to a different page won't automatically remove the body class. Unfortunately, that means the scroll will still locked when the new page is loaded in.

None of this is insurmountable by any means, but managing the body class to cope with edge-cases takes a bit of effort. CSS can make things simpler.

Solving edge-cases with `:has()`

Because :has() lets us modify a parent element based on its contents, handling scroll locks becomes a breeze. We can tweak the CSS declaration on our body element to use :has():

body:has(.lock-scroll) {
  overflow: hidden;
}

Now, rather than managing state directly on the body by toggling a .lock-scroll class with Javascript, we can now manage it on the markup of any element that needs to lock the page scroll:

<dialog class="lock-scroll">
<!-- some wonderful modal content -->
</dialog>

Instead of the lock being hinged on JS state-management, we've tied it to the contents of the DOM itself. As long an element with .lock-scroll is in the DOM, the scroll we be locked.

Need to unlock the scroll? remove the element from the DOM. If there are multiple instances of .lock-scroll, then the scroll will remain locked until all of them are gone. The same goes for route changes - if there's no .lock-scroll class present in the new page then the scrolling will be automatically unlocked.

...and that's kinda all there is to it. Lush.

Wrapping up

The above is a very simple example, but it's one that I've found useful. With support for :has() now across all browsers, it's also one that is increasingly viable. The nature of CSS means it's pretty simple to expand the example to more elabourate use-cases too. You might, for example, wish to bind the scroll lock as a side-effect to changes in data or aria attributes:

body:has(.some-class[aria-expanded="true"]) {
  overflow: hidden;
}

Whatever your application, :has() looks to be a really handy tool and I'm stoked to see it finally get full support.

HTML is like a camera

2023-11-16T00:00:00-00:00

Recently, as I started getting back into photography I read something that stuck with me (though sadly the source didn't). To paraphrase:

If you were able to take a great photo on a camera from 1979 then that same camera can still take a great photo today. New and shiny tech may make certain things easier, but a good photo is a good photo. Ultimately, the viewer won't give a shit which camera you used

As a frontend developer, I think about this a lot.

Legacy code

2023-04-17T00:00:00-00:00

Before he retired, my dad was an electrical and diagnostic engineer. In short, he dedicated most of his adult life to designing and building lasers and laser equipment – everything from laser-tag through to guidance systems for those massive drills that dig rail tunnels. After dad passed away, I stumbled across a box in my parent's garage containing prototypes and product specimens for many of the laser modules that he'd built throughout his career. That box now serves as a tangible legacy of a long and varied career.

Flash forward to a few months ago when I was chatting with a potential client. They asked me to show some of my past work, so I duly shared my screen and hopped over to the URL of a humanitarian campaign site that I was particularly proud of having worked on...

I often think about that box in the garage.

Let's get existential for a moment

This is not a new phenomenon. In my younger years I was keen to make a mark in the industry and would often find myself working to the point of exhaustion in order to meet unreasonable deadlines. What was I working on at the time? There's the kicker, I can't even remember. Whatever it was, I know that the site has probably been long since replaced. That is just how the web industry is.

But, what does it actually mean to work in an medium that is so temporary? How does it shape us? When your work can literally disappear at any given moment, how do you reason with the effort that went into producing it?

Personally, these are uneasy questions but, thankfully, I know that I'm not alone in feeling this. I recently found myself nodding along with Jason Lengstorf's video "Your job doesn't matter (and that's a good thing)" and, just this morning, I felt Eric W. Bailey's beautifully to-the-point Sandcastles in my bones.

Control structures

The more I think about the why, the more I believe my own sense of discomfort ultimately comes down to a lack of control in a job that is seemingly all about control.

As developers we spend a lot of our time trying to take nothing and give it the necessary structure and logic that turns it into something. Once we have the something, the job shifts gears. We start to monitor uptime, we handle traffic spikes, triage error logs, make tweaks to the UI and do everything we can to keep the project ticking along. We are in charge of managing and maintaining the systems necessary for the project's life-support. And yet, despite those efforts, there's no system that can stop a project from just running its course.

It's a truism that, from the point of launch, our work is no longer "ours". We have full control, until suddenly we have none. Eventually, someone will make the decision that the time has come. The server will be shut off, the domain will be left to expire and the website will be gone, save for a trail of broken links.

The industry has collectively come to call the closure of project, "sunsetting". In a world of blazing-fast bro-sy newness, it's an oddly melancholic bit of romanticism that seems to suggest that we knew the end was inevitable from the start. Regardless of any prior understanding, it can still feel uncomfortable that an entire body of work can just be ...gone.

Code conservation

So, if we know our projects will end, perhaps we can lessen any sense of existential unease by taking steps to preserve them. The question is, how can we do that?

Well, the most obvious solution seems to be case studies, which is perhaps why so many of our portfolios are screenshot memorials to that sweet-spot between launching the site and handing over the keys to the CMS. Screenshots and videos definitely go some way towards the job, but its little more than a tribute – you can't really get a feel for the work in the same way as a live site. Set Studio's recent site launch included a beautiful and novel solution to this – it contains embedded, responsive snapshots of their work preserved in time. I'm a huge fan of this approach but, as a freelancer, licensing and NDAs mean that it isn't always possible to do the same.

What about retaining local versions of projects? Licensing issues aside, anyone who has spent any time struggling to update and run an old project's NPM dependencies will know the answer. Hell, even recording our work to physical media isn't a solution as external storage can fail – the box of useless, peeling DVDRs that I found alongside my dad's lasers is a testament to that.

In times gone by I would have suggested that projects like the Internet Archive's Wayback Machine had our backs. By archiving websites long after the servers have been shut down, they have been ensuring that nothing is ever truly gone. Unfortunately though, it's not a perfect solution and we have a new problem. Perhaps it was a side-effect of having ceded final control of our work to external companies and corporations, but the industry's increasingly introspective focus on developer experience means we've saddled ourselves with an over-reliance on JavaScript. Sadly, fantastic as they are, projects like Wayback Machine can't keep up with how we've reshaped the industry. Many of the heavily JavaScript-based sites we're now making just can't be archived in the same way as HTML could. Just like all of the Flash-only sites of the early 2000s, what we're building today risks our work being totally lost to history.

It's funny that, as developers, we often talk about "legacy code". For us though, the word "legacy" isn't used in terms of something to preserve the past. More often than not, "legacy code" is something to be refactored, replaced or removed altogether in the name of progress. Without necessarily realising it, we have unconsciously accepted the temporary nature of our work into the language of our industry.

This is all to say that, at the end of the day, perhaps it's the nature of digital things that they just aren't meant to last.

The ephemeral nature of (digital) things

It is the ephemeral nature of things that makes them wonderful - Yoshida Kenkō, 1283 – 1350

Up until now, you'd be forgiven for thinking that this post was a bit of a downer. But, honestly, I don't want to see any of this in that light.

Prior to joining the industry, I didn't formally study web development but rather social and cultural anthropology. The quote above is something I read in my university days which still sticks with me. Perhaps, rather than getting caught up in a bleak everything-ends sensibility, the steady destruction of our past work should be seen as a strength.

That humanitarian campaign I worked on was only destined to run for a short time and, because of that, the team pulled together to make sure that we got it right in the time we had. If the initial impact is great enough, the need for preservation is secondary. In many ways, a finite shelf-life is an opportunity to be better.

I want to get more comfortable with that idea, so I've been thinking of how to get there. Here's my plan going forward:

Wherever possible, use tried-and-tested tech. Stay as close to the platform as possible. Fewer moving parts means fewer chances to break and resiliance creates longevity. Look, I know that it's a massive cliché at this point, but there's a reason that Space Jam's website is still online.
Longevity shouldn't always be the goal and you need to be comfortable with letting go. Your work is ultimately not your own and today's shiny new tool is tomorrow's technical debt. Tools are rarely worth fighting for, but the thing you're building should be. If the work is only going to be around for a short while, try to make the most impact on the people who will use it. Focus on their experience over your developer experience.
Code like you think no-one's reading. Try not to get hung up on "good code" and burn yourself out on over-engineering the perfect, scaleable solution. That scaled-up future may not happen so solve the user's problem first, then iterate it to solve the code. (Remember the bowl).
Back in December I mentioned how I wanted to make more things "for the sheer hell of it". I realise now that this isn't just great for creativity, but it also helps with attachment. Make more things for fun. Prototype, build sites that are intentionally throwaway and play with your code. Things built for only yourself are no less important than the things built for others. Think of these projects as recycling – the project will live on in the new skills you use for your next bit of client work.
Lastly, if you do ever find yourself having to put in unreasonable hours to get a job done, make damn sure it's for a cause you'll care about and remember in fifteen years.

Will I stick to all of this? probably not. Will doing any of it have an effect? most definitely.

After more than 15 years, I don't see the industry suddenly shifting to a preservation mindset but that's fine. I want to focus on doing the best work I can right now. In the end I probably won't have a box of my work in the garage but, ultimately, I think I'll be OK with that.

Hand-thrown frontends

2023-01-19T00:00:00-00:00

I've been thinking about my approach to frontend a lot recently and an analogy that comes up pretty consistently when talking about building user interfaces is that the frontend development process should be like efficiently assembling a model from Lego bricks.

With the web industry's shift towards agile, feature-focused methodologies and componentisation, this analogy certainly makes sense. To be honest though, I've personally never really seen frontend as an assembly job. Lego is admittedly awesome, but for me the mental model of assembling Lego bricks in the required order until a Jira ticket can be marked as "done" feels too linear and too rigid for how I like to work. And that's not to mention the pain that comes when you have to partially dismantle your bricks to correct some earlier misstep.

I know that it's almost certainly because I came to frontend from a creative background rather than a compsci one, but I've personally always seen frontend as more about iteration or refinement. Not to be too artisan-code-wanker about it, but it helps me to reason about my process if I think about it more like working with clay:

When you're working with clay, you always start out with the same, rough raw material. It definitely isn't perfect, but it has possibilities. If you manipulate, shape & tweak it the right ways, those possibilities will start to take form. You're no longer just working with clay, you have a thing. Over time, and with enough coaxing, perhaps that thing starts to look like it might be a bowl. Sure, it might be a bit crude – it's lopsided and the structure is just all over the place – but it's definitely concave enough to hold water.

You're not shooting for core functionality though, so you go back again and hone that shape so that everyone knows without a shadow of a doubt that it's a bowl. Maybe you raise it up a bit to give it space to breathe and straighten out the edges so the shape reads better. You might give it more structure in the areas that were fragile and you might also thin out the parts where the clay was laid on too thick. Now, this might not happen in one pass, but with enough time and care you'll eventually arrive at something that could only ever be described as a bowl. You may still want to add some extra nuance and fine detailing at this point, but your bowl is ready to go into the kiln and be fired.

Firing the bowl doesn't have to be the end of the process though. Your bowl is well-structured, the weight is balanced and it holds just the right amount, but you might want to give the aesthetics some love. Maybe you could look at painting it, or giving it a lush teal-amber glaze. Given enough time you could do pretty much anything you want but, though the tools might be different, the same rules apply. You'll still need to take care not to overdo it – if the bowl cracks it might leak, which would both undo all your hard work and make for a pretty crappy bowl.

So, for me, the ~~frontend~~ bowl-making process is a cyclical, non-linear one. On a surface-level it probably doesn't seem like it's as efficient as assembling Lego bricks to order, but over time you'll make more bowls and each phase of iteration will gradually shorten as your skill increases towards mastery. Where you once might have gotten hands-on and worked on-the-fly, you'll prepare all of your tools and materials in advance and you'll have the experience to foresee where things might go wrong. The steps of your process aren't always going to be the same – sometimes you'll be making a plate or a mug – but you have built up a feel for how the clay works, you respect its limits and you can shape it into most anything.

I mean seriously, what even is a plate if not a slightly-flattened bowl?!

So long, 2022

2022-12-31T00:00:00-00:00

It's been a little while since I did a year in review post, so let's get that out of the way first. For all the wild unknowns of 2020, 2021 was a landmark year but for, sadly, all the wrong reasons.

In September '21, I lost my dad. Just over a month later, my partner lost her wonderful step-dad. Come the end of the year, and in the shadow of that combined grief, my drive to talk about literally anything else that happened in 2021 was at absolute zero. I skipped the blog post.

Now a year on, as we're closing out 2022, I've realised that writing (publicly or privately) helps me to organise my thoughts and, in a roundabout way, helps me to reach some amount of closure. 2022 has absolutely blinked by so, in that spirit, I feel that this time a year-and-a-bit-in-review post might help to make things a bit less rushed.

Work

Please understand that, as I'm British, I am hardwired from birth to hate any kind of own-horn-tooting. That said, experiencing such a huge loss in 2021 has made me realise that I need to properly celebrate my wins when they happen. In that spirit, here's a bunch of positive work-related things that made me feel good in 2022.

Please forgive me as I commence tooting:

After dad died, I finished up my last contract and took some time off work to be with my family. When January 2022 rolled around, the year kicked back into gear with the launch of that final '21 project – I had an absolute blast working with the talented team at True Digital to build the frontend for the new Aardman website. As a teenager I had actually dreamed of studying animation and working at Aardman, so it was such a pleasure to work on something with so much scope for building fun little interactions and animations.
Despite taking time off at the end of 2021, I managed to stay booked throughout the whole of 2022 and worked with some truly awesome people on everything from brochure sites to design systems and web apps.
I said no to a lot of projects this year. That might seem like an odd thing to celebrate, but in past years I have really struggled with burnout. Turning down more projects and forcing myself to take at-a-bare-minimum a week between projects felt like a really positive step in staying healthy. I'm not going to say that I didn't feel overwhelmed at times this year, but I'm looking forward to saying "no" a lot more in 2023.
I'm not really sure that I've nailed my unofficial goal of blogging more in 2022, but I did manage to fit in a handful of blog posts this year. One of them, based on a hologram technique that I'd first tried out back in the skeuomorphic mists of 2010, proved quite popular. Ultimately that post was shared on the orange site, which culminated in a funny couple of days seeing my site's normally meagre bandwidth spike – no, rupture – to around 60gb in 48 hours (remember that a compressed png can be much smaller than an SVG, folks 😅)
To my endless surprise, the continued enthusiasm for my Synthwave '84 VS code theme carried it past one million downloads at the start of September. I really will do a light version one day, I promise.
In late summer I got a surge of Twitter DMs and emails from strangers. Normally that's a signal that Synthwave's glow has stopped working again, but this time it was thankfully more fun. Unbeknownst to me, YouTuber Gary Simon's DesignCourse channel featured this website in a roundup of developer portfolios and it was driving a lot of enthusiastic people my way...
...and then, in October, that momentum got this site nominated for the "Personal website of the year" award at Jamstack conf's Jammies. I didn't win, but it was a huge confidence boost to know that people liked my work enough to place me alongside such talented finalists.
Also in October, my partner and I were able to attend WDC in Bristol together. It was my first conference since New Adventures in January of 2020 and I've definitely missed the conf buzz. Hearing such fantastic talks and hanging out with the speakers and attendees was both amazingly fun and hugely inspiring in equal measure. In 2023 I'm definitely going to be attending more, and * maybe * even think about writing a talk of my own.

Looking forward to 2023

I've tried to avoid making this post about the sudden increased speed of big-tech-corporations imploding, but the whole thing and the subsequent shift to open-source alternatives like Mastodon has left me feeling positive about the future of the web in 2023.

I absolutely love my work, but for a long time now I've been feeling a bit out of step with the industry as a thing. The endless Twitter arguments about which new frontend framework makes you a Real Developer have left me disengaged at best and, at worst, almost drove me off of social media entirely. Now that the old world-as-we-knew it is starting to look a bit more fractured, I'm feeling oddly more upbeat.

As someone who cut their web-development teeth on Geocities, I couldn't be any more here for the sudden resurged interest in owning your own content. The momentum is infectious and in the coming year I'd love to see conversation shift even more. Tools are hugely important of course, but I'd much rather hear more about what we're making, than how we're making it. Even bigger than that, I'm hoping to see less emphasis on the FAANG model of corporate gains, OKRs, KPIs and WTFs – I want to see industry focus shift to smaller projects and, more importantly, the lives, aspirations and emotions of the humans building them.

For perhaps obvious reasons I haven't dwelled too much on my personal life in this post but, speaking for this human, everything I experienced has made me realise two fundamental truths: Life is short, and we don't have the time to take things too seriously.

I'm going to spend the next year making more time for my family, and creating more space for personal projects and building weird/cool stuff for the sheer hell of it. I'm going into the new year feeling energised – Here's to a healthy and happy new year in 2023!

The Jammies 2022

2022-11-08T00:00:00-00:00

To my surprise this website was recently nominated for the "Personal Website of the Year" award at Jamstack Conf 2022! To be nominated as a finalist in this category, both by a public vote and alongside two seriously creative websites from John Beresford and Lynn Fisher, is a real honour.

I wanted to write a quick post to say a huge thank you to anyone and everyone who nominated or voted for this website. This site isn't just a personal website, it's also the online face of my business, and the recognition that this kind of event brings is such a huge boost. Cheers, you're awesome! 🍻

Most importantly of all though, I want to say a massive congratulations to Lynn Fisher for bringing home the win. Lynn's annual website update is always super creative, and I'm stoked to see that she picked up a very well-deserved golden jam jar. Lynn's work is a constant source of inspiration for me, and I can't wait to see what the next iteration of her site brings!

(I might have missed out on the award this time but, in recording my conference clips, I did get to make this excellent reaction gif 😆)

Holograms, light-leaks and how to build CSS-only shaders

2022-07-07T00:00:00-00:00

I might be understating it a bit, but WebGL is a big deal. You only need to spend five minutes on one of the many design awards sites to see site-after-site fully leaning into the power of canvas. Tools like threejs make it easier to harness the power of 3D and GLSL shaders and, with that, a whole new level of visual effects.

This got me thinking though; why let JS have all the fun? With mix-blend-mode finally gaining wide browser-support, we now have access to many of most common shading techniques in CSS. With some choice images and a bit of careful layering it's possible to build some surprisingly high-quality effects without the need for introducing any JS dependencies.

Let's take a look at an example. As you scroll past the image below, the sunlight blooms a warm orange, before fading to a cool blue. You'll also briefly see some lens bokeh.

Ooooh shiny. Let's break it down.

What is a CSS 'shader'?

Shaders in the WebGL world are complex GLSL scripts that determine how each individual pixel is rendered to the screen. We still don't have that level of control in our CSS so, at its most basic level, our CSS 'shader' is just an image with additional background-image layers above it. Yes, I'm taking a few liberties with the name but with careful use of gradients, masking, nesting and mix-blend-mode we can manage how these layers interact with both one-another and the image at the bottom of the stack.

For the sake of visualising this core structure, the 'shader' example above is set up with a few nested divs:

<div class="shader">
  <img src="tower.jpg" alt="Asakusa at dusk">
  <div class="shader__layer specular">
    <div class="shader__layer mask"></div>
  </div>
</div>

To keep each layer aligned with the image at the base, we keep the nested content positioned with the following CSS:

  .shader {
    position: relative;
    overflow: hidden;
    backface-visibility: hidden; /* to force GPU performance. More on that later */
  }

  .shader__layer {
    background: black;
    position: absolute;
    left: 0;
    top: 0;
    width: 100%;
    height: 100%;
    background-size: 100%;
  }

Ok, with the basic layout taken care of, lets take a look at the first layer of our effect - the lighting.

Simulating specularity

First of all we need to think about how light travels from light to dark across the surface of our image. We'll need an area of brightness where the light is at its most intense, falling off gradually into darkness as the light dissipates. We'll do this with a gradient.

.specular {
  background-image: linear-gradient(180deg, black 20%, #3c5e6d 35%, #f4310e, #f58308 80%, black);
}

If you imagine looking at a shiny surface, the light that reflects back is known as a specular reflection. How and where that highlight appears is dependant on the light source, but also your viewing angle - the highlight moves with you. Whilst our gradient is looking lovely, it's all a bit static. We'll need to introduce a bit of movement to really sell the effect.

Fortunately, there's a vintage CSS Level 1 property that can help with that; setting .specular to background-attachment: fixed means that, as the page scrolls, the gradient remains locked to the browser's viewport. This not only brings some much needed motion to our shader, but also means that we can very roughly simulate the changing view-angle without reaching for JavaScript.

.specular {
  background-attachment: fixed;
  background-image: linear-gradient(180deg, black 20%, #3c5e6d 35%, #f4310e, #f58308 80%, black);
}

Great! Now, let's get to applying this lighting to our base image.

Know your blend modes

As the name implies, mix-blend-mode mixes the colours of each pixel in one element layer together with the layer directly below it. As with GLSL, CSS gives us a nice long list of options to choose from, and creating the right effect means knowing which blend is going to give the results we need. But what do these blend modes actually do? Before we get stuck in with our shader, let's take a quick look at the blend modes we'll be using.

Below you can see the images that we'll be using for these examples. On the left is the upper layer to be blended, and the right is the base image we'll be blending onto.

First off, let's look at a multiply blend. Multiply takes the colour of each pixel in the current layer and multiplies it with the colour of the pixel directly beneath it. In practice this means that darker colours in the current layer will obscure those in the layer below:

Setting the blend to screen takes the inverse of each pixel and multiplies them before inverting the result. This might sound complicated, but you can think of screen as the opposite of multiply - Darker colours become transparent and only the lighter colours will show through to the layer below:

Lastly, color-dodge and color-burn are like taking multiply and screen into overdrive. Both modes divide the pixel colour on the base layer with the one in the current layer.

For color-dodge this means that highlights and midtones get blown out whilst dark tones have no affect at all. color-burn will boost shadows and darker midtones, whilst lighter tones have no affect at all.

In the image below, the left example is color-dodge and the right is color-burn.

Compositing layers

Now we know what we're working with, it might seem like the next step would be to slap a blend mode onto our gradient, place it over our base image and call it a day. That will definitely work, but it won't reach the level of quality we're going for.

Blending the gradient directly to the base layer will mean that the lighting will be totally uniform across the image. Aside from chromed surfaces, that doesn't happen too often in nature. To really sell the effect we want to have control over the areas of the image where light can fall and where it can't. To simulate this, we can use a predominately dark image to mask out our gradient. This technique of using a dark image to mask off areas of a lighter one is often known as a specular map.

You might be wondering how it will be possible to do this with CSS if mix-blend-mode only affects the pixels in the layer directly below it, and we can only set one blend mode at a time. This is where our HTML structure starts to shine.

<div class="shader">
  <img src="tower.jpg" alt="Asakusa at dusk">
  <div class="shader__layer specular">
    <div class="shader__layer mask"></div>
  </div>
</div>

By nesting div layers inside of one another, we can work outwards applying additional mix-blend-modes to each wrapping div. Essentially, this lets us add another mix-blend-mode to the output of the previous blend. This process of layering different blend modes to produce a final output is known as compositing.

Let's give it a try. Using a suitably dark background-image we'll set mix-blend-mode: multiply on our .mask layer and throw away the parts of our gradient where we don't want light to show through.

.mask {
  mix-blend-mode: multiply;
  background-image: url(/tower_spec.jpg);
}

.specular {
  background-attachment: fixed;
  background-image: linear-gradient(180deg, black 20%, #3c5e6d 35%, #f4310e, #f58308 80%, black);
}

Now that we have our specular map, we can apply the final lighting to the base image. We need to use one of the blend modes that ignores black and dark tones. This means that we should set our .specular layer to use mix-blend-mode: screen or mix-blend-mode: color-dodge. Either would work in this case, but because we want the highlights to blow out into a nice sunlight-bloom effect, we'll go for color-dodge.

Let's take a look:

.specular {
  mix-blend-mode: color-dodge;
  background-attachment: fixed;
  background-image: linear-gradient(180deg, black 20%, #3c5e6d 35%, #f4310e, #f58308 80%, black);
}

The final shader

And with that, the effect is complete! Here's the completed HTML and CSS:

<div class="shader">
  <img src="tower.jpg" alt="Asakusa at dusk">
  <div class="shader__layer specular">
    <div class="shader__layer mask"></div>
  </div>
</div>

<style>
  .shader {
    position: relative;
    overflow: hidden;
    backface-visibility: hidden; /* to force GPU performance */
  }

  .shader__layer {
    background: black;
    position: absolute;
    left: 0;
    top: 0;
    width: 100%;
    height: 100%;
    background-size: 100%;
    background-position: center;
  }

  .specular {
    mix-blend-mode: color-dodge;
    background-attachment: fixed;
    background-image: linear-gradient(180deg, black 20%, #3c5e6d 35%, #f4310e, #f58308 80%, black);
  }

  .mask {
    mix-blend-mode: multiply;
    background-image: url(/tower_spec.jpg);
  }
</style>

Let's take another look at the completed effect, but this time with the added ability to isolate each layer of the shader. Change the view mode dropdown to step through the effect and get a better idea of how the layers work together to produce the final image:

View mode:

Taking it further

In the example above, we used a greyscale version of the main image (with added scratches and bokeh) as a mask. That's a great way to add interest to an image, but shader layers can be whatever you want them to be. Let's look at a few more examples.

Aurora Borealis

In this example, repeating the gradient background gradient and reducing background-size-y causes the light effect to move more quickly across the screen. When masked out with a specular map, this creates the illusion of an aurora rippling over the main image. Blown-out highlights with colour-dodge creates the wrong effect here, so swapping our .specular layer to mix-blend-mode: screen maintains the sharp definition of the aurora.

View mode:

Light-leak

Until now the examples have all used a greyscale specular map, but a full colour specular map can introduce new effects. In this example the mask image is created from an inverted and blurred version of the primary image, with a blue-red tone overlaid on top. When it's all layered together with a hot red-orange gradient, the resulting blend of colours results in something that looks a little like the light-leaks you get on vintage film cameras.

View mode:

Hologram

Layering within the mask opens up even more possibilities. What would happen if we add another layer with background-attachment: fixed?

In this final example the mask layer has a background image SVG, and another black-white gradient running at the opposite angle to the specular gradient in the .specular layer. Setting the nested mask layer to color-burn causes it to blow out the definition of the SVG and you get this sweet two-way holographic look. CSS is awesome.

View mode:

Wrapping up

I've said it before, but it bears repeating: modern CSS is such an amazing tool to work with and I'm consistently impressed with the level of fidelity you can achieve. That said, It's time to address the potential elephant in the room. Depending on the device or browser you've used to read this article, your scroll performance might be on the floor and your fans may have kicked up a notch.

At the time of writing, blend modes in browsers are still pretty resource heavy. For more complex effects, with several layers of compositing, you will see a real performance hit. Add any CSS animations or transitions to the mix and it will really tank - particularly in Safari. After a bit of tweaking I eventually managed to claw back a bit of a performance boost by using backface-visibility: hidden, but my initial impulse was to force GPU rendering by using the trusty transform: translateZ(0); hack. Sadly, adding a transform revealed another quirk to be aware of.

Due to the reliance on background-attachment: fixed, applying CSS transforms to the shader can cause some strange side-effects. In Chrome it broadly works, but the gradients may appear offset depending on the transforms applied. Firefox on the other hand, will simply ignore the fixed positioning and your gradients will totally appear static. I'm sure there are ways and means around that, but they'd likely be testing the spirit of doing all of this without using JS.

All-in-all this was really fun to explore. Sure, we can't get quite the same level of fidelity as GLSL, but for simpler effects this technique is a great alternative to introducing extra libraries to your project. As great as these effects can look though, I think that for now this is very much a case of: just because you can, doesn't mean you should.

Until CSS filters and blend modes become more performant (or until browsers allow linking GLSL filters directly from CSS 🤞) restraint and subtlety might be the best way to go.

Image credits

The demos in this article use a collection of images or composited textures made available by the Unsplash photographers below. Please go check out their beautiful work.

Bokeh lights by Hello I'm Nik
Silhouette of pine trees under stars by Joshua Woroniecki
Aurora by Johannes Groll
Lake under blue sky by Juan Davila
Vintage dashboard by Wassim Chouak
Light leak by Sean Sinclair
Scratches by Dan Cristian Pădureț

Mind your language

2022-07-05T00:00:00-00:00

The web has a diverse global audience and the websites and apps we build have to cater towards a wide range of languages, scripts and dialects. Developing for multiple languages isn't as simple as bashing the text onto the page though. As developers, we need to take extra care to present multi-lingual content in the most natural way possible. Fortunately, HTML and CSS present us with a few options to enhance the reading experience of our users.

If you find yourself needing to design or develop content to work in multiple languages, here are five tips and gotchas that might help things run more smoothly:

1. Fonts and diacritics

Have you ever heard the works of the Czech composer Antonín Dvořák? Perhaps you might have visited the beautiful Latvian city of Rīga, or strolled lazily through the Champs-Élysées in Paris?

Ok, so contrived example text aside, choosing a webfont with wide accent (or 'diacritic') support can be a real quick-win when designing for multi-lingual content.

It's easy to take for granted, but not all fonts cover the full range of diacritic marks and this can be particularly noticeable with brand or display fonts. In fact, a quick look at Google Fonts shows that even some of the most popular webfonts struggle.

Wherever possible, make sure to check support before deciding on your webfonts. If you're stuck with a font that doesn't include the diacritics you need, you needn't worry though. In the event that your primary font doesn't include a particular diacritic mark, browsers will render the missing character with the next available font in your font-family stack.

To avoid harming your design with clunky, mismatched text like the example above, make sure that the fonts in your stack are as close a visual match as possible:

Match the type of fonts. If your primary font is a serif, your fallback fonts should all be serif fonts. The same goes for for sans-serif or monospace fonts. Swap like for like.
Match the x-height of your fonts to ensure the size is similar. Mismatched fonts might appear taller than others, leaving your content looking ragged or uneven.
Match the contrast or weight of your fonts to ensure that missing characters don't appear thicker or thinner than the primary font

All of this might seem obvious but take a quick look through the font choices on Instagram stories and you'll see how easily font stack can slip through the net.

2. The `lang` attribute

Another useful tool for improving the semantics of multi-lingual content is the lang attribute.

The immediate benefit of setting a page-level lang attribute on the html tag is that search engines will know how to index your content. More importantly though, the lang attribute will inform assistive technologies such as screen-readers which accent and dictionaries to use when reading the content aloud. When a language code is combined with a regional subcode, for example en-GB, the results can get even more granular – as Michelle Barker writes, the subcode can also be used to specify the regional dialect of a screen reader.

Beyond assistive tech, setting the lang attribute is also beneficial to our CSS. When the attribute is set, we can use the :lang pseudo class to style content based on language. For example, the following CSS could be used to serve a specific font stack to any content that matches :lang(ar)

:lang(ar) {
  font-family: 'Noto Sans Arabic', sans-serif;
}

If you need more fine-grained control, the :lang selector also stacks codes and regional subcodes. With the following CSS snippet, content nested under a lang attribute of en-GB would be both blue and bold, but content with en-US would only be blue:

:lang(en) { color: blue; }
:lang(en-GB) { font-weight: bold; }

The `lang` attribute and character sets

There's one last feature that the lang attribute provides for CJK languages in particular that might not be immediately obvious to people unfamiliar with those languages.

Chinese, Japanese and Korean all use idographic characters but, as with all languages, usage has changed over time and so have the characters themselves. A hanzi character used in traditional Chinese, might be considerably different to a Japanese kanji or Korean hanja character of the same meaning. In a attempt to minimise the number of character variations, the unicode maintainers decided that all variations should be linked together under a single unicode point. This was known as the Han Unification and it's pretty controversial.

Why does this matter for typesetting on the web? Let's take a quick look – Below is the same character (U+8FD4) repeated five times:

返返返返返

Now let's try that again, but this time setting the lang attribute for each from left to right: Simplified Chinese, Traditional Chinese (Taiwan), Traditional Chinese (Hong Kong), Japanese, Korean.

返返返返返

  <span lang="zh-ZH">返</span>
  <span lang="zh-TW">返</span>
  <span lang="zh-HK">返</span>
  <span lang="ja-JP">返</span>
  <span lang="ko-KR">返</span>

Without setting the lang attribute, the browser doesn't have any knowledge of which language you are using and will default to its best guess. These characters might look similar, but they're distinct between languages. For speakers of CJK languages, a word or phrase displaying the wrong character variant might still be readable, but it will look a bit jarring.

Setting the lang attribute ensures that browser renders the character appropriate for the target language. It's also important to note that the region subcode of the language definition is helpful here too - zh-ZH, zh-TW and zh-HK are all under the zh macrolanguage code, but the character still differs by region.

All-in-all, the lang attribute is an vital tool in removing ambiguity from our multi-lingual content.

3. Direction and writing mode

Another common requirement of typesetting different languages is how to handle right-to-left scripts such as Arabic or Hebrew.

Simply entering RTL text will flow the text properly, but the alignment of elements to the page itself will be off:

أنا أسف ، لا اتكلم عربي جيدا

<p lang="ar"> أنا أسف ، لا اتكلم عربي جيدا</p>

Fortunately HTML gives us a handy way to set the writing direction with the dir attribute. Setting dir="rtl" on the html tag will flip the text direction for the whole page, but you can also set it at text-level on individual elements. Let's take another look:

أنا أسف ، لا اتكلم عربي جيدا

<p lang="ar" dir="rtl"> أنا أسف ، لا اتكلم عربي جيدا</p>

Much better!

There's more to text direction though – RTL is not the only alternative writing mode. Some scripts such as Japanese or traditional Chinese can have a vertical writing mode, written from top to bottom and from right to left. This was historically much harder to handle in CSS, and for a long time it was common to fake vertical text with a questionable combination of word-break: break-all and a width of 1ch. Fortunately with writing-mode gaining support in all major browsers, there's a better way. This property gives us the abillity to easily set lines of text to run vertically and in either direction. A value of vertical-lr sets it from top to bottom, left to right. vertical-rl flows lines of content top to bottom, right to left.

But how much of a difference does this actually make vs the 'creative' method of using word-break?

Take a look at the Japanese-language examples below. On the left is vertical text faked with word-break. On the right is text set correctly with writing-mode: vertical-rl. The differences might seem subtle at first, but they're immediately obvious to anyone who reads Japanese:

1980年代のストリートファッション

Ok, before we move on, you might have noticed the conspicuous split between controlling text direction with the dir attribute in HTML and then writing-mode in CSS. Personally, I find this to be a little confusing. Fortunately though, it looks like the CSS spec agrees and there is an experimental specification for writing-mode that will bring sideways-lr for LTR languages and sideways-rl for RTL languages. Currently this is only supported in Firefox, but here's hoping it gains wider support.

4. Logical CSS properties

Building on the last point, we can now get our text orientated properly. But what about padding and margin?

Traditional margin and padding CSS properties specify a direction: top, right, bottom or left. These are fine for LTR languages, but when writing mode changes, these properties won't take direction into account and may break your designs. Fortunately with CSS Logical properties, we now have access to direction-aware alternatives.

Where you would have previously used padding-left and padding-right, you can instead use padding-inline-start and padding-inline-end. Similarly for padding-top and padding-bottom you can now use padding-block-start or padding-block-end. The same pattern works for margins.

The great thing about these new properties is that for LTR languages, they're totally indistinguishable from the standard padding properties. Below is an example in English, the first uses padding-left and the second uses padding-inline-start.

Half-fat decaf soy-milk caramel latté

<p lang="en" style="padding-left: 40px">Half-fat decaf soy-milk caramel latté</p>
<p lang="en" style="padding-inline-start: 40px">Half-fat decaf soy-milk caramel latté</p>

When you find yourself supporting an RTL language though, these new properties suddenly make all the difference. Let's compare:

القهوة العربية الأصيلة

<p lang="ar" dir="rtl" style="padding-left: 40px">القهوة العربية الأصيلة</p>
<p lang="ar" dir="rtl" style="padding-inline-start: 40px">القهوة العربية الأصيلة</p>

The huge benefit of using logical properties is even more obvious when using a vertical writing-mode. As with the previous examples, for the first example we're using padding-left and on the second we're using padding-inline-start:

水出しコーヒー

At the time of writing, CSS Logical properties are really widely supported so there's every reason to start using them today. If you'd like to know more, you can read more about logical properties on MDN

5. Form validation

This last point is where things get a bit tricky. The main point of contention is that, as web developers we need form validation to keep the web secure. At the same time though, we need to be mindful that our security measures don't unintentionally alienate or block users from using our websites.

A cursory web search for name validation rules throws back regex patterns like this:

<input name="firstname" value="" required pattern="^[a-zA-Z ,.'-]+$" />

This validation pattern definitely allows for a wide range of name punctuation but at the same time it would exclude a vast number of people who have accents, diacritics or non-Latin characters in their names. It's possible to extend this regular expression to include a wider range of accented characters, but making sure that all bases are covered can quickly become a maintenance nightmare.

A common approach to this challenge is to simply ask users to write their name without diacritics. Whilst this would certainly pass validation rules, this is not a true solution. Rendering a character without its diacritic can sometimes change the meaning of a word and names are a deeply personal thing that vary widely by culture and by language. Regardless of the intent, to build with assumptions on what constitutes a valid name risks excluding those who fit outside of those assumptions.

My recommendation for the most inclusive strategy? Make sure you do all of your usual security checks for script injection etc. but, wherever possible, don't validate the individual characters in a user's name. After all, as Patrick McKenzie wrote in the evergreen essay "Falsehoods programmers believe about names", it's near-impossible to get it right.

...Oh, and one last thing. If you absolutely have to validate names then make sure that any feedback messages put the blame firmly on your systems. Telling a user that their name is 'invalid' is rarely a good look.

Wrapping up

This post is just scratching the surface, but hopefully illustrates how important it is to handle multi-lingual content with care. Here's a quick summary of what we've looked at:

Choose fonts with good support for accents and diacritics and build a solid font stack to handle missing characters
Always set the lang attribute to let the browser know what language your content is in
Set horizontal text direction with the dir attribute
Set vertical text direction with the writing-mode css property
Use logical properties for padding and margins to ensure that layout changes won't break your design
Where possible, avoid validating name inputs and write conscientious, user-friendly error messages

HTML and CSS will get us far, but it's worth noting that there are no one-size-fits-all solutions for getting multi-lingual content right. I'd still advise that, wherever possible have your work reviewed by a native-speaker. That goes double if you're developing content for a language that you yourself don't understand.

That said, over the years I've found that following these steps can provide a solid foundation for building flexible, multi-lingual content.

Getting started with Go

2021-07-08T00:00:00-00:00

Lately, it seems like Go (or sometimes, Golang) is having a bit of a moment.

Developed by Google, Go has been around for just over a decade now but over the last year it seems to have been steadily gaining in popularity on social media and Github. Given its versatility, It's perhaps easy to understand why - Go has been used for everything from CLI tools to building high-profile devops software like Docker and Kubernetes.

One thing that might be less immediately obvious though, is that Go is also equally well suited to building web apps and APIs. In fact, as a JavaScript (or TypeScript) developer, Go has a lot to love:

Simple syntax - Go was designed in a way that, once you know the core syntax, you should be able to read anyone's code. In fact, there's officially only one way to write Go code, and the excellent language tooling will keep you on the straight and narrow. There'll be no time wasted deciphering someone else's "clever" one-liners!
Statically-typed, compiled language - As with a language like TypeScript, typed variables mean that it's easier to manage bugs. The compiler does a lot of heavy lifting here too - you can't even compile your code if you have any unused variables knocking about in your codebase.
Asynchronous code and concurrency - Go was built with concurrency in mind and features 'go routines' to manage multi-threaded, asynchronous code
Cross-platform - The Go compiler allows you to build cross-platform applications which are easy to deploy pretty much anywhere. You don't need even to deploy your sourcecode, just the compiled binary.

As for me though, all of that stuff is kinda secondary.

You see, Go comes with a very powerful standard library (stdlib) that means that you can really do a lot without needing to reach for a framework. Coming into the language from the JS world, which often relies heavily on third-party packages from NPM, it can initially seem really counter-intuitive to be writing so much low-level code. On the contrary though, I've found that writing Go has led me to better understand certain concepts that other languages and frameworks such as Express or Rails have let me 'magic away' in the past.

The Go way of doing things feels very considered and deliberate; it makes me feel like I'm learning more deeply about how the web works in general, and I love that.

For me, writing Go is just – dare I say it – fun.

Let's build something

Ok, enough about why I like Go. If any of the above sounds appealing but you're not sure where to start, then this post is for you.

That said, this tutorial isn't intended for anyone who's already started writing Go - it's going to deliberately be very bare bones. For the sake of brevity, I also won't be spending much time covering core programming concepts too much. Prior to learning Go my primary language was JavaScript and I suspect that many of you who will be reading this will be somewhat familiar with that language. When I do make comparisons with other languages, it will be to JavaScript.

With all of that out of the way, let's go.

(I'm not even sorry for that pun)

Preparing to work with Go

Thankfully, getting set up for Go development is not as complicated as some other languages. Before we start, I'd suggest completing the following three steps:

If you're not already using it, I'd strongly recommend downloading and using VS code
Download and run the Go installer. At the time of writing the latest Go version is 1.16
Install the Go VS code extension to enable intellisense, auto-imports, linting and more.

Starting a Go project

If you've done any JS development, you're probably familiar with using third-party code from NPM.

Go uses the concept of packages in a similar way, but for quite a while Go didn't have an official means of managing project dependencies. Several package management solutions popped up to try and make development easier but, in my experience, having a wide range of package managers made things a lot more confusing.

Thankfully though, Go 1.13 introduced go modules as the de facto means of managing your application's dependencies. Coming from the JS world, Go modules uses the go mod command in a way that might be familiar.

Let's initialise a go modules project. Create a folder for your project and from the root open your terminal and run the go mod command, replacing <PACKAGENAME> with the desired project name:

go mod init <PACKAGENAME>

You can choose whatever you want for this name, but be aware that it needs to be unique.

Later on we'll be importing external packages, so we will need to make sure that our application's package name doesn't clash with any future dependencies. Understandably, seeing into the future is a big ask. To mitigate name-clashes there's a Go convention of using your project's github path or a website url as the package name.

Let's try it. You can use whichever name you want, but I might run something like:

go mod init robbowen.digital/go-intro

When the command has finished, we will now have a go.mod file in our project root. Inside, it will look a little something like this:

module robbowen.digital/go-intro

go 1.16

We don't need to worry about this too much for now, but this file specifies the name of our root module (our application) and the version of go that it requires. If you know JS, the go.mod file functions like a package.json.

Our first file, and the main package

Go uses the concept of packages to group code and all Go applications start with a package called main. You can think of it a bit like the entrypoint of a JS bundle - the main package runs first, and everything else branches out from there.

We can declare which package a particular file belongs to with the package keyword. Let's create a file in our project root called app.go. Inside the file, let's declare that this code belongs to main.

package main

The package declaration is the first step, but we will also need to tell the go compiler where our application actually starts. Inside of our main package, we will need to declare a function, also called main. Functions in Go look a lot like they do in JavaScript and use the func keyword.

In our app.go file, let's prepare a main function for our application.

package main

func main() {
  // application code will go here
}

Nice, that's everything we need to get started.

At this point you might have noticed that we're not calling main() anywhere, and you'd be correct. Go will automatically call main() when our application runs. To see that in action we'll need to update our code so that it actually does something.

Let's write a message to the terminal. For that we're going to need to use the fmt a package from the Go standard library. The name fmt stands for format and, in case you were wondering how to say it out loud, is usually pronounced like "fumt". Inside of this package there's a handy function called Println that we can use to print a message to the console.

Let's update our main function:

package main

import (
  "fmt"
)

func main() {
  fmt.Println("Aw yiss")
}

If you're coding along in VS code, you might have noticed that you don't actually need to add that import line to the top of the file. Typing fmt. should prompt intellisense to show you the available functions and, whenever you save a Go file, VS Code's language server should automatically add all of the appropriate imports.

Let's build and run our application.

From your terminal, you can run your new program with

go run main.go

Hell yeah, you're now officially a Go developer 🎉

Variables and types

At the moment we've hardcoded that message, so let's move it to a variable.

Variable definition in Go will be familiar to a JS dev, and even moreso if you've dabbled with TypeScript:

var myString string = "Aw yiss"
var someNumber int32 = 37
var mmmPie float32 = 3.14159
var myBool bool
myBool = false

The var keyword followed by a name defines a new variable. Being a typed language, the variable's type definition comes next (there's a full list of the available types in the Go documentation).

Lastly, you're free to specific an initial value but Go is statically typed, so bear in mind that the type of a variable cannot change type.

var someNumber int32 = 37
// this won't work
someNumber = "thirty seven"

Shortform variables

Writing var and the type out every time you need a new variable can get a bit tedious, so Go also provides a handy shortform syntax. This shortform doesn't include a type definition and instead assigns a type by inference. If that last sentence meant nothing to you, don't worry. The shortform allows us to set a variable and let the compiler worry about what type it is.

message := "Aw yiss"

Most of the time, you're going to be using this syntax. There are two caveats to be aware of when using this little walrus-looking lad though: Firstly the := is only used when you first define a variable. Reassignment the value is done with =.

message := "Aw yiss"
message = "some new value"
// this won't work as the variable is already defined
message := "yet another value"

The second caveat is that the short syntax can only be used within a function. Defining package-scoped variables must use the var syntax. We don't really need to worry about this one for now, though.

Ok. Let's update our application to pass the message as a variable.

package main

import (
  "fmt"
)

func main() {
  message := "Aw yiss"
  fmt.Println(message)
}

Functions

We've already written a main function but before we finish let's take a closer look at how to define our own functions in Go. Here's a simple function that adds two numbers:

func addNumbers(a int, b int) int {
  return a + b
}

The func keyword is used the same way as our main function above, however within the parentheses we've defined some input parameters and their types. After the closing bracket we define the function's return type.

It's worth noting that, though it is generally frowned upon in the JavaScript world, there is something of a convention in Go for naming a function's input parameters with a single letter such as a or b. Not everybody does this, and it's perfectly fine to use something more descriptive, but you'll see it in the stdlib so it's good to be aware.

Ok, now we know a little bit more about functions, let's finish our application with a custom greeting.

package main

import (
  "fmt"
)

// where n stands for the name of a programming language
func sayYiss(n string) string {
  return "Aw yiss, I know " + n
}

func main() {
  message := sayYiss("Golang")
  fmt.Println(message)
}

If all goes well, running go run app.go should print "Aw yiss, I know Golang" to your console. That's it, we're finished. From your terminal, you can compile a distributable binary of your application by running:

go build main.go

Wrapping up for now

What is essentially a riff on a "Hello World" might not seem like the most exciting application ever, but we've actually covered quite a few core concepts of building Go applications.

We've learned how to start a go modules project. We've learned about packages and how the main package acts as an entrypoint for Go applications. We've learned a little bit about variables and functions and, to finish, we learned how to compile and run our application.

Hopefully this tutorial has given you a taste for what it's like to write Go and, if you're coming from JS or TypeScript background, then it should be clear that learning Go will be building on top of common concepts that you already know.

If you've found this useful, then I'm hoping to make this into a small series. Next time we'll take a look at structuring your Go applications and keeping things tidy with custom packages.

The year that was(n't)

2020-12-31T00:00:00-00:00

Holy. Shit. Let's get it out of the way - 2020 has been a prize dickhead.

Like many of you I started the year with plans. I was going to learn X, Y and Z. I was going be more active with the industry on Twitter. I was going to work on my side-project and, after taking nowhere near enough holiday in 2019, I was going to travel more. Sufficed to say, that is not the year I had.

I was fortunate to take a (very-surreal) trip to Japan at the start of the year, but I flew home with just enough time to get myself into lockdown. I haven't really been outside of Abergavenny since. Then, there was this website. I was super-excited to launch it back in January, and the positive feedback absolutely blew me away. As I wrote back then, one of my big motivators in building the site was my intention of properly blogging for the first time. Well, a quick look at my articles page will show that it didn't really pan out. Some of you might also have noticed that I have been a lot quieter on Twitter lately too.

It needs to be said though, that all of the above is utterly inconsequential in the face of what we have collectively faced in a year that has been so painful for so many people.

2020 has felt a lot like treading water. Like many of you I'm sure, maintaining a business, my physical and mental health, and the health of those around me with everything that's going on has been utterly exhausting. Honestly, making it through the year is enough, and something that we can all be proud of.

That said, in the spirit of reviving this blog I feel that writing a little more introspectively about my year might help me to make sense of the chaos.

Work

Working as an independent developer, maintaining a consistent work-stream is always playing on your mind. After a very busy December in 2019, I had a quiet start to the year before eventually hitting my stride during lockdown. From March onwards I was very fortunate to have a steady stream of client work right up until about two weeks ago.

With hindsight though, I overdid it. I believe in doing things well and as a result, put a lot of myself into my work. The year’s continuous and over-arching sense of oh shit, what now!? meant that ultimately I took on a massive amount but didn’t allow myself enough time between projects to decompress. The run up to Christmas is the closest that I've come to burn-out since I went freelance, and I'm definitely going to slow down for a while as a result.

On the positive side though, this year I’ve done some of the most technically complicated work of my career. Whilst I mostly can’t share it publicly due to NDA (that old cliché!), I've had a string of happy clients and I’m very proud of what I’ve achieved given the circumstances.

Another unexpected silver-lining is that the pandemic has normalised remote work. Living in rural Wales, I usually work remotely to avoid a long commute. The sudden change has created new opportunities and it will be interesting to see how this shift pans out longer term, once it is safe for my clients to return to their offices.

Personal life

As a response to my overworking and having extra time at home due to the lockdown, I've thankfully been able to prioritise more offline activities this year. Every Autumn, like clockwork, I start to miss being a student — no, not the heavy drinking — rather, the feeling of purposeful learning. This year was no different, except that I decided to do something about it.

Around 2011, I studied Korean on-and-off for about a year. Since then I’ve mostly forgotten everything, beyond being able to read Hangul. In late October I bought a Korean grammar textbook and started regularly studying again. So far I'm absolutely loving it. Whilst the language obviously has its own unique history and culture, on a purely linguistic-level Korean syntax and vocabulary are not a million miles removed from what I already know from having studied Japanese at university. It's empowering to feel like I'm building on top a shared-foundation, rather than learning something totally new. Whenever it's safe to travel again, I can't wait to visit South Korea. Hopefully I can get to a conversational level by then.

Lastly, the one thing in 2020 that has made the biggest positive impact is that, with the pandemic, my partner's job has become remote and she has been able to move in with me. Due to our working circumstances, my partner and I have been living apart on opposite sides of the country - it has been beyond amazing to finally spend out first Christmas together. Oh, we also got a kitten, Frīda, who is a constant source of joy. It's been a long while since I had a pet and I can't overstate the positive and motivating effect of having a little ball of chaotic energy in our home.

Looking forward

Well, we made it through a very difficult year. Unsurprisingly, I'm not going to offer any predictions or goals for the new year. Doing our best day-by-day seems more attainable for now. If you’ve hired me to help out with your project, used any of my open source work, read my blog, or promoted my work in any way, I’d like to say thanks – you’re awesome.

Stay safe, everyone. Happy new year!

Introducing Rekishi

2020-05-26T00:00:00-00:00

Imagine that you're building a website and you need all links to a particular type of content to open in a modal. On top of that, you would also like a nice transition animation to play whenever the user moves in and out of that content type.

Working with a framework like React or Vue, there are a number of clientside routers and components available to help transition between different pages of content. However, whilst I'm a fan of frontend frameworks, I'm a big believer in incremental development. Instead of reaching straight for a framework, I tend to approach each project from a user-centric path of using the minimum-possible JS, only adding dependencies as I need them.

If you're working closer-to-the-metal with Vanilla JS, coordinating the above example can be ...tricky. In order to capture and handle URLs as a user moves around the site, you need to use the History API.

In a nutshell, the history API lets you capture each URL change, and listen to 'pop' events that fire whenever the user navigates forwards or backwards through history. You are also able to associate a particular 'state' with each change. However, there's a frustration that comes with this. When a 'pop' event is fired the URL has already changed and you no longer have any access the outgoing route, or the state object associated with it.

If you're stringing different types of content together with page transitions, this can make it particularly tricky to choreograph everything. It's precisely this frustration that led me to build Rekishi - a minimal pubsub wrapper for the history API.

Wrapping the API

Rekishi, like my Tornis library before it, uses a pubsub pattern to listen to any changes in URL. This means that you can 'subscribe' handler functions to Rekishi. Whenever you push, pop or otherwise change the browser's URL, each of those subscribed functions will fire automatically.

The key difference with the standard history API though, is that each of those subscribed functions will have access to an object containing information about both the incoming and outgoing route. That object looks a little like this:

{
  incoming: {
    path: String,
    hash: String,
    params: Object,
    data: Object
  },
  outgoing: {
    path: String,
    hash: String,
    params: Object,
    data: Object
  },
  action: REKISHI_PUSH || 
          REKISHI_POP || 
          REKISHI__HASH || 
          REKISHI_PARAMS || 
          REKISHI_HASHPARAMS || 
          REKISHI_NOCHANGE
}

You might also have noticed that this object contains an 'action' property. This property contains a record of the type of URL change that has occurred. This could have been a change in hash fragment, an update to the query string, or whether the user has clicked a new link or travelled backwards through history.

Similarly, both the incoming and outgoing routes can also have an associated data object. This functions a little bit like the History API's state object, however knowing both incoming and outgoing information allows you to compare and respond accordingly.

In isolation, actions and data information are useful, but in combination they provide a powerful means of choreographing content changes - Returning to our initial problem of transitioning between a modal and a page, Rekishi would allow you to handle that scenario as follows:

const handleRouteChange = ({ incoming, outgoing, action }) => {
  switch (action) {
    // on either history, or new link events...
    case REKISHI_POP:
    case REKISHI_PUSH:
      
      if (incoming.data.type == 'modal' && outgoing.data.type == 'page') {
        // AJAX the content from incoming.path
        // set up your modal and inject AJAX content
      }

      if (incoming.data.type == 'page' && outgoing.data.type == 'modal') {
        //close your modal and remove the content
      }

      break;
  }
};

Associating path data

Aside from handling URL changes, there's another reason that clientside frameworks like React make page transitions easier. Because they take the rendering of content away from the server entirely, they have access to information about each route ahead-of-time. When building an application with the History API and server-side routing, this approach isn't available to us.

Rekishi also provides a means of bridging the two approaches. When initialising Rekishi, it's possible to pass an array of URL matchers that can associate default data with a particular path. This means that your app will know what data might be coming from a particular URL, before it is hit:

[
  {
    path: '/posts/*',
    data: {
      type: 'post'
    }
  },
  {
    path: '/posts/riding-the-shinkansen',
    data: {
      type: 'post',
      featured: true
    }
  }
]

Putting it to the test

To put Rekishi to the test, I decided to refactor this website to use it instead of the (still very useful) history module. Rekishi is small library (less than 2k when gzipped) and in making the switch I have managed to reduce my JS bundle size by a total of around 4kb. In isolation that figure might not seem much, but it made up roughly 23% of the pre-Rekishi bundle size of approximately 17kb. Not too shabby.

Wrapping up

All-in-all, I've found that using Rekishi has greatly sped up my workflow for building vanilla JS websites. Using it in conjunction with Tornis to handle interactions, I'm finding that I'm needing to rely less and less on frameworks in my day-to-day website builds. In terms of my end-user's bandwidth, I consider that a very good thing.

I'm hoping that others will find it useful, so I've released Rekishi as an open-source project. The source and documentation is available on GitHub. It is also available to install as a clientside dependency from npm.

How to name your agency with NLP

2020-04-18T00:00:00-00:00

As with so many things these days, it starts with clickbait.

"17 tricks to running a digital agency" was, for the most part, the same kind of unremarkable listicle that surfaces on Twitter from time to time. You know the sort - it keeps things light, you chuckle at a few zingers about office-dogs, exposed piping and wall-mounted fixies. You hit retweet and carry on with the day. This time though, there was one section that stood out to me. On naming your agency, it read:

Just pick a random word or two, and go with that

Could it really be that simple? Let's find out.

Striking the right tone

Random is a pretty strong word.

Think about the web agencies that you admire. The best names might seem random but usually carry some extra weight or depth behind them. This is all perhaps quite obvious, but it pokes an immediate flaw in our meme-ified advice. How can our choice be random, but still retain some deeper meaning?

Fortunately for our soon-to-be-industry-leading web agency, there's a whole branch of machine learning that can help us automate exactly this kind of problem: Natural Language Processing.

An introduction to NLP

Natural Language Processing, or NLP, is all about training computers to process and understand human languages. At this point you might be thinking that teaching language to humans is already pretty difficult and, honestly, you wouldn't be wrong. NLP is a really dense topic, but building even the smallest NLP applications can feel hugely empowering.

That said, NLP tutorials have a tendency to get very technical, very quickly and they often assume that anyone entering the field is coming armed with a dual-PhD in linguistics and computer science. On top of that, NLP and machine learning are often cushioned by a thick layer of marketing BS that makes it hard to separate reality from building SkyNet. It's clear that NLP is an exciting topic but, for newcomers, all of the above means that it isn't always clear what you might actually want to do with it.

In this tutorial, we're going to start slow and ease into a few core NLP concepts. We'll write a short script to 'borrow' the tone of voice from other agencies that we like. We'll do this by scraping their websites and plucking a list of nouns and adjectives from the text content. Finally, as the original meme suggested, we'll randomly mash some of those words together to generate a few names for our awesome new web agency.

Pre-requisites and setup

Python is considered to be the de facto place to start for natural language processing and to generate our agency name, we're going to need Python 3.7. We'll also need to manage our dependencies with a Pipfile (for the JavaScript fluent amongst you: think package.json). For that, we're also going to need pipenv.

If you're new to Python, then you can install everything you need with the brilliant Hitchhiker's guide. Once you have installed Python itself, the guide has a handy page explaining how to install pipenv. This tutorial will assume some knowledge of Python syntax, but I'll keep the code as simple as possible.

With everything installed, create a project directory and we're ready to get going.

The Corpus

Before we can process any text content, we first need to find a suitable a body of text. In NLP terminology this input text is known as our 'corpus'.

In our case, we want to grab our text content from other web agencies that we admire, so we can kick things off by writing a function to grab text content from a remote url. Fortunately the Beautiful Soup package helps us to do this.

Let's install Beautiful Soup, and the HTML5 library to our project dependencies. Open the project directory in your terminal and run:

pipenv install bs4 html5lib

Next, create a file called main.py with the following contents:

import requests # we'll need this to make requests to URLs
from bs4 import BeautifulSoup, Comment # HTML and comment parsers

def read_urls(urls):
  content_string = ''
  for page in urls:
    print(f'Scraping URL: {page}')
    # Synchronous request to page, and store returned markup
    scrape = requests.get(page).content

    # Parse the returned markup with BeautifulSoup's html5 parser
    soup = BeautifulSoup(scrape, "html5lib")
    
    # loop script tags and remove them
    for script_tag in soup.find_all('script'):
      script_tag.extract()

    # loop style tags and remove them
    for style_tag in soup.find_all('style'):
      style_tag.extract()

    # find all comments and remove them
    for comment in soup(text=lambda text: isinstance(text, Comment)):
      comment.extract()

    # Join all the scraped text content
    text = ''.join(soup.findAll(text=True))
    # Append to previously scraped text
    content_string += text

  return content_string

You don't need to worry too much about the specific code of the function above, but it goes as follows: It read a list of URLs, making a request to each before parsing the content with BeautifulSoup. The scraped markup needs to be tidied up a bit though, so next it removes any comments, script or style tags before pulling out the remaining text content and appending it to a string. When every URL in the list has been scraped, the string is returned as our corpus.

Now we have our corpus, we can start to process it.

Lost in SpaCy

SpaCy bills itself as 'Industrial-strength Natural Language Processing in Python'. Whereas packages like NLTK offer immense amounts of flexibility and configuration, the flipside is a steep learning curve. SpaCy on the other hand, can be set up and ready to go in minutes.

We need to add SpaCy to our project as a dependency. Open your project directory in your terminal and run:

pipenv install spacy

SpaCy doesn't do much by itself though - it needs a pre-trained language model to work with. Fortunately several are available out of the box. We'll also install the standard english model and save it to our Pipfile:

pipenv install https://github.com/explosion/spacy-models/releases/download/en_core_web_sm-2.2.5/en_core_web_sm-2.2.5.tar.gz

With our dependencies installed, let's get back into the code. Open up main.py and add SpaCy to our imports at the top:

import requests # we'll need this to make requests to URLs
from bs4 import BeautifulSoup, Comment # HTML and comment parsers
import en_core_web_sm # SpaCy's english model

Next, underneath our read_urls function, we can define a new function to allow SpaCy to parse the corpus.

def get_tokens(corpus):
  # load the pre-trained english model
  nlp = en_core_web_sm.load()
  # parse the corpus and return the processed data
  return nlp(corpus)

Notice the name of our function, get_tokens. What's that all about?

Parts of Speech and Tokenization

Most languages divide their words up into different categories. These usually comprise nouns, verbs, adjectives, adverbs and more. In linguistic terms, these categories are known as 'parts of speech', or POS. This is important to us as, to generate our agency name, we want to single out nouns and adjectives. But how can we get at them?

One place to start would be to break each sentence up into its individual parts but this isn't a straightforward as using String split(). We need a way to intelligently divide our text, whilst retaining the individual purpose of each word. Doing this manually would be too time consuming, so this is where machine learning becomes necessary. Most NLP libraries use trained language data to intelligently scan, compare and identify the characteristics of each word. Once identified, these words are separated out into 'tokens'. This process is known as tokenization and is one of the most important core principles of NLP.

Our get_tokens function tokenizes our corpus. Or, in simpler terms, SpaCy reads over the corpus, splits out individual words and returns a list of tokens. In creating that list, SpaCy also adds a lot of extra information to each extracted word, such as its relationship to other words in the sentence or which part of speech it is. We can use those attributes to filter the list down to find a specific part of speech.

Let's create another function:

def get_word_list(tokens, part_of_speech):
  # extract a list of words and capitalise them
  list_of_words = [
    word.text.capitalize() 
    for word in tokens 
    if word.pos_ == part_of_speech
  ]
  
  # make the list unique by casting it to a set
  unique_list = set(list_of_words)

  # cast it back to a list and return
  return list(unique_list)

This function receives the list of tokens, a part of speech code, and then filters the results using a list comprehension (again, for JS developers, a list comprehension is a bit like a cross between Array.map and Array.filter). To break this list comprehension down, it's best to work from the inside out – For every word in our tokens list, we grab word.text and capitalise it, but only if the part of speech (word.pos_) matches our POS code parameter. You can find a full list of these POS codes in the SpaCy POS documentation. If you're curious about what other attributes might be available on each token, you can read the Token reference.

Lastly, we can filter out any duplicated words by casting the results to a set(). We'll need to perform some list actions later though, so it is cast back to a list before being returned.

This is all looking great and we can now use this function to create a list of nouns, adjectives, verbs or adverbs. There's a slight problem though - if you were to use this function as-is, you might find that the list of words you get back is a bit of a mess.

Stop words

Most languages have a set of core words that occur frequently. In English, this might be words like "the", "at", "from", "in", "for" and so on. Whilst these words are useful for humans, they can quite quickly get in the way extracting meaning with NLP. As a result, it's common to filter them out and these kinds of words are known as stop words.

Our script is no different and the stop words need to go. Whilst we're here, we can also get rid of any rogue punctuation. Fortunately SpaCy tokens have two handy attributes that allow us to do this - the aptly named is_stop and is_punct. Let's update the list comprehension in our get_word_data function:

  list_of_words = [
    word.text.capitalize() 
    for word in tokens 
    if word.pos_ == part_of_speech 
    and not word.is_stop
    and not word.is_punct
  ]

Now we can extract a nice sanitised list of words, but there's a tiny bit more optimisation that we can do.

Lemmatization

Let's say you've scraped your website content and in amongst your list of tokens are the words "goes", "going", "went" and "gone". That's quite a few words to express the same base idea. We can make this simpler.

These words could all be lumped together under the core concept: "go". In linguistic terms, we call this a word's 'lemma' or the uninflected root form of a word.

The simplest way to think of a lemma is to see it as what you might look for in a dictionary:

Out of the box, SpaCy provides a convenient means to convert any matched term back to its lemma. This is called lemmatization. Let's hone our list of tokens down into a much tighter list of core ideas by updating our list comprehension. We'll change the first line to call .lemma_ instead of .text.

Your final get_word_list function should look like this:

def get_word_list(tokens, part_of_speech):
  # extract a list of lemmas and capitalise them
  list_of_words = [
    word.lemma_.capitalize() # <-- update .text to .lemma_
    for word in tokens 
    if word.pos_ == part_of_speech 
    and not word.is_stop
    and not word.is_punct
  ]
  
  # make the list unique by casting it to a set
  unique_list = set(list_of_words)

  # cast it back to a list and return
  return list(unique_list)

Bringing it all together

Now we've set up a few functions and we've covered the core concepts, let's pull everything together. To generate the final name, we're going to need to be able to make random selections from our word lists. At the top of main.py, add random to your imports.

import requests # we'll need this to make requests to URLs
from bs4 import BeautifulSoup, Comment # HTML and comment parsers
import en_core_web_sm # SpaCy's english model
import random

At the end of the file, underneath your get_word_list function, paste the following:

# create a list of urls to scrape
# For illustration, I'm using my website 
# but replace with any urls of your choice
CORPUS = read_urls([
  'https://robbowen.digital/',
  'https://robbowen.digital/work',
  'https://robbowen.digital/about'
])

# parse the corpus and tokenize
TOKENS = get_tokens(CORPUS)

# extract a unique list of noun lemmas from the token list
nouns = get_word_list(TOKENS, "NOUN")

# extract a unique list of adjective lemmas from the token list
adjectives = get_word_list(TOKENS, "ADJ")

# create a random list of 500 nouns and adjective-noun combos
# cast to a set to make sure that we only get unique results
list_of_combos = set(
  [
    # String interpolation of an adjective and a noun...
    f'{random.choice(adjectives)} {random.choice(nouns)}' 
    # 50% of the time...
    if random.choice([True, False]) is True
    # else return a random noun
    else random.choice(nouns)
    # and repeat this 500 times
    for x in range(500)
  ]
)

# Write list of combinations to a text file
output_file = open("./output.txt", 'w')
for item in list_of_combos:
  output_file.write(f'{item}\r\n')

Let's break that code down.

First of all, we pass a list of URLs into our read_urls function and store the result in a constant for later. Be sure to change the example URLs to your own choices here, and remember: the more text on your chosen pages, the better your results will be.

Next, we pass the corpus into our get_tokens function. This is where SpaCy does its magic, tokenizing the corpus and returning a list of data-rich tokens.

To generate our agency name, we want some random nouns. Nouns by themselves aren't much fun, so we'll grab some adjectives too. This uses the get_word_list function we created earlier. The first argument is the list of tokens, and the second filters by a 'part of speech code'.

Now we have our nouns and adjectives lists we can prep our final list of names. We want to generate a list of names – let's say 500 of them. We can use another list comprehension to do this.

Remember the random library we imported above? It gives us access to the random.choice function. As the name implies, it allows us to randomly choose a single item from a list. random.choice also gives us a handy way to embed a 50/50 chance into our comprehension. Here, an if-else means each iteration of our loop will return either an adjective-noun combo or a single noun. Finally, with the comprehension complete, we wrap the list in set() to ensure that we only have unique results.

Ok, everything is ready. At the very end we create a file called output.txt, loop through our list of names and write each to a new line.

And...we're done! If you need to, you can double check your code against the final source on github.

Generate the name

It's time to fire up the final script and generate some names. At your terminal, run the following command:

pipenv run python main.py

If all goes well, you should have now a file named output.txt chock full of multi-award-winning agency names.

And the winner is...

"Just pick a random word or two and go with that". So, after all this, what name did I go with?

Well, I had some real gems: Loaf, Strategic Bear, Rise, Chaotic Rest, Bold Tomorrow. After a few minutes crawling through the output list though, I spotted the one.

Exciting, yet confident. Like a life-raft in a sea of comedic nonsense:

Wrapping up

Ok, I get it. Like most clickbait, this might not have been a completely satisfying ending. Hopefully though, you've learned a little about the potential application of even the most superficial Natural Language Processing scripts.

To recap, in this introduction, we've used and learned about:

Corpus: The body of text to be processed
Parts of speech: The name given to the categories of words comprising nouns, verbs, adjectives etc.
Tokenization: The act of splitting sentences into individual words, or tokens
Stop words: Small, frequently occurring words that we do not wish to include in our results i.e. "the", "for", "it" etc.
Lemmatization: Changing a word back to its root concept, or dictionary form i.e. the lemma of "best" or "better" is "good"

From these core concepts, the possibilities are vast. Imagine going into a pitch having scanned the client's website in advance to profile exactly how they talk about themselves. Or perhaps you could take the jump into sentiment analysis to scan how well received a particular topic is on Twitter. There's still a lot to learn but, with these core building blocks, you're on your way.

If you enjoyed this article and have any ideas on how to extend this example, or if you generated a particularly badass name, then please let me know on Mastodon.

If you're looking to learn more about NLP, I strongly recommend the Advanced NLP with SpaCy course by Ines Montani - it's free, and really rather good.

Synthwave '84 has changed

2020-02-10T00:00:00-00:00

It's been a wild ride since I first tweeted about Synthwave '84. The support has been amazing and I'd like to start by saying thanks everyone who has shared or used the theme since the last release. Particularly, I'd like to thank you all for battling through the less than ideal installation process.

It's been a bumpy road but it's been truly great to see so many people enjoying the theme.

Neon Dreams

This v0.1.0 update marks a changing point for the theme.

As of writing, VS Code still doesn't support text effects in its themes, so the only way to apply the neon glow for Synthwave '84 is to inject code directly into the application markup. The previous versions of Synthwave '84 relied on a third-party extension to inject an extra stylesheet into the VS code editor. This was a hacky, if serviceable, method for adding extra styles, but I suspected it would never be long-term.

With the v1.40.0 release of VS code, those suspicions were confirmed - the internal classes used for the glow had been changed. It was clear that another solution would be needed.

This new update, called Neon Dreams, removes the need to use the Custom CSS and JS extension to enable the glow. It also rethinks how to apply the glow, so it should cope better with updates to VS code.

Before using

If you have been using Synthwave prior to v0.1.0, you will likely have used the Custom CSS and JS extension to enable the glow. Before enabling Neon Dreams, you will need to disable the prior method. You can do this by pressing Ctrl + Shift + P or Shift + ⌘ + P and choose "Disable Custom CSS and JS".

In the name of simplifying the install process and mitigating update-related issues, the new version of Synthwave doesn't use a custom CSS file anymore. If you have been using a custom-modified version of the theme, then you might want to leave it as is for now.

Start dreaming

Firstly, if you are a Windows user, you may need to run VS Code with administrator privileges. For Linux and Mac users, Code must not be installed in a read-only location and you must have write permissions.

Once you have admin permissions, open VS Code, and set your active colour theme to Synthwave '84 - the glow is only active when the base theme is selected.

press Ctrl + Shift + P or Shift + ⌘ + P and choose "Enable Neon Dreams"

You should be prompted for a restart. When the editor reloads, the glow should be active.

As with the prior versions, VS Code may warn you that your installation is corrupt. You can suppress this message by choosing 'Don't show this again' from the notification.

Also as before, whenever VS code updates, you will need to rerun the enable command

Launch day

2020-01-22T00:00:00-00:00

Today is something of a milestone. For the first time in a long while, I have a new website. I'm not talking about a holding page, or link to a resumé, but an actual honest-to-goodness home on the internet.

More importantly than that, I have a personal blog for the first time ever.

It's been a while coming. As a freelancer your website can often be the first impression your prospective clients will get, so the pressure to get it right can be massive. Beyond that though, it felt important that I create something that reflects me and my values. Working on this site has been something of a labour of love for me, so what better way to kick off the blog than writing a little about how I got to this point?

Constraint breeds creativity

Without a shadow of a doubt, a blank canvas is an intimidating thing. It can feel especially daunting when it seems like there’s a new JS framework popping up every other day. Thankfully, over the years I’ve learned that I'm at my most creative when I'm working with restrictions. To get things moving, I sketched out a few constraints.

The site should:

Convey a strong personality and a sense of place
Showcase my interaction library and emphasise the kind of work I enjoy
Deliver all of the core site assets in 100kb or less
Use progressive enhancement to keep the site usable when JavaScript is not available

With those targets in place, I set to work.

Finding inspiration

The design direction was the first thing I had to nail down. I knew that I wanted to keep things simple, but full of character. I also wanted to ground everything with a sense of place. But where to start?

I work remotely 80% of the time, so it made sense to try and bring something of my home environment into the design. I live in a small Welsh town, Abergavenny, which is surrounded by three distinctive mountains - Sugarloaf, Blorenge and Skirrid. No matter where you are in town, you can always see one of them. I figured that if these mountains can ground me, they could also ground my website.

I got out my sketchbook and before long I had roughed out three abstract representations of the peaks. Rather than pick one mountain for my logo, I decided to mimic the town and show all three, randomly swapping them on each page of the site.

The logo got things moving. The simple line-art style leant itself well to SVG illustrations, which would not only keep the page weight down, but also be a good way to inject a bit of character into the design. I sketched up a stylised self-portrait and several other scenes to accompany each page. To compliment the simple illustration style I opted for a 5-tone colour palette, adding a little texture with patterns and an off-registration shading effect.

Hello, Eleventy

Before I started coding I knew that I wanted to build a JAMstack site and host it on Netlify. However the self-imposed 100kb limit meant that, right off the bat, using something like React or Gatsby would be tricky. Though it is possible with optimisation, the runtime JavaScript required for a single-page app would likely take up most, if not all of my initial load budget.

If I wanted to keep this site small and snappy, I'd need to find an alternative.

At the time I started the build, I'd been hearing a lot of buzz around a static site generator called Eleventy and decided to check it out. On the surface, it's closer to something like Jekyll than it is to Gatsby. Pages are constructed from Markdown files using one or more templating languages and then compiled into vanilla HTML, CSS and JS files. It's hugely configurable and crucially there's no clientside bundle either, meaning you're entirely free to add as much or as little JavaScript as you like.

Eleventy was the perfect fit.

Beyond the standard templating features, Eleventy allows you to write custom nunjucks partials (or shortcodes as they're known here). On the surface that might not seem too exciting, but by using shortcodes I was able to approximate a React-like developer experience by breaking my UI into a series of neatly reusable components. The real magic comes with the way Eleventy stacks template formats though.

If you write a markdown file it can optionally be parsed as one additional format defined in your .eleventy.js config file - in my case, first as markdown, then as nunjucks. This means that these same shortcodes are also available within my markdown files allowing me to build more interesting layouts inside of blog content.

In-keeping with Eleventy's ethos, I've opted to kept clientside JavaScript to a minimum. To retain the feel of a single-page app, I'm using the history api to capture internal links and transition between pages and, to spice things up a bit more, CSS custom properties swap out the colour palette on each page transition. Aside from Tornis, I've kept dependencies light and the final JS bundle clocks in at only 17kb when gzipped.

Getting animated

I love interaction design, and it was inevitable that my site would feature animation of some kind. The decision to use SVG throughout gave a simple way to add a little spark - I'd use Tornis to manipulate the position of the off-registration effect, and scatter an additional layer of interactivity throughout my illustrations.

I wanted the homepage to stand out in particular. The concept was simple - I'd have a stylised self-portrait track the user's mouse cursor around the site and a series of grouped paths and a bit of selective masking would create the illusion that the illustration was three dimensional.

Animating nested SVG elements directly can cause performance issues on some low-end devices, but this isn't the case with standard HTML. To make sure the animation would be buttery smooth, I first needed to separate each section of the illustration into divs and then stack them with CSS. From there I could start the interaction:

Tornis first captures the user's mouse position (or device tilt) as X and Y co-ordinates which I then convert into a percentage relative to the centre of the screen. Multiplying the positions of two extreme keyframes by this relative value, allowed me to gradually tween each section of the illustration between both poses. To sell the effect, CSS transitions smooth out the movement and make each keyframe blend seamlessly.

The results really surprised me. I found that approaching motion in this way - as a series of blended positions rather than individual animation sequences - makes for a much more organic feel. The gradual blending also means that you avoid any of the visible cuts you'd get when swapping between CSS animations.

Final Thoughts

So did I keep to my restrictions in the end? Broadly, yes.

With a little help from Netlify hosting, the initial page transfer on the homepage clocks in at ~80kb (gzip) and, should the site load without JavaScript, everything is fully usable with an alternative layout. Ultimately, I have used some images on blog articles and the like which brings the individual page weight higher but I feel like that's still acceptable as the core assets are well within my target.

Most of all though, I'm happy with the look of the site - it feels like home. Setting myself constraints early on really helped to focus development whilst still allowing me to explore the design. Similarly, putting aside my default tech choices has meant that I've been able to craft a comparable experience in a fraction of the filesize. I will definitely be using Eleventy for future projects.

Finally, as with any personal website, I wouldn't call it totally finished and I dare say that I'll keep on tweaking and updating things as it lives and grows. For now though, I’m really happy with how the final site has turned out. It's been a long road.

Synthwave '84

2019-05-09T00:00:00-00:00

Do you remember that endless summer back in '84? Cruising down the ocean-highway with the top down, the wind in our hair and heads buzzing with neon dreams?

No, I don't remember it either, but with this experimental theme we can go there.

This colour scheme is influenced by the music and the cover artwork of modern Synthwave bands like FM-84, Timecop 1983 and The Midnight. By association, that means I've also taken heavy influence from the excellent retro-tinged artwork of James White (check out his work, it's awesome).

But ...why?

I was a kid in the 80s but for most of my teenage life I strongly disliked nearly everything about the 80s aesthetic of my childhood. It was like, so lame. With the hindsight of recent years though, I've realised that it was actually pretty sweet and I wanted to celebrate it a little.

Much the same way, in the modern web-development world of shaders, React and WebGL, I feel like it's easy to forget that the basics are actually pretty damn good. To that end, this theme goes back to basics - No Shader magic. No cloud-streamed WebGL render-farms. Just plain CSS.

Using SynthWave '84

The theme can be downloaded from the Visual Studio marketplace or from VS code itself, by searching for SynthWave 84 in the extensions tab. If you want to enable the glow, please carefully read the installation instructions for this, and the theme's dependencies.

Looking into the future

So, what's in store for the future of this theme? First and foremost, better language support. I primarily develop with JavaScript, Elixir and Python so whilst the theme looks good for those languages, tweaks have been needed for other languages. There's more to come.

Many people have been also excited to see Synthwave '84 ported to other software. Whilst I'm not currently planning to port the theme myself, the community has already produced several fantastic ports:

Synthwave 85 for Rstudio courtesy of Jacqueline Nolis
Synthave '84 for Carbon courtesy of Adam
Hyper terminal courtesy of Diogo Cezar Teixeira Batista.

Perhaps most surprisingly for me, Panic, the team behind the legendary Mac editor Coda have recently announced their next-generation editor, called Nova. Turns out that the team at Panic liked Synthwave '84 enough to create their own version, called Outrun. It's looking pretty sweet.

Lastly, beyond editor support, the most popular feature-request has been for a light version. To that I can say: It's in the works. Which reminds me, the eagle-eyed amongst you might have noticed that this page is sporting a lovely shade of sunset-peach...

Robb Owen Digital

Looking elsewhere

Hype-driven development

Raising the standard

Fast-software

The case for blurred specialisms

But should designers code, though?

Craft is community

Hype Hope-driven development

Getting something from Nothing

Software that makes you want to stop

Business in front, party in the back

Final thoughts

It's OK to abandon your side-project

The background

The approach

The realisation

Maybe the real treasure is the code we wrote along the way

Wrapping up

2023 Wrapped

"This year, your contracts were eclectic"

"This year, the words came easier"

"Another year, another framework"

"This year, you left the UK for the first time in 3 years"

"This year you got super sick of superheroes"

"In 2023 you played a whole bunch of games...or did you?"

Wrapping up

Locking scroll with :has()

Locking scroll

Solving edge-cases with :has()

Wrapping up

HTML is like a camera

Legacy code

Let's get existential for a moment

Control structures

Code conservation

The ephemeral nature of (digital) things

Hand-thrown frontends

So long, 2022

Work

Looking forward to 2023

The Jammies 2022

Holograms, light-leaks and how to build CSS-only shaders

What is a CSS 'shader'?

Simulating specularity

Know your blend modes

Compositing layers

The final shader

Taking it further

Aurora Borealis

Light-leak

Hologram

Wrapping up

Image credits

Mind your language

1. Fonts and diacritics

2. The lang attribute

The lang attribute and character sets

3. Direction and writing mode

4. Logical CSS properties

5. Form validation

Wrapping up

Getting started with Go

Let's build something

Preparing to work with Go

Starting a Go project

Our first file, and the main package

Variables and types

Shortform variables

Functions

Wrapping up for now

The year that was(n't)

Work

Personal life

Looking forward

Introducing Rekishi

Wrapping the API

Associating path data

Putting it to the test

Wrapping up

Solving edge-cases with `:has()`

2. The `lang` attribute

The `lang` attribute and character sets