
In 2023 more than ever the front-end ecosystem is thriving and we have amazing new tools coming up. TypeScript is very mature, meta-frameworks are pushing the industry forward, and we're spoiled for choice of component libraries, CSS frameworks, build and deploy tools, etc, etc.

Having a lot of options is great for keeping the industry and the ecosystem moving forward. It's also very cool when you're tinkering, but it can be kind of daunting when you're working on production-grade applications.

We sometimes tend to over-rely on third-party code. There is an NPM package for everything and it's tempting to just go for it. Having a lot of external dependencies [can be](https://javascript.plainenglish.io/the-biggest-scandals-of-npm-d739c11a2406) a [problem](https://www.bleepingcomputer.com/news/security/big-sabotage-famous-npm-package-deletes-files-to-protest-ukraine-war/).

:::quote{as="h3"}
As front-end engineers, it is our responsibility to balance between relying on as few dependencies as possible while having enough tools to be productive.
:::

Here are the main criteria I use to guide my choices, in order of importance:

1. Use tools that are **stable** and considered production-ready.
2. Use tools that are **actively maintained** - no dead code.
3. **Avoid bloat**. Use only the minimum dependencies that you can get by with.
4. **Keep cognitive load low.** Be cautious when introducing dependencies that require a specific mental model. They can be taxing on your team, especially when onboarding new people.

