Component World

Whatever stack of framework you use, everything in web development seems to be going modular. We’re no longer building pages of screens but components and component systems. This is changing the way I work with files. Where once I would have combined my script and styles into a single resource to reduce requests, I now actively look to break everything down into tiny pieces. For example, I have loads of Sass files. These get compiled into CSS before being concatenated and minified – turned back into the single big file. Working this way has several advantages. It’s easier to work in smaller files – easy to find the line you need with minimal scrolling. It paves the way for using web components of a component system where styles of scripts can be embedded within the component, making it a true standalone piece of the document. Finally, it makes it easy to build dependency free components in a tool like CodePen. You can just write the HTML, Sass and JavaScript and save it as an isolated component with its own demo.

Precision Level in CSS

When we’re using relative sizing in CSS, percentages or ems, how precise do we need to be with our fractions? Is there an optimum level?

If we have a font size of 18px (or anything, it’s relative after all) and we want some smaller text at two thirds of its size (12px) then we can express this as .6666666667em or 66.6666666667%. Here I’ve used 10 decimal places to give a very precise fraction but this feels like overkill to me. If I used just 2 decimal places, .67em or 66.67%, is this accurate enough to consistently calculate the desired pixel value. Or should I not worry? It’ll be near enough.

Looking at other developers’ CSS, mainly in tutorials, the general pattern seems to be to use between 4 and 6 decimal places. Looking back through my own code, my preference seems to be to use 6 but I couldn’t tell you why. I’d imagine I’ve just adopted someone else’s coding style. I definitely feel that going beyond 6 seems unnecessary but am not sure how little I can get away with.

Sass is able to perform calculations using fractions. Here’s an example:

$two_thirds: 2/3 * 1em;

.smaller {
  font-size: $two_thirds;
}

This resolves to .66667em, 5 decimal places. Is this a set precision or did Sass actually calculate it from the root size and decide what precision was needed for it to resolve to an integer? Hmm (rubs chin). I guess that most people let Sass handle this for them and don’t even look at the compiled CSS.

Learning the Right Things

With so much happening so fast knowing what new tech to learn next can be difficult. Where should you invest your time and energy? What if you spend ages learning the shiny new framework and it’s gone within 2 years?

There are a lot of trends and a lot of new-fangled things do come and go. How do you spot the ones that are going to stick around. It’s not easy – you kind of have to go with the flow, not swim against the tide (2 water based metaphors in one sentence, tut).

In front end development there are currently a few big JavaScript frameworks – Angular, React and Vue. It seems obvious to me that none of these are going away any time soon. Which do you choose? It really doesn’t matter. Learning one in depth, finding its powers and limitations, will help you learn the others or other future technologies.

If you’re really not sure where to turn I’d focus on core learning. In the front-end world, learn plain JavaScript. With ES2015 and newer versions than that emerging there’s still plenty to take on and perfect. That knowledge will always be useful.

I guess my short answer would be to favour the evergreen HTML, CSS and JavaScript over associated tech like Pug, Sass, TypeScript, etc. As the core technologies get better over time these current convenience technologies may one day not be needed.

One word answer. JavaScript. :)