DEV Community: Kevin Ruhl

Tailwind CSS: A Pragmatic Choice for Faster UI Development

Kevin Ruhl — Mon, 24 Mar 2025 05:05:00 +0000

Introduction: Beyond the Framework Wars

Another day, another Tailwind post and a new JS framework coming out (very likely). As a disclaimer, this isn’t a “Tailwind vs X” piece or an attempt to convince you to switch. Instead, I’ll explore what Tailwind gets right, who benefits most from it, and why it gained traction.

As developers, we love to defend our beloved tools and frameworks. Personally, I am not a fanboy and view software tools as that—just tools. Some are better suited for particular tasks and teams depending on the situation and context. I will not attempt to persuade you to ditch your current styling solution for Tailwind and pretend it will fix all your problems.

The truth is, convincing developers can be a monumental task and a waste of effort. Technology moves incredibly fast. It is hard enough to keep up with tech news and new tools coming out. By the time this article is published, two new CSS frameworks will likely have been released. Instead, I want to share what competitive edge Tailwind brings to the table and why it has become a popular choice for many developers and teams.

Our guy Tailwind here serves a purpose and fills a void that has been present in the UI world for some time now. Before Tailwind, teams had to:

Write and maintain large, bloated CSS files.
Deal with specificity issues and cascading conflicts.
Come up with and enforce naming conventions (e.g., BEM, SMACSS) to keep CSS manageable.

All of the above challenges are not necessarily problematic if you have a standardized approach and system that “forces” developers to follow the rules of your custom CSS “pseudo-framework.” The issue is, very few FE teams can check that checkbox. Many teams roll their own styling systems, but few have the deep design expertise to cover all edge cases. This leads to inconsistent and unintuitive CSS solutions.

Back to Tailwind. It is a utility-first CSS framework that offers an alternative way to style UIs. It has an arguably great developer experience, a mature ecosystem, wide adoption, and compatibility with a ton of web frameworks. I’ve been using it professionally for the past four years, and for the most part, it has been a nice and enjoyable experience. It has helped me build and ship UIs faster, more consistently, and has reduced the need to dive too deep into CSS.

The Tailwind Landscape: Lovers, Skeptics, and Critics

Some developers are using Tailwind and genuinely love it, others may be considering giving it a test drive to see what all the fuss is about, and there are yet those who will die on the “Tailwind turns HTML into an unreadable mess” hill. Honestly, Tailwind is not for everyone. And the utility classes can make your HTML look a bit noisy and cluttered. But it is a cost I am willing to pay for the benefits it provides.

That’s fine. We all have our philosophies, beliefs, and preferences when it comes to tech tools and approaches. I get it. Tailwind is not for everyone. It is a utility-first CSS framework, and some developers prefer to write raw CSS or use a preprocessor like SCSS. That’s fine. Tailwind is not a silver bullet, and it has its own set of trade-offs. It has its own set of limitations. But it is a pragmatic choice for many teams and developers who want to ship UIs faster and more consistently. These benefits are hard to ignore, especially for small teams and startups that need to move fast and iterate quickly. Tailwind is a great choice for them. Loads of tech companies, early startups, and solo devs are all building and shipping their UIs using Tailwind. And they are doing it very rapidly.

What Makes Tailwind Stand Out

Probably Tailwind’s biggest selling points are customizability, good built-in defaults, un-opinionated styles, speed of development, and documentation. It provides a standardized system of utility classes and design tokens, covering colors, typography, layouts, spacing, responsiveness, positioning, sizing, dark mode, and much more. You can customize the theme configuration or stick with the default—up to you. This is great.

Before Tailwind came onto the scene, creating a custom design system meant either hand-rolling it with raw CSS or a preprocessor, or adopting a full-fledged UI component library like Material UI, Bootstrap, Chakra UI, etc. With most UI libraries, adopting one meant locking yourself into their predefined styles.

Tailwind, however, took a different approach. It said:

"Naming CSS classes, managing rules, and handling specificity conflicts is a hassle. Here are utility classes you can inline to cover most common use cases, so you don’t have to worry about styling overhead or remembering class names. We’ll also tree-shake unused styles in production to improve performance. Plus, you can easily build your own theme and design system using our primitives, or just use our default theme. Up to you!"

It became the missing answer for teams and companies who lacked deep CSS expertise but also did not want to pay the cost of getting married to a pre-styled UI component library (although TW does play nicely with things like Material UI) just to reap the benefits of a production-ready CSS theme and design system. Tailwind came in and filled that gap, which helped tons of developer teams build UIs faster. Its impact on the developer community and the industry as a whole is undeniable.

The Trade-offs: Tailwind vs. Alternative Approaches

Can you achieve the same with raw CSS, SCSS, or even another CSS framework? Absolutely. Have a ton of successful tech companies built UI products with just raw CSS and no other styling abstractions? Surely. But understand the tradeoff you are making. It takes significant time and effort to properly build a styling & design system. You then also have to onboard new developers to your custom system. This is time and effort that could be spent on building features and shipping products.

