Brian Lewis ModulesUnraveled

Summary:

Defining a frontend architecture that implements modern best practices including component-based development, atomic organization, and the BEM css naming convention may take more forethought when initially starting up, but has consistently (across our projects) proven to actually speed up development as a project matures, and save both time and money when updates or bug fixes are required. It will also make any future frontend developer's experience with the codebase far more pleasant!

Component Based Development

DRY (Don't Repeat Yourself). Write code once, and re-implement it - instead of rewriting it

Because we follow component-based development principles, our projects get faster to work on over time. If you don't do things that way, projects inevitably get SLOWER to work on over time. And you're never sure if the change you're about to make is going to affect all of the places you want it to, nor if it's going to change the way some other element in an unrelated part of the site

A commentary on excerpts from the book "Frontend Architecture for Design Systems"

Chapter 5: CSS

Single Responsibility Principle

Excerpt from the book

The single responsibility principle states that everything you create should be created for a single, focused reason. The styles you apply to a given selector should be created for a single purpose, and should do that single purpose extremely well.

Tailwind vs. Four Kitchens Methodologies

Intro

For this post, I took a look at the card examples provided on the Tailwind website at https://v1.tailwindcss.com/components/cards.

In order to keeps things simple, I chose to focus on one example, the "Horizontal" card.

"Horizontal" example from tailwindcss.com

First of all, the name is poor because on mobile devices, it's stacked... That's why we believe a component's name should "describe it's purpose, rather than its appearance".

But on top of that, looking at the code, I'm even sure where the card styles actually start. As you can see in the screenshot, there's padding around the card... Looking at the code, there's no obvious way to know if that's coming from the card styles, or the component that's wrapping the card.

We read our code far more than we write it, so plan accordingly.

Even if you don't plan on anyone reading your code, chances are someone will... even if it's you 12 months from now.

Why we use "semantic" variable names rather than "primitive" names.

What do we mean by "Primitive" names?

Primitive names typically call the thing what it is. Some examples are:

	#!/bin/sh

	# Installation:
	# - Copy this file to /usr/local/bin/k4
	# - Make it executable `chmod +x /usr/local/bin/4k`
	#
	# Use:
	# - Run `4k <command>`
	# - If you haven't configured that command for the current project
	# you'll be asked to configure it now