## This is Bait
I'm afraid you've been click baited. I will not be arguing for or against HTML's status as a programming language. But now that you are here, can we spend a minute pondering why it's so important that HTML be classified as a programming language?

## The Value of HTML
The issue that I have with this argument, is I feel like certain groups of people feel as though without classifying HTML as a programming language, you are somehow doing a disservice to HTML as a skillset or the people who either make their living in-part by writing HTML or those who only know HTML. 

HTML is a critical skill. Let's go ahead and establish that now. Even if you work in a framework like React where you are writing a superset of HTML (eg. JSX), HTML is still the magic that actually makes the web what it is. Without it, every single website would no longer exist. 

## Tech is not Exclusively Programming
The issue with the implication that if HTML is not a programming language, then it is somehow not valuable and the people who use it are not "real programmers", is that it leaves a whole lot of people out in the cold. 

The modern landscape of development, whether that be for the web or any other platform, is a dense community of very diverse skills that must work together to create the internet as we know and love it. Some people write code, but other people do not. The latter group is just as important. 

## A Few Examples

### People writing documentation for a framework, library, or product
Without these people, all knowledge of how a tech or product works has to be figured out through trial and error, taught one-to-one from knowledge keepers, or just never discovered. Products have literally failed just because of this one shortcoming. 

### People building infrastructure and automations using configuration languages
The internet may be held together by cooking twine and craft glue as people like to say, but it still works a majority of the time and the majority of the infrastructure is created without "writing code". Some people still build their infrastructure manually with GUI interfaces. Without this effort, it doesn't matter how great your code or product is. 

