
It's been a minute or two since "think in React" was something that was talked about. React has changed quite a bit since then. Is it even relevant anymore? Based on the conversations and articles being written, one might think it isn't.

I'm going to push back hard on that and remind everyone that the way we should think of our React applications is — and always has been — as a pure function of props and state. That is the core, fundamental model of React. If React ever departs from it, it will no longer be React.

This is not me just being pedantic. Thinking this way eliminates a ton of complexity. Folks seem to wrestle so much with things like useEffect, useMemo, useCallback, unnecessary renders, forms, etc. Sometimes we come up with some pretty over the top "solutions" to these problems, but if we take a step back and remember that React expects us to think of our application — and each individual component — as a pure function of props and state, then we can begin to see our problems clearer. We know that if we give different inputs to a pure function we get different outputs. So we know if we give a different object reference as a prop to a component, it will rerender, even if that object has an equivalent shape<sup>[1](#footnote-records-tuples)</sup>. Remembering that a change in props will result in a rerender will do more to prevent unnecessary renders than any of the various techniques or libraries out there are able to do on their own.

This is what "Thinking in React" is fundamentally about.

The same thinking is applicable to hooks, particularly the ones that take a dependency array argument. Think of that dependency array in the same way you would your component props. Your hook will re-run when any element in that array changes, the same way your component will re-render when any of its props changes. In this way, the same mental model applies. Like your components, your hooks are a pure<sup>[2](#footnote-pure-functions)</sup> function of arguments<sup>[3](#footnote-props-arguments)</sup>, and will react similarly to how your components react when new values are "passed".

Perhaps one of the reasons we haven't been accustomed to thinking of hooks in this way is because it is common to write our hooks in-line, right in the component. This makes them feel like they behave differently. Since everything we need is already in scope for our hook, it's tempting to think of the dependency array as a "run only when these values change" array.

```react
const Welcome = ({ name }) => {
  useEffect(() => {
    logWhoSawThePage(name)
  
  // eslint-disable-next-line react-hooks/exhaustive-deps
  }, []) // <-- we only want this to run on mount, right?
  
  return (
    <>
      <h1>Welcome {name}!</h1>
      <p>So glad you could stop by.</p>
    </>
  ) 
}
```

But that would be a mistake. It's not a list of things to watch, it's a dependency array. This is why I am 100% with [Kyle Shevlin](https://kyleshevlin.com/use-encapsulation) when he advocates to never use a bare react hook in a component. Always wrap them in a custom hook. There are many other reasons following this advice is a good idea, but even if this were the only one, I'd still recommend it. Moving all your react-hooks into a custom hook highlights all the things your hook relies on to function. Not just the things you think are the ones that matter to re-run.

```react
const useLogWhoSawThePage = () => {
  useEffect(() => {
    logWhoSawThePage(name) //❌ `name` is not defined!
  // eslint-disable-next-line react-hooks/exhaustive-deps
  }, []) // <-- we only want this to run on mount, right?
}


const Welcome = ({ name }) => {
  useLogWhoSawThePage() // 🧐
  
  return (
    <>
      <h1>Welcome {name}!</h1>
      <p>So glad you could stop by.</p>
    </>
  ) 
}
```

If we need to pass it in, we need to add it to our dependency array.

```react
const useLogWhoSawThePage = (name) => {
  useEffect(() => {
    logWhoSawThePage(name) //✅ that's better
  }, [name]) // <-- 🤔
}
```

```react
const Welcome = ({ name }) => {
  useLogWhoSawThePage(name) // 😆
  
  return (
    <>
      <h1>Welcome {name}!</h1>
      <p>So glad you could stop by.</p>
    </>
  ) 
}
```

"BUT WAIT!" I hear you saying. "We will have '_unnecessary renders_', won't we? We don't want this to re-run every time `name` changes, only on the first render!"

To that, I say, "Oh, really? Tell me why."

Let me help you out if you're stumped. Your initial thinking was that this is a page, and it would be silly to log that the same person saw this page multiple times, just because props change and the page re-renders. Perhaps you realized that that's not quite what would happen. The hook will only rerun when `name` changes, not when the component it's used in is rerendered.

A similar mental model error people make is when they think to themselves that they want something to run "on mount". This is borrowing concepts from lifecycle methods in class components. These are completely irrelevant to hooks. Hooks asks us to think in terms of what has arguments, not in terms of lifecycles. What does this hook _need_ to know about to function. Let React handle the rest. that's what it's designed to do.

I imagine most of you actually saw the problem quite early on and felt a little insulted that I thought you or anyone you work with would make this mistake, but such is the benefit and curse of a contrived example. You can clearly see the problem, so I can clearly point you to the proper solution. In the real world, the problem would be more obscured, but I can assure you, I've seen this category of fallacy — even almost this exact situation— happen shockingly often by some of the most experienced engineers, myself included. Not because it's such a hard problem, but it's just so damn easy to do it incorrectly when we are not thinking in the "React way". The habit of always wrapping bare react-hook calls in a custom hook just creates an environment where thinking in the React way is much more natural.

Pure functions should inform our mental model of how React works across all its features. Purity naturally leads to encapsulation. It becomes easier to identify the lines to draw component boundaries around when we consider that components should be pure functions of state and props. A collection of UI and functionality are a good candidate for a component if we can encapsulate that collection in such a way that it is a pure function of state and props. Pure functions make composition — a central pillar of React — possible. Without it, we would not be able to compose simple pieces into complex applications.

A parting thought. If you are still learning React (and shouldn't we all consider ourselves as learners?) I would very much recommend you try to error on the side of too many components than too few. Think of it as practice. The more we do it the better we get at it. And it has been my experience that having too few components tends to cause those components to become a tangled mess of multiple concepts and functionality all being intermingled together. Such a thing is very time-consuming to disentangle. Whereas components that are too fine-grained are very easy to unwrap. Anything can be taken too far, but in my experience, having too many components is not our collective problem.

Got a comment, or do you disagree? I'd love to talk with you about it. Comment on this post, or hit me up on Twitter. I'm @uniqname. I'm always happy to engage in good-natured discussions and honest debate.

<sup><a name="footnote-records-tuples">[1]</a></sup>The Records and Tuples proposal will change this sentence somewhat and, I think will radically change the game with programming in Javascript. You can think of Records and Tuples as objects and arrays that are compared by value rather than by reference. Therefore two Records with the same shape (keys and values) are strictly equal (#{a: 5} === #{a: 5}). Two Tuples with the same shape (types and values) are strictly equal (#[‘a', 5] === #[‘a', 5]).

<sup><a name="footnote-pure-functions">[2]</a></sup>Obviously, when it comes to useEffect and useLayoutEffect we aren't talking about "pure" functions. These hooks are designed specifically to handle impurity. Impurity is necessary to any application, but ought to be strictly and wisely managed. Effect hooks are a key component of that strict and wise management.

<sup><a name="footnote-props-arguments">[3]</a></sup>Props and arguments are, for all intents and purposes, the same thing. We just use different names for them for different contexts. Strictly speaking, arguments are a more generic term and refer to all the values sent to a function. Props are all the properties (see where we get the term "props"?) on the first argument sent to a function being treated as a React component.


Have we forgotten how to think in React?


“Knowledge is power” it is said. It is also said that “power tends to corrupt”. These axioms are true in our code as much as they are true in life. Let me explain.

When we work in our code bases, we tend to hold varying degrees of the application logic in our head at once. It helps us to understand the relevant parts of the system we are working in. This is a good thing. It is important for us to understand how a change in feature A might have an affect on feature B. Depending on how we’ve designed our application, we need to hold more or less of that knowledge in our head at once in order to be productive.

The trick to being more productive is not to hold more of that application knowledge in your head though. The trick is to create an application that requires as little information as possible to need to be held in anyone’s head at one time to be able do what they need to do.
For me, I’ve found holding lots of the application logic in active memory tends to cause me to over engineer things. In other words, while I might strive for a vast mind palace, I like to keep the desk in my mind palace small and tidy; refiling pieces of information as I finish with them before retrieving new pieces for the next problem. We have a word for this behavior in programming. It’s called encapsulation.

## Encapsulation

Encapsulation is the idea that certain pieces of information are contained entirely within certain boundaries. Like medicine inside a tiny capsule.

Why do we value encapsulation in programming? It’s not so that the computer can understand it better. In fact, if anything, it likely adds a degree of overhead to the execution because now the computer has to create many more contexts and scopes to represent this encapsulation. No, we worry about encapsulation to make it easier for us to reason about the code. It’s for the next person. Code that limits the scope of a thing is easier to reason about. If we don’t give access to some piece of information or functionality to an other part of the code, that code does not need to consider that information or functionality in its logic, and nor do we.
But this idea can work the other way too. Say, for example, we need to verify the role of some user. Let’s say they need to be a contributor in order to do some certain thing in the system. We might write a validation function like this:

```js
const isContributor(user) => user.role === `contributor`
```

This is a very normal and common approach. But it also encourages scope creep over time such that the isContributor function is more likely to begin to do other things as more hands touch the code base and more features are demanded.

```js
const isContributor(user) => user.role === `contributor` || user.id === `0000001`
```

Now, perhaps user `0000001` has a legitimate reason to be able to do everything a contributor does, but this function is now a lie. It is no longer telling us whether a given user is a contributor, it’s telling us whether they are a contributor OR they have this very special id.

> But that’s just bad programming. Who ever did that was an idiot.
> — You, in your mind just now

Well, that’s a bit harsh. True, this is bad programming, but I’ve been around long enough to understand that given the right (wrong?) incentives, good programmers often write bad code. Maybe there was a hard deadline, maybe it’s the boss’s id and they demanded to be able to do something right now. Perhaps their grandmother just died and their headspace was not 100% engaged in the work. It really doesn’t matter why it happened. What matters is that it did, and does happen. Often. The question we should be asking ourselves is “how can we reduce the incentive to write code like this?”

For that, we can rely on something called “[the principle of least knowledge](https://en.wikipedia.org/wiki/Law_of_Demeter)” also known as “the Law of Demeter”.

The principle of least knowledge is that “a given object should assume as little as possible about the structure or properties of anything else (including its subcomponents).” What this means in practice is that a function or an object should be exactly the information it needs to do its job, and nothing else. So how does our previous example violate this principle?

In this case, we are passing in what we sometimes call a “domain object” It is an objet that encapsulates (there’s that word again 🤔) a single concept; a domain. In this case, it is the user domain. Sometimes these are also called “well-known objects”. In the context of our application, the concept of a user and all the properties and methods that that entails is a concept that is understood throughout the whole of the application. The justification for this is that we can use knowledge and information sharing to build out our application quicker.

There are some faults in this logic. For instance, the productivity gains decrease with the volatility of the domain. If the structure of the domain object is relatively fixed over time, there can be meaningful productivity gains. But if the domain is volatile, if we find we need to alter properties or methods fairly regularly, productivity declines rapidly. Particularly if that domain object is both widely used and highly volatile. In my experience, we often under estimate the volatility of our domain models, they tend to change far more often than we believe they do. So I’ve found domain object often to be the root cause of large merge requests because changes to those domain objects radiates out to every part of the application that relies on them.

To combat this, we can fashion our functions to take in only the information they need to do the job they are designed for.

```js
const isContributor(role) => role === `contributor`
```

Instead of accepting an object with many properties, one of which is role, we simply pass in the value of role from the object.

This seems small and perhaps inconsequential, but remember back to our earlier example. When we pass in the whole user object, the temptation to inflate the scope of what the function is doing is great. After all, we are already passing the object in, what’s the harm in just plucking another property off?

Certainly this makes for an easy change right now. But we loose out on clarity and determinism. Bugs are often introduced because of bad assumptions on the part of developers. Increasing the surface area for assumptions to happen necessarily increases the surface area for bad assumptions to happen.

Here’s a real use case that happened to me recently. I refactored some code to accommodate a new feature and inadvertently introduced a bug (don’t worry, I caught it before it got to production 😅). Notice that this even had static typing. In theory this should have been caught by the compiler. I’m not entirely sure why it wasn’t caught, but it wasn’t.

```ts
const hasError = (message: MESSAGE_TYPE): boolean => (
  message.status === UNKNOWN_ERROR ||
  message.status === UNKNOWN_STATUS ||
  message.status === ERROR
)
```

This code failed because message was coming in as undefined causing the application to throw causing a giant blank screen. The compiler didn’t find this, but applying the principle of least knowledge would have prevented the error from being thrown.

```ts
const hasError = (messageStatus: MESSAGE_STATUS_ENUM): boolean => (
  messageStatus === UNKNOWN_ERROR ||
  messageStatus === UNKNOWN_STATUS ||
  messageStatus === ERROR
)
```

We could take this a step further and reduce a bit more surface area for bugs while also being more explicit about what our intention is:

```ts
const hasError = (messageStatus: MessageStatusEnum) =>
  [UNKNOWN_ERROR, UNKNOWN_STATUS, ERROR].includes(messageStatus)
```

If you want to eliminate a lot of opportunity for bugs to creep in, make your code base more resilient to many hands, and help JR engineers or new hires more quickly become productive, practice the Principle of Least Knowledge. Make your data on a need to know basis. If the function doesn’t need to know it, don’t give it to it. It’s a small thing that pays dividends in sometimes unexpected ways.

There’s so much more that could be said about this, but we would start getting into a whole thing. I think it’s best to leave it here for now. Just remember. when disseminate assumptions about your application throughout your application, not only do you make it materially harder to change those assumptions as your business needs shift, in a sense, your are making your application self-aware, and we all know how that tends to go.

![The Terminator](/terminator.jpeg)


The perils of knowledge


It’s been a minute since I’ve last seen a “considered harmful” story. I’d say it’s about time for a new one.

To be honest though, I do consider the string concatenation operator (`+`) in JavaScript problematic. For one thing, it’s overloaded with the numerical add operator (also `+`). In strongly typed languages this is less of a problem, but I don’t know that it helps with human readability. In a dynamically typed language like JavaScript though, it can be down right dangerous.

## The problem

What does this even mean?

```js
2 + 'Hello'
```

I know what it does, but what does it mean, logically? It doesn’t make any sense. Imagine saying something like “Pickle more hours till noon” or “If Sally had four apples and gave swimming to Patrick, how many apples does Sally have?” This is nonsense, but it makes about as much sense as `2 + 'Hello'` . Yet this is perfectly valid JavaScript.

No doubt this is a contrived example, but what about this?

```js
const finalVal = valA + valB
```

Uh oh! But still, I’m sure it wouldn’t take long to look at the file and figure out what `valA` and `valB` are meant to be. It’s not ideal, but maybe we wouldn’t go so far as to say it’s harmful… unless…

```js
const combine = (a, b) => a + b
```

Hmmm, could be add. Could also be concat. What are we trying to accomplish here? Again. Contrived, but you can see the principle of the problem.

I think it’s fair to say that `+` is much more associated with addition than with concatenation, so let’s leave `+` to the maths.

## The solution

Ok, so now we know we shouldn’t use `+` for string concatenation, but what should we use. Well, we could go a few different ways, but I think the most obvious — the one that makes it very clear we mean to be dealing with building up a string — is by using template literals.

```js
const combine = (a, b) => `${a}${b}`
```

That’s much nicer. It obvious that we are trying to combine strings here. Sure, value coercion to strings can still happen if one of the values is not a string, but it is evident that the end result here is going to be a string. With `+` we could get a number or a string, depending on what values we are combining.

Let’s do our selves a favor and stop using `+` for string concatenation. Let’s use template literals instead.


String concatenation operator considered harmful


Dieter Rams is arguably the most celebrated and influential product designers of the last century. His ten principles of “good design” influenced product design the world over. Part of what made Ram’s ten principles so compelling is their ability to be adapted to virtually anything that is created, from socks to software.

And that is exactly what we shall set out to do. We are going to apply Dieter Ram’s ten principles of Good Design to software. Not the end user product — much can be found about that — but to the source code.

![Image of source code written in COBOL](/source-code.jpg)

## Good design is innovative

> “The possibilities for progression are not, by any means, exhausted. Technological development is always offering new opportunities for original designs. But imaginative design always develops in tandem with improving technology, and can never be an end in itself.”

![Original BRAUN weighing scale -- Tonarmwaage -- used to define the correct counterweight of a record player’s tonearm. [Braun Tonarmwaage, 1962](https://en.wikipedia.org/wiki/Dieter_Rams)](/Tonarmwaage.jpg)

Our software source code need not be outlandish or complex to be innovative. In fact, it’s quite the opposite. Innovative source code seeks to discover the pattern of a problem, and solve the entire category in elegant ways. `a² + b² = c²` is innovative. It has immense implications, but it is not complex.

Likewise, higher-order functions like map or reduce are innovative solutions to the problem of changing a list of things into something else. These solve the category of iteration while remaining flexible enough to do virtually anything within that iteration.
React is another innovative design solution within code.

[Ben Alman
 (@cowboy on twitter)](https://twitter.com/cowboy) inadvertently coined a very apt description at one time: “[Rethinking Established Best Practices](https://twitter.com/cowboy/status/339858717451362304)”. It has since gone on to have a tremendous impact on the Front-end community challenging us to reconsider what [separation of concerns](https://en.wikipedia.org/wiki/Separation_of_concerns) means for front-end and that we can think of user interfaces to be a pure function of the state.
Each of these advances leveraged the best technologies and ideas available to take the next leap in terms of developer interfaces. There are many more examples of innovative design in software and they all share a common thread. They each managed to simplify a concept in creative and approachable ways.

## Good design makes a product useful

> “A product is bought to be used. It has to satisfy not only functional, but also psychological and aesthetic criteria. Good design emphasizes the usefulness of a product whilst disregarding anything that could detract from it.”

![Braun pocket calculator designed by Deiter Rams.
ET 55 control LCD: Dieter Rams + Dietrich Lubs: 1983 [source](https://readymag.com/shuffle/dieter-rams/products/)](/rams-calculator.jpg)

Of all Dieter Ram’s ten principles, this is probably the one that is most naturally adhered to, at least at first blush. Market forces tend to ensure that the products we build are generally “useful” in the sense that they fulfill a functional need that consumers have. However, Rams lists psychological and aesthetic aspects of usefulness that serve to draw users to one product over another. UX designers sometimes speak of “[delight](https://ux.christmas/2019/24)” and it is these psychological and aesthetic aspects which are being invoked.

In software development, code obviously must be functional, in the sense that it must function. But our source code can and should also be psychologically useful and aesthetically useful. Code that is overwhelming in complexity or volume is [psychologically distressing](https://www.quora.com/Why-do-I-get-overwhelmed-by-seeing-too-much-code?share=1) and not particularly useful. Best practices such as restricting the scope of a [file](https://eslint.org/docs/5.0.0/rules/max-classes-per-file), [function](https://en.wikipedia.org/wiki/Unix_philosophy), or [class](https://en.wikipedia.org/wiki/Single-responsibility_principle) to one purpose helps in limiting psychologically distress and using tools such as [cyclomatic complexity](https://en.wikipedia.org/wiki/Cyclomatic_complexity) [linters](https://eslint.org/docs/rules/complexity) will help to make sure new comers to a code base can quickly get up to speed.

## Good design is aesthetic

> “The aesthetic quality of a product is integral to its usefulness because products are used every day and have an effect on people and their well-being. Only well-executed objects can be beautiful.”

![Universal Shelving System designed by Deiter Rams
606 Universal Shelving System, 1960 [source](https://en.wikipedia.org/wiki/Dieter_Rams)](/rams-universal-shelving-system.jpg)

When we talk about the usefulness of source code, we are generally speaking of developers' ability to work within it. Rams says that the aesthetic quality of a product is integral to its usefulness. So what is aesthetic source code then? “Only well-executed products can be beautiful”, he says.

It is commonly said that [code is read far more often than it is written](https://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds). We read code to understand it. Like a well-written book, well-written code tells a story. But more than that, well-written, aesthetically pleasing code is clear, concise, and unambiguous. It focuses the eyes on what is important and seeks to eliminate [noise](https://www.deepdyve.com/lp/association-for-computing-machinery/signal-and-noise-in-programming-language-8p0a4k7KDZ).

Code formatters go a long way in helping to make aesthetically pleasing code. [Prettier](https://prettier.io/), a code formatting tool, even has it in the name. It promises to make your code “prettier.” Beauty, as they say, is in the eye of the beholder, but some things are more objective than others, and consistently and thoughtfully formatted code is always preferable to unformatted, inconsistent code.

Formatting only gets us so far though. Just as anyone can apply a set of design criteria to make something look _less_ bad, it takes thought and skill to create something beautiful, something that elegantly satisfies our requirements.

One way to do this is to push edge case handling to the edges of the application. [If](https://degoes.net/articles/destroy-all-ifs)/[else](https://janalmazora.medium.com/how-to-prevent-using-if-else-statements-in-your-code-7e05e43afde) statements, type checks, [try/catches](https://www.oreilly.com/library/view/functional-programming-in/9781492048633/ch01.html). These are not aesthetic. Control flow constructs such as these disrupt the flow of reading. They should be [avoided](https://www.oreilly.com/library/view/functional-programming-in/9781492048633/ch01.html) where ever possible and minimized when not. [Many](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Conditional_Operator) [patterns](https://jrsinclair.com/articles/2019/elegant-error-handling-with-the-js-either-monad/) [exist](https://jrsinclair.com/articles/2016/marvellously-mysterious-javascript-maybe-monad/) to help encapsulate and mitigate the need for control flow interruption such as [Promises](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) and [Monads](https://medium.com/javascript-scene/javascript-monads-made-simple-7856be57bfe8).

## Good design makes a product understandable

> “It clarifies the product’s structure. Better still, it can make the product clearly express its function by making use of the user’s intuition. At best, it is self-explanatory.”

![A pocket transistor radio designed by Deiter Rams bearing a striking resemblance to the original iPod. [source](https://www.lifeofanarchitect.com/who-is-dieter-rams/)](/rams-pocket-transitor-radio.jpg)

We all seek to write code that is understandable. We often refer to understandable code as being “maintainable.” Code that is difficult to understand is even more hard to maintain. Fear grows proportionally to the understandability of the code we are seeking to change it. [Many](https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882) [books](https://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/ref=pd_d_sim_b2b_5?pd_rd_w=fu3qo&pf_rd_p=c1143869-a7d7-4cfd-bf9c-0da7305c3e64&pf_rd_r=M5PWGF52TTWE9PSDGJ2D&pd_rd_r=a5ed51c1-9648-4b7b-8740-830449a48fd3&pd_rd_wg=exq6V&pd_rd_i=0201633612&psc=1) [have](https://www.amazon.com/Refactoring-Improving-Existing-Addison-Wesley-Signature/dp/0134757599/ref=pd_d_sim_b2b_6?pd_rd_w=fu3qo&pf_rd_p=c1143869-a7d7-4cfd-bf9c-0da7305c3e64&pf_rd_r=M5PWGF52TTWE9PSDGJ2D&pd_rd_r=a5ed51c1-9648-4b7b-8740-830449a48fd3&pd_rd_wg=exq6V&pd_rd_i=0134757599&psc=1) [been](https://www.amazon.com/Eloquent-JavaScript-3rd-Introduction-Programming/dp/1593279507/ref=sr_1_1?crid=AQBUFESYQ5LU&dchild=1&keywords=eloquent+javascript&qid=1620402341&s=books&sprefix=eloquent+%2Cstripbooks%2C240&sr=1-1) [written](https://leanpub.com/composingsoftware) on the topic of understandable code in an attempt to bottle the trick to consistently reproducing it. Some of them are useful. Many are not. The real trick is, there is no trick. Like so many things in life, it takes effort, practice, and intention.

One thing we all do is to document our code with comments that describe what our code is trying to accomplish. This is sometimes necessary, but when it is, it also represents an opportunity for improvement. After all, “at best, [our code] is self-explanatory.” Striving to write self-explanatory code is practicing good design.

## Good design is unobtrusive

> “Products fulfilling a purpose are like tools. They are neither decorative objects nor works of art. Their design should therefore be both neutral and restrained, to leave room for the user’s self-expression.”

![FS 80 TV, 1964; A television designed by Deiter Rams. 1964 [source](https://www.lifeofanarchitect.com/who-is-dieter-rams/)](/rams-tv.jpg)

Unobtrusive code gets out of the way. There are many ways code can be obtrusive to engineers. It can be laden with unnecessary syntax noise, excessive annotations, boilerplate, concept fatigue, or “magic.” But perhaps the most common form of obtrusiveness is [bad abstractions](https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction). A bad abstraction is unclear. It is a puzzle piece that almost but doesn’t quite fit. So every use requires building up a little here, or shaving off a little there. A sure sign of a bad abstraction is the need for a growing collection of configuration options or arguments. Good abstractions, like good code generally, get out of the way to let you do your job. It presents itself as a useful tool that allows you to express what needs to be done, not an obstacle to overcome. There is always an element of learning, but if you find yourself routinely “wrestling” with your code, it is too obtrusive.

## Good design is honest

> “It does not make a product appear more innovative, powerful or valuable than it really is. It does not attempt to manipulate the consumer with promises that cannot be kept.”

![Vitsœ 601 Easy Chair (1960) designed by Deiter Rams [source](https://gizmodo.com/10-iconic-dieter-rams-designs-from-a-store-that-sells-h-1045228746)](/rams-chair.jpg)

Have you ever had to work in a new code base that took months to be productive in? Navigating around opaque, obscure, or obtuse patterns and practices that require seemingly secrete knowledge of magic incantations to make things work? I have more often than I care to admit. So often in our efforts to “simplify” all we end up doing is creating [“magic](https://dev.to/matks/what-is-magic-in-code-and-why-avoid-it-1m4p).” Magic is the enemy of good design. It calls attention to itself, not the work at hand. It is a form of misdirection and deception, actively hindering the understanding of what’s going on under the guise of productivity. It is a lie. Honest code can be followed. It leads from one call to another. Dishonest code masks its functionality behind build steps, generated files, and side effects. Dishonest code is handy-wavy.

## Good design is long-lasting

> “It avoids being fashionable and therefore never appears antiquated. Unlike fashionable design, it lasts many years — even in today’s throwaway society.”

![Braun Clock designed by Deiter Rams: Braun ABK 31 (1985) [source](https://gizmodo.com/10-iconic-dieter-rams-designs-from-a-store-that-sells-h-1045228746)](/rams-clock.jpg)

We have a problem in our discipline. We are obsessed with the new and shiny. What is the hot new framework, library, pattern? We chase these things as if it were the air we breath, but we give them little thought. We secede our thinking to the thought leaders, or the big organizations. It seems like the JavaScript framework fatigue has died down somewhat of late, but it has not been all that uncommon for full rewrites in new technologies to happen almost on a yearly cadence.

Products change. Business needs change. These are givens. The code we write should build in that expectation from the start. Our architectures, philosophies, patterns, and principles should not have to change with the market winds, they should be able to accommodate them. Paradoxically, code optimized for change, needs to change less often than code not anticipating change. It’s obvious if we think about it. If we anticipate change, we build in fewer hard assumptions. As assumptions inevitably change, the code is already able to adapt to it without having to first tear down the foundations. Code that is long-lasting, is built to anticipate regularly changing assumptions.

## Good design is thorough down to the last detail

> “Nothing must be arbitrary or left to chance. Care and accuracy in the design process show respect towards the consumer.”

![HLD 4 Hairdryer 1970 designed by Deiter Rams for Braun [source](https://gizmodo.com/10-iconic-dieter-rams-designs-from-a-store-that-sells-h-1045228746)](/rams-hairdryer.jpg)

Intentionality and purpose in everything is a challenge. There are as many ways to accomplish an end in code as there are engineers. To write well-designed code it is not enough to know that dictionaries, tuples, maps, linked lists, and trees are all data structures. One must also be able to choose the best one for the circumstance. Furthermore, one must be able to articulate why that is the best choice.

> “If you can’t explain it to a six year old, you don’t understand it yourself.” — Albert Einstein

Do you import a library or write your own? Why this pattern and not that one? Do you use semicolons or rely on automatic semicolon insertion? Do you accept the defaults of your code formatter? Do you know why they are the default? Do you know what is being enforced? Well-designed code is not arbitrary. It is intentional from its architecture to its formatting. There is nothing wrong with accepting defaults, as long as you know what the defaults are and why they are.
This becomes more challenging the more people are involved. More people inevitably leads to conflicting perspectives. There is almost never a “right” choice, there are only tradeoffs. Intentional decisions recognize the tradeoffs and make choices with eyes wide open.

## Good design is environmentally friendly

>“Design makes an important contribution to the preservation of the environment. It conserves resources and minimizes physical and [visual pollution](https://en.wikipedia.org/wiki/Visual_pollution) throughout the lifecycle of the product.”

![LE1 electrostatic speaker, 1959 designed by Deiter Rams [source](https://www.oobject.com/le1-electrostatic-speaker-1959/)](/rams-electrostatic-speaker.jpg)

Sure, the actual code itself is all digital, but code is meant to be executed and that execution has a cost. Not only that, costs are not evenly distributed. Servers must be run, which takes a lot of cooling. Code is downloaded to browsers across networks of various speeds and reliability — often at a direct cost per MB to the one downloading it. Well designed code takes these costs into consideration

There is also visual pollution to consider. This is the noise that surrounds the signal. As mentioned before, code is read far more often than it is written. The denser the communication the better. Where there is lots of information not pertinent, or that could easily be derived from context, there is noise. Noise distracts us from the message, the logic of the code we are attempting to understand. Therefore, well-designed code is well-organized code. Well-designed code is annotated with comments or types only where necessary and only as much as is needed. It is wise to choose patterns that maximize communication and minimize distraction. Declarative code is dense communication, imperative code is noisy communication. “Take me to the airport” conveys the same information to an Uber driver as a long list of turn-by-turn directions.

## Good design is as little design as possible

> “Less, but better — because it concentrates on the essential aspects, and the products are not burdened with non-essentials. Back to purity, back to simplicity.”

![L-2 speaker (1958) by Dieter Rams for Braun [source](https://www.lifeofanarchitect.com/who-is-dieter-rams/)](/rams-speaker.jpg)

`E=MC²`

Einstein’s mass-energy equivalence equation is undeniably simple. It is beautiful, elegant, functional, and understandable. It is all these things because it describes its intent in the simplest way while still being complete. There are no `if` statements. No `switch` statements, temporary variables, or state. It is so simple, a child can comprehend it, yet it took one of the brightest minds of the 20th century to distill it.

__[Simple is difficult](https://www.inc.com/jim-schleckser/simple-is-hard-design-secrets-of-jeff-bezos-and-steve-jobs.html)__. But it is also beautiful. Well-designed code is simple. It takes thought, reworking, refactoring, and the ruthless elimination of the unnecessary to arrive at it. But once there, once the problem the code is solving has been distilled down to its essence. It is complete.


Dieter Rams’ design principles applied to source code


The whole job of a class is to ultimately create an object. But JavaScript has one of the simplest, most clear and succinct ways of creating an object, and a familiar dead simple way to do it over and over again in a particular way:

```js
{} // an object

() => ({}) // a function that returns the same object shape every time.
```

So how far can we reasonably take this? Well, to paraphrase a sports references, it could go all the way!

```js
// Why do all of this
class SubClass extends BaseClass {
  #state = {}

  constructor(arg) {
    super(arg);

    this.#state = arg
  }

  get state() {
    return this.#state
  }

  set state(newState) {
    this.#state = newState
  }

  gimmeAThing() {
    return `here's a thing`
  }

  goDoAThing() {
    console.log('did a thing')
  }
}
```

```js
// When you can to this
const factory = (state) => ({
  ...baseFactory(),
  state,
  gimmeAThing: () => `here's a thing`,
  goDoAThing: () => { console.log('did a thing') }
})
```

## Prefer Composition over Inheritance

Like, I mean, everyone knows this one right? It’s famous. It’s the quote you drop to imply to others that you’ve actually read the Design Patterns book from the Gang of four, and it hasn’t just been sitting on your shelf for years and every now and then you tell yourself you should really sit down and read it because when you think about it, you’ve probably consumed more of it in quotes from articles you’ve read online than actually out of the book in your own library. Not me. But, you know… others 😳.

Composition is manifestly more versatile and flexible than inheritance. No serious software engineer that I know of questions the idea that one ought to prefer composition to inheritance.
So let me ask you this. How does one favor composition over inheritance with JavaScript classes? What does that even look like? JavaScript classes don’t have traits or mixins or anything like that to allow for composition. If you want to extend the functionality of a class in JavaScript, you need to subclass it. Composition is not really an option with JavaScript classes.
So if composition is out from the start, why are we using classes?!?!

I suspect part of the reason is an element of an appeal to novelty fallacy. Classes are a newer feature of the language and therefore must be superior to preexisting ones. But perhaps even more than that, there’s also an incorrect assumption that classes are more versatile or offer better ergonomics than objects. What with their methods, getters, setters, private members, static members, constructors, and what not, aren’t classes better than what we were doing before with function constructors and closures?

Well, inasmuch as we were using older JavaScript features to emulate classes, yeah. Classes are better. But what if we never should have been trying to emulate classes to begin with?
Look, there are legitimate reasons to use classes in JavaScript… probably. Or at least I’m willing to concede that I haven’t experienced the entire universe of problems to solve, and it seems plausible that for at least some of those, classes are a better solution. It’s just… apart from dealing with the DOM (where one is compelled to deal with classes because that’s what the spec authors semi-arbitrarily decided), I haven’t run into any of them yet. In every real world case I’ve come across, plain objects are at least as versatile and ergonomic as classes, and most of the time more preferable. In fact, it seems to me like classes are just Rube Goldberg machines for objects. There’s just a whole lot more concepts and ceremony that go in to classes just to do everything we can already do more simply without them. Don’t believe me? Let’s look as some examples.

## Constructing a object of a given shape

Ostensibly, this is the classic case. You need an object? Use a class. Let’s take a look.

### Class pattern

```js
class BeautifulObjectClass {
  isMagnificent = true

  constructor(marvelousness = 11) {
    this.marvelousness = marvelousness
  }
}

const myBeautifulObject = new BeautifulObjectClass()

myBeautifulObject.isMagnificent // true
myBeautifulObject.marvelousness // 11
```

Delightful. Couldn’t be simpler. Could it? Well, actually, yeah!

### Factory pattern

```js
const beautifulObjectFactory = (marvelousness = 11) => ({
  isMagnificent: true,
  marvelousness
})

const myBeautifulObject = beautifulObjectFactory()
myBeautifulObject.isMagnificent // true
myBeautifulObject.marvelousness // 11
```

Shorter, clearer, more signal, less noise, fewer things to think about. This is just a function that returns an object. That’s all. But it’s called the factory pattern. And it can do anything a class can.

## Methods? sure

### Class pattern

```js
class BedazzlerClass {
  dazzle() {
    console.log('Look at how dazzling I am!')
  }
}

const bedazzled = new BedazzlerClass()

bedazzled.dazzle() // Look at how dazzling I am!
```

### Factory pattern

```js
const bedazzlerFactory = () => ({
  dazzle() {
    console.log('Look at how dazzling I am!')
  }
})

const bedazzled = bedazzlerFactory()

bedazzled.dazzle() // Look at how dazzling I am!
```

## Private Members? Come on son!

### Class pattern

```js
class Shhh {
  _secrete = ''

  constructor(secrete) {
    this._secrete = secrete
  }

  revealYourSecretes: () => this._secrete
}

const shh = new Shhh('Mischief managed')

shh.revealYourSecretes() // 'Mischief managed'
shh._secrete // 'Mischief managed' 🤥
shh._secrete = 'password123' // 🤭
shh._secrete // 😱
```

Did you catch that? With the class, you have this “private by convention” problem where you have to store your value in a property that is public, but we let users know that we want them to pretend its private by starting the name with an “\_”. That’s not very safe. But it’s cool, JavaScript classes just got a way to have truly private members!

```js
class Shhh {
  #secrete = ''

  constructor(secrete) {
    this.#secrete = secrete
  }

  revealYourSecretes: () => this.#secrete
}

const shh = new Shhh('Mischief managed')
shh.revealYourSecretes() // 'Mischief managed'
shh.#secrete // Uncaught SyntaxError: Private field '#name' must be declared in an enclosing class 😅
```

So that’s nice. Certainly an improvement, but we’ve now added yet another thing to remember. The more things to remember, the more footprint there is for human error. Simpler is better. Especially if you don’t loose any functionality. Now let’s look at the factory pattern solution.

### Factory pattern

```js
const shhhFactory = (secrete = '') => ({
  revealYourSecretes: () => secrete
})

const shh = shhhFactory('Mischief managed')
shh.revealYourSecretes() // 'Mischief managed'
shh.secrete = 'password123'
shh.revealYourSecretes() // 'Mischief managed' 🙌
```

## Getters/Setters? Yep.

### Class pattern

```js
class NameManagerClass {
  constructor (name = '') {
    this.#name = name
  }

  get name() {
    return this.#name
  }

  set name(newName) {
    this.#name = newName
  }
}

const nameManager = new NameManagerClass()
nameManager.name // ''
nameManager.name = 'Rumplestiltskin'
nameManager.name // 'Rumplestiltskin'
```

### Factory pattern

```js
const nameManagerFactory = (name = '') => ({

  get name() {
    return name
  },

  set name(newName) {
    name = newName
  }
}

const nameManager = new NameManager()
nameManager.name // ''
nameManager.name = 'Rumplestiltskin'
nameManager.name // 'Rumplestiltskin'
```

## Composition

In the context of objects, composition is the idea that one object can be composed of all the parts of two or more other objects. Let’s see what this looks like with classes.

### Class pattern

```js
class AClass {
  propA: 'propA'
}

class BClass {
  propB: 'propB'
}

class CompositeClass {
  // 🤷
}
```

There’s no canonical way to do composition with classes in JavaScript that I am aware of. It’s programming though, right. I’m sure we can hack something together…

```js
class APrimeClass {
  propAPrime = 'propAPrime'
}

class AClass extends APrimeClass {
  propA = 'propA'
}

class BClass {
  propB = 'propB'
}

class CompositeClass {
  constructor() {
    const a = new AClass()
    const b = new BClass()

    const ab = {
      ...a,
      ...b
    }

    Object.entries(ab).forEach(([key, val]) => {
      this[key] = val
    })
  }
}

new CompositeClass()
// { propAPrime: 'propAPrime', propA: 'propA', propB: 'propB' }
```

That’s about the easiest way I can think of to do it. It even works if one class inherits from another (though we all know we should avoid that right?). But There’s a lot going on there. It’s not axiomatic. There are rough edges. What’s the factory situation look like?

### Factory pattern

```js
const aFactory = () => ({
  propA: 'propA'
})

const bFactory = () => ({
  propB: 'propB'
})

const compositeFactory = () => ({
  ...aFactory(),
  ...bFactory()
})

compositeFactory()
// { propA: 'propA', propB: 'propB' }
```

Well, damn. That was easy.

> Oh, but wait! You said with classes, it can still work with inheritance. So even if it’s something to be avoided, it’s still something we can’t do with plain ol’ objects… is it?
>
> -- Some nay-saying, eagle-eyed reader


Hold my Diet Dr. Pepper…

```js
const aPrimeFactory = () => ({
  propAPrime: 'propAPrime'
})

const aFactory = () => ({
  ...aPrimeFactory(),
  propA: 'propA'
})

const bFactory = () => ({
  propB: 'propB'
})

const compositeFactory = () => ({
  ...aFactory(),
  ...bFactory()
})

compositeFactory()
// { propAPrime: 'propAPrime', propA: 'propA', propB: 'propB' }
```

Now some of you be like:

![Oh, snap indeed](/oh-snap.gif)

Others be like:

![Red card! That's not inheritance! That's just more composition](/red-card.gif)

Well, ok, yeah. I just used more composition. But, uh, that’s what inheritance kinda is. Functionally, it’s just linear composition.

Ok, cheap trick, I’ll admit it. But, for the sake of completeness, I will show you real, proper inheritance with plain objects and 
the factory pattern. Just, please don’t use it. The whole point is to avoid inheritance. There is always a better way.

```js
// Never do this!!
const superObjectFactory = () => ({
  superProp: 'superProp'
})

const grossInheritanceFactory = () => {
  const obj = ({
    subProp: 'subProp'
  })

  obj.__proto__ = superObjectFactory()
  return obj
}
```

Ugh! I feel so icky! 🤢

## Type checking

One last thing that we need to cover. And when you get right down to the bones of it all, this is really the reason for classes in JavaScript. It’s not that they enable any functionality that was missing before. It’s that they enable a particular kind of pattern in programing. Type checking. The crux of it is, everything I’ve shown you so far is oriented around the idea that an object has a property or method or whatever. We call this relationship between objects and their purpose a has-a relationship. It is fundamentally functionality oriented.

But class based programming is oriented around the idea that an object is a certain type. We call this relationship between an object and its purpose an is-a relationship. It is fundamentally identity oriented.

There is actually some monumental paradigm shifts between these two ways of thinking. The most obvious of which is a code base obsessed with type checking and error throwing:

```js
if (obj instanceof SomeClass ) {
  // do something I know I can do with SomeClass
} else {
  //Crap! I don't know what to do! Uhhhhh
  throw new Error('obj is not and instance of SomeClass')
}
```

Now me, personally, I find this kind of programming ugly and overly complicated. Raising errors — like other forms of side effects — should be avoided all together or pushed to the edges of the system as much as possible. Littering a code base with exceptions, error throwing, and type and instance checks makes everything difficult to follow and full of landmines for your users. Failing loud and fast is great for development, but it doesn’t help your users out at all, and it’s a nightmare to read through (really, any branching logic makes comprehending the code more difficult, but that’s for another article). But this is what modern object-oriented programing looks like, so you are almost certain to run into it if not actually be trained to write it.

So plain objects with the factory pattern does not allow for instance checks, and that’s a virtue. There are many, many patterns that avoid the issues that class oriented programming create and for which class oriented programming have created dozens and dozens of concepts to correct for them. I think the more you have to think about with respect to your design patterns, the less you’re thinking about the problem at hand. Using plain functions and objects in JavaScript really simplifies things, and allows you to focus on the actual problem you’re trying to solve.
Just for kicks, let’s put every good feature that classes offer together in one class, and compare it to what that would look like with the factory pattern

### Class pattern

```js
class SuperClass {
  superProp = '🦸‍♀️';

  constructor(name) {
    this.name = name;
  };
  
  someSuperMethod() {
    console.log(`I'm ${this.name}!`)
  }

  someOverrideMethod() {
    console.log(`I get overridden`)
  }
}

class FinalClass extends SuperClass {
  finalProp = '🪦';

  #privateProp = '🔐';
  #configProp = null;

  constructor(configProp) {
    super('super');
    this.#configProp = configProp;
  };

  someMethod() {
    console.log(`I'm only a member of FinalClass`);
  };

  someOverrideMethod() {
    console.log(`I override the super class method of the same name`);
  };

  get finalProp() {
    return this.#privateProp;
  };

  get configProp() {
    return this.#configProp;
  };

  set configProp(newVal) {
    this.#configProp = newVal;
  };

}
```

### Factory pattern

```js
const superFactory = (name) => ({
  superProp: '🦸‍♀️',

  someSuperMethod() {
    console.log(`I'm ${name}!`)
  },

  someOverrideMethod() {
    console.log(`I get overridden`)
  }
});

const finalFactory = (configProp) => {
  const privateProp = '🔐';

  return {
    ...superFactory('super'),
    finalProp: '🪦',

    someMethod() {
      console.log(`I'm only a member of the finalFactory object`);
    },

    someOverrideMethod() {
      console.log(`I override the method of the same name in superFactory`)
    },

    get finalProp() {
      return privateProp;
    },

    get configProp() {
      return configProp;
    },

    set configProp(newVal) {
      configProp = newVal;
    }

  }
}
```

I think the most important thing to recognize in these two examples is how completely normal the factory function is. There’s no unusual syntax there. There’s nothing there you wouldn’t probably write hundreds of times in your every day work. It’s just a regular function. It’s possible you might not be as familiar with the getter/setter on the object, but those predate classes. JavaScript classes didn’t need to do anything different to support that. The short of it is, a function that returns an object is just far simpler than — and can do just as much as — classes. Why not prefer the simpler case. At least then you can have composition. Something you can’t get from JavaScript classes.

---

## Further & recommended reading

[Design Patterns: Elements of Reusable Object Oriented Software](https://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/ref=sr_1_4?crid=1G1VPOL7OIZF0&dchild=1&keywords=design+patterns&qid=1618624417&sprefix=practical+microser%2Caps%2C244&sr=8-4) by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

[The Hidden Treasures of Object Composition](https://medium.com/javascript-scene/the-hidden-treasures-of-object-composition-60cd89480381) by Eric Elliott
JavaScript Factory Functions with ES6+ by Eric Elliott

[Elegant Error Handling](https://jrsinclair.com/articles/2019/elegant-error-handling-with-the-js-either-monad/) by JR Sinclair

[Class Composition in JavaScript](https://alligator.io/js/class-composition/) by Alex Jover Morales — overall a terrific article but in his zeal to demonstrate how one can do composition through JavaScript classes, the author inadvertently demonstrates the lengths one has to go through to sort of look like you’re doing it, but actually it’s just deep linear inheritance bastardized to look like composition.


JavaScript Classes Are Just Rube Goldberg Machines for Objects


## We've been going about this all wrong!

- OOCSS
- BEM
- SMACSS
- SUITCSS
- AtomicCSS
- Bootstrap
- Tailwind

One of the things that link all these tools is that they all seek to tame complex CSS. Another thing that links them is that they all fail at that goal to one extent or another.

Ok, that's a little provocative. It's also not quite true. It's not that these tools have failed us. The real problem is that we have failed to understand CSS at a very basic level. As long as we continue to do that, no tool will really be able to fully meet our needs at scale.

How's that for provocative?

## CSS is likely not what you think it is

When I first learned frontend development, I was taught that there were three primary concerns; *structure*, *style* and *behavior*. And those concerns had corresponding languages to address them, namely *HTML*, *CSS* and *JavaScript* respectively.

This was great! One did not need to develop an intuition about the boundaries of concerns. If a file had a particular extension, it necessarily dealt with a particular concern. No additional thought needed!

It makes sense! It made so much sense, no one thought to question it for a very long time. But new paradigms have a tendency to reveal the boundaries of our previous paradigms.

Then an age of componentization was ushered in with the initial work of a standardized WebComponents specification, and frameworks such as React. The entire industry followed suit.

The Angular team, famously already deep into a rewrite of their massively popular framework, pivoted mid-stream to be fundamentally component oriented.

Component orientation came to CSS in the form of several methodologies including OOCSS, BEM, and SMACSS. These ideas sought to compel a form of modularity to CSS through discipline.

```css
.block {}
.block__element {}
.block—modifier {}
```

Soon however, CS-in-JS came along to compel the same thing through code and gave us true componentized UI. Implementation of the WebComponents specification with ShadowDOM and scoped styles began to accomplish true modularity at the platform level as well. Throw in tools and technologies like Sass, CSS Variables, and the like, and it seems like we should have attained CSS transcendence by now.

So why do we still struggle with CSS at scale? It’s almost like we are missing some fundamental truth!

To be fair, what we are about to discuss is not really new at all. The idea has been teased, hinted at, presumed, or stated outright ever since at least the introduction of [OOCSS](https://www.slideshare.net/stubbornella/object-oriented-css) by [Nicole Sulivan](https://twitter.com/stubbornella) back in 2005!

What I hope to do is not to bring forth a revolutionary idea, but rather to add a small contribution to the incredible work of those that have preceded me by tweaking our perspective just a bit. I hope that in so doing, all of us can go forward with a more accurate sense of things that will provide clarity and simplicity.

## A slight correction

To properly understand, we need some background, some context, and a correction.

First the correction.

I said that when I was first learning frontend development, the three primary areas of concern were Structure, Style, and Behavior which were handled by HTML, CSS, and JavaScript respectively.

This was never quite true.

Certainly Style was handled by CSS, and behavior by JS, but HTML is not structure. At least, not as it pertains to how the user perceives it.

HTML provides _semantic_ structure, which really means it deals with the meaning of the relationship between objects — one thing is a child of another, or this thing represents an external resource, or a block of text, or an item in a list.

Semantic structure has nothing to say about how a user consumes such things, only how those things relate to each other. Ideally there is a loose relationship between the semantic structure and the visual structure of things. There are a ton of multiplying advantages to that being true, but it is not necessary.

Consider a well formatted pice of HTML. It has all the right structure and semantics. It describes the object, has the proper accessibility attributes, but it's style is set to `display: none;`

```jsx
<figure style="display: none;">
  <img src="https://fillmurray.com/400/600" alt="A beautiful Bill Murray placeholder image" />
  <figcaption>
    A beautiful Bill Murray placeholder image
  </figcaption>
</figure>
```

What does the (typical) consumer of this experience? A ghost. A blank slate. Nothing at all.

Conversely, consider Louise Flanagan’s CSS rendition of Vermeer’s “The Girl With the ~~Pearl~~CSS Earring”.

<iframe height="366" style="width: 100%;" scrolling="no" title="The Girl With A p̶e̶a̶r̶l̶ CSS Earring" src="https://codepen.io/louflan/embed/JjGVbjY?height=366&theme-id=10292&default-tab=result" frameborder="no" loading="lazy" allowtransparency="true" allowfullscreen="true">
  See the Pen <a href='https://codepen.io/louflan/pen/JjGVbjY'>The Girl With A p̶e̶a̶r̶l̶ CSS Earring</a> by Louise Flanagan
  (<a href='https://codepen.io/louflan'>@louflan</a>) on <a href='https://codepen.io'>CodePen</a>.
</iframe>

The divs used as the canvas for this masterpiece provide no semantic relationship to anything we see.

They are in fact, utterly ambiguous to what they are used for. Yet one cannot help but feel a sense of wonderment and awe when looking at it.

So if HTML does not provide a sense of visual structure, what does?

## Double Duty

It turns out that CSS is really pulling double duty here, and that is the secret, the missing piece of the puzzle.

Without understanding that one language is solving for two entirely different concerns, we are bound to end up in a hot mess of CSS soup given enough time and cooks in the kitchen.

I say that’s the secret, but it’s been right in front of our faces this whole time. We have just been too busy not paying attention.

![CSS (Cascading Style Sheets) is used to style and lay out web pages — for example, to alter the font, color, size, and spacing of your content, split it into multiple columns, or add animations and other decorative features. This module provides a gentle beginning to your path towards CSS mastery with the basics of how it works, what the syntax looks like, and how you can start using it to add styling to HTML.](/MDN-CSS.png)

> While HTML is used to define the structure and semantics of your content, CSS is used to **style it and lay it out**.

That CSS is doing two things for us is not a problem, per se. In any other development platform, there is typically only one language to address all concerns. This is managed by applying architectural patterns such as MVC, Functional programming, OOP, and many many others, depending on one’s needs.

And we have those patterns too! We have just been looking past what they are actually solving for us, the need to segregate the structure from the style of our web applications.

## Don't Stop!

Careful now! This is where everyone else has stopped. If we stop now, we haven’t learned anything that isn’t already widely known.

What’s the next step? Where is the tweak? What’s the perception shift that radically changes what we do?

Left with only this information, what has tended to happen is that a bunch of style only components get created, and then someone has a lightbulb moment and is like I’ma make Grid component, or some other Layout component.

> I'ma make a <Grid/> component! 🤯 😍

And why not? If CSS is handling two concerns, creating separate components for style and layout is the next logical step. Folks much smarter than me have [made](https://www.joshwcomeau.com/react/modern-spacer-gif/) [cases](https://twitter.com/mjackson/status/1301940869210095616?s=20) [for](https://mxstbr.com/thoughts/margin/) [this](https://twitter.com/ryanflorence/status/1301943037702991872?s=20).

I have a great deal of sympathy for this inclination, but this is not the way. It only leads to suffering.

> Layout components lead to anger, anger leads to hate, hate leads to suffering.

In all seriousness though, layout components just complicate things. One ends up with so much extra and unnecessary stuff! Now we are sacrificing the semantic structure HTML is supposed to provide to force it to give us the visual structure we are seeking. It’s div soup all over again. It’s not necessary.

![div soup](/div-soup.jpeg)

We need a way to use CSS to give us the visual structure we need, without destroying the semantic structure of the underlying HTML.

Let me suggest a simple mantra that allows us to keep a proper separation of style from layout within CSS, allowing our components to be freely portable, without the unnecessary cruft and circumstance.

> Components style themselves, and position their immediate children.

👆This is it. It’s all you need to know to begin immediately creating more resilient components, whether you are using BEM or Sass and have separate CSS files, or you are using CSS-in-JS or Web Components to co-locate relevant component code, this mantra will ease your pains.

A mantra is only as good as our understanding of its implications though, set’s really look at what this means in practice.

What is style, and what is position? I’d like to get into some really interesting [cross discipline](https://slides.com/corybrown/deck-8) [discussions](https://users.manchester.edu/Student/DJSprunger/FLW%20vs%20Bauhaus%20paper.pdf) of [structure](https://en.wikipedia.org/wiki/Bauhaus) vs [ornamentation](https://en.wikipedia.org/wiki/Frank_Lloyd_Wright), but for the sake of time, when it comes to CSS, just think of the [box model](https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_blocks/The_box_model).

![The CSS box model](/box-model.png)

Anything that affects only the border-box inward, is style. Everything else is position.

There’s another easy thing to remember!

> Anything that affects only the border-box inward, is style. Everything else is position.

## Pop Quiz

O.k. Let's see how well we understand this principle. Below is a little pop quiz. Listed is a CSS rule property. Your job is to determine whether that property affects style — and can be safely applied directly to an element, or whether it affects position — and should be applied by its immediate parent. Expand the dropdown to check your answer.

<details>
<summary>color</summary>
style
</details>

<details>
<summary>padding</summary>
style
</details>

<details>
<summary>margin</summary>
position
</details>

<details>
<summary>border</summary>
style
</details>

<details>
<summary>display</summary>
Well, it depends 😏. Some values, such as `grid`, and `flex` are known as "[display-inside](https://developer.mozilla.org/en-US/docs/Web/CSS/display-inside)" values and affect the layout of their immediate children. By definition, these rules can safely be applied directly to the element. For our purposes then, these can be considered style rules.

Other values such as `block`, `inline`, and `run-in` are known as "[display-outside](https://developer.mozilla.org/en-US/docs/Web/CSS/display-outside)" values and affect how sibling elements interact with them. For our purposes, these can be considered position rules.
</details>

<details>
<summary>flex</summary>
position
</details>

<details>
<summary>grid</summary>
position
</details>

<details>
<summary>width/height</summary>
position
</details>

## Show me some code already!

What does this look like in practice? Stay with me here, because this part could get a little controversial. I’ve found the easiest way to write CSS that demonstrates this principle is by using the immediate child selector.

```css
.component {
  & > .component-part {
    margin: auto;
  }
}
```

Let’s get a good look at this. We’ll start simple, with a button.

<iframe height="300" style="width: 100%;" scrolling="no" title="KKzegpx" src="https://codepen.io/uniqname/embed/KKzegpx?height=300&theme-id=10292&default-tab=css,result" frameborder="no" loading="lazy" allowtransparency="true" allowfullscreen="true">
  See the Pen <a href='https://codepen.io/uniqname/pen/KKzegpx'>KKzegpx</a> by Cory
  (<a href='https://codepen.io/uniqname'>@uniqname</a>) on <a href='https://codepen.io'>CodePen</a>.
</iframe>

We can move this button around it’s container using margin (give it a go), but as soon as we add more buttons, they inherit those same styles (try it!). Maybe that’s what we want, but probably not.

In any case, as soon as we put a button in a different container, all kinds of weird stuff starts happening. And heaven help us if we make assumptions about the display type of the container we expect a button to be in and add an `align-self` or similar.

You see, the common cause of the problems here are assumptions about positioning. Things only the containing element actually know cares about.

If we move that responsibility to the container. All that context can be taken out of our generic component, and it can be brought into any container with no pretext, other than being what it is, a button.

The container is now responsible for laying itself out. After all, it’s the only one that knows how it’s supposed to layout.

I hope this makes some sense. If not, and you want to talk further, or you're a nay-sayer, want to debate me on the merits, or just want to give some of those solid burns you've been crafting to generate twitter likes on me, hit me up. Let's discuss.

If all of this is too much to hold on to just now, just remember three things.

1. Components style themselves, and position their immediate children.
2. Anything that affects the border-box inward, is style. Everything else is position.
3. Layout components are NOT the solution.

Happy CSSing!

---

_This was originally given as a [conference talk](https://youtu.be/GdnVCB_8XA0) at [UtahJS](https://www.utahjs.com/conference/) in December of 2020. It has been lightly edited for the written medium._


The Miseducation of CSS


Let’s cut to the chase. There have been several high profile folks in the JS community that have laid out some pretty strict limitations on when they think arrow functions are appropriate. Many words have been spent talking about readability, variability, etc. For what little it is actually worth, I’m here to add to the din with a reasoned defense of straight up replacing the function keyword with the arrow function (`=>`).

I’m normally a pretty nuanced person. There is usually no “right” way to do something. Just various ways with different trade offs. Really, that’s all I want to suggest here. A way to write functions in JavaScript — among many — that has benefits and drawbacks. It’s just, in my own experience doing this exclusively for the last four years, I have yet to find a situation where the drawbacks have even approached the benefits. This is about as close to an absolute as I get.
JavaScript is at it’s best when teams define the slice of it that they are going to work in. A consistent way of doing something within a code base is often of more importance than the “right” way. Consistency can be reasoned about, compared, and debated. But perhaps most importantly, consistent patterns don’t require debate or conversation. They can become habitual and reflexive. Mental energy can be applied to other, more pressing issues.

So without further ado, here is why I haven’t used the function keyword in over four years, and I don’t intend to.

## `this`

The this reference in JavaScript is shared mutable state who’s scope (and reference) is the object itself and is implicitly available within either the object’s constructor function, or the class definition depending on what one is using. It’s not just mutable state, it’s a mutable contextual reference that may itself contain state, methods, properties, prototypes, etc. It is worse than a leaky abstraction as it leaks virtually everything by default, and allows mutations of what it leaks. It is the problems with this that is the primary motivation around the animus many have toward JavaScript classes.

Hands down, the single biggest win with arrow functions is a complete lack of a reference to this within it. In my experience, patterns that rely on this, and misunderstandings about how this works are the greatest source of bugs in a system. There is nothing that this offers that cannot be accomplished without it — most of the time with less complexity. If this can be avoided, it should be. Occasions where this cannot be avoided are almost always because an API that one needs to integrate with made the decision to leverage patterns that rely on this. Arrow functions don’t give you the option, so win in my book.

## New! no new

Arrow functions cannot be used as constructors. One cannot cause mischief and confusion by using new (or failing to) on an arrow function like one can with functions defined with the function keyword. With traditional functions, the behavior of a function changes depending on if it is invoked with new or not. This is enough of a problem that prior to proper classes, patterns arose to ensure that constructors were called properly with new

```javascript
function Named (name) {
 if (!(this instanceof Named)) return new Named(name)
 this.name = name
}
```

Today, if one wants a class, one uses a class. There really is no reason to use a function as a constructor. Similarly, I’m not finding much of a reason to use traditional functions as… well… functions. Arrow functions provide all the tools I need.

## Arguments

Less problematic, but related to the first two points, is the absence of the arguments reference when using arrow functions. Unlike functions defined with the function keyword, an arrow function does not have access to the implicit arguments reference. Instead, if an arrow function is meant to accept an arbitrary number of arguments, the rest operator (`...`) is used to gather up all remaining arguments not specified in the signature.

```javascript
// old and busted
function sum () {
  const tail = arguments.slice(1)
  const head = arguments[0]
  tail.reduce(function (sum, num) {
    return sum + num
  })
}
```

```javascript
// new hotness
const sum = (head, ...tail) => tail.reduce((sum, num) => sum + num, head)
```

This has a number of advantages. Not the least of which is that we are no longer dealing with an implicitly available reference within the function. If we need it, we need to declare it, right in the signature.

Another benefit that is demonstrated in the example above is that with the rest operator, we get a proper array that we can operate on directly. The arguments reference we when using the function keyword gets something that kind of looks like an array, but has none of the methods. It’s array-like, but it’s not an array. In the example above, we need to coerce the arguments object to an array with slice in order to begin working on it the way we want to, because an arguments object does not have a map method.

## Readability

There doesn’t seem to be much data around the readability of arrow functions vs traditional functions, so I can only rely on my own experiences, but I teach and interact with a lot of new developers and what I hear from them backs this up. Most people don’t have issues with the readability of arrow functions. For those that do, it often appears to be one of familiarity. In my experience, newer developers who are taught arrow functions first tend to find functions defined with the function keyword slightly more difficult to read. As with so many things, one’s own experiences and preferences play a huge role in whether arrow functions are seen as more readable or not, but just as universal, the more exposure one has, the more familiar a thing becomes. Arrow functions are no different. If you find them harder to read than the function keyword, using them more often will likely alleviate that.

Another facet of readability is the signal to noise ratio of the syntax. Let’s look at a very simple example:

```javascript
function add2(arg1) {
  return arg1 + 2
}
```

The example above takes a single argument, and adds 2 to it. There are a few things with the syntax in this example that give meaning to the reader. The function keyword informs us that we are defining a function<sup>[1](#footnote-1)</sup> (obvi). `add2` is how we reference the function. The `(` and `)` let us know that what comes between them are arguments. The `{` and `}` provide bounds for the function body; and finally the return statement lets us know what calling the function will (or may since we can have multiple return statements) resolve to when called.

Character count is not a perfect proxy for syntactic complexity, but it’s sufficient for our needs. The function declaration form of our example took 42 characters to express. We will use that as our baseline.

Now, let us compare what this could look like with as an arrow function:

```javscript
const add2 = (arg1) => arg1 + 2
```

Let’s see how our visual cues compare to the more traditional function declaration. Initially we have const which tells us we are declaring a reference. Immediately after that we have our reference identifier. This is how we reference what ever it is. Next is the `=` which tells us we are about to see what value is being assigned. So far, this is exactly like any other assignment we might see. This pattern; `(const|let|var) [identifier] =` is perhaps the most common pattern our brain sees when reading JavaScript and is grokked as if it were all one “word”<sup>[2](#footnote-2)</sup>.

Immediately following that, we see `(` . We are now able to infer that we are assigning a function to our reference<sup>[3](#footnote-3)</sup>, we are immediately in function mode now. We find the closing paren `)` and recognize the end of our argument list. The `=>` tells us the function body comes next. Our brain has long ago recognized that this is all on one line, so we don’t even bother looking for or expecting either curly braces or return statements. We know that what follows will be evaluated and returned.

As you can see, all our visual cues are accounted for with our arrow function form, and it took only 31 characters. That’s a 26% savings on our function declaration form. That’s 26% less visual parsing to get all the same information. Once familiarity with the arrow function form is on par with function declarations, that’s 26% less brain processing too. I’ll take a 26% efficiency improvement any day.

Admittedly, this efficiency improvement does not scale as a function increases in size, but regardless of which function form we prefer, it is generally agreed upon that smaller functions are better than larger ones.

## Variability

This, I will concede, is probably arrow function’s biggest drawbacks. There are (too?) many ways to write an arrow function. Under various circumstances, parts of the syntax of a functions may be omitted. For this cause, it’s variability actually gives support to arguments against its readability, and I again concede that certain forms of arrow functions I find have more friction in reading than others.

### Verbose functions

The most verbose form of the arrow function syntactically just replaces the `function` keyword with `=>` and move it to the other side of the arguments list. There’s still quite a bit of syntactic noise.

```javascript
(arg1, arg2) => {
  return {
    sum: arg1 + arg2
  }
}
```

### Single argument functions

In cases where there is only one argument, it is not necessary to enclose that argument with parentheses. In my view, this eliminates only a tiny bit of “unnecessary” syntax, but I find that the open parentheses provides an initial cue that we are entering “function mode” and is valuable enough to retain. Without it, the first indication we are in function mode is the arrow (`=>`) which by the time we get to it we have already had too much ambiguity to safely put our minds into function mode.

```javascript
arg1 => {
  return arg1 + 2
}
```

### Single expression function bodies

In cases where the result of a single expression is to be returned, the curly braces that normally bound a function body, as well as the return keyword may be omitted. This right here is the money shot. If we accept the [unix philosophy](https://en.wikipedia.org/wiki/Unix_philosophy) of simple, short, clear, modular, and extensible code, then functions that fit this condition should be our most common form of function. As such, they benefit the most from this shorthand. All syntax that does not provide value is removed and what is left is about as clear and concise as one can get without sacrificing one for the other. Most of my functions fit this pattern.

```javascript
(arg1) => arg1 + 2
```

There is one caveat to this form. If the expression is an object definition, then in order for the object definition to not be misidentified by the compiler as a function body that contains syntax errors, the object definition must be wrapped in parentheses.
I’ll be honest, this has slowed down authorship just a bit, as I often find myself having to mentally backtrack and wrap the object in parentheses. With that said, a small hit to authorship is vastly outweighed by the improved readability, because without the parentheses, our brains fall into the same assumptions as the compiler and begin reading the object as a function body. The syntax that informs the complier that the code that comes after the arrow is actually an object, not a function body, also informs our brain of the same thing!

```javascript
// 🙅‍♀️What even does this mean?
(arg1) => {
  sum: arg1 + 2
}
```

```javascript
// ️🙆‍♀️O I C. It's an object.
(arg1) => ({
  sum: arg1 + 2
})
```

You may remember this little nugget from earlier;

> JavaScript is at it’s best when teams define the slice of it that they are going to work in
>
> -- Me, just a few paragraphs ago

Well, it’s particularly fitting for the various incarnations of arrow functions. If I may be so bold as to suggest the style my team and I prefer:

- Always include **argument parentheses**, regardless of the number of arguments. This provides an early visual indication that we are dealing with a function, which otherwise wouldn’t come until after the argument. By that time, we have already likely dropped into another context mentally such as variable assignment.

- Prefer functions that are **single expression function bodies** and eliminate the syntactic noise of the curly braces enclosing the function body and return keyword. This has the tendency to reduce complexity by keeping functions small and focused, an orthogonal, but important goal nonetheless.
- It is not always possible, or reasonable, to have only single expression function bodies. In those cases, we end up with the most verbose form of the arrow function. But even in the most verbose form, we still have reduced cognitive load due to the universal _assignment_ pattern (`(const|let|var) (identifier) =`) — remember our brains treat that pattern as one “word” and have the benefits of those missing “features” of `new`, `this`, and `arguments`. Regardless of the style used, arrow functions remove unnecessary complexity and cognitive load when used exclusively, without sacrificing any functionality that isn’t replicated by better patterns anyway.

So, to hell with nuance, arrow function all the things!

<hr/>
<small>

<sup><a name="footnote-1">[1]</a></sup> The function keyword caries with it some other implications that are worth considering too, as they can result in some nasty bugs if incorrect assumptions are had. For instance, in the example the line begins with the `function` keyword. This tells us it is a function declaration — as opposed to a function expression.

A function declaration is subject to function hoisting, meaning it can be referenced at any point within the current scope, even before the function is defined. That can get really weird when that concept is not clear to the reader. A function expression on the other hand begins with an assignment `const add2 = function () {}` and is not hoisted. It can only be referenced after it is declared. It can get even more confusing if both forms are used at the same time: `const add2 = function addTwo() {}` . One might expect that `addTwo` is hoisted and later assigned as a reference to `add2` but it is not. Attempts to reference `addTwo` prior to it being assigned to `add2` result in a syntax error 🤦‍♂️. You might see this combined form espoused by some as it gives the name of the function in the stack trace should an error be thrown inside the function.

But assigning an arrow function to a variable a definition time will also bind that name to the arrow function in the stack trace, so a traditional function expression might result in an annonymous function in a stack trace, it will not occur if that function is an arrow function.

<sup><a name="footnote-2">[2]</a></sup> It’s partly for this reason that even before arrow functions were a thing, I have advocated for not using the function declaration form and instead have preferred the function expression. By leveraging existing, built-in cognitive shortcuts, we cut down on the scope of things that need to be held simultaneously in memory to understand a program as we are reading it. Less cognitive load means fewer bugs, and cleaner code.

<sup><a name="footnote-3">[3]</a></sup> Sure, an opening parentheses immediately following an equal sign could technically mean many things and still be syntactically correct, and the compiler can’t know for certain that it’s a function until it gets to `=>` but in practice `= (` humans don’t write code that way. Since we are talking about human readability, if someone is defining an assignment that starts with an opening parentheses that isn’t a function they are doing something unusual enough that the readers cadence is going to be broken anyway. Jumping immediately to the assumption that an opening parentheses after an equal sign is a function is exactly the correct assumption to make until/unless further reading disrupts that.

</small>


To hell with nuance, arrow function all the things


_Disclaimer_: This is not a dig at either of the fantastic underscore or lodash libraries, nor any other utility library. It is not a call to stop using any of them. Nor is a pitch for some replacement library. Rather this is a suggestion to stop and think. Is using a utility library improving the end user experience on a given project, or are we just falling into habit from previous projects?

As discussed in part I, there may be many reason to reach for a utility library. I hope to persuade you, dear reader, that one on those reasons ought not to be out of mere habit.
We began using the lodash library as a proxy for the many utility libraries out there, and selected several Array utility functions from it that had a native counterpart. We looked at how to use those particular functions in lodash, then implemented them using the native, built-in counter-part.
This time, we are going to look at those utility functions that don’t have a native counterpart, but are nonetheless trivial to implement. Again, the intent here is not to persuade you from using your utility library of choice, but to show you that you don’t necessarily need to. Let’s begin.

## Trivial Native Solutions

### _.compact

`_.compact` filters an array to only truthy values.

```js
_.compact([0,1,false,2,'',3])    // [1,2,3]
```

this is perhaps the simplest useful example of a filter.

```js
[0,1,false,2,'',3].filter(item => !!item)  // [1,2,3]
```

Because the filter method coerces every return value into a boolean, we don’t even need the !! coercion. To make things just a hair simpler, we can accomplish this with another utility function in lodash, and which is also exceedingly trivial. The identity function, which is just a function that returns the argument that is passed to it. It doesn’t sound that useful, but it has some surprising applications, such as this one. We will cover identity again when we get to lodash’s util category

### _.difference

`_.difference` filters a target array to only those values the do not exist in the source array.

```js
_.difference([2, 1], [2, 3]) // => [1]
```

Here, we can combine a simple filter, with the array’s includes method which returns true if the target item is present in the array, and false otherwise.

```js
[2, 1].filter(item => ![2, 3].includes(item))  // [1]
```

### _.differenceBy

`_.differenceBy` is almost identical to _.difference except that instead doing the check against the item itself, it allows the consumer to give it a custom function to get at the heart of what is being compared.

```js
_.differenceBy([2.1, 1.2], [2.3, 3.4], Math.floor) // => [1.2]
```

In this case, `Math.floor` is called on each item before it is compared. This has the effect of comparing only the whole number portion of each item, ignoring the fractional part.

```js
const iteratee = Math.floor
[2.1, 1.2]
.filter(item => ![2.3, 3.4].map(iteratee).includes(iteratee(item)))  
// [1.2]
```

This is just a little more complicated than the difference example. All we are doing differently is calling iteratee on every item in the target array before checking for its existence in the source array that has also been mapped through the iteratee function.
This probably fine for small arrays, but we are mapping the entire source array for every item in the target array. We can optimize this quite a bit by storing a copy of the mapped source array from the start.

```js
const iteratee = Math.floor
const mappedSource = [2.3, 3.4].map(iteratee)
[2.1, 1.2]
.filter(item => !mappedSource.includes(iteratee(item)))  // [1.2]
```

### _.drop

`_.drop` slices off from the beginning of an array the number of items specified defaulting to 1.

```js
_.drop([1,2,3,4,5])    // [2,3,4,5]
_.drop([1,2,3,4,5], 2) // [3,4,5]
```

`[].slice` can be used exactly the same as `_.drop`. Simply pass `[].slice` a single positive integer. If no arguments are passed to `[].slice`, nothing is dropped. It effectively performs a shallow copy.

```js
[1,2,3,4,5].slice()  // [1,2,3,4,5]
[1,2,3,4,5].slice(2) // [3,4,5]
```

### _.dropRight

Similar to `_.drop` only `_.dropRight` slices off from the end of an array.

```js
_.dropRight([1,2,3,4,5]) // [1,2,3,4]
_.dropRight([1,2,3,4,5], 2) // [1,2,3]
```

`[].slice` has an interesting feature where if you pass it a negative integer as it’s first argument, it will move backaward from the end of the array. So we can use it very similarly to `_.dropRight`.

```js
[1,2,3,4,5].slice(-1) // [1,2,3,4]
[1,2,3,4,5].slice(-2) // [1,2,3]
```

### _.first/_.head

These two are aliases for each other, so I’m just going to reference head . `_.head` return the first item of an array

```js
_.head([1,2,3,4,5]) // 1
```

Of course, arrays can be accessed by index, so we can implement _.head trivially.

```js
[1,2,3,4,5][0] // 1
```

We could also use destructuring.

```js
const [head] = [1,2,3,4,5];
// head = 1
```

This is great because it is not uncommon to want `tail` along with `head`. We can use collect up the rest of the array using the rest (`…`) operator for a very succinct pattern.

```js
const [head, ...tail] = [1,2,3,4,5];
// head = 1
// tail = [2,3,4,5]
```

### _.flatten

As the name suggests, flatten will bring elements from sub-arrays, up one level.

```js
_.flatten([1, [2, 3, 4], 5]) // => [1, 2, 3, 4, 5]
```

We can combine one syntax feature with one array method and achieve exactly the same effect. We spread the array we want to flatten as arguments into an empty array’s concat method.

```js
[].concat(...[1, [2, 3, 4], 5]) // [1, 2, 3, 4, 5]
```

### _.fromPairs

This method returns an object composed from key-value pairs.

```js
_.fromPairs([['a', 1], ['b', 2]]) // => { 'a': 1, 'b': 2 }
```

The Object class has a `fromEntries` method to do this natively.

```js
Object.fromEntries([[a, 1], [b, 2]])
// { a: 1, b: 2 }
```

### _.initial

`_.initial` takes a slice of the source array up to, but not including the last item.

```js
_.initial([1,2,3,4,5]) // [1,2,3,4]
```

We’ve seen how to use `[].slice` with one parameter when we looked at `_.head`. This first parameter is actually the beginIndex for where to start the slice. `[].slice` also takes a second parameter. The second parameter is the endIndex. endIndex tells `[].slice` where to stop and it is exclusive, meaning the item at that index will not be included. As with the beginIndex parameter, a negative endIndex parameter will refer to the end of the source array and go in reverse.

```js
[1,2,3,4,5].slice(0, -1) // [1,2,3,4]
```

### _.last

`_.last` is the inverse of `_.first`. It will return the last item in the array.

```js
_.last([1,2,3,4,5]) // 5
```

We can get the last item directly like so:

```js
[1,2,3,4,5].slice(-1)[0];
```

### _.nth

`_.nth` will return the nth item from an array. Negative indexes return the nth from the end.

```js
_.nth([1,2,3,4,5], 2)  // 3
_.nth([1,2,3,4,5], -2) // 4
```

Following similar previous patterns we can use slice to accomplish this. The difference is that slice will return an array, which we can unwrap if we need to by referencing the 0 index.

```js
[1,2,3,4,5].slice(2,3)   // [3][0] => 3
[1,2,3,4,5].slice(-3,-2) // [4][0] => 4
```

### _.take

`_.take` creates an array from 0 to n of the source array.

```js
_.take([1,2,3,4,5], 3) // [1,2,3]
```

This is trivially accomplished with [].slice

```js
[1,2,3,4,5].slice(0, 3) // [1,2,3]
```

### _.takeRight

`_.takeRight` creates an array from n to arr.length inclusive.

```js
_.takeRight([1,2,3,4,5], 3) // [3,4,5]
```

This is even more trivially accomplished with slice.

```js
[1,2,3,4,5].slice(-3) // [3,4,5]
```

### _.union

```js
_.union([1,2], [2,3], [3,4]) // [1,2,3,4]
```

A union can be thought of as a concat followed by a dedupe. We’ve already seen concat, and we can leverage Set, which enforces uniqueness, to dedupe for us.

```js
[...new Set([].concat([1,2], [2,3], [3,4]))] // [1,2,3,4]
```

### _.uniq

`_.uniq` dedupes an array keeping the first occurrence of an item.

```js
_.uniq([1,2,3,4,1,2,3,5]) // [1,2,3,4,5]
```

Set is a data structure similar to arrays, but which enforce uniqueness. We can leverage this feature to automatically dedupe an array by coercing the array to a Set and back to an array.

```js
[...new Set([1,2,3,4,1,2,3,5])] // [1,2,3,4,5]
```

### _.without

`_.without` takes an array as its first argument, and any values you wish to exclude from that array as its remaining arguments. It returns an array similar to the first array only “without” any items matching the arguments passed in.

```js
_.uniq([1,2,3,4,5], 1, 3, 5); // [2,4]
```

This is little more than a filter which can be used to accomplish the same task.

```js
[1,2,3,4,5].filter(item => [1,3,5].includes(item))
```

### _.zip

`_.zip` takes any number of arrays and recombines them as arrays of items at corresponding indexes.

```js
_.zip(['a', 'b'], [1, 2, 3], [true, false]);
// => [['a', 1, true], ['b', 2, false], [undefined, 3, undefined]]
```

We will need to take this in two steps. First we need to find the largest of the arrays we are zipping together. Then, we map over that array, and return for each item an array of items from all arrays at that corresponding index.

```js
const zip = (arrs) => arrs
  .reduce((longest, next) => 
    next.length > longest.length ? next : longest, [])
  .map((_, i) => arrs.map((arr) => arr[i]))
}
zip([['a', 'b'], [1, 2, 3], [true, false]])
// [['a', 1, true], ['b', 2, false], [undefined, 3, undefined]]
```

### _.zipObject

`_.zipObject` takes two arrays, treating the values in the first array as a collection of keys and the values in the second array as a collection of values and creates an object marrying the keys with the values

```js
_.zipObject(['a', 'b'], [1, 2]);
// => { 'a': 1, 'b': 2 }
```

There are many ways to approach this, but since we are changing data structures we are going to reach for reduce to help us. We iterate over the first array and build up an object with reduce using the index of the iteration to access the corresponding value in the second array.

```js
zipObject = (arr1, arr2) => arr1.reduce((obj, key, i) => ({ …obj, [key]: arr2[i] }), {})
```


Maybe you don't need that utility library after all: Part II


_Disclaimer_: This is not a dig at either of the fantastic underscore or lodash libraries, nor any other utility library out there. It is not a call to stop using these or any other library. Nor is a pitch for some replacement. Rather this is a suggestion to stop and think. Is using a utility library improving the end user experience on a given project, or are we just falling into habit from previous projects?

Every added dependency has a cost, especially when it comes to browser-side JavaScript. Much of the time this cost is completely justified — even required — but sometimes we just tend to reach for what we are familiar with and not stop to consider the problem we are addressing.
The same thing happened with jQuery. It became so ubiquitous that even when the web platform offered native solutions to the vast majority of common use cases, it was still quite a while before there was a major push for developers to ask themselves if jQuery still made sense for their projects, or if it was overkill now.

Just like jQuery, I don’t see utility libraries like underscore or lodash going away anytime soon, nor do I think they should. But I do think it’s time to look at what we are building and where sensible native solutions exists, favor those.

Also just like jQuery, advocates for underscore, lodash, etc., will argue points about efficiency, performance, cross-browser compatibility, etc. These points are all valid, and if the native solutions don’t provide everything you need, or polyfills get too unwieldy, then by all means, use the library. The point of this article is to get us to think before reaching for a large library. Underscore/lodash is just the latest straw-man in this argument. The mantra is simplify. If using the native versions for these problems isn’t creating a simpler solution, then it’s not the right choice. That door swings both ways.

## Let us begin

For brevity and readability, I will just be referring to lodash. Lodash has a very large collection of utilities and addressing each one in this post will quickly make this post intimidating for you to read and me to write. We will start the series by looking first at Lodash’s Array functions.
This series will break down lodash Array functions into four categories:

* __Native Twins__
  
  These are library functions that have direct native solutions. You should have a pretty good reason if you’re to not going to use the native version for these.

* __Trivial Native Alternatives__
  
  Consider using these native solutions if this is the extent to which you would use a utility library like underscore or lodash. May need light code commenting to elucidate what is happening.

* __Moderately Complex Native Solutions__
  
  For the occasional one off problem. A handful of these per project and you may want to consider bringing in the library version as a module for these.

* __Maybe you do need that utility library after all__
  
  Don’t bother rewriting these. A native solution doesn’t exist (yet) and the solutions are sufficiently complex that you are likely to miss some edge cases that will bite you later.

This post will only cover the functions with native twins. Next in the series we will cover functions that are trivial to implement but don’t have a direct native twin.

## Native Twins

One may ask one’s self why a library would implement a function that does exactly the same thing as native functions. Well there are valid reasons, but it does not follow that because someone (or even many someones) had a need for these functions, that your project has the same needs. In fact, I might argue that most of the time, you don’t.

For the most part, these functions are used exactly the same way the library versions are. Notes are made inline where there may be a caveat.

### `_.concat`

`_.concat` concatenates any number of arrays or items onto a source array, producing a new array with all the values.

```js
_.concat([1,2,3], 4, [5,6,7,8], [[9]])
// [1,2,3,4,5,6,7,8,[9]]
```

`[].concat` works exactly the same way, only it is a property of the source array itself.

```js
[1,2,3].concat(4, [5,6,7,8], [[9]]);
// [1,2,3,4,5,6,7,8,[9]]
```

### `_.fill`

`_.fill` will take an array and replace all values in with the supplied fill value.

```js
_.fill([1,2,3,4], ‘x’)       // [‘x’, ‘x’,‘x’,‘x’]
_.fill(Array(3), 9)          // [9, 9, 9]
_.fill([1,2,3,4], '*', 1, 3) // [1, '*', '*', 4]
```

`[].fill` does the same thing.

```js
[1,2,3,4].fill(‘x’)       // [‘x’, ‘x’,‘x’,‘x’]
(Array(3)).fill(9)        // [9, 9, 9]
[1,2,3,4].fill('*', 1, 3) // [1, '*', '*', 4]
```

### `_.findIndex`

`_.findIndex` will return the index of the first occurrence of an item that passes the predicate.

```js
_.findIndex([1,2,3,4,5], (item) => item % 2 === 0) // 1
```

Unsurprisingly, the language also has a `[].findIndex` which does the same thing.

```js
[1,2,3,4,5].findIndex((item) => item % 2 === 0) // 1
```

### `_.indexOf`

`_.indexOf` is similar to `_.findIndex`, but takes a search element rather than a predicate. It may also take a `searchfrom` parameter that begins iterating at the provided index.

```js
_.indexOf([1, 2, 1, 2], 2);
// 1

// Search from the `fromIndex`.
_.indexOf([1, 2, 1, 2], 2, 2);
// 3
```

`[].indexOf` has the same signature and functions the same way.

```js
[1, 2, 1, 2].indexOf(2);
// 1

// Search from the `fromIndex`.
[1, 2, 1, 2].indexOf(2, 2);
// 3
```

### `_.join`

`_.join` turns an array into a string separating each item with the value of the `separator` parameter

```js
_.join([1,2,3,4,5], ', ') // '1, 2, 3, 4, 5'
```

`[].join` is identical

```js
[1,2,3,4,5].join(', ') // '1, 2, 3, 4, 5'
```

### `_.reverse`

`_.reverse` reverses the order of an array in place. Meaning it mutates the array

```js
_.reverse([1,2,3,4,5]) // [5,4,3,2,1]
```

Same for native `[].reverse`, including it’s mutative property

```js
[1,2,3,4,5].reverse() // [5,4,3,2,1]
```

### `_.slice`

`_.slice` will create and return a sub array from a source array starting at `startIndex`, defaulting to `0`, up to but not including `endIndex` which defaults to `arr.length`.

```js
_.slice([1,2,3,4,5])         // [1,2,3,4,5]
_.slice([1,2,3,4,5], 1)      // [2,3,4,5]
_.slice([1,2,3,4,5], -2)     // [4,5]
_.slice([1,2,3,4,5], 1, 3)   // [2,3]
_.slice([1,2,3,4,5], -3, -1) // [4,5]
```

`[].slice` works the same way.

```js
[1,2,3,4,5].slice()       // [1,2,3,4,5]
[1,2,3,4,5].slice(1)      // [2,3,4,5]
[1,2,3,4,5].slice(-2)     // [4,5]
[1,2,3,4,5].slice(1, 3)   // [2,3]
[1,2,3,4,5].slice(-3, -1) // [4,5]
```

## In Conclusion

Well done everyone! We have successfully examined a number of utility functions that have native implementations in javascript. Whether you choose to use the native versions or a utility library to accomplish these tasks is completely up to you. I hope now at least you have just a bit more information as to what you are able to accomplish with just the platform.

I would love to hear comments, feedback and polite, professional discussions in the comments.
Next time we will look at some more common utility functions that don’t have a direct native counterpart, but are nonetheless trivial to do natively. Don’t miss it.