Find in Similar Files for VSCode

I want a shortcut for VSCode that lets me”Find in files”, but with the filter pre-filled to current file type. So searching from a scss file will default to searching scss files. Same for rb or js files. This might use a different shortcut to the default find in files, or use the same one but configure pre-filled file types.

Not sure how it would handle the case where you’d previously set filename filters – should it clear the filter, or only replace empty filter? Not clearing would match the default behaviour a bit better.

Optionally add multiple file types in some order, and order the results like that. So prefer files that match the current suffix (e.g. _spec.rb), then show similar file types (.rb).

I haven’t yet found an extension that does this. I’m confident it exists, but I cannot think of how to phrase a search query to find it.

In the meantime, some useful shortcuts:

  • Alt + F12 to go to definition
  • Shift + F12 to find usages
  • Alt + Click for multiple cursors (totally unrelated but cool)

Utility CSS Is Not Inline Styles

I love utility CSS. It means I write CSS once, and change it rarely. I can quickly and easily add/change pages, and can often read a chunk of markup and know what something will look like. text-right font-bold is more obvious to me than nav_item--inner.

But a common complaint is “it’s like inline styles”. This seems based purely on appearances, rather than actual function. Looking similar doesn’t mean they are the same.

People rarely ask “why is that bad?”. What is actually wrong with inline styles? Does any of that apply to functional CSS? Let’s find out!

Inline styles don’t allow media queries

This is a huge reason to not use inline styles. And a valid one. It does not apply at all to functional CSS! Utility classes in bootstrap, tailwind, and others have classes with media queries.

You can use .p-md-2 to only add padding on medium-and-larger screens. Or d-sm-noneto hide stuff on small screens.

Inline styles cannot be easily changed

For testing quick changes in devtools, or changing a style project-wide. Inline styles requires a full text find/replace. Using CSS does not. You want to be careful to not end up with .text-red { color: blue }. But this can be avoided by naming things properly in the first place. If you change your primary color, the one-line CSS change for text-primary is easier than replacing every color attribute.

Maintenance is harder

Similar to the previous point; with correct names this shouldn’t affect functional styles. There are cases where you’ll still need a find/replace (i.e. if you decide labels shouldn’t be bold). In this case component styles are simpler, as you just update the label.

Separation of Concerns is another popular-but-misguided argument against util classes. Splitting unrelated components or modules into different files is how you separate concerns. Putting related code far apart because they have different file extensions is not.

Performance blah blah

Please measure before using this as an argument. There may at some point be a performance impact. But this is not your bottleneck yet. If you are serving many MB of HTML without gzip, this may come into play. If you get to that stage you have other problems.

I think a lot of this comes from people opening devtools and seeing so much markup. But browsers don’t really mind this. They are pretty good at parsing HTML. Don’t optimize for devtools users.

Additionally, you can easily strip out unused classes with a tool like purifycss. This leaves you with a pretty minimal set of styles + markup.


5 Quotes About Getting Started

“The secret of getting ahead is getting started.”- Mark Twain

“To begin, begin.”- William Wordsworth

“The journey of a thousand miles begins with a single step.”- Lao Tzu

“What is not started today is never finished tomorrow.”- Johann Wolfgang von Goethe

“There are only two mistakes one can make along the road to truth; not going all the way, and not starting.”- Buddha