DEV Community: Rico Sta. Cruz

Why I’m moving from Jest to Vitest

Rico Sta. Cruz — Thu, 07 Apr 2022 13:21:38 +0000

I've always reached out to Jest for any JavaScript testing, but I think it's time to rethink that. I just discovered Vitest, and thought I'd try it out in one of my projects. It feels like a test runner for 2022 - it covers everything Jest does, plus a few extras that just make it a great alternative.

It has a UI!

Vitest comes with a UI that runs in the browser. It can show code, and even print out console.log() calls!

This might seem excessive for those who prefer the command line, but it makes for a lot of convenient things like drilling down to specific tests.

☝Run `vitest --ui` to run the test UI in the browser.

ES modules, TypeScript and more

Vitest supports modern features like ES modules, TypeScript, JSX, PostCSS, async-await and more—all without the need for complex configuration. (docs)

In contrast, getting these things to work with Jest has often been frustrating. The most practical way is to use Babel alongside Jest to compile JavaScript, and use workarounds to make Jest ignore CSS files.

With Vitest, it seems these things just work.



import 'react' from React
import 'react-dom' from ReactDOM

it('works', () => {
  ReactDOM.render(<div>hello!</div>, document.body)
  expect(document.body.innerText).toBe('hello!')
})

☝ A test like this will require a Babel pipeline in Jest. In Vitest, it should work with the default config.

The API is Jest-compatible (mostly)

Vitest makes migrating from Jest as easy as possible. It supports Jest assertions by default.

That was exciting enough, but I was surprised to see that the Jest interop goes even further. Special functions like jest.useFakeTimers() have equivalents Vitest as vi.useFakeTimers().



/* Vitest */
const spy = vi.spyOn(obj, 'getApples').mockImplementation(() => apples)

/* Jest */
const spy = jest.spyOn(obj, 'getApples').mockImplementation(() => apples)

☝ Just change `jest` to `vi`.

Jsdom is optional

Vitest also supports browser emulation via Jsdom… and there’s more.

Unlike Jest which always runs with Jsdom by default, Jsdom can be turned off in Vitest. In fact, there are options of what environment to emulate. As of v0.8, Vitest supports node, jsdom and happy-dom.



/**
 * @vitest-environment jsdom
 */

☝ Adding this to the top of a test file enables Jsdom.

No global pollution

Unlike Jest which automatically drops things into the global context (eg, expect(), describe(), etc), Vitest requires importing them in every test file. While this may be a bit more typing, I think it’s more explicit and follows principle of least surprise.

It’s also possible to have them globalised automatically to make migration from Jest easier. (docs)



import { expect, test } from 'vitest'

test("My test", () => {
  expect(2 + 2).toBe(4)
})

☝ The functions `expect` and `test` are explicitly imported before use.

Parallel tests work great

Vitest can run tests in parallel—and the feature is stable!

While Jest has test.concurrent, it’s been considered as “experimental” for as long as Jest has been around. Vitest’s counterpart of test.concurrent seems to be considered stable.

Vitest has multi-threaded support built in and is enabled by default. (docs)



/*
 * Vitest will attempt to run these tests
 * in parallel:
 */

test.concurrent('concurrent test 1', async() => {
  /* ... */

})
test.concurrent('concurrent test 2', async() => {
  /* ... */
})

Thanks for reading!

Thanks for checking out my post! I'm a web developer who loves open source and JavaScript. If you liked this post, consider following me on Dev.to (@rstacruz) or Twitter (@rstacruz)!

Vitest

Switching apps slows down my productivity (and how I fixed it)

Rico Sta. Cruz — Mon, 04 Apr 2022 04:58:17 +0000

Switching apps is something I do hundreds of times a day on both MacOS and Windows. I found a way to make this faster, which has made my workflow a lot more efficient.

☝ Has this been as frustrating for me as anyone else?

Is switching apps really difficult?