Me and my team at [LatticeFlow](https://latticeflow.io) use the same approach to define our front-end stack and we've been pretty happy with the results so far.

The following is my pick for what I consider to be a great front-end stack for production applications.

:::note{type="warn"}
⚠️&nbsp;&nbsp;Disclaimer: This is **a deliberately opinionated take**. I don't mean to discard or dismiss other tools. I truly believe in using "the right tool for the right job." My opinion will also probably change in the years to come.
:::

# TypeScript

**TypeScript is the backbone of the stack.** It's always there in the background and lets you know if there is something wrong. It helps you keep our code clean, maintainable, and understandable. It makes refactoring code much less painful.

The first time someone suggested using TypeScript in production at a company I worked at was in 2018. I voted against it - I thought it was not mature enough and the ecosystem wasn't there. We ended up adopting it, and we had some troubles. Libraries either missed typings, and we had to define our own, or there were a lot of outdated and plain wrong typings from DefinitelyTyped. Back then, it felt more like a burden and a chore than a helpful tool.

Things have changed a lot! TypeScript is my go-to choice and has been for at least the past three years. If a library doesn't have typings (which is a very, very rare occasion these days), I tend to dismiss it.

I suggest using TypeScript and **upgrading often**. It has been a wonderful experience working with it (especially once you get used to the `tsconfig`).

:::note
[Native Type Annotations are coming to ECMAScript](https://github.com/tc39/proposal-type-annotations). They are in Stage 1 though. Far away from being production-ready.
:::

# React

Old Faithful. [React](https://react.dev/) is still a great choice for application development.

I admit it's not the new kid on the block and doesn't have a lot of the new features of something like [Qwik](https://qwik.builder.io/) or [SolidJS](https://www.solidjs.com/). However, React is solid (no pun intended 😁), dependable, and has a great ecosystem of tools and supporting libraries. It's also very easy to hire people who have experience working with it.

If you write Functional Components (and you should), I would say React is not the easiest to learn, but it's not hard either. There isn't a lot of custom syntax. JSX/TSX is very intuitive to most people. Most of the time, you use 5 hooks and a couple of other functions. Everything is well-documented, and there are a ton of examples online.

React is, in a (maybe a bit poetic) sense, the heart of the stack:

:::quote
The decision to use React affects how we organize our entire codebase, how to think about and define abstractions, and how *we interact* with the people[^1] who use our product.
:::

Oh, and [React Router](https://reactrouter.com/en/main) is a no-brainer.

## Alternatives to React

If you require Server-Side Rendering, the obvious choice is [Next.js](https://nextjs.org/). Next's recent transition from Pages Router to App Router has been a bit controversial, but that doesn't change the fact it is still a great choice. I'd advise against using App Router for production-grade apps for now - I've had some issues with it on smaller projects and it doesn't seem stable enough yet.

I still think [Vue](https://vuejs.org/) and [Nuxt](https://nuxt.com/) are viable alternatives, if your team prefers that. Most of the tools I talk about work or have some sort of alternative in the Vue ecosystem. If you had asked me two or three years ago, I would have said Vue is better than React. Nowadays I think it has too much custom syntax for too little added benefit.

If you ask me today, the future is either in React (if they keep up the pace, modernize, and embrace new concepts - like signals), or something new like SolidJS.

# TanStack Query (formerly react-query) and React Context

[TanStack Query](https://tanstack.com/query) has been an absolute joy to work with. It is TypeScript-native, has a great Hooks API for React, and strikes a great balance of [sensible defaults](https://tanstack.com/query/v4/docs/react/guides/important-defaults) and customizability.

The documentation is great, and [there is a great series of tutorials/articles](https://tkdodo.eu/blog/practical-react-query) by the creator of the library.

**I recommend embracing TanStack Query for both query management and caching of API responses.** It introduces a bit of cognitive load with the caching mechanisms (e.g., `cacheTime` vs `staleTime`), but this is an [area](https://martinfowler.com/bliki/TwoHardThings.html) I'm okay to spend some of my brain cycles on.

:::quote
Keep API-related state in TanStack Query cache. Keep other shared state in either global React Context(s), Outlet Contexts, or LocalStorage. Don't be afraid of a bit of prop drilling.
:::

Oh, and if state is confined to a single component, keep it in that component. I know this may seem obvious, but I've seen people get it wrong enough times to warrant a callout.

To be honest, describing a good solution for global state management is a longer topic. I'll try to do it justice in a future article.

## State management libraries

The elephant(s) in the room are the state management libraries: [Redux](https://redux.js.org/), [Jotai](https://jotai.org/), and [Recoil](https://recoiljs.org/).

To be honest, I have never liked Redux. It has always been too boilerplate-y and unnecessarily complicated for me. It's the reason I was put off by React for a long time. It seems like every React tutorial in 2016 started with "let me tell you about reducers."

The atom-based libraries (like Jotai and Recoil) simplify things a bit. However, I still find they lead to spaghetti on your plate. They encourage, and almost require you to start putting as much state as possible in them. Junior engineers will typically make the mistake of reaching for atoms even for component-private state.

I think that with a large codebase, unless you have religiously defined conventions (which would increase cognitive load), atoms can easily get out of hand and the code can become a mess. All components start to depend on some partially available or global context, and you become a detective (or archeologist) of "how was this value computed through 5 layers of atoms and selectors."

**I believe TanStack query strikes a great balance of usability and usefulness, introducing cognitive load only where it's needed, and providing a great developer experience.**

# CSS Modules and classnames

Yes, you read that right - no SCSS.

Chances are, if you need to do something fancy with SCSS, you're doing something wrong(-ish) and can encode this complexity somewhere else. I'm not saying there are no legitimate use cases for SCSS, but more often than not, what is done via `if`, `for`, or modules can be refactored as separate React components.

I recommend you **rely on CSS variables** (both on a global and component level) and use simple CSS modules.

The only big piece missing from SCSS (and I do really miss it) is rule nesting. You can get it in the form of a [PostCSS Plugin](https://github.com/csstools/postcss-plugins/tree/main/plugins/postcss-nesting) or wait a bit [for it to become](https://caniuse.com/css-nesting) part of the CSS standard.

## A note on CSS Frameworks

I am not a fan of CSS frameworks for large production apps. I see their value for rapid prototyping, but as your codebase grows large, they can become more of a hindrance than a help. Once you have a growing front-end team and your product starts to define its own design language, I would advise against using them.

CSS frameworks also score low on the "keep cognitive load low" criterion. You have to learn their conventions and always keep them in mind when writing code.

# Unstyled Components

First of all, a disclaimer - I have not used Unstyled Components in production, so take my advice here with a grain of salt.

However, I have looked at and experimented with some libraries. I really like Adobe's [React Aria](https://react-spectrum.adobe.com/react-aria/). I think this is the future.

Styled component libraries are great when you're starting out and need to do fast prototyping. But as your company grows and your product matures, you'll start wanting to **define your own design language**. You'll also eventually **need custom components** that you have to build on your own anyway.

Once these two factors are present, people start contemplating switching from a ready-made solution to an in-house one.

:::quote
Most front-end teams start implementing components from scratch when they transition to their own component library.
:::

The problem with that is that there are a bunch of functionalities and accessibility features that you have to implement, and you're bound to miss something.

This is where an Unstyled Component library can shine. Don't worry about implementing a button; just provide your own style on top of something that already has the basics nailed down.

# MirageJS

I cannot emphasize this enough - [Mirage](https://miragejs.com/) is a-ma-zing!

It is probably the least popular tool on this list, so if you haven't heard of it - Mirage is an API mocking library. It intercepts HTTP requests and mocks the responses. It also creates a local in-memory database of objects that your mock responses can use.

Essentially, it allows you to simulate your app's entire back end and state with a very manageable amount of code. You can build full CRUD - your mocked responses will be able to create, edit, and delete objects from the mock database.

Mirage is proving to be an indispensable tool for development. The entire team can come together and discuss the product and define an API. After that, front-end engineers can split off, define the mocks, and do the entire implementation without having a real API server.

It is great for testing too - you can spin up a partial mock back-end server and mock the responses on a test-by-test basis.

Mirage also helps my team build interactive prototypes and gather feedback quickly. We can implement a new feature with a mocked API, give it to people to test and play around, and see if they have feedback about the UX.

# React Testing Library

[React Testing Library](https://testing-library.com/) is a no-brainer for unit tests. It is fast, easy to get into, and most importantly - it encourages (and almost forces) you to use meaningful selectors when querying for elements.

You can get a lot of accessibility improvements just by writing the proper selectors for tests.

:::note
If you can, avoid using data-test-id attributes. Use role and label-based selectors instead.
:::

# Prettier and ESLint

Now, I know what you're thinking - “duh, of course, everybody uses [ESLint](https://eslint.org/)”. And yeah, you're right! But I wanna use this to bring up the fact that I believe **[Prettier](prettier.io) and ESLint are *crucial* when working in a team**.

My experience has been that most front-end engineers are quite opinionated (and I do admit I'm also sometimes guilty of this). I think we have to acknowledge it. Everybody has their preferred way of writing code - spaces, braces, quotes, alignment, etc, etc, etc.

:::quote
I've been in front-end team discussions where people argue about code formatting for 2 hours. I never want to be in a meeting like that ever again.
:::

I'm now lucky to work in a team where we don't put focus on discussions like this and we reach a consensus quickly. I gotta give some of the credit for that to the tools.

Prettier and ESLint ***enforce* a common ground**. Nobody is perfectly happy, but everybody has a compromise they can work with. It is what it is - you'll never have a massive argument in PR comments about style.

And yeah, I admit, sometimes arguments will arise about a specific ESLint rule or Prettier config… but you should be able to quickly resolve these by having everyone cast their vote and moving on. There's a lower chance of something becoming a long-winded religious argument. Most of the time discussions will be about a specific rule: “hey folks, how about increasing print width from 80 to 100?” → vote → change (or don't).

# Notable mentions

## Ramda

I don't think there's much more to say here. Pick whichever library you prefer: [Ramda](https://ramdajs.com/), [Lodash](https://lodash.com/), or [RxJS](https://rxjs.dev).

You could also embrace the fact that probably [you-dont-need-lodash-underscore](https://github.com/you-dont-need/You-Dont-Need-Lodash-Underscore). However, this may be too optimistic for production. Call me overly defensive, but I would still rely on the thousands of hours of work put into any of those libraries.

That said, my **current choice is Ramda.** It has cleaner API design and makes it easier to compose functions.

:::note{type="warn"}
While RxJS is very powerful, it also introduces a significant cognitive load for people who are not familiar with its concepts. It is essentially a different paradigm. That's why I would avoid RxJS unless your application will heavily rely on streams.
:::

:::note
Go for [lodash-es](https://www.npmjs.com/package/lodash-es) if you're using Loadsh and ES modules.
:::

## (Optional) date-fns or Day.js

When choosing a date library, consider [you might not need a date library at all](https://dev.to/dmtrkovalenko/you-might-not-need-date-fns-23f7).

Here's some thoughts:

- If you haven't already, let go of Moment.js, it is time.
- [Day.js](https://day.js.org/) is a decent alternative and uses an interface similar to Moment.
- [date-fns](https://date-fns.org/) is smaller and more performant.

**I recommend going with date-fns**, but I don't think you can go wrong with either.

## (Optional) Zod

It feels like [Zod](https://github.com/colinhacks/zod) has taken the front-end world by storm. It is proving to be a great tool - small, lightweight, TypeScript-native.

If you need some additional schema validation, especially when working with external data sources and services, I wouldn't blame you if you reach for Zod.

One thing you may wanna be cautious about is performance. Zod [has improved this drastically](https://github.com/colinhacks/zod/issues/205) in the past year, but it is something to think about.

There are lighter-weight alternatives like [myzod](https://github.com/davidmdm/myzod) if you only need schema validation.

## Vite & Vitest

This is where I'll stray a bit from the “production-ready” criterion and suggest something that's not as battle-tested, as say, Webpack.

[Vite](https://vitejs.dev/) still has some quirks to iron out, but the improved developer experience you'll get from it is worth spending some time tweaking it to make it work.

That said, I wouldn't think less of you if you went with Webpack. It is still a great and very safe choice. If build time is important to you, Webpack [could be the better choice](https://storybook.js.org/blog/storybook-performance-from-webpack-to-vite/).

# Conclusion

That's it! And this is the important part - **I don't see this list as a starting point, this *is it*.**

Of course, if you need something specialized on top - like a charting library or analytics tools - that makes perfect sense and definitely go for it.

But as far as the basics go, this should be enough.

Your dependencies will end up looking like this:

```json
"dependencies": {
  "@tanstack/react-query": "",
  "classnames": "",
  "date-fns": "",
  "ramda": "",
  "react": "",
  "react-aria": "",
  "react-router-dom": "",
  "zod": "",
},
"devDependencies": {
  "@faker-js/faker": "",
  "@tanstack/react-query-devtools": "",
  "@testing-library/react": "",
  "@types/ramda": "",
  "@types/react": "",
  "@types/react-dom": "",
  "@typescript-eslint/eslint-plugin": "",
  "@typescript-eslint/parser": "",
  "@vitejs/plugin-react": "",
  "esbuild": "",
  "eslint": "",
  "eslint-plugin-prettier": "",
  "eslint-plugin-react": "",
  "miragejs": "",
  "prettier": "",
  "typescript": "",
  "vite": "",
  "vitest": ""
}
```

… plus or minus some dev plugins. I think that's a very manageable `package.json`.

Hope you found this article useful! If you did, please let me know by pressing the heart below! Thank you!

[^1]: I'm starting to dislike the term "[user](https://esynonyms.com/user)" more and more.


A sensible Front-end stack for Production applications · 2023 edition

As we all know, [Hexagons are the Bestagons](https://www.youtube.com/watch?v=thOifuHs6eY) - we see them in honeycombs, they are in snowflakes and pencils, there’s one [on Saturn](https://en.wikipedia.org/wiki/Saturn%27s_hexagon), and they are... *(math incoming)* the only regular polygon to tile a plane without resorting to debasing self-divison 😅.

When I started rebuilding my website, I knew I wanted a live, configurable background and it quickly became clear it’ll be rendered on a **canvas**. I was playing around, drawing various 2D shapes, when I remembered the [CGP Grey](https://www.youtube.com/greymatter) video - hexagons... The Bestagons were the obvious choice!

In this series of tutorials I’ll show you how I built this background.

## Part one: how to render a hexagon?

OK, so how do we render a regular hexagon? We want to draw 6 straight lines of equal length. To form a hexagon, the angle between every two sides has to be 120°.

:::note
Each time we add a side to a polygonal shape, the sum of its interior angles increase by 180°. So a triangle has a total of 180°, a square - 360°, a pentagon - 540°, and a hexagon - 720°.

A hex has six sides, and from the formula `degrees = (# of sides - 2) * 180`, we can compute the angle size of 720 / 6 = **120°**.
:::

![hex-1.png](/images/hexagons-are-the-bestagons-js-edition-part-one/hex-1.png)

Let’s explore our options for drawing stuff on a canvas. Here's some API methods from [CanvasRenderingContext2D](https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D), the interface from the Canvas API that we use to draw in two dimensions:

- [arc()](https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/arc) - creates a circular arc. Hexagons only have straight walls, `arc` is definitely not our thing;
- [ellipse()](https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/ellipse) - creates an ellipse. Same as above, cool, but not for us;
- [rect()](https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/rect) - adds a rectangle to the current path. Finally, some straight lines. Still won’t work for us though - rectangles are obviously the inferior choice... and we can't really draw a hex using a full reactangle;
- [lineTo()](https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/lineTo) - adds a straight line to the current sub-path. This is our thing!

Unfortunately, there doesn’t seem to be anything more convenient in the API. No `fillHex()` function yet 🙄. We’ll have to draw our hexagons line by line.

So, let’s take a look at the `lineTo()` method - it accepts an `x` and a `y` coordinate. Here’s the example from MDN:

```js
const canvas = document.getElementById("canvas");
const ctx = canvas.getContext("2d");

ctx.beginPath(); // Start a new path
ctx.moveTo(30, 50); // Move the pen to (30, 50)
ctx.lineTo(150, 100); // Draw a line to (150, 100)
ctx.stroke(); // Render the path
```

OK, so in order to draw a hex, we need to figure out the coordinates of all its vertices.

## Computing the vertices

Let’s give the vertices of our future Hex names - A, B, C, D, E, F:

![hex-2.png](/images/hexagons-are-the-bestagons-js-edition-part-one/hex-2.png)

And let’s say we start from vertex A. Our code will then look something like this:

```js
const canvas = document.getElementById("canvas");
const ctx = canvas.getContext("2d");

ctx.beginPath(); // Start a new path
ctx.moveTo(vertexA.x, vertexA.y); // move the pen to vertex A
ctx.lineTo(vertexB.x, vertexB.y); // draw a line from A to B
ctx.lineTo(vertexC.x, vertexC.y); // draw a line from B to C
ctx.lineTo(vertexD.x, vertexD.y); // draw a line from C to D
ctx.lineTo(vertexE.x, vertexE.y); // draw a line from D to E
ctx.lineTo(vertexF.x, vertexF.y); // draw a line from E to F
ctx.lineTo(vertexA.x, vertexA.y); // ...and finally, from F to A to finish the hex
ctx.closePath();
ctx.stroke(); // Render the path
```

The next question we have to answer is - if vertex A has coordinates `(0, 0)`, where is vertex B?

![brace-yourselves.jpg](/images/hexagons-are-the-bestagons-js-edition-part-one/brace-yourselves.jpg)

First, we need to define the length of our hex’s side. Let’s hardcode it to `10px`.  Then, figure out where B is.

![hex-3.png](/images/hexagons-are-the-bestagons-js-edition-part-one/hex-3.png)

Let’s call the coordinates of A `(ax, by)` , and of B `(bx, by)` . We draw a line between A and C and the height of the ABC triangle - BH.

We can now see that:

- `bx == ax + length(AH)` - B is straight on top of H, so `bx` is the same as the `x` coordinate of H (`hx`); H is `length(AH)` away from A, so `hx` is `ax + length(AH)`
- `by == ay - length(BH)` - B is `length(BH)` away from H, so `by = hy - length(BH)`; and because A and H are on the same `y` → `hy` is the same as `ay`.

If we find the lengths of AH and BH, we’re good to go. To find them, we need a bit of math “magic”:

- `∠AHB` is **90°**. `∠ABH` is half of `∠ABC`, so it’s **60°**, therefore `∠HAB` is 180 - (90 + 60) = **30°**.
- From trigonometry, [we know](https://www.khanacademy.org/math/trigonometry/trigonometry-right-triangles/sine-and-cosine-of-complementary-angles/a/trig-ratios-of-special-triangles) that `length(AH) = cos(∠HAB) * length(AB)`, and `length(BH) = sin(∠AHB) * length(AB)`

Let's call the length of AB `hexSide`, then:

- `length(AH) = cos(30°) * hexSide`
- `length(BH) = sin(30°) * hexSide`

## Math over!

We’re mostly done with the math. Back to code!

```js
const COS_30 = Math.cos(Math.PI / 6);
const SIN_30 = Math.sin(Math.PI / 6);

const hexSide: number = 10; // the side of our hex is hardcoded to 10px

// Note: in real life, lacking the diagram above, `AH` means nothing.
// I would keep this as `COS_30 * hexSide` or try to give a more
// meaningful name.
const AH = COS_30 * hexSide;
const BH = SIN_30 * hexSide;

const vertexA = { x: 0, y: 0 };
const vertexB = { x: vertexA.x + AH, y: vertexA.y - BH };
```

And we have our vertex B!

At this point I suggest you pause for a bit and try to figure out the coordinates of C, D, E, and F. Use what we already know - the coordinates of A and B, `hexSide`, `AH`, and `BH`.

Here’s the solution:

```js
const vertexA = { x: 0, y: 0 };
const vertexB = { x: vertexA.x + AH, y: vertexA.y - BH };
const vertexC = { x: vertexB.x + AH, y: vertexA.y };
const vertexD = { x: vertexC.x, y: vertexC.y + hexSide };
const vertexE = { x: vertexB.x, y: vertexD.y + BH };
const vertexF = { x: vertexA.x, y: vertexD.y };
```

So, now that we have all vertex coordinates, we're finally ready to render our hexagon:
```html
<html>
  <body>
    <canvas id="canvas"></canvas>
    <script>
    const COS_30 = Math.cos(Math.PI / 6);
    const SIN_30 = Math.sin(Math.PI / 6);

    // Coords of our first vertex.
    const start = { x: 100, y: 100 };

    // Length of our hex's side.
    const hexSide = 100;

    // Find or create a canvas.
    const canvas = document.querySelector('#canvas');
    canvas.width = 400;
    canvas.height = 400;

    const ctx = canvas.getContext('2d');

    // Compute the vertices (same as above).
    const vertexA = start;
    const vertexB = {
      x: vertexA.x + hexSide * COS_30,
      y: vertexA.y - hexSide * SIN_30
    };
    const vertexC = { x: vertexB.x + hexSide * COS_30, y: vertexA.y };
    const vertexD = { x: vertexC.x, y: vertexC.y + hexSide };
    const vertexE = { x: vertexB.x, y: vertexD.y + hexSide * SIN_30 };
    const vertexF = { x: vertexA.x, y: vertexA.y + hexSide };

    // List all vertices. Remember - we have to `lineTo()` to vertex A to
    // finish the hex.
    const vertices = [
      vertexA, vertexB, vertexC,
      vertexD, vertexE, vertexF, vertexA
    ];

    // Begin a new sub-path at vertex0.
    ctx.moveTo(vertices[0].x, vertices[0].y);
    ctx.beginPath();

    // Add line to the sub-path from each vertex to the next one.
    vertices.forEach(({ x, y }) => ctx.lineTo(x, y));

    // End the sub-path.
    ctx.closePath();

    // Set the stroke color for our hex.
    ctx.strokeStyle = 'rgb(0, 0, 0)';

    // And finally, our Bestagon:
    ctx.stroke();
    </script>
  </body>
</html>

```

And the outcome is:
![result.png](/images/hexagons-are-the-bestagons-js-edition-part-one/result.png)

This is it for Part one! Thank you for reading!

In Part two we will continue with rendering multiple hexes on a grid. Stay tuned 😉


Background options

front-end

A sensible Front-end stack for Production applications · 2023 edition

Hexagons are the Bestagons (JS edition) · Part one