DEV Community: Betsy Haibel

What are "HTML-CSS-JS" and "CSS-in-JS", anyway?

Betsy Haibel — Wed, 30 Jan 2019 12:51:42 +0000

Yesterday afternoon, an early-career developer I know DMed me to ask: "What are people defining as CSS-in-JS, anyway?" They had seen a lot of the debates flying around the internet, but didn't know how to engage with The Discourse, because no one was bothering to define terms. As I thought about how to answer them, I realized... "CSS-in-JS" is a large, umbrella term! There are a lot of different "CSS-in-JS" techniques out there, and some of them are closer to "traditional" HTML-CSS-JS approaches than others!

A lot of the HTML-CSS-JS vs JS-JS-JS debate is rooted in historical context and feelings rather than precise technical details. I don't think that trying to turn it into a purely technical discussion is a good idea, because there's so many other social dynamics in the room. But I also think that the technical aspects of the discussion will be healthier if we bother to define our terms. In that spirit, I'd like to talk about some specific front-end strategies I've observed.

TL;DR

From breaking these strategies down, the best working definition I can figure out of CSS-in-JS:

any technique which uses JavaScript to apply styles universally, as opposed to applying styles in response to user behavior.

"Separate file" CSS.

Generally not considered CSS-in-JS

CSS is developed in .css (or .scss, or .less) files that are maintained separately from .js files. In development, they are generally be kept in a separate stylesheets directory. These CSS files might be preprocessed from several small files into a larger CSS bundle, or they might not. If the CSS uses component-oriented techniques, developers use BEM or another naming convention to ensure that component-level styles stay component-level.

Web components and Shadow DOM

Generally not considered CSS-in-JS

No strong conventions around "where" the CSS is kept yet here because it's a young technique! But in this style, Shadow DOM style isolation is used to ensure that component-level styles stay component level.

Component-level CSS with informal scoping

Generally not considered CSS-in-JS

CSS is (usually) developed in .css/.scss/.less files that are maintained in the same directory as other component files (e.g. HTML, JS, JSX). This strategy also covers .vue files that do not use the scoped attribute in their style block. These styles are preprocessed into a larger file for delivery, but no data attributes or "roboclasses" are added to enforce component scope. Instead, developers have to use BEM or another naming convention to ensure that component-level styles stay component-level.

JS-applied utility classes

Sometimes considered CSS-in-JS

A utility class framework like Tailwind or Tachyons is maintained in a separate file. All components are rendered by JS, and use that JS to decide which utility classes to apply to HTML elements within the component.

Component-level CSS with JS-enforced scoping

Sometimes considered CSS-in-JS

In this frontend strategy, CSS is used for styling in conjunction with component files OR is embedded in those component files, .vue style. The Vue scoped attribute or a plugin like React's styled-components is used during processing to add a "roboclass" prefix to the component's styles for scoping. This "roboclass" is applied during client or server rendering of the component, so this strategy requires that JavaScript be used for template rendering.

JS-applied inline styling

Pretty much always considered CSS-in-JS

All components are rendered by JS, and use that JS to decide which specific inline styles to apply to HTML elements within the component. "CSS modules" fall into this category.

I'm dashing this post off quickly before leaving for a month-long trip. My list isn't intended as exhaustive and my explanations may not be as clear as I'd want them to be in a more polished post. I'd really appreciate it if y'all could help fill in things I've missed or handwaved, so that this post/discussion can become a strong resource for folks who are confused by CSS-in-JS discourse.

I'd appreciate it if y'all kept your opinions about these technologies OUT of the discussion. I intend to write a follow-up post about what I perceive these technologies' strengths and weaknesses to be. I'll welcome your opinions in that comments section! But right here, I'd like to keep it to definitions, to maximize this post/discussion's usefulness as a resource.

Haskell, Vectors, and Implicit Knowledge

Betsy Haibel — Thu, 03 Jan 2019 16:01:36 +0000

Hey folks!

This piece is a few years old now, but I'm republishing it on dev.to as I move more of my stuff here. It's kind of personal. Unlike a lot of my other work, it's not about teaching folks how to tech better -- it's about why it's so important to me to do so in an accessible way.

This winter I was teaching myself Haskell.