Well, just a bit. Not much, but small frustrations easily add up over time. Switching with a keyboard always required too much effort for me. I often try one of these, but each one requires some thinking (or typing):

win-4 to launch the 4th taskbar app (Windows)
ctrl-alt-4 using uBar to emulate Windows behaviour (MacOS)
alt-tab-tab-tab to switch to a window (Windows and MacOS)
cmd-space firefox to use Spotlight (MacOS)

My solution: fixed key bindings

I settled a way that’s easier for me: shortcuts that always do one—and only one—thing. For example, ctrl-win-w will always focus my web browser, where alt-tab requires some thinking to figure out how many Tabs to press.

The result: I save a second of thinking for every app switch I do. For something I do hundreds of times a day, it all adds up! 🎉

☝ Just a small selection of the shortcuts I use.

MacOS via Raycast

There are many ways this can be achieved in MacOS. The simplest one I think is with Raycast.

☝ Raycast allows defining shortcuts for many actions, including launching apps.

MacOS via Hammerspoon

For my MacBook, I used Hammerspoon, a hotkey automation suite for MacOS. Writing a Lua script to launch apps with hotkeys isn’t too difficult:

-- ~/.hammerspoon/init.lua
hs.hotkey.bind({"ctrl", "cmd"}, "v", "Visual Studio Code", function()
  hs.application.launchOrFocus("Visual Studio Code")
end)

hs.hotkey.bind({"ctrl", "cmd"}, "w", "Firefox", function()
  hs.application.launchOrFocus("Firefox")
end)

hs.hotkey.bind({"ctrl", "cmd"}, "s", "Slack", function()
  hs.application.launchOrFocus("Slack")
end)

☝A simple Hammerspoon script to launch apps from hotkeys. (Docs: launchOrFocus, bind)

Windows via AutoHotkey

For my Windows laptop, I used a powerful automation scripting language called AutoHotkey. Here’s an example that launches apps based on start menu items (w and o), URL (c) and file path (v).

UserStartMenu := A_AppData . "\Microsoft\Windows\Start Menu\"
SysStartMenu := "C:\ProgramData\Microsoft\Windows\Start Menu\Programs"

; [w] Firefox (web)
^#w::LaunchOrFocus({ run: SysStartMenu . "Firefox", select: "ahk_exe firefox.exe" })

; [o] Obsidian
^#o::LaunchOrFocus({ run: UserStartMenu . "Programs\Obsidian", select: "ahk_exe Obsidian.exe" })

; [c] Calendar
^#c::LaunchOrFocus({ run: "outlookcal:" })

; [t] Terminal
^#v::LaunchOrFocus({ run: "wt.exe", select: "ahk_exe WindowsTerminal.exe" })

LaunchOrFocus(app) {
  selector := app["select"]
  If (selector and WinExist(selector))
    WinActivate,
  else
    Run % app["run"]
}

☝A simple AutoHotkey script to launch apps from hotkeys using WinActivate and Run. Save it as example.ahk and double-click on it to open in AutoHotkey.

My shortcuts

I set up shortcuts for the apps I use 90% of the time. For anything not here, I would use Spotlight or Windows Search.

☝I use the Colemak mod-DH layout, but this can work on any keyboard layout. (The * keys are reserved for moving windows to the side of my screen, but that’s for another article!)

Thanks for reading!

Thanks for checking out my post! I'm a web developer who loves open source and supercharging productivity. If you liked this post, consider following me on Dev.to (@rstacruz) or Twitter (@rstacruz)!

Autohotkey - automation for Windows
Raycast - app launcher for MacOS
Hammerspoon - automation for MacOS

Public CDN's aren't useful anymore

Rico Sta. Cruz — Fri, 01 Apr 2022 02:30:33 +0000

Public CDN’s were supposed to help page speed, but things have changed in 2019. Services like Google Fonts, Cloudflare’s cdnjs, jsDelivr and Google Hosted Libraries may not help make sites load faster anymore.

