When CSS beat Javascript

Categories: Newbie, Technical,

Feb 16, 2020 · 2 mins read
When CSS beat Javascript

My team was building several React components for the front-end of what would be a highly-trafficked app. One of these components required that if the page’s subtitle was longer than 70 characters, we inserted a break at the 70-character point, for the sentence to continue on a new line. Checking the database, we determined that no page’s subtitle was longer than 140 characters. So we’d probably need to break subtitles only once.

Another dev had created the subtitle component, and I was tasked with adding another feature to it. I opened the file and saw this function for fulfilling the subtitle’s 70-character width requirement:

It took me several minutes to understand what the function was doing:

  • First the sentence (string) is split into an array of its words (tokens), and a counter i is initialized to 1.
  • Next, accounting for spacing, we add the lengths of each word in tokens together. With each addition, we check if the total is less than 70; if so, we add the length of the next word to our total.
  • The goal is to identify the word before which the sentence is at or just below 70 characters (indicated by the incrementing i value), and then break the sentence at that word (this is what the return line does).

The approach was effective; it met task requirements. But could it be simpler?

I thought so, and googled “limit sentence length to number of characters html css”. I discovered the ch property, one of several font-relative CSS units. 1ch is equal to the width of the zero (‘0’) character of the current font-family, at the current font-size. It is important to note that the ch value will change for different font-families. But considering that my team follows very strict typography standards, I wasn’t worried about this potential variation in the ch value.

I deleted the Javascript function and then, within CSS, I set the maximum width of the subtitle’s container equal to 70ch:

5 lines of Javascript replaced by 1 line of CSS. Ooooh, it was satisfying indeed when my fellow devs reviewed and embraced my implementation as the better approach indeed.

As a bootcamp-educated developer, I would always feel the pressure to quickly level up to the ‘higher’ programming languages, and ‘graduate’ from HTML and CSS. With more experience, however, I’m finding that it is not about how ‘loaded’ my developer tool belt is. It always comes back to: How can I solve this problem, or implement this feature? How simple is my solution? How understandable? How maintainable?

"It's not about how bloated our developer tool belts are. It always comes back to: How can I solve this problem? How simple is my implementation? How understandable? How maintainable?"
Join My Newsletter

You get one email whenever I post new stories.
I never spam!