Daniel Schulz
Daniel Schulz iamschulz avatar

Mostly frontend, sometimes art

my Mastodon
Icons of a hammer, wrench and saw next to each other, extruded out

Web Technology as a Spectrum

Josh W. Comeau talked on Twitter about no-code solutions, specifically for CSS, and how they impact what developers work on after trivial tasks in their workflow have been automated.

Imagine a spectrum. At one end, you have template-focused website builders like SquareSpace. A little further along, you have Webflow. At the opposite end, you have raw HTML/CSS.

This is a very nice perspective on the subject. And one I'd like to talk about, not just in the context of CSS.

The question of when developers would become irrelevant has always come up. Students making websites on the cheap, WYSIWYG editors, Easy-to-setup solutions like Wordpress and Shopify, and last but not least GitHub Copilot have human coders wondering if they'll be pushed out of a job soon. The answer has always been no and will be for a very long time.

Tools for Users

Good automation tools reduce friction and give developers the tools to tackle more complex problems:

  • Wordpress gave me a CMS so I don't have to worry about that and can create a nice frontend
  • It also had themes, so backend developers could build sophisticated plugins and not worry about the UX
  • GitHub Copilot writes Regular Expressions and SQL that works well enough for me, and sometimes lets me second-guess my own code.

I value a custom and purpose-built UI more than a clean backend. Tools like those took the parts that I didn't like (such as server-side programming) and gave me solutions that worked well enough out of the box. In the meantime, I could dig even deeper in frontend development and specialize in the parts that I like. Doing that I quickly overtook the automated solutions and was back to hand-writing my own code. As Josh would take it: I moved up the spectrum, to the end which gave me more flexibility with more general-purpose tools.

Users for Tools

Not all tools allow me to shift go into the direction I want to so easily, though. Sometimes tools create their own set of problems and suddenly you need to become an expert on drywall construction in order to hang a picture. That's how I wound up being more of a full-stack developer than I would have liked a few years ago.

Ever since JavaScript first ran on a server it took on a crusade to swallow more and more aspects of frontend development. While you could score a decent job with HTML, CSS, and a little jQuery on the side 10 years ago, deep JavaScript knowledge is a basic requirement for most positions nowadays. As I learned ES6, Node and Vue, I gradually lost my focus on design and layout, to the point where I have never even touched Figma (or Sketch, speaking of) yet. Those tools have been solving problems for me, sure, but they weren't able to let me move up my spectrum. They weren't as general-purpose as HTML and CSS. Instead of crafting beautiful websites, I now had to care about things like routing and data structures – things I thought the server and the browser were doing for me.

It's tools like these that eventually created what Chris Coyier would later describe as The Great Divide, with engineering-focused front enders on one side and design-focused ones on the other. Reactive frameworks have not only solved their own problem, they created so many new ones that an entire new school of engineers followed in their wake. So much for becoming obsolete!

Josh's perspective on no-code solutions brings a nice way to evaluate tools with it. Can a tool help me not only with my current task but can it help me become a better developer, or does it try to lock me inside a walled garden?