Shared caches don’t work anymore

Today, the primary advantage of public CDN’s is no longer supported by modern browsers.

Resources (like .js files) loaded by a site the user visits will no longer be cached for other sites they visit. Browsers have stopped having shared caches around Sep 2019 (Chrome 77, Firefox). This has all been done to address a cross-site leak security issue reported on March 2019:

Shared Cache is Going Away (jefftk.com)
sirdarckcat: HTTP Cache Cross-Site Leaks (sirdarckcat.blogspot.com)

About public CDN’s

CDN’s were supposed to help sites load faster. For example, a popular library like jQuery can be loaded from a CDN by one site, making it load faster for other sites the user will visit who would use the same CDN.


<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.6.0/jquery.min.js"></script>

☝Google has been running a CDN serving popular JavaScript libraries. (via Google)

Other issues with public CDN's

📉 Downtime — Downtime in Public CDN’s will impair the service of your site. Compare this to something like npm or Rubygems where downtime will affect builds and deploys, but not users.

⚠ Blocked in some regions — There are countries that block Google domains, which will impair your site if it loads critical assets from Google Fonts or Google Hosted Libraries.

🥷 Resource integrity issues — In the event of a compromised public CDN, malicious code can be inserted into your site. This can be mitigated using Subresource Integrity (SRI) (ie, <script src="..." integrity="(sha384_hash_here)">) but maintaining these can be a hassle.

Are public CDN’s still useful?

While public CDN’s have been heavily nerfed, some have found it to be useful for other reasons.

💻 Code examples — Using Google Fonts can be useful in code examples. There are even CDN’s like skypack that will create optimised versions of npm packages, allowing code examples to skip having build & compile pipelines.

🏗 Simplifying build pipelines — Tools like Rails’s import-map recommend using a CDN like jspm to outsource to build step needed by some npm packages. Personally I find this questionable for security reasons, but some prefer to trade security for convenience.

🔌 Sidestepping max connections? — Browsers limit HTTP requests to 6 connections per domain, so having some assets served in a different domain can potentially have some advantages. In practice however, HTTP/1.1 pipelining and HTTP/2.0 Multiplexing should already allow browsers to make multiple concurrent requests.

What do we do now?

For production builds, self-hosting seems to be a much better alternative to using CDN’s.

💡 Self-hosted JavaScript — There are many options today for self-hosting npm packages.

💅 Self-hosted fonts — Fontsource is an easy way to self-host Google Fonts (and more) without having to manually manage font files.

⚡ Use a CDN — Not a public CDN, but CDN services like Cloudflare and Fastly can make pages load fast (<100ms!). This will make self-hosting very viable.

🔌 Enable HTTP/2 — It’s a great idea to support HTTP/2.0 across all steps in web hosting infrastructure. Cloudflare, for example, allows enabling HTTP/2 support in their cache proxy service.

Guide: Netlify-to-Discord notifications

Rico Sta. Cruz — Tue, 29 Mar 2022 11:44:29 +0000

Discord is a great way to get Netlify notifications! I set up my own private server to collect notifications with my open source projects.

There’s an official guide to set up GitHub notifications on Discord, but I like using it too for other things like monitoring Netlify deployments. Here's how I got it set up.

Solution: webhooks

Discord supports any Slack-compatible webhook. I used this to set up send Netlify notifications to Discord using Slack’s webhook format.

Step 1: Create a webhook in Discord

In Discord’s channel settings, go to “Integrations” and select “Create Webhook”. In the next screen, use “Copy Webhook URL” to copy the URL.

Step 2: Site settings in Netlify

Under Netlify’s “Site settings”, go to “Build & deploy” → “Deploy notifications”.

Step 3: Add a notification

Under the “Outgoing notifications” section, click the “Add notification” button.

Step 4: Choose Slack integration

