
You can often hear two vastly different opinions on macOS that are opposites on the same spectrum - the OS is either great because _"it just works"_, or terrible because it is _"very limited and can't be customized"_.

I think both are wrong.

I like macOS for a couple of reasons:
1. It is Unix-like, and you can use a lot of the tools and software from the Unix world;
1. People write some great software for it;
1. It can be customized just enough (at least for now) to make it much more usable than it is by default;
1. It looks good without the need to spend hours working on it; [^1]
1. It integrates well with other Apple devices.

Having said that, I believe that in the state it comes out of the box, macOS is barely usable[^2] for more complex workflows.

There are a couple of major problematic areas:
1. window management is nonexistent;
1. finder is stuck in its ways and lacks some basic functionality;
1. the Menu bar (for Windows people - this is the alternative to the System tray) gets flooded by random icons.

All of these pain points can be alleviated to some degree using third-party software.

## Contents


# Window Management
 By default, you are given a very minimal amount of options - you can minimize, hide windows, and make windows fullscreen. You can also create multiple spaces for windows. That's about it.
 It is embarrassing how much macOS has fallen behind Windows in that regard. [^3]

There are a couple of very notable omissions:
- no window snapping/tiling whatsoever (either using the mouse or via keyboard shortcuts);
- no easy way to move windows between different monitors.

:::note
I think people underestimate how much good window management can improve their productivity, especially on small laptop displays.

Moving windows around with the mouse without snapping is a huge hassle. Full-screening apps to new virtual desktops tends to get disorienting. I often see people fumble around trying to find their windows.
:::

## Option 1: Rectangle (free)
Download from: https://rectangleapp.com.

Rectangle is a free [^4], open-source app that gives you a lot of options for resizing windows to a bunch of areas, moving windows around, etc.

Besides the keyboard shortcuts, you can also use the mouse to resize windows to predefined snap areas - e.g. move a window to the left half of the screen to snap it to the left 50%.

