HTML & CSS Are Critical To Your Teams, Business, and Product.

There is a nasty thread weaved through the world of web development that I consider insidious and different from the other programming language holy wars. To wit, I consider the hate thrown at HTML & CSS developers to be a wildly counterproductive aspect of web development that causes damage to companies, teams, and individuals.

I say developer very consciously, because the first attack deployed against anyone who specializes in HTML and CSS is that they aren’t true developers. From one perspective, this is somewhat true in that those who work in HTML and CSS aren’t often working with, and manipulating, data structures. But they are still working in an abstracted language that has become incredibly complex with time. Performing complex calculations in CSS for the purposes of animation can be deeply mathematical and time consuming, as the inimitable Ana Tudor shows with every demo she posts.

Furthermore, the “true” developers who work with data transport between layers of an application are often also not working with data structures! They are simply using pre-packaged tools to get data from one place to another. Yet no one questions their developer bona fides. This is idiotic.

Coming from the perspective of someone who has been deployed on projects staffed primarily by full-stack developers who have created incredibly messy edifices of HTML and CSS that grow to the point of being terrifying, I am convinced that every project, ideally, should have someone who specializes in the two.

From Whence The Hate?

What do programmers hate the most? Syntax. It’s why discussions about syntax have filled as many pages as actual code. In programming, a for loop will always be a for loop. The syntax may be slightly different, but the principle is the same. As such, you have beloved languages where the entire point of the language was to get rid of as much syntax as possible! I’m looking at you, Python.

That’s understandable. It really is. Syntax can represent things, sometimes subtle, that can have an outsize effect on how code runs. Programmers want to be able to easily reason about their code without syntax getting in the way. To reason is a programmer term describing the mental process of thinking about and understanding the logical functioning of a program, and it's what brings them joy. Syntax concerns rip them out of this mental state. It’s stuff that they have to remember as opposed to concepts about which they have to think. So it’s no surprise that they hate HTML and CSS. They are nothing but syntax! Changes to CSS can have a seemingly arbitrary effect on both the element being changed, and every other element on the page! Taking an element out of one parent and putting it in another can break things completely. Without the huge matrix of knowledge necessary to understand those effects, someone innocent of HTML/CSS can produce a mesmerizing train wreck.

This is why Bootstrap, which is really nothing more than a CSS framework, is the most starred Github repository in history. Thousands of full stack devs, who become overwhelmed by HTML/CSS, simply leverage a framework. They disparage HTML and CSS, then reveal how important and difficult it is by making Bootstrap a worldwide superstar.

For Companies

If you cannot afford an HTML/CSS specialist, then I recommend leveraging a framework. The developers mentioned in the previous paragraph have it right. For the purposes of a skeleton crew team, spending time and money writing logic is more important than the mere look and feel of the application. Bootstrap is the most common, but Foundation is also quite good. I prefer these over more complex UI libraries because they can easily be used in rendering libraries like Angular, React, and Vue.

A word of warning, though. Without a CSS expert, do NOT change the frameworks unless you are merely changing the styling or colors of a single element such as a button. If you make changes to the structure itself, you lose one of the key benefits of the framework: the structure! With that structure, you do not have to worry about elements not playing nice with each other or behaving unexpectedly. You are forced to work within the structure, of course, but that is the point. The moment you begin to alter the structure, the developers of the framework stop having an intentional influence. You have left the bounds of their expertise. Do not do that.

If you have a suitable budget, a company can land themselves an excellent HTML/CSS/Accessibility expert for less than $100k per year. That is great value, not just because they will produce their own code, but because you can now leverage frameworks more completely. By that, I mean how your project can leverage Boostrap, which lets your full-stack team become accustomed to using it in their code, but you can now customize Bootstrap. Before, Bootstrap and Foundation's basic structure was off-limits. Now it isn't. It is a new creative horizon for your UI.