I was unfortunate enough to work on a handful of projects that had their design system built on raw CSS, and I still get war flashbacks from the over-engineered and just outright clunky ergonomics they offered. Developer experience was an afterthought. Frankly, I don’t blame the authors of those custom design systems and styling abstractions; frontend development is complex, and we’re juggling a lot of different responsibilities. Tailwind understands this and helps lighten the load.

Its true value lies in its convention—a widely adopted, standardized approach that many teams and organizations have converged on. The developer experience, with inline comments on utility classes that clearly indicate which CSS is being applied, is seamless and intuitive. The Tailwind team understands developer pain points and works to minimize them.

The Bigger Picture: Developer Experience and Team Productivity

Other utility-first CSS frameworks exist, such as UnoCSS, AtomicCSS, and many more. I chose Tailwind for this article because it is widely known and needs no introduction. Remember, Tailwind’s value is in the system it provides. It offloads decisions on how to style UIs, which ultimately helps many small and resource-constrained teams get up and running quickly and ship UIs faster. Once you’re familiar with it, working in Tailwind-based projects is seamless, eliminating the need to learn custom styling abstractions and wasting onboarding time.

That said, if you’re a CSS expert and have already built a scalable, standardized approach within your team, more power to you. Like everything in software development, what you choose to use depends on your own context, needs, and experience.

Happy hacking!

The Hidden Cost: Why Dead Code Shouldn’t Linger in Your Codebase

Kevin Ruhl — Thu, 13 Jul 2023 02:30:13 +0000

You may know it as dead code, unused code, redundant code, dead branches, or zombie code. In the realm of software development, dead code lurks like a silent menace within codebases. It refers to sections of a codebase that are no longer executed, or if executed, have no effect on the application behavior or produced output. Over time, as software evolves and requirements change, dead code accumulates, leading to bloated, confusing and fragile systems.

This article aims to shed light on the perils of keeping dead code around and emphasizes the importance of actively removing it from codebases. It also proposes tools and techniques to effectively address this issue. Let’s dive in!

Understanding the Downsides of Dead Code

This unused code has numerous negative consequences on our codebases and applications when left untouched and unresolved. It increases complexity and maintenance costs, obscures code’s intent, reduces code quality, and can negatively impacts debugging and testing.

Increased Complexity and Maintenance Costs

As dead code builds up within a codebase, the complexity of the system grows exponentially. This complexity hinders the understanding of the code, making it more difficult for developers to navigate and update the system. Consequently, the addition of new features, bug fixes, or optimizations becomes more challenging and error-prone. Developers may inadvertently modify or remove code that appears unused, only to discover later that it was still being referenced by other parts of the system. This leads to increased maintenance costs, longer development cycles, and a higher chance of introducing bugs.

Obscuring the Code’s Intent and Logic

Code serves as a form of communication among developers, enabling them to understand the intent and logic behind a program. Dead code muddles this communication by introducing noise and confusion. When developers encounter sections of code that are seemingly inactive, they may waste time analyzing it, searching for its purpose or relevance. This unnecessary cognitive load can lead to misunderstandings, misinterpretations, and reduced productivity. By eliminating dead code, developers can focus on the active and relevant parts of the codebase, improving collaboration and comprehension.

Code Quality and Maintainability Overhead

Maintaining high code quality is crucial for long-term project success. Dead code, however, directly opposes this principle. Its existence can imply a lack of diligence within the development process. Over time, dead code can accumulate to the point where it becomes difficult to differentiate between active and inactive sections. This hampers code maintainability and increases the risk of introducing bugs or security vulnerabilities. By eliminating dead code, developers can improve code quality, reduce technical debt, and ensure a more maintainable and reliable software system.

Negative Impact on Testing and Debugging

Testing and debugging are essential aspects of software development, enabling the identification and resolution of issues. Dead code complicates these processes. The presence of unused code increases the surface area for potential defects, requiring additional testing efforts. Moreover, dead code can confuse the debugging process, as developers may spend time analyzing irrelevant sections of code, diverting attention from the true cause of a bug. Removing dead code reduces the testing scope, making testing and debugging more efficient and effective.

Detecting and Discarding Dead Code

At first glance, the solution appears straightforward: remove any unused functions, variables, types, modules, branches, parameters, and fields. However, in practice, eliminating dead code can prove challenging. While there are cases where removing the problematic code is as simple as it sounds, there are also situations where dead code might be concealed and not immediately apparent. In this section, we will explore several options and strategies to effectively detect and remove hidden dead code. By implementing these steps, developers can ensure a more thorough removal of unused code and improve the overall cleanliness and maintainability of their codebases.

1. Audit the Codebase and Pull Requests

Perform a thorough codebase audit to identify potentially dead code. Look for unused variables, functions, classes, and components. Pay attention to code that is commented out or disabled. In addition, developers can also perform these checks and audits in pull requests to verify the absence of any newly introduced dead code in the codebase.

2. Use Static Analysis Tools

Utilize static analysis tools like linters, code analyzers, and IDE plugins. These tools can help identify unused code and provide automated suggestions for removal. Incorporating linting steps into the CI process provides valuable feedback to developers regarding unused code prior to merging their changes into remote branches. This proactive approach ensures that potential dead code is identified early, allowing developers to address it before it becomes part of the codebase.