### People designing UX and UI 
I won't speak for all developers, but I couldn't be trusted with making a flier for my band to play at the local dive bar on 5th street, much less a fully featured web application optimized for ease of use and accessibility. Designers are brilliant and multi-disciplined people and without them, the internet would still look like [Tim Berners-Lee's website](https://www.w3.org/People/Berners-Lee/).

## Conclusion
I considered adding more examples, but fear I am on the edge of beating a dead horse if I have not reached that point already. The key take-away here is, however you feel about the classification of HTML and what sort of language it is is totally fine. Just keep in mind, when you imply that someone saying "HTML is not a programming language" devalues people who write HTML, that the opposite also devalues anyone whose job does not involve writing code.

Is HTML a programming language?

## Prerequisites

This post makes the assumption that you are familiar with Python and installing packages with the Pip command line tool. It also assumes that you already have either Python2 or Python3 installed on your system.

All commands will work on Windows, Mac, and Linux unless otherwise stated.

## Introduction

If you are new to Python or always work with the latest library versions, it's likely you just use Pip to install everything globally. This works fine at first,but can lead to problems quickly as your projects age. Imagine the following scenario.

You manage an application that is dependent on version 1.0 of AwesomePyLib, so you simply install it and move on. The problem enters when you begin managing a second application that relies on version 2.0 of the same library.

Now what do you do? Maybe you upgrade to 2.0, but now your first application is broken. So maybe you just update the code to both use 2.0, or maybe you uninstall and re-install as needed.

Whatever you choose, you've been distracted now from what you set out to accomplish in the first place. Let me show you a better way.

## Enter Virtualenv

Virtualenv is a Python package for creating virtual Python environments for your project.

So what does this mean? Conceptually think of it as a box to keep a single application in. Inside that box you will also keep an isolated copy of Python, Pip, and any packages your application needs.

To revisit the example from earlier, this would allow us to have one environment for application A with AwesomePythonLib 1.0 and a second with version 2.0 for our application B. Let's look at a real world example.

## Installing Virtualenv

Installing Virtualenv is easy as pie and can simply be installed via Pip on Windows, Mac, or Linux.

```
$ pip install Virtualenv
```

You will need to ensure Python has been added to your PATH, which typically happens when Python is installed.

## Setting Up a Virtual Environment

Let's start by creating a new directory then we will initialize a new Virtualenv environment.

```
$ mkdir pyproject && cd pyproject
$ virtualenv venv
```

This will create a new directory called `venv` inside our directory. This will contain our isolated instance of Python and packages. The next step is to activate the environment and install a package.

```
$ source venv/bin/activate
$ (venv) pip install requests
```

**Windows Users**
On Windows, a batch script is created for activating an environment. The command is as follows:

```
C:\PATH_TO_PROJECT\venv\bin\activate.bat
```

This will install the requests package to your `venv` directory, freeing you worrying what version other projects might be using.

Virtualenv provides a shell function called `deactivate` to exit an environment when you are finished.

```
$ deactivate
```

## Warning About Terminal Sessions

When you activate an environment, it is only activated for that particular terminal session. Be careful of switching to your IDE's embedded terminal or opening additional tabs.

When a Virtualenv environment is active, you will see the environment name in the terminal like the command examples above.

## Alternative Python Versions

While this is less of a problem than it was even just a few years ago, you may still find yourself in a situation of maintaining projects that utilize different versions of Python.

Virtualenv has your back in this situation as well allowing you to create an environment with any Python interpreter you have installed on your system using the `--python` command line flag.

Here's an example of what that looks like.

```
$ virtualenv venv --python=python2.7
```

Now you can work on Python2 and Python3 side by side without any of the usual headache.

## Conclusion

Virtualenv is only a single tool that solves this problem, but I highly recommend you utilize some sort of virtual environment package. Especially if you come from Node where dependencies are scoped to each individual project by default. Another such option is [pyenv](https://github.com/pyenv/pyenv).


Taming Python Dependencies with Virtualenv

## Preface
All Tailwind example codes are taken from the official website or documentation located at [tailwindcss.com](https://https://tailwindcss.com/).

## What is Tailwind?
I would honestly be pretty surprised if anyone hasn't heard of Tailwind CSS by now! But for the uninitiated, Tailwind is a CSS framework that takes a utility-first approach to its naming conventions and usage. To contrast it against component based CSS frameworks, in Bootstrap, you might have something like this:

```html
<div class="card">
  <div class="card-body">
    <h5 class="card-title">Card title</h5>
    <p class="card-text">Some content for the body of the card</p>
  </div>
</div>
```

Where each HTML element has no more than a few classes, sometimes one or less. The names of the classes represent the type of UI being styled. This starts off fine, but can lead to some long term maintainability issues I'll dive more into later. Spoiler: I was very stubborn and did not learn this lesson easily. 

While the same general idea would be expressed in Tailwind more like this:

```html
<div class="max-w-sm rounded overflow-hidden shadow-lg">
  <img class="w-full" src="/img/card-top.jpg" alt="Sunset in the mountains">
  <div class="px-6 py-4">
    <div class="font-bold text-xl mb-2">The Coldest Sunset</div>
    <p class="text-gray-700 text-base">
      Lorem ipsum dolor sit amet, consectetur adipisicing elit. Voluptatibus quia, nulla! Maiores et perferendis eaque, exercitationem praesentium nihil.
    </p>
  </div>
  <div class="px-6 pt-4 pb-2">
    <span class="inline-block bg-gray-200 rounded-full px-3 py-1 text-sm font-semibold text-gray-700 mr-2 mb-2">#photography</span>
    <span class="inline-block bg-gray-200 rounded-full px-3 py-1 text-sm font-semibold text-gray-700 mr-2 mb-2">#travel</span>
    <span class="inline-block bg-gray-200 rounded-full px-3 py-1 text-sm font-semibold text-gray-700 mr-2 mb-2">#winter</span>
  </div>
</div>
```

The short and sweet of it is that in Tailwind, you use classes that apply one specific property to your element. Reading over them, it can be reasonably assumed in most cases what that particular utility will do such as adding a predetermined amount of padding or setting a font size or color. 

## First Impressions: Alphabet Soup
I am not going to lie about it. I **hated** Tailwind. As I said in the opening, it can be a very divisive framework. 

My first impression that began to build this conclusion was a very common complaint. Referencing the two code samples above, it's easy to be a little bit overwhelmed by the amount of classes in the Tailwind example, frequently called class or class name soup. I found it harder to read, harder to think about, and since I didn't know any of the classnames - slower to write.

This was a huge hurdle for me, and the one that always made me go back to styled components / emotion.

## Changing Hearts and Minds
You are probably asking now, so what changed?

It came down to forcing myself to put aside my preconceived notions about Tailwind and how to write CSS in general. I came to the conclusion that Tailwind was gaining too much momentum to risk sleeping on and I forced myself to just start building with it and see the full lifecycle. This eventually led to Tailwind UI and building this site using one of their starter templates, by the way. 

One realization at a time, I began to change my mental model and understand the power beneath the hood.

## Realization #1 - The Apply Pattern and Thinking in Utility
One frequent retort to the complaint above is the `@apply` pattern which allows you to compose new utility classes using existing utility classes. 
 
```html

<button class="py-2 px-4 bg-blue-500 text-white font-semibold rounded-lg shadow-md hover:bg-blue-700 focus:outline-none focus:ring-2 focus:ring-blue-400 focus:ring-opacity-75">
  Save changes
</button>


<button class="btn-primary">
  Save changes
</button>
```

The CSS that accompanies this:

```css
  .btn-primary {
    @apply py-2 px-4 bg-blue-500 text-white font-semibold rounded-lg shadow-md hover:bg-blue-700 focus:outline-none focus:ring-2 focus:ring-blue-400 focus:ring-opacity-75;
  }
```

The documentation actually cautions against extracting out to such a style (semantic) and instead to extract utility classes; but I chose to include it because it's a perfect illustration of why I disregarded and misunderstood this feature.

The best description I can think of is that it made me feel like it was a completely unnecessary abstraction. Because I could only think in terms of classes named after their components or usage, it felt like writing CSS through the proxy of utility classes and then my markup being essentially the same. Why not cut out the middle man?

When you use the pattern instead for a more complex utility, the simple elegance becomes extremely more clear. For example:

```css
.flex-full-center {
	@apply flex justify-center items-center
}
```

As an experiment, I pulled up the last major project I released and did a quick scan to see how many instances of those three particular styles appeared and I found 97 different styled components with those three styles. That's 6KB of CSS before GZIP just for centering things. This is one of the biggest drawbacks of semantic class naming and organization. 

Where this pattern shines is that middle ground where you have repeated yourself so many times that extraction makes sense, but extracting a stand-alone component would be overkill. 

## Realization 2: Shipping Less CSS
I won't sit here and lie and say I had reached the apex of shipping only necessary CSS, but I thought I had surely gone to the big leagues at least. All of my projects had a very small global stylesheet that was more or less used on every page. Then everything else was styled components that lived alongside the React components so that they could be chunked into much smaller packages of what I needed page by page. 

I was blown away once I began to see how much smaller my CSS payloads were with Tailwind. The framework in its entirety starts off extremely large, even more so once you begin generating custom utilities, adding colors, and things of that nature. When you build your production bundles, a combination of Post-CSS and CSS Purge removes any of the styles that are not being used in your application, leaving only the bare necessities. 

I know some people can be a little shy about adding yet another build step to their application, but the setup is painless and fast. I'm not one to advocate for obsessing over bundle size, especially since one poorly optimized image can easily be several magnitudes larger than your entire site's CSS. But it's a sizable benefit you get for free without really having to ever think about it or spend time on it, which is a win.

## Realization #3: Never Build a Theming System Again
This was actually the most recent realization as I was building the website you are looking at now. I knew Tailwind was customizable from a brief glance at the documentation, but it wasn't until using this TailwindUI starter that I realized exactly how powerful the built-in theme system is. 

Show of hands, who has built out a theme system from scratch? 

It's never a ton of fun, at least not for me, and the more that I dug into Tailwind's system of defaults, overrides, presets, plugins, and utility generation, the more I realized I have about 60 hours in every project I've built in recent years that covered functionality Tailwind would give me for free. And to sweeten the pot, instead of the system being designed by just me, it's the collective work of hundreds of contributors. 

Fun example, Tailwind's color system is based off of a series of available color groups like slate, rose, or zinc and shades ranging from 100 to 900. You can override these or create entirely new color sets and it automatically generates the necessary classes for you with no extra work. Then just as described above, your final CSS bundle will only contain the classes that you actually use so your users aren't paying for colors you thought you might need and didn't use. 

## Realization #4: Consistency
Consistency has always been my achilles heel. The small differences in details like margin, padding, font-size, and spacing can start off subtle bordering on invisible, but as they congregate, they can quickly lead you to a layout that just looks disorganized and strung together. 

Tailwind is not a silver bullet in regards to this problem, but having predetermined sizes for most properties that I can base my design off of and customize very easily both during development and during revisions is the easiest way I've found so far to attack this.

This may seem like an trivial problem not worth mentioning, "just use some CSS vars, Jody!" But then we end up back at realization #3. Now I'm working on a theme system again instead of the fun features that I want to be working on. 

## Realization #5: Time Savings in Customization
I've always had a love-hate relationship with component based CSS frameworks or React UI kits like Bootstrap or Chakra-UI. Because on one hand, it's nice to be able to immediately start laying down UI and building features instead of boilerplate and "back office" code. But the majority of my work is either for clients at my day-job at an agency, or freelance clients for my own agency, so there are agreed upon design parameters that I don't dictate. Also, just between you and I, I can't even design a bake sale flier. A good designer is such a treasure.  

So what I've come to learn through much trial and error is that I almost always spend more time massaging these components to match the design I am given than it would have just taken me to create them myself. 

With Tailwind, I can immediately start building exactly what I need and only what I need, cutting straight to the chase and this saves me time and as such saves my clients money. To address the elephant in the room -- yes, there are always exceptions. I have a literal negative amount of interest in building a from-scratch DatePicker for example. But for those extremely complex components, there are no shortage of fantastic headless UI kits like HeadlessUI by Tailwind Labs that do the heavy lifting. 

## Some Gripes and Trade-Offs
There is no such thing as a perfect solution, and while Tailwind has become my weapon of choice, there are a few gripes and trade-offs that I feel pertinent to mention.

### Is it "easier"?
A common claim made in social media circles is that Tailwind is easier than writing your own CSS, especially for beginners. There is some truth to this in an architectural sense that I am going to mention shortly -- but in terms of "I need to build this design", I disagree. 

The reason being is that in order to be productive with Tailwind, you need to already have a strong grasp on CSS. This is because in a utility based approach, you are applying atomic properties, not complete component styles. If you need to build a card, you can't just use `class="card"` and be off to the horse races, you need to be aware of each CSS property involved and how to compose them for the effect you need. 

### CSS Architecture
I've actually had this debate with Adam himself 😬, and I did not articulate myself properly so hopefully I can find better words this go round. 

Most of the complexity in CSS, in my opinion, is not "How do I make this box look like I want it to", but rather in the architecture. Details like shipping the minimal amount of CSS required, understanding the cascade and specificity behavior so you are not fighting with yourself to make changes or overrides, or ensuring the long term maintainability of your styles are handled for you in Tailwind. This is a double edged sword.

On one hand, it's a powerful time saver that people should absolutely take advantage of. On the other hand, what if you find yourself unable to use Tailwind? My projects at work exclusively use CSS-in-JS solutions with component UI kits. I maintain that if you still take the time to learn these skills, it will make you more effective at CSS in all your projects whether they be Tailwind or something else. 

### Accessibility
Not all UI kits / CSS frameworks are created equally in this regard. Bootstrap as an example is not oblivious to the concerns of accessibility, but does not come anywhere close to the amount of work and care put into projects such as Shoelace Styles or Reach UI. 

But in any case, when stepping back into what is essentially a "vanilla CSS" approach at the end of the day, by that I mean no pre-build components, you lose any of the accessibility work that has been done by the library maintainers and contributors and you need to be more aware of additional steps you may need to take to ensure the accessibility of your application. 

If you are using HeadlessUI or other similar libraries in combination with Tailwind, the sting of this potential issue will be far less problematic, but still something to be aware of.

## Conclusion
I started off as the most intense of skeptics, very vocal and confrontational about my feelings around Tailwind. But now I have no intentions of using anything else for my personal projects and freelance work and am pushing to convince coworkers to try their own experiments to assess what us adopting Tailwind as our default may mean and what trade-offs that would involve. 

Sometimes it's good to remind yourself that you can't be sure how you feel about something without giving it a thorough and good-faith try, and if you find yourself relating more to my initial thoughts and less with my realizations, then maybe you just need to build something top-to-bottom with Tailwind and experience the full lifecycle of benefits? 

Or maybe you already have and just don't like it, that's totally fine too :).

I'm Sorry Tailwind, Let's Be Friends

## The Elephant in the Room
Am I guilty of a clickbait headline? I think most content creators are at one point or another.

But before you start yelling "gatekeeping!" allow me to elaborate. Anyone who **wants** to learn to code, **should**, and **can** learn to code. The intent of this article is not to deter people or to make claims that "some people," wherever that line gets drawn, cannot learn to code.

This post will delve more into this idea's "should" aspect.

## The Motive of Learning to Code
One commonly debated topic on social media is that people should have a specific motive or that other reasons are more pure or acceptable than others. For example, some folks claim that you should not pursue programming or coding unless you are passionate about programming and computer science. People who only get into coding because it can be an incredibly lucrative career should not have.

I'm not going to lie to you. A career in programming is **life-changing**.

I grew up in extreme poverty. I was never homeless or facing food insecurities, as far too many people in the world do, for which I am incredibly grateful. Still, my parents both worked multiple jobs and went without so I would have the quality of life I did. A career in programming allowed me to increase my income by 1200% from 2008 to 2022. It allowed me to dig myself out of a bottomless hole, give my kid's the lives I want them to have, and build the future I want to develop. 

The income alone is a damn good motivation to want to break into the programming or tech positions, and I wouldn't fault anyone for feeling this way. Likewise, I would never think poorly of a co-worker, colleague, or individual to cross my path, for this being their primary rationale. However, let's briefly consider that there is more to life than making money.

## "I hate my job." 
If you are a programmer at any level and love writing code, you may find it hard to believe or relate to, but some people despise writing code. 

This dislike of coding can be for a multitude of reasons. For example, some folks find the process of commanding silicon to do our bidding uninteresting, overly tricky, unfulfilling/boring, or any other unsatisfactory descriptors. Other people dislike sitting or standing at a desk for long periods. 

Hate may be a strong word initially. You may even feel indifferent at first, but we are talking about a scale of 30+ year career. 

Anyone is free to disagree. However, I firmly believe that money is not worth working for a job you hate. Even high earners will likely not retire by 50, with an average lifespan of around 77 years. Do you want to spend a third or more of your life unhappy?

## Think you might like it?
To re-iterate my opening message, if you think you may like coding, absolutely give it a try. The best resource around, in my humble opinion, is [FreeCodeCamp](https://freecodecamp.org). They have a wealth of resources available, ranging from a guided course from "Hello World" to fully functional web applications, a YouTube Channel with hundreds of videos, and an enormous community to support you.

Don't let this article or your preconceived notions about what a job in programming might be like worry you. The only way to know for sure is to dive in, learn some concepts, and apply them to fun projects that interest you. You may find something you love so much that you even want to do it in your free time as a hobby, something that is fulfilling enough to be a career but maybe not a "passion," or you may not like it at all. In any case, that's ok! 

## Conclusion
Some might say this entire article is nitpicking, and they would not be entirely wrong. But in a global world where writer and reader may not speak the same native language or platforms like Twitter where post-length limitations limit context, I find it's often better to be as explicit as possible. 

One might say it's better to say, "Anyone who wants to write code should learn." 


Full stack developer, open source enthusiast, and aspiring public speaker

Latest Articles

Is HTML a programming language?

Taming Python Dependencies with Virtualenv

I'm Sorry Tailwind, Let's Be Friends

Is Coding Really for Everyone?