![rectangle options](https://rectangleapp.com/assets/images/shortcutScreenshot.jpg)
:source[source: https://rectangleapp.com.]

## Option 2: Raycast (free, paid AI features)
Download from: https://www.raycast.com/.

Raycast is an awesome tool. It is a Spotlight replacement and does much more than just window management. **I cannot recommend it enough.**

Raycast allows you to quickly open apps, execute various commands with aliases, and most importantly - has a huge ecosystem of free, open-source extensions.
I recommend setting up Raycast to start on login and to be opened with :kbd[⌘]+:kbd[space] (replacing Spotlight's shortcut).

You can browse Raycast's [extension store](https://www.raycast.com/store) to see what it integrates with. Some of the extensions I use are:
- [Bitwarden Vault](https://www.raycast.com/jomifepe/bitwarden)
- [Encoding Tools](https://www.raycast.com/eth-p/encoding-tools)
- [Home Assistant](https://www.raycast.com/tonka3000/homeassistant)
- [Kill Process](https://www.raycast.com/rolandleth/kill-process)
- [Port Manager](https://www.raycast.com/lucaschultz/port-manager)
- [Search Can I Use](https://www.raycast.com/thomaslombart/can-i-use)
- [Spotify Controls](https://www.raycast.com/thomas/spotify-controls)
- [UUID Generator](https://www.raycast.com/jmaeso/uuid-generator)
- and of course, Window management (built-in)

You can set up keyboard shortcuts and command aliases for all commands (including all the window management options).
In my setup, this enables me to hit :kbd[⌘]+:kbd[space] and type `lf` (or other short aliases) for quick window tiling of the active window.

![raycast](/images/making-macos-more-usable/raycast.webp)

This is the option I use. While it may take a bit more time to set up and get used to, this is a must-have for me.

Here are some example workflows from my system that I cannot live without.

### Moving windows around via keyboard shortcuts and aliased commands
![resizing windows with raycast](/images/making-macos-more-usable/resizing-with-raycast.gif)
Used shortcuts (this is my configuration):
- :kbd[⌃]+:kbd[⌘]+:kbd[up] to resize the window to full screen
- :kbd[⌃]+:kbd[⌘]+:kbd[left/right] to tile to the left/right and cycle between various widths
- :kbd[⌘]+:kbd[space] to launch raycast, then `lf` for "Last Fourth" to tile the window at the last 25% of the screen
- :kbd[⌘]+:kbd[space] to launch Raycast, then `trs` for "Top Right Sixth", etc

### Obtaining a 2FA token for my Discord account from Authy
![using raycast with authy](/images/making-macos-more-usable/authy-raycast.gif)
Keystrokes:
1. :kbd[⌘]+:kbd[space] to launch Raycast
1. type :kbd[at] and press space (or enter) to search authy tokens
1. type :kbd[dis] to search for Discord
1. enter

### Quickly switching between open applications
![app switching with raycast](/images/making-macos-more-usable/app-switching-raycast.gif)


# Menu bar clutter
A lot of software written for macOS wants to put its icon in the Menu bar. Some give you the option to hide the icons, but not all of them do.

Even when I disable whatever I can, things tend to get cluttered. And if you are working on a MacBook that has a notch, icons can even get hidden behind the notch.

![menu-bar](https://matthewpalmer.net/vanilla/images/notch-guide-1.jpeg)
:source[source: https://matthewpalmer.net/vanilla/vanilla-macbook-notch.html]

The main missing functionalities are:
- easily hide icons
- have the option to show the hidden icons when you need them
- be able to easily rearrange icons

There are a lot of tools in this space. There's a website dedicated to them - check out [Menu Bar Managers](https://macmenubar.com/menu-bar-managers/).

## Option 1: Bartender (paid, $16)
Download from: https://www.macbartender.com/.

![bartender](https://www.macbartender.com/Bartender5/img/quickreveal.gif)
:source[source: https://www.macbartender.com/]

This is the one I've been using - it is paid, but not on a subscription basis. They typically charge upgrade fees for major release versions once every few years.

It allows you to hide items and has a bunch of customization on top of that. It also allows you to customize the appearance of the Menu bar, including reducing the distance between icons.

In my experience, this is the best option for managing Menu bar icons.

## Option 2: Vanilla (free)
Download from: https://matthewpalmer.net/vanilla/.

Vanilla allows you to hide Menu bar icons in an expandable tray.

It is free but has a paid version with extra features. The only drawback of the free version is that it seems like they prohibit you from running Vanilla on login, which is a bit of a bummer.

## Option 3: Dozer (free, open-source)
Download from: https://github.com/Mortennn/Dozer.

Kinda the same thing as Vanilla. Free and open-source, but unfortunately development seems to have stopped.


# Finder & File browsing
I mean... if you've used it, you probably felt frustration at some point. Even though I think Finder has been improving with recent versions of macOS, it still has a way to go.

Here's a non-exhaustive list of missing things:
- no option to see folders on top,
- no split view,
- limited options to work with remote file systems.

## Option 1: Forklift (paid, $20)
Download from: https://binarynights.com.

![forklift](https://binarynights.com/images/main.png)
:source[source: https://binarynights.com.]

Forklift is a great Finder replacement. It is very customizable, has great support for working with remotes, has split screen support, and has remappable shortcuts. It has an improved UI for copying and moving things around, especially in-progress jobs.

Its license says 1 year, but it is not a subscription. You get lifetime access and 1 year of updates.

## Option 2: customize Finder as best as you can (free)

If you go to Finder's preferences, you will find options to change the default folder and to use tabs instead of opening new windows. You can also customize the sidebar to show only what you need. In "Advanced", you can choose to keep folders on top when sorted by name.

## Option 3: might as well use the terminal (free)
... If you're into it 😁

Some tools that are worth looking into:
- [fzf](https://github.com/junegunn/fzf) - fuzzy search in the terminal. Integrates well with zsh, git, and others.
- [eza](https://github.com/eza-community/eza) - `ls` replacement. Shows useful information and is easy to customize.


# Bonus round: remapping keyboard keys

Sometimes the default keyboard layout is just hard to get used to.
For example, I have a very hard time getting used to my MacBook's European keyboard layout:

![keyboard with EU layout](/images/making-macos-more-usable/eu-keyboard.webp)
:source[Keyboard with EU layout]

Notice the :kbd[~] is next to the left shift key instead of its usual location below :kbd[esc].

macOS supports some key remaps out of the box. You can go to System Preferences -> Keyboard -> Keyboard Shortcuts -> Modifier Keys and remap some keys.

I always swap the globe (:kbd[fn]) and left control keys and set :kbd[caps] to :kbd[esc]:
![remapping keys in macOS](/images/making-macos-more-usable/key-remap.webp)

For my case of the :kbd[~] key, though, nothing built-in can help. I use [Karabiner Elements](https://karabiner-elements.pqrs.org/) for that. It is a bit more complex to set up, but it is very powerful - it allows you
to remap any key to any other key.


# Misc apps a.k.a honourable mentions
- [Sound Source](https://rogueamoeba.com/soundsource/) (paid, $47) - Incredible audio management tool. Lets you control audio volume per app & device, equalize audio, easily connect to audio accessories, and much more. Unfortunately, it is pricey and also requires quite a lot of control over your system.
- [Monitor Control](https://github.com/MonitorControl/MonitorControl) (free) - Handy tool that improves support for external monitors. If you're having issues with blurriness, this might help. Also allows you to control the brightness and volume of external monitors.
- [Dato](https://apps.apple.com/us/app/dato/id1470584107?mt=12) ($10) - Nifty calendar in the Menu bar. Has great notifications for upcoming events.
- [DatWeatherDoe](https://github.com/inderdhir/DatWeatherDoe) (free) - Menu Bar weather.
- [Stats](https://github.com/exelban/stats) (free) - Show detailed system usage (disk, network, CPU, memory, battery, etc.) in the Menu bar.
- [Alfred](https://www.alfredapp.com/) (free) - Raycast's older brother. Alfred has been a thing for a long time. It is a bit harder to configure and extend, though. Currently, I don't see a reason to go for Alfred instead of Raycast.
- [The Unarchiver](https://theunarchiver.com/) (free) - Lets you extract various archive file types easily. Adds support for a lot of archive types that are not supported by default.
- [rcmd](https://lowtechguys.com/rcmd/) ($13) - Even faster keyboard-based app switching. Allows you to assign a single character key to every app and open/focus the app by hitting right command + that key.  If you use Raycast, this may be a bit of an overkill. Still, really cool and a great idea.


# Conclusion
If you were to try only one of the apps I mentioned here, I suggest going with Raycast. It is a great tool that can improve your workflow in numerous ways.

I hope I was able to show that macOS can be customized and optimized for your workflow if you spend a bit of time tinkering and are willing to use some third-party tools.


[^1]: Though I admit browsing through [r/unixporn](https://www.reddit.com/r/unixporn/) once in a while and some of the stuff there looks excellent.
[^2]: Ok, maybe I'm being a bit overly dramatic here. I recently used a "vanilla" macOS machine and was very frustrated by how hard navigating around is
[^3]: I'm not even gonna mention the Linux world, because there we've always had a sea of options, and most DEs come with very adequate window management out of the box.
[^4]: Rectangle has a paid Pro version, but you don't necessarily *need* it.


Making macOS more usable


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

posts

Making macOS more usable

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

Hexagons are the Bestagons (JS edition) · Part one