Web Development

Or: How I Learned to Stop Worrying and Love Utility-First CSS Frameworks

If you go back in the history of web development far enough, everything was an inline style. Then CSS came along and brought a decoupled and powerful way of styling your site, and a lot of headaches for web developers who weren't clear on how to float with the tide, to overflow a metaphor.

That would be a lot to repeat in several of your BEM-style components, so it's handy to have some global CSS classes that take care of it. A utility-first CSS framework tries to provide that DRY (don't repeat yourself) convenience to all your CSS styles. In the case of Tailwind, nearly every CSS property you can think of writing has a pre-defined class ready to go. If you want to see it for yourself, go ahead and scroll through Tailwind's docs, I'll wait.

Okay, that's a bit more concise, but what of it? Where's the advantage from writing CSS in a slightly more terse format? For one thing, reusable utility classes help us keep consistency. The color of that tan background, or the pixel radius we round off the borders is the same everywhere we use it, which is something we'd previously use Sass or CSS variables to ensure. But more on that later.

But wait, we just did a couple things here that break some of the fundamental rules of CSS! First, by using classes that describe what the page looks like instead of the function of the element, we're tying styling back to our content! Well... sort of. Web development's changed a lot since that rule came about. We're not often making entire documents that contain our entire HTML structure and repeating it across several documents. In this case, our card is going to look the same wherever we use it, regardless of if it's getting its styles from the .Card class or directly in the HTML.

You could further customize this to give you automatically generated light and dark shades of your base colors, using a PostCSS plugin such as PostCSS color-mod(), similar to Sass' lighten() and darken() functions.

If there's one thing that there've been an ample number of articles telling front end developers they must unequivocally adopt in the last five years, it's responsive images. We're all aware that more and more users are viewing our websites on mobile devices, and standard definition image assets simply won't do for today's retina displays. Thankfully, the W3C and WHATWG standards bodies have done a great job of taking feedback to give front-end developers simple but powerful tools to begin handling serving images at a wide range of resolutions for all the devices we now have to target.

Img srcset looks much more compact, as it only needs a single <img> tag to contain all your sources. It'll have a standard src and alt attribute, but it'll add the srcset and sizes attributes as well. srcset contains a comma separated list of your different resolution images and the actual image width. You must supply the width here because the browser won't know what the width of each image is until it first retrieves it, so to avoid downloading each one, we give the browser a hint.

So, with two very different approaches to responsive images, which one should you use and when? The answer to this question took me quite a long time to figure out, despite there being a lot of articles devoted to this topic. Most articles will say that <picture> should be used for "art direction", but as a non-designer, that meant nothing to me.

It's also important to note that the polyfill is Javascript, so a browser that has Javascript disabled will only display the fallback image. These are minor issues, but I found things get more complicated.

Web development has undergone major shifts in the last 5-10 years, both structurally and technologically. The days when making a webpage meant hosting some HTML files on a server are largely long gone. As are the days of businesses employing a single web developer for the position of running an enterprise-level website, as mid-to-large scale companies now have internal development teams of at least a dozen engineers with various disciplines, or will more often use the resources of outside development shops that have the experience in producing high quality deliverables.

The web utilizes a rapidly increasing number of programming languages, but HTML, the first and most basic building block of the web, is not one of them. Most developers would say with some condemnation that HTML is not a programming language, and while they are correct that it is not programming, it is a language. A programming language can provide instructions using computer analogues of all the basic constructions of human language: nouns, verbs, descriptors, punctuation, and rules of grammar.

is HTML’s way of ascribing a purposeful intent in the text that goes on the webpage. The dictionary for HTML contains 109 adjectives in its most recent publication, and the job of every current browser is to read the meaning of them in as close to the same way as possible, though each browser infers the intent of those words slightly differently. However, unless your goal in life is to learn all the ins and outs of HTML, there is no reason to cover any more of these fundamentals.

Open-source champion, Eric Raymond, famously described his preferred method of software development as a bazaar, a marketplace of ideas where every person was free to contribute and improve on a software project. The idea that many developers working on a problem, each with their own agenda and motivations, could produce a better product than a top-down approach to software development was only starting to see adoption at the peak of the first internet boom. But the strength of the idea outlasted the projects and companies that were the early adopters of it.