Inspect Element Debugging Makes Me Want To Punch Through My Screen
Picture this. You’re editing your website and you have a button component that just doesn’t look right. You want to see which mishmash of CSS rules will get it to do what you want, so what do you do?
Inspect element and Chrome DevTools of course!
So you continue trying out style after style, maybe having to reload the page a few times and lose your progress, until you finally get it looking how you want.
From there, you have to open up your IDE, find the code that corresponds to the component you were editing, and translate the styles you tried out into whatever CSS framework or component library you’re using.
So efficient, so fun. It really doesn’t get better than this…
Annoyance Aplenty
As many of us front-end devs have experienced, the inspect element styling workflow often leaves a lot to be desired. While it does provide a much quicker way to iterate on styles than just changing your source code and refreshing (even with Hot Module Replacement), it comes with its own set of issues.
Given the increasingly large gap between the HTML code that you see in the inspector and the source code that generates it (often a JS framework like React), these issues are only becoming more annoying.
In my view, the inspect element debugging workflow has 3 main flaws:
- Not being able to find and directly edit your source code
- Only being able to edit final styles, not the logic that decides them
- Needing to translate CSS to whatever framework you’re using
Where’s My Code? 😡
One of the most common issues I face, especially when working on a new codebase, is finding which piece of code rendered which component in order to edit it.
The first part of this is the inconvenience of having to switch between your browser and IDE to get to your code in the first place, but even after opening your IDE, finding the code you need is its own time sink.
When you look at the page, it’s often hard to see how the previous dev (even if it’s your past self) split things up. The filesystem doesn’t help much since even well-named files are hard to trace back to individual components. Worst of all, the inspector often shows a mountain of divs with no source information whatsoever.
This leaves me hunting through file after file for the component I need, over and over and over again. A tragedy :(
The one saving grace here is modern utilities like React DevTools which map HTML elements to their React source. In my experience it only lets you open the component in your IDE about half the time, but it’s a big step in the right direction.
Unfortunately, even with these tools theres yet another level of complexity to sort through—style logic.
Source-Style Disconnect ⛓️
Oftentimes, the styles that end up on a given HTML node are the result of an arbitrarily large heap of logic that decide what classes, styles, and IDs get applied.
In contrast to this, the inspector only shows us the final version of those styles that a node takes on. You can think of this is a chain of configurations and logic decisions that terminate in our DOM styles. For example:
- CSS variables containing colors
- Your classes combining rules into bundles of styles
- Some JS logic to apply styles conditionally
- Maybe even some in-line styles injected imperatively at the end
- Finally, the styles you see in the inspector
Since the inspector only shows us the last link in that chain, we have no idea where the styles we find we need have to go. I inevitably spend almost as long looking for where to insert that style as I do finding out what the needed style is!
Even after putting in the legwork to find the component that renders an element and the logic that outputs a style, there’s often a final hoop to jump through—CSS translation.
So Many CSS Flavors 🍬
For anyone using a CSS abstraction, like Tailwind, MUI components, or any random library component, you likely control your CSS by writing things that are decidedly not CSS.
If you use vanilla CSS in any form, from stylesheets to CSS modules to CSS-in-JS, this might not be something you face a majority of the time, but anyone working in a large enough application will come across this issue at some point. Even a CSS purist likely has to edit a library component through its props at some point.
It’s not too much to translate from CSS to whatever flavor your using once, but when you have to do it every single time you go from inspector to IDE, it becomes a big waste of time.
How to Make it Not Suck
This annoying cycle, along with the undeniable usefulness of inspect element debugging, led us to make Vivid!
In a nutshell, Vivid lets you directly edit the source code of any component on your page, and navigate to other parts of the code that affect its styles from there. The source code of any component you click comes up in-browser, can be easily edited, and all changes get synced to your code base.
It also lets you apply styles directly in your preferred CSS flavor, with Tailwind CSS currently supported!
This is even faster when you do it with the command palette, which can apply styles and create new elements all with shortcuts.
So give it a look! Gotta be better than inspect element, that’s for sure.