3. Verify Unused Code

Once you identify potentially dead code, ensure it is genuinely unused. It’s essential to exercise caution and ensure that removing the code won’t cause any unintended side effects. This step is particularly crucial for large codebases or when dealing with legacy code.

4. Remove Unused Code

Once you are confident that the identified code is genuinely dead, remove it from the codebase. Remove the unused variables, functions, classes, components, properties, parameters as well as any associated imports, comments, or disabled code blocks.

5. Perform Thorough Automated Tests

After removing dead code, run your tests to ensure that the codebase still functions correctly. Dead code removal can introduce unintended consequences, such as breaking dependencies or revealing hidden bugs. Running comprehensive automated test cases helps catch any regressions.

6. Refactor as Needed

Dead code removal often reveals opportunities for refactoring. Take the opportunity to refactor the codebase, simplify complex sections, and improve overall code quality. Refactoring can make the code easier to understand and maintain in the long run.

In Closing

Dead code burdens projects with increased maintenance overhead and complexity. It hampers code readability, raises costs, and confuses newcomers and authors.

To address these issues, we can adopt a proactive approach by implementing regular code reviews, performing refactoring tasks, and maintaining good code hygiene practices. Additionally, leveraging powerful tools like linters can significantly aid in detecting and removing dead code. This, in turn, promotes the development of cleaner, more readable, bug-free, testable, and maintainable software systems.

Remember, removing dead code is an iterative process. It’s recommended to start with small and safe changes, test thoroughly, and gradually tackle larger codebase cleanups. Additionally, consider collaborating with your team and seeking code review to ensure the removal of dead code is well-planned and coordinated.

Immutably remove object properties in JavaScript

Kevin Ruhl — Mon, 06 Dec 2021 15:16:35 +0000

Most of us have at one point in time needed to remove an object property for whatever reason (i.e. a runtime condition was successfully evaluated, a server response was received, etc.). In these cases, arguably the most commonly used approach was to use the built-in JavaScript delete operator which will attempt to remove a given property from an object, if that property exists. This is a perfectly reasonable way of removing an object’s property in the language, but there are some caveats around it that may cause foot shootings if not careful. The most noticeable problem to this approach is in the inherently mutable nature of the delete operator. It mutates the underlying object reference, therefore mutating the original object and causing unwanted side effects.

In this article, I will first give an example of removing a property from an object using the delete operator, and will then present a safer alternative approach that uses object destructuring along with the rest operator to accomplish the same.

The NOT RECOMMENDED mutable approach

First things first, let’s remove a property from an object literal using the delete operator:

const person = {
    name: "foo",
    age: 34
}

function removeObjPropertyMutably(obj, key) {
    delete obj[key]
}

removeObjPropertyMutably(person, "name")

console.log(person) // prints out { age: 34 }

However, there are some drawbacks to point out when using the delete operator:

It will mutate the object reference in memory (i.e. it will not create a new copy).
It is only capable of removing one property at a time. Meaning, if your use case requires removing multiple properties, then your code will look a little something like this:

const person = {
  name: "joe",
  age: 33,
  email: "joe@gmail.com",
  isOnline: false,
  hasPets: true
}

delete person.email
delete person.isOnline
delete person.hasPets

The RECOMMENDED immutable approach

Now, let’s see a better and safer alternative to removing object properties using destructuring and rest operator/syntax:

const person = {
    name: "foo",
    age: 34
}

function removeObjPropertyImmutably(obj, key) {
    const { [key]: removedProp, ...objRest } = obj
    return objRest
}

const updatedPerson = removeObjPropertyImmutably(person, "name")

console.log(updatedPerson) // prints out { age: 34 }

Notice that in doing …objectRest , we are creating a new copy of the passed in object (in this case person) after having removed the target property (name) by dynamically destructuring and aliasing said property. Aliasing in this case refers to naming the variable that will hold the value of the key we want to remove. This way, we can reference it later if we need to.

This approach has the benefit of simultaneously allowing the deletion of multiple properties by means of a single operation. Personally, I find this very handy and practical:

const person = {
  name: "joe",
  age: 33,
  email: "joe@gmail.com",
  isOnline: false,
  hasPets: true
}
const { email, isOnline, hasPets, ...personRest} = person

In the above code snippet, you can see that we are destructuring the keys which we wish to remove — email, isOnline, and hasPets. These are kept in memory as variables that can be accessed if needed to.

So, next time you have a use case to remove a property from an object, you can do so in an immutable and safer manner :)

Final Thoughts

Wrapping it up, whenever I need to to remove object properties in JavaScript, I opt for using destructuring and rest syntax as I consider it a cleaner and safer option when compared to doing it via the mutable delete operator. Which approach are you currently using in the projects you’re working on? Is there another (better?) alternative besides the two mentioned here? Let me know what you think.

Take it easy and see you on the next one!

PS: I have not measured the Big O of either of these techniques, so happy to hear comparison benchmarks if anyone wants to share them :)