In the dropdown, select “Slack integration.” (Yes, select “Slack” even if it’s Discord!)

Step 5: Add the URL

Paste the webhook URL and add /slack to the end. Don’t forget to change the “Event to listen for” dropdown.

All done!

New notifications should now show up on Discord.

Faster multi-line jumps in VSCode-Vim

Rico Sta. Cruz — Tue, 29 Mar 2022 02:37:27 +0000

One of the things that bothered me with VSCode-Vim was with how slow it was to use (number)(arrow) (eg, 42(down)) to move multiple lines down. In the screencast below, notice how it goes line-by-line rather than skipping ahead instantly.

☝ Figure 1: VSCode scrolls slooowly line-by-line when pressing 42(down).

Solution: use j/k

TIL that VSCode-Vim already accounts for this with hjkl movements, so 42(down) can be pressed at 42j.

☝Figure 2: Using j/k keys (eg, 3j instead of 3(down)) hops to the target line instantly. I also did a trick to make this work with arrow keys (see below).

Making it work with arrow keys

To make this work with (up) and (down) arrow keys too, I rebound my arrow keys to j/k movements.

/* settings.json */
{
  "vim.normalModeKeyBindings": [
    // Make "9j 9k" work faster
    { "before": ["Down"], "after": ["j"] },
    { "before": ["Up"], "after": ["k"] },
}

Windows Subsystem for Linux - explained by a Linux user

Rico Sta. Cruz — Fri, 04 Oct 2019 20:59:27 +0000

You can now run Linux apps on Windows thanks to a feature called Windows Subsystem for Linux ("WSL" for short). But what is it, exactly? Is it an emulation layer like Wine? Is it a VM like VirtualBox? Is it dual-booting like Boot Camp? It's none of the above—it's something pretty unique and hard to explain.

👇

Next: Let me try to explain it anyway!

## Ubuntu as a Windows app

To get Linux working on Windows, you first need to install Linux. Not from an ISO... but from the Microsoft Store (think: Windows's version of the Mac App Store). A full guide to installing WSL is available from Microsoft.

Linux distributions are available as apps. To be specific, they're command-line apps, just like git or vim.

Many devs use Ubuntu as their Linux distribution in WSL.

👇

Next: To understand WSL, let's first look at how the Windows command line works.

## Command-line apps

Windows has support command line interface (CLI) apps, just like Linux. In fact, many built-in system utilities are CLI apps.

💡 Try this: press Win + R, then run ping 8.8.8.8. It will open a new window.

ping.exe is a built-in command line application.

👇 Next: Let's see what makes this window work.

## Windows console host

CLI apps are ran inside the Windows console host. The console host, or conhost.exe, is a GUI app that draws a terminal inteface in a graphical window.

💡Try this: open the task manager (Ctrl + Shift + Esc). Now run ping -t 8.8.8.8. You'll see a new application in the task manager called TCP/IP Ping Command. Under this group are 2 processes:

ping.exe—the command you just ran; and
conhost.exe—also known as Console Window Host, the GUI that shows ping's output.

ping.exe is running alongside the conhost.exe GUI.

In Linux terms: Think of conhost.exe as a terminal emulator, like XTerm might be for Linux. It's a graphical UI that shows terminal output. ping.exe runs on conhost.exe in the same way /usr/bin/ping runs inside Xterm.

👇 Next: Let's see how the Windows Command Prompt works.

## Cmd.exe on Conhost

All CLI apps open in conhost.exe. This includes the Windows Command Prompt, or cmd.exe—which is a CLI app, just like ping.exe!

💡 Try this: Go to Win + R and run cmd.exe. You'll see this open in the same Windows console host window that ping.exe opened.

cmd.exe opens in a Conhost window.

In Linux terms: Think of cmd.exe like the Bash shell. A terminal window in Linux will run Bash, and will close the window when Bash exits. cmd.exe (the shell) and conhost.exe (the terminal GUI) works the same way.

👇

Next: This may be the case for the Command Prompt, but why does Powershell's window look different?

## Powershell's blue window

If you open Powershell, you'll notice that the window is blue. It's not a different app, it's still the same conhost.exe with different settings! You'll notice it has the same menus as cmd.exe.

Powershell.exe is a CLI app, too—just like cmd.exe. Conhost simply lets you choose different settings per app. It simply comes with different color settings for Powershell by default.

Powershell's Properties window lets you configure conhost settings.

In Linux terms: Most terminal emulators on Linux would support different profiles, and you may be assigning different profiles per command. Windows's conhost.exe has a different profile for Powershell that has its Screen Background set to blue.

👇

Next: Is WSL just like cmd.exe and Powershell then?

## The WSL launcher: `wsl.exe`

Yes! You can think of WSL as another CLI application just like cmd.exe and powershell.exe. Just like other CLI apps, you can run wsl.exe. This is the WSL Launcher, which boots up the WSL platform and drops you into the bash (your user's shell by default).

💡 Try this: Try running wsl.exe via Win + R. This should get you a Linux bash prompt running inside a conhost.exe window. Seems very similar to Cmd and Powershell, doesn't it?

Running wsl gets you a conhost window, just like cmd.exe.

👇

Next: Let's try mixing all these together.

## Shells inside shells

Windows's cmd.exe and powershell.exe can run command line applications. You can use it to run ping.exe, chkdsk.exe, or—wouldn't you know it—even wsl.exe.

💡 Try this: Try running wsl.exe or bash.exe from within a Command Prompt (cmd.exe). In fact, try running wsl.exe inside powershell.exe inside cmd.exe, or any combination above! Typing exit will bring you one level out.

In Linux terms: Think of them just like shells. Windows's Cmd might be like Bash, and Powershell might be Fish or Zsh. wsl.exe works the same way.

👇

Next: Why do the backslashes (\) in Windows appear as forward slashes (/) in WSL?

## The WSL filesystem

WSL has its own filesystem! If you do ls / inside WSL, you'll find /usr, /bin and the other usual suspects in a Linux filesystem. This is a full POSIX-compliant filesystem managed by WSL, away from the limitations of your Windows's NTFS.

💡 Try this: Go to your Linux's home directory with cd. Create two files with the same filename, but different case: touch xyz.txt XYZ.TXT. These two files can't co-exist in Windows's case-insensitive filesystem, can it? They will live happily inside WSL just fine.

In Linux terms: Think of WSL as a separate Linux system—a bit like a VirtualBox VM. It has its own filesystem, processes, /dev devices. Running wsl.exe will tunnel you into this Linux subsystem.

👇

Next: So is it a virtual machine?

## Linux in a box

Not only does WSL have its own filesystem, it's a full Linux system that runs as an app in Windows! It may be easy to think it's like VirtualBox, but it's not a VM.

Why is it not a VM? There's no CPU or hardware emulation involved like in a VM. A whole Linux system runs like any other app in Windows.

💡 Try this: Run htop inside WSL (you may need to install it first), and view it as a tree (shift-T). It has a whole process tree, even with an /init process! You'll see your machine's full CPU and memory capacity—it's not pre-allocated, unlike a VM. It shares these hardware resources just as any other Windows app would.

In Linux terms: On a typical system, Linux's entry point would be in /boot/vmlinuz-linux, which is fired by a bootloader like GRUB. Think of WSL as a version of this packaged as a wsl.exe file. The whole Linux subsystem will be running as a process inside Windows.

Note about WSL2: There are two versions of WSL. The new experimental version, WSL2, actually works as a Virtual Machine.

👇

Next: If WSL is a separate subsystem from your Windows environment, how do they share files?

## Windows files inside WSL

Your Windows files are visible inside WSL under /mnt/c.

💡 Try these: Here are some experiments you can try inside WSL:

Case insensitive files: In WSL, try cd /mnt/c/Windows and cd /mnt/c/WINDOWS. They'll both work! The Windows filesystem you're accessing in /mnt/c is case-insensitive.
Check mount points: Run findmnt. You'll see /mnt/c is mounted as drvfs, just as how you would mount a drive in Linux.
Two home directories: Look at /mnt/c/Users. You'll see you have 2 home directories: your WSL/Linux one in /home, and your Windows one in /mnt/c/Users.
Permissions won't work: Try to make a file in /mnt/c and run chmod to change its permissions. It won't work—the filesystem these files live on is NTFS, which doesn't support UNIX-style permissions.

findmnt will tell you where /mnt/c comes from.

👇

Next: We can see Windows files in WSL. Can we see WSL files in Windows?

## WSL files from Windows

WSL exposes your files as a network resource in \\wsl$. (The actual files live somewhere in C:\Windows, though it's not a good idea to use them directly.)

💡 Try this: Open Windows Explorer. In the location bar, type in \\wsl$\Ubuntu. This should get you access to the WSL filesystem as a network folder.

In Linux terms: \\wsl$\Ubuntu is called a UNC path, which is Windows's way of accessing network resources. Think of it like smb://wsl/Ubuntu.

## Running Windows apps in WSL

You can run Windows *.exe programs inside WSL. It will simply open them in Windows, just as you would have ran those programs from Windows itself.

💡 Try this: In WSL, type notepad.exe. In fact, you can even try running cmd.exe—this should get you a Windows command prompt! To see how this works, try which notepad.exe, which shows that it's simply running /mnt/c/WINDOWS/system32/notepad.exe.

user@desktop ~$ notepad.exe

In Linux terms: Linux can run ELF binaries (ie, Linux's native executable format). Once it finds a PE32+ binary (ie, Windows's format), it'll simply tell Windows to open it outside of WSL. Also, Windows's %PATH% carries over into Bash's $PATH, making the system .exe files available anywhere in WSL.

## Running WSL apps in Windows

Linux apps can be ran from Windows using wsl.exe, the WSL launcher. This starts up the WSL subsystem (if it hasn't been yet) and runs a command from within it.

Try this: Open a command prompt (Win+R to run cmd.exe), then type: wsl ls /

Microsoft Windows [Version 10.0.18985.1]
(c) 2019 Microsoft Corporation. All rights reserved.

C:\>wsl ls /
bin/   dev/  home/  lib/    lost+found/  mnt/  proc/  run/
boot/  etc/  init*  lib64/  media/       opt/  root/  sbin/
...

👇

Next: Can we replace conhost?

## Alternatives to _conhost_

You don't need to use conhost.exe to run CLI apps. You can run them in third party terminal emulators. There's wsltty (based on Cygwin's mintty), Terminus (an Electron-basde terminal), Conemu (supports tabs and panes), and a few more.

Any of these apps can run any CLI application. They often usually come with built-in shortcuts for cmd, Powershell, WSL, and possibly a few others.

In Linux terms: Just like XTerm has many alternatives, conhost has its own alternatives as well.

Windows Terminal is an alternative to conhost. It supports WSL, Powershell, cmd, and more.

👇

Next: Let's recap what we know so far.

## Recap

Ubuntu is a command-line app. It's installed from the Microsoft Store.
Windows provides wsl.exe that launches an installed Linux distribution (Ubuntu in this case). This is a command-line program that brings you to a Bash prompt. There's also bash.exe, which does the same thing (it's like an alias for "wsl.exe bash").
CLI apps: are ran inside conhost.exe, the built-in Windows terminal. There are alternatives to this that developers might like better.
Environments: cmd.exe, powershell.exe, and wsl.exe
WSL launcher: wsl.exe runs the WSL subsystem and drops you into a Bash prompt. It's just a CLI app.

What media query breakpoints should I use?

Rico Sta. Cruz — Mon, 12 Aug 2019 07:41:35 +0000

Responsive design calls for a lot of media queries. This is universally agreed upon, but should we write min-width or max-width? Should we use 768px or 780px? There's a lot of variance here, so I went to dig up to see if there's an established consensus on the topic.

@media (min-width: /* ??? */) {
}

What are we designing for?

Before we can figure out what media query breakpoints to use, we need to look at what devices we're designing for.

I've dug into some common device resolutions, and most can be grouped into categories. I've listed these categories, along with the resolutions they cater to:

Mobile portait (320px to 414px)
For devices with 4" to 6.9" screens.
Mobile landscape (568px to 812px)
Same, but landscape.
Tablet portait (768px to 834px)
For devices 7" to 10"
Tablet landscape (1024px to 1112px)
Ditto, but also 12" tablets on portrait
Laptop & desktop displays (1200px+)
Varies a lot, but is usually 1200px and above

Devices

Let's look at a few iOS devices. While Android devices are important too, they have a lot of variance—device DPI's are adjustable in most phones. Most Android phones ship with defaults that are comparable to iOS's anyway, so let's look at those.

Here's a list of some common devices, along with their device-independent pixel widths:

Category	Width	Device
Mobile, portrait	`320px`	iPhone SE
	`375px`	iPhone 6, 7, 8, X
	`414px`	iPhone 8 Plus
Mobile, landscape	`568px`	iPhone SE
	`667px`	iPhone 6, 7, 8
	`736px`	iPhone 8 Plus
	`812px`	iPhone X
Tablet, portrait	`768px`	iPad Air, iPad Mini, iPad Pro 9"
	`834px`	iPad Pro 10"
Tablet, landscape	`1024px`	iPad Air, iPad Mini, iPad Pro 9"
	`1024px`	iPad Pro 12" (portrait)
	`1112px`	iPad Pro 10"
Laptop displays	`1366px`	HD laptops (768p)
	`1366px`	iPad Pro 12" (landscape)
	`1440px`	13" MacBook Pro (2x scaling)
Desktop displays	`1680px`	13" MacBook Pro (1.5x scaling)
	`1920px`	1080p displays

The most common breakpoints

I took a look at some of the most popular CSS frameworks on 2019 (and some from the past) to see what breakpoints they use. Most of them use the same points, with a small bit of variance.

Framework	Small	Medium	Large	Exra large
Bulma	-	`min: 769px` ("mobile")	`min: 1024px` ("desktop")	`min: 1216px` ("fullhd")
Bootstrap 3	-	`min: 768px`	`min: 992px`	`min: 1200px`
Bootstrap 4	`min: 576px`	`min: 768px`	`min: 992px`	`min: 1200px`
Tailwind	`min: 576px`	`min: 768px`	`min: 992px`	`min: 1200px`
Zurb Foundation	-	`min: 640px`	`min: 1024px`	`min: 1200px`

768px, 992px, 1200px

Many frameworks use 768px, 992px and 1200px. This has been Bootstrap 3's default breakpoints, and seems to be considered sensible enough to have been adopted by other projects.

No small breakpoints?

Some opt not to have breakpoints below 700px. This is likely taken from Bootstrap 3, which advocated making the mobile landscape view the same as the portrait view. Bootstrap 4 has since changed their position on this, which I personally agree with—seeing tall headers on a landscape screen is pretty annoying!

Where did 576px come from?

Before Bootstrap 4 added the 576px breakpoint, 480px was a popular choice. 576px was eventually chosen since it was roughly halfway between 320px and 768px (+32px). I personally don't think choosing 576px over 480px is a big deal (or the other way around); either one should be enough to cover the 414px width of the iPhone 8 Plus. However, I prefer 480px since 576px still covers the iPhone SE landscape view.

640px

Zurb's 640px breakpoint is an interesting choice. It covers both tablet-portait and (most of) mobile-landscape.

So what should I use?

This is mostly subjective and may depend on what screens you would design for. I use this set of breakpoints as a starting point, and I can recommend them for most projects.

Breakpoint	Purpose
(default)	Mobile-portrait
min-width: `480px`	Mobile-landscape (and larger)
min-width: `768px`	Tablet-portrait (and larger)
min-width: `992px`	Tablet-landscape (and larger)
min-width: `1200px`	Laptops (and langer)

Avoid max-width

I prefer only using min-width and avoiding max-width as much as possible. Mixing min-width and max-width can make CSS code shorter, but much more difficult to read.

Offset your max-widths

If you must you max-width, be sure to offset it by at least 0.02px. That is, use max-width: 479.98px instead of max-width: 480px, since the latter will have a small overlap with min-width: 480px.

480px or 576px?

I suggest using 480px instead of 576px simply because it would cover smaller phones as well (eg, iPhone SE).

Should I use 768px?

The min-width: 768px might not be as useful as most would think. If you're designing for tablet-portrait, consider using min-width: 480px, it might look good on mobile-landscape as well. Zurb Foundation seems to promote this idea of co-designing for mobile-landscape + tablet-portait too, considering they use 640px as a breakpoint.

The mystery of 768px

The min-width: 768px breakpoint is often described in guides as "tablet landscape". This is misleading, because it also matches tablet-portrait mode as well. Use min-width: 992px if you need to target tablet-landscape. (You can also use 769px, but that won't cover iPad Pro 10".)

How should I name them?

I personally don't like calling things small, medium and large. These words can be ambiguous; does an iPad Pro 10" count as medium or large? Would the iPhone SE be counted as extra small? These words are relative, and their subjectiveness can cause some confusion.

I'm not a fan of calling them mobile, tablet and so on, either. The iPad Pro 12" is a tablet, but why can you only target it with a desktop media query? The Samsung Note is technically a phone, but why is it covered with tablet? Does tablet account for landscape or portrait? The lines between device classifications are a bit blurry nowadays.

Instead, I propose calling it with more generic names. Most designers are intimately familiar with "how 700px feels like", so I think that would make a more appropriate name. I like naming them by their closest hundredths like so.

@custom-media --viewport-4 (min-width: 480px);
@custom-media --viewport-7 (min-width: 768px);
@custom-media --viewport-9 (min-width: 992px);
@custom-media --viewport-12 (min-width: 1200px);

@media (--viewport-4) {
  /* ... */
}

Thank you!

I hope you'll find all these helpful. References:

DEV Community: Rico Sta. Cruz

Why I’m moving from Jest to Vitest

It has a UI!

ES modules, TypeScript and more

The API is Jest-compatible (mostly)

Jsdom is optional

No global pollution

Parallel tests work great

Thanks for reading!

Switching apps slows down my productivity (and how I fixed it)

Is switching apps really difficult?

My solution: fixed key bindings

MacOS via Raycast

MacOS via Hammerspoon

Windows via AutoHotkey

My shortcuts

Thanks for reading!

Public CDN's aren't useful anymore

Shared caches don’t work anymore

About public CDN’s

Other issues with public CDN's

Are public CDN’s still useful?

What do we do now?

Links

Guide: Netlify-to-Discord notifications

Solution: webhooks

Step 1: Create a webhook in Discord

Step 2: Site settings in Netlify

Step 3: Add a notification

Step 4: Choose Slack integration

Step 5: Add the URL

All done!

Faster multi-line jumps in VSCode-Vim

Solution: use j/k

Making it work with arrow keys

Windows Subsystem for Linux - explained by a Linux user

What media query breakpoints should I use?

What are we designing for?

Devices

The most common breakpoints

768px, 992px, 1200px

No small breakpoints?

Where did 576px come from?

640px

So what should I use?

Avoid max-width

Offset your max-widths

480px or 576px?

Should I use 768px?

The mystery of 768px

How should I name them?

Thank you!