Earlier, I mentioned accessibility only in passing, but I'd like to focus on it for a moment. It's a subject that is worthy of an entire book, and indeed has entire books dedicated to it. A large percentage of your users will have problems accessing your product. For many people, it's merely being a bit far-sighted. But others may be more severely impaired, such as being completely blind or having limited motor functioning. Their money is just as green as anyone else's, though, so cater to them! To do this very well requires UI/UX specialists, but I think that many projects can get away with simply using well-known interaction patterns that any HTML/CSS expert worth their salt will understand. A little accessibility goes a long way toward building good will with important demographics.

If you have the budget for it, a new job category is starting to rise in prominence in most tech-oriented companies, and that is the UX Engineer (A term I recently learned that is on the rise is Design Technologist, or DT). Google, Microsoft, Amazon, Apple, Ebay: all of them have developers who do nothing but UI. They know every in and out of HTML and CSS, and know most of the particulars of complex, client-side coding. Their knowledge fades once you get to application architecture, but they aren’t architects. That’s not why they are there.

I would like to specify that while this article is specifically about HTML, CSS, and JavaScript, this person works in whatever language is driving the interaction. They are designer developers who understand human-computer interaction. They are a key part of all aspects of design and prototyping, and usually spend most of their time with the design team, but they then spend extensive time with developers to ensure that designs are implemented as intended.

As computing power enables more complex applications, and as the growth of socio-technological mores allows ever-more complex human-computer interaction patterns (we're long past the days of people not understanding "open the folder"), this person will become critically important for the creation of competitive digital products.

For Developers

The era when a full-stack developer could be completely ignorant of HTML is over. As applications have moved over to the client, and frameworks like React and Angular have made UI rendering a central element of their design considerations, the tools that actually enable the display of the application have become more important. Furthermore, as JS/HTML/CSS applications are being shoehorned into mobile environments with tools like React Native and Apache Cordova, understanding the significant considerations of the UI elements that will operate in that constrained environment is beyond critical; it can be the difference between a good UX that brings users back, and a bad UX that drives them away.

I am not saying that you need to become an HTML/CSS expert. You do not need to understand everything, but you do need to understand the dangers. If more developers did that, we wouldn’t have thousands of deployments with butchered installations of Bootstrap.

For Designers

You have a much easier job than the developers since the languages of HTML and CSS will map to your intentions pretty well. That’s why programs like Sketch, or Adobe Fireworks back in the day, can output entire pages of HTML and CSS.

Unfortunately, the HTML and CSS output by those programs is almost always a mess. It might look right, but on a code level, it's likely a dumpster fire. Anyone who remembers working with the early WYSIWYG tools like Drumbeat and Dreamweaver will remember the shit show that was their output. Somehow, things haven’t gotten better.

Regardless, the point is that producing good HTML and CSS can easily be a part of your design process. Create your designs, then literally give the development team the code for them to directly integrate. You can’t give them an entire framework, but you can at least make sure that the buttons aren’t a mess. This is often referred to as a pattern library and is something you should be well acquainted with creating.

Conclusions

• HTML and CSS are first-class concerns for your application. Do not rely on your full-stack developers.
• If you do not have the budget for HTML/CSS specialists, then leverage an unadulterated framework like Bootstrap. Allowing non-experts to change it would be like having your maid repair your HVAC system.
• For larger budgets, consider hiring a pukka developer to be a part of the design team. You can call this person whatever you want: UX Engineer, UI Developer, Design Technologist, it doesn’t matter. They are your design team's access to the wild, woolly world of application logic.
• If you are a developer, learn the pitfalls of HTML and CSS, and the particulars of the various UI frameworks. That is a better use of your time than trying to keep up with the languages. Let the framework developers worry about that. You worry about the implementation.
• If you are a designer, learn HTML and CSS. I know this is common advice, but it will only make your life easier. Instead of saying "here's how the button should look and work," you just say "here's the button. Don't bloody change it."