I'd tried before, with everyone's darling Learn You a Haskell for Great Good. My old boss had compared its "offbeat" approach to _why's Poignant Guide to Ruby, which I love. Both have an informal tone, but the similarities stop there: where the Poignant Guide has adorable cartoon foxes, Learn You a Haskell has upsetting bro humor. I think I snapped at one of the (many) fat jokes.

This time around I tried Real World Haskell, and at first things went much better. The material was more usefully organized, and the examples and exercises better suited to my learning style.
Then I came to The Problem.

The Problem

The problem set at the end of Real World Haskell’s third chapter contains the following sequence:

Consider three two-dimensional points a, b, and c. If we look at the angle formed by the line segment from a to b and the line segment from b to c, it either turns left, turns right, or forms a straight line. Define a Direction data type that lets you represent these possibilities.

Write a function that calculates the turn made by three 2D points and returns a Direction.

Define a function that takes a list of 2D points and computes the direction of each successive triple. Given a list of points [a,b,c,d,e], it should begin by computing the turn made by [a,b,c], then the turn made by [b,c,d], then [c,d,e]. Your function should return a list of Direction.

Using the code from the preceding three exercises, implement Graham's scan algorithm for the convex hull of a set of 2D points. You can find good description of what a convex hull is, and how the Graham scan algorithm should work, on Wikipedia.

Problem 9 was pretty simple:

data Direction = Left | Right | Straight

Problem 10 took me a month.

I figured it had to be simple; if it were a difficult geometry problem, it wouldn’t be in a beginners' Haskell book, it would be in a "Haskell as applied to tricky math" book. But approach after approach after approach failed me. I compared slopes. I tried complicated conditionals based on what quadrant each line was in when its base was set at origin.

Did you know that Haskell has two Data.Vector modules? There's one in the standard library that deals with Vectors like the array-like CS concept. There's one on Hackage that deals with Vectors like the geometry and second-year algebra concept. They are called the same thing. I know this now, because I found the docs for the latter, imported Data.Vector like a good girl, and spent aeons of subjective time banging my head against arity mismatch errors before giving up on a dot-product-based solution.

Eventually I finally hammered out all of the special cases.

I’d been pushing myself to finish, rather than cutting my losses and moving on in the book, because I figured it would feel good when I finally did. It didn’t. I just felt stupid, because it had taken me a month to figure out what the authors of the book had clearly expected to be simple.

I moved on to Problem 12. Looked up the Graham Scan algorithm on Wikipedia, as ordered.

Again, determining whether three points constitute a "left turn" or a "right turn" does not require computing the actual angle between the two line segments, and can actually be achieved with simple arithmetic only. For three points , and , simply compute the z-coordinate of the cross product of the two vectors and , which is given by the expression . If the result is 0, the points are collinear; if it is positive, the three points constitute a "left turn" or counter-clockwise orientation, otherwise a "right turn" or clockwise orientation (for counter-clockwise numbered points).

Reader, I saw fire.

At first I was angry at myself, because there had been a straightforward answer and '’d "just been too stupid" to get it. Then I was angry at the authors for not putting that "simple arithmetic" answer in the text for problem 10. Then I was furious at the authors — because I realized why they hadn't.

They thought it was too simple to explain. They thought that anyone learning Haskell would have retained all the random topics that are contained in high school precalculus. They thought that anyone learning Haskell would be the Kind Of Person who just "naturally" remembers that sort of stuff.

And now, because it's a woman writing this, you're probably assuming that this is a rant about how you don't need to know math to computer.

Think again. I am That Kind Of Person. I started programming at either twelve or eight, depending on whether you count HyperCard. I learned Scheme in ninth grade. I am That Kind of Person, and the problem still made me feel like a fucking idiot. Like an impostor. Like I ought to just give up.

Over whether I could remember offhand that vector cross products were not commutative, and what implications this had for turn direction problems.

This could be a rant about the arrogance of the functional programming ivory tower. But a lot of people have made that rant already, and I'm more interested in self-reflection than in being yet another Ruby programmer who’s snotty about non-Rubyists.

Closer to Home

I teach people to program in my free time. I co-organize a drop-in group called Learn Ruby in DC, so every other week I walk people of all different skill levels through how to code. This includes honest-to-god raw beginners, as well as apprentices and juniors.

There is one understanding gap that every single one of them runs into at some point. They mix up local variables and instance variables, or variables and strings, or ivars and symbols — the exact mixup doesn't matter. They respond by randomly adding and subtracting @s and colons and quotation marks until it works, and then they sigh relief. This happens because they don’t have mental scaffolding for the differences between variables and symbols, between locals and ivars — to them, they’re just words that may or may not have magic before them, and so you fiddle with the magic until it runs.

It always takes me a few minutes of observation to figure out that that's what's happening in their heads. I’ve been writing Ruby since 2008; the scope differences between raw ivars and accessors and local variables are like breathing now. My intuitive brain assumes that everyone knows this, and I need to back up and remind it that that’s not true.

I need to do this even though in 2008, as a woman who’d worked with various conventional languages for 8 years, I'd struggled like hell to internalize that difference myself.

Am I making my students feel stupid? I hope not, but… sometimes I probably am.

Where do we go?

The educational materials we create encode our values -- often accidentally. _why's Poignant Guide reflects an ethos where programming is a joyful, creative activity. Learn You a Haskell conveys a worldview that fat jokes are hilarious fun. Real World Haskell assumes that all truly educated people remember vector-math intricacies off the top of their heads.

The values of our educational materials create our community values. People whose assumptions mesh with theirs proceed onward to community participation; people whose assumptions and values don't leak out of the pipeline. I think Haskell is a really pretty language, but I can't tell if the Haskell community wants me.

It’s human to forget that knowledge one has internalized is not common knowledge. It's human to be a poor teacher. It's human to confuse students; to make them feel terrible. It's still cruel. And when we encode that cruelty into our educational materials -- however accidentally -- we turn surviving that cruelty into something we value above all.

What implicit knowledge is needed in your language of choice? How do you deal with that around juniors?

If you found this post helpful, I'd love it if you subscribed to my company's monthly newsletter! We share some of the things we've found valuable each month, as well as exclusive insights into being a more effective programmer and engineering leader.

A senior dev's #1 piece of advice for newbies

Betsy Haibel — Thu, 01 Nov 2018 02:02:31 +0000

Go ahead! Do the thing! Make that refactor you're scared of! You have version control.

You did commit first... right?

Metrics, Async/Await, and Really Big Hammers

Betsy Haibel — Tue, 30 Oct 2018 18:29:31 +0000

The other night my partner Chris asked me over dinner, “Betsy, how would you handle a call to a metrics library using async/await?”

Chris makes developer tools at an e-commerce company. JavaScript isn’t a big part of the stack where he works, but everyone works with at least a little JavaScript nowadays. He needed to expose metrics APIs for the applications developers he works with. He wanted them to be easy to use, and not get in the way of their application code.

Two things about metrics calls: first, they need to be cheap. You don’t want to impose a runtime performance penalty on developers when they measure things. If you do, developers can’t measure that many things! Then, when everything crashes and they need to have measured things, everyone’s stuck with guess-and-pray debugging. In a JavaScript context -- you don’t ever want a metrics call to block the execution thread.

Second, we generally aren’t interested in the return value of a metrics call. We often don’t even care if they fail! Metrics calls aren’t about producing results the user cares about. They’re about observing the process that gets those results. We don’t want to get in the user’s way while we’re reporting on things that only developers care about.

So: metrics calls shouldn’t block the thread, and we don’t care about their return values. Chris, therefore, figured that it was a bad idea to stick a metrics call in the middle of a function and await on it.

async function showPrice(item) {
  const priceWithoutShipping = onSale ? salePrice(item) : item.price;
  const shippingCost = await shippingRate(item);
  const totalPrice = priceWithoutShipping + shippingCost; 

  await postMetrics('userCheckoutStep3', totalPrice);
  showUserTotal(totalPrice);
}

He’s right about that. That await before showUserTotal would mean that the user’s shopping cart wouldn’t get updated until the metrics posted! That might mean that they would get frustrated and close the tab before they bought things. A metrics API that presented that risk would be worse than useless. So Chris wondered — did it make more sense to make a convention of only awaiting metrics at the end of a function?

This idea had some problems. This code is fine:

async function showPrice(item) {
  const priceWithoutShipping = onSale ? salePrice(item) : item.price;
  const shippingCost = await shippingRate(item);
  const totalPrice = priceWithoutShipping + shippingCost; 

  showUserTotal(totalPrice);
  await postMetrics('userCheckoutStep3', totalPrice);
}

But this next code -- which is practically identical — has a bug in it. Can you spot it?

async function showPrice(item) {
  const priceWithoutShipping = onSale ? salePrice(item) : item.price;
  const shippingCost = await shippingRate(item);
  const totalPrice = priceWithoutShipping + shippingCost; 

  showUserTotal(totalPrice);
  return totalPrice;

  await postMetrics('userCheckoutStep3', totalPrice);
}

The difference is that we’ve added a return statement midway through the function. Execution will never proceed beyond the return statement, so the metrics call will never happen.

What if we change it so that the metrics call is on the last line before the return?

async function showPrice(item) {
  // beginning of function

  await postMetrics('userCheckoutStep3', totalPrice);
  return totalPrice;
}

That doesn’t really help us. We’re back to blocking part of the function’s work -- the return statement -- on the results of the metrics call! We don’t know how long it will take to complete. We do know -- computers being computers -- that it could be slow and flaky. We don’t want that to annoy our users.

It’s a conundrum.

Let’s re-examine the assumptions that went into writing this code. Do we really need to use await? If we remove it, what happens?

async function showPrice(item) {
  // beginning of function

  showUserTotal(totalPrice);
  postMetrics('userCheckoutStep3', totalPrice);
  return totalPrice;
}

The answer: it works just fine! Since we were awaiting on postMetrics before, we know that that function returns a promise. But just because it returns a promise doesn’t mean we need to do anything with that promise. After all, we don’t need the value it resolves to. We can just remove the await keyword. postMetrics will perform its network call or socket write or whatever. It will do that happily in the background. The user will not need to care, and neither will we.

Come to think of it, does postMetrics even need to return a promise? Let’s take a look at the current definition of postMetrics:

async function postMetrics(eventName, metadata) {
  return fetch(METRICS_URL, {method: 'POST', data: { eventName, metadata }}).catch(noop);
}

It’s an async function that returns the result of fetch — which also returns a promise. But what if we didn’t make it return that promise? We do that by removing the return statement. We can also remove the async keyword. It's not relevant here. We don't need to guarantee that postMetrics returns a promise, and we don't need to await within it.

function postMetrics(eventName, metadata) {
  fetch(METRICS_URL, {method: 'POST', data: { eventName, metadata }}).catch(noop);
}

Just because a function does work asynchronously doesn’t mean that it needs to be marked with the async keyword, or return a promise. There are three reasons you might want to return a promise from a function:

You care about the value the promise resolves to.
You care whether the operation succeeds or fails.
You care that a side effect has happened before you continue on.

Since none of those are the case here, it’s safe to not return anything from postMetrics.

This is an awful lot of words for “sometimes it’s ok for things to fail silently.” Is there any deeper moral here?

Chris didn’t ask me “how should I design my metrics API?” He asked, “How should I use await in my metrics API?” instead.

Right now, async/await is the cool new kid on the block in JavaScript land. Chris hasn’t done much JS in years, but even he knew that it was what he was “supposed” to use nowadays. Whenever we learn a new programming technique, it’s easy to develop a bad case of hammer-and-nail syndrome.

Async/await is a really shiny hammer. So much of what we do with asynchronous code in JavaScript isn’t complicated evented code. It’s just waiting for things. It’s waiting for API results or database updates, doing a small calculation, and then waiting for something else. The only difference between it and the same code in Python is that the execution thread is doing something else while we wait. Async/await lets us make our code look like the same code would in Python, instead of jumping into Promise-chain hell.

It’s such an obvious win that it’s easy to think that it ought to be a win everywhere.

But that means we start looking at our code and asking, “how can I apply this solution?” It’s dangerous, because it means we skip right past, “what problem am I trying to solve?”

Async/await can solve a lot of problems. But the fact that it’s often the answer doesn’t mean we can skip past asking the question.

Want to learn more about async/await, or about asynchronous JavaScript generally? Sign up for Untangling Asynchronous JavaScript! This free email course looks at the history of asynchronous JavaScript. It puts async primitves like event emitters, promises, and async/await in the context of the problems folks were trying to solve. This lets us talk about what each of them is good for, and where each of them falls down.