DEV Community: Helmuth Saatkamp

Web Workers: The Unsung Heroes of Responsive Web Apps

Helmuth Saatkamp — Mon, 26 May 2025 05:56:57 +0000

Introduction

Have you ever faced a sluggish UI in your web app after heavy computation? Or maybe you've run into unresponsive interactions when processing large data sets? Welcome to the land of main thread bottlenecks. Luckily, JavaScript gives us a powerful tool to deal with that: Web Workers. In this article, we'll break down what Web Workers are, how they work, when to use them, and when to steer clear. We'll also finish with a neat, practical example you can plug right into your codebase.

Introduction
Table of Contents
What is a Web Worker?
How to Use It?
Abstracting Worker Creation
- Practical Examples
  - 1. Heavy Data Transformation
  - 2. Image Processing
  - 3. Offloading Search Indexing
  - 4. Using External Libraries
When to Use Web Workers
When to Avoid Web Workers
Conclusion

What is a Web Worker?

Web Workers are a way to run JavaScript in background threads. They allow you to offload heavy computations or non-UI blocking tasks, keeping your main thread (and UI) smooth and responsive. Think of it as spinning up a helper thread that works in parallel without freezing your app.

Web Workers:

Run in a separate global context (not blocking the main thread)
Don't have access to the DOM
Communicate via postMessage
Can import external scripts

How to Use It?

Here's the classic workflow:

Create a separate JavaScript file (the worker)
Use new Worker('worker.js') in your main code
Use postMessage to send data to the worker
Listen for results using onmessage

Example:

// worker.js
self.onmessage = function (e) {
  const result = e.data.num * 2;
  self.postMessage(result);
};

^{See code in action}

// main.js
const worker = new Worker('worker.js');
worker.postMessage({ num: 5 });
worker.onmessage = function (e) {
  console.log('Result from worker:', e.data); // 10
};

^{See code in action}

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1" />
  <title>Worker Demo</title>
</head>
<body>
<h1>Hello From a Web Worker!</h1>
<script type="module" src="main.js"></script>
</body>
</html>

^{See code in action}

As seen in the screenshot, when main.js is executed, it loads worker.js via the new Worker('worker.js') call. This triggers a GET request to worker.js (seen in the Network tab of DevTools). The response status 200 confirms the worker script was successfully fetched and executed, and the result (10) is logged in the console, showing communication between the main thread and the worker via postMessage and onmessage.

Abstracting Worker Creation

Creating and managing worker files can get repetitive, especially when you want to inject external libraries or isolate logic. Here's a flexible utility function to abstract worker creation dynamically:

/**
 * Creates a function that runs the provided callback in a web worker with specified dependencies.
 *
 * @example
 * const sum = worker(({ _ }) => (...args) => _.sum([...args]), ['https://cdn.jsdelivr.net/npm/lodash@4.17.21/lodash.min.js']);
 * await sum(1, 2); // 3
 *
 * @param callback - A function that receives the worker's `self` and performs work.
 * @param dependencies - Optional array of URLs to scripts that the worker should import.
 *
 * @returns A function that takes the arguments for the callback and returns a promise with the result.
 */
export function worker<T extends (...args: any) => any, R = Awaited<ReturnType<T>>>(
  callback: (self: any) => T,
  dependencies: string[] = [],
): (...args: Parameters<T>) => Promise<R> {
  const callbackString = callback.toString();
  const workerScript = `
    ${dependencies.map((dep) => `importScripts('${dep}');`).join('\n')}
    const callback = (${callbackString})(self);
    self.onmessage = async function(e) {
      try {
        const result = await callback(...e.data.args);
        self.postMessage({ success: true, result });
      } catch (error) {
        self.postMessage({ success: false, error: error?.message || String(error) });
      }
    };
  `;
  const blob = new Blob([workerScript], { type: 'application/javascript' });
  const workerUrl = URL.createObjectURL(blob);

  return (...args: Parameters<T>): Promise<R> =>
    new Promise((resolve, reject) => {
      const worker = new Worker(workerUrl);
      worker.onmessage = (e) => {
        if (e.data.success) resolve(e.data.result);
        else reject(new Error(e.data.error));
        worker.terminate();
        URL.revokeObjectURL(workerUrl);
      };
      worker.onerror = (err) => {
        reject(err);
        worker.terminate();
        URL.revokeObjectURL(workerUrl);
      };
      worker.postMessage({ args });
    });
}

^{See code in action}

Practical Examples

Here are several ways you can use this utility during development:

1. Heavy Data Transformation

const transform = worker(() => (data) => {
  return data.map((item) => ({ ...item, computed: item.value * 2 }));
});

await transform(largeDataset);

2. Image Processing

const grayscale = worker(() => (imageData: Uint8ClampedArray) => {
  for (let i = 0; i < imageData.length; i += 4) {
    const avg = (imageData[i] + imageData[i + 1] + imageData[i + 2]) / 3;
    imageData[i] = imageData[i + 1] = imageData[i + 2] = avg;
  }
  return imageData;
});

await grayscale(imageData);

3. Offloading Search Indexing

const buildIndex = worker(() => (docs) => {
  const index = new Map();
  for (const doc of docs) {
    for (const word of doc.content.split(/\s+/)) {
      if (!index.has(word)) index.set(word, []);
      index.get(word).push(doc.id);
    }
  }
  return Array.from(index.entries());
});

await buildIndex(documents);

4. Using External Libraries

const sum = worker(({ _ }) => (...args) => _.sum([...args]), [
  'https://cdn.jsdelivr.net/npm/lodash@4.17.21/lodash.min.js',
]);

await sum(5, 10, 15); // 30

This approach eliminates the need to manually manage worker files and allows you to dynamically define logic and dependencies. It's great for one-off computations, utility-heavy tasks (like using lodash), and keeping your UI snappy.

When to Use Web Workers

✅ When dealing with CPU-intensive operations:
- Image processing
- Data parsing (CSV/JSON/XML)
- Cryptography
- Heavy math (e.g., simulations, sorting large arrays)
✅ When maintaining UI responsiveness matters:
- Progressive loading
- Background pre-processing
- Search indexing

When to Avoid Web Workers

🚫 If the task is trivial or fast — the overhead isn't worth it.
🚫 If you need access to the DOM.
🚫 When the logic involves frequent main-thread interactions.
🚫 If you rely heavily on a shared state (workers are isolated).

Conclusion

Web Workers are an underused but incredibly powerful feature in the modern frontend toolbox. They shine when performance and responsiveness are a concern, and they’re especially useful in data-heavy or compute-heavy tasks. By abstracting away boilerplate with a reusable utility, you can tap into this power with minimal effort and maximum clarity.

Keep your main thread light, your UI responsive, and your code clean — happy multithreading! 🚀

GitHub Copilot in Frontend Development

Helmuth Saatkamp — Wed, 31 Jan 2024 09:06:06 +0000

In modern aviation, there are machines capable of flying themselves, but we don't trust them because we know it's not a question of "if" they fail, but "when" and "how". Therefore, by having a pilot and a copilot to operate it, we are provided with the guarantee of safety we need to use it.

When comparing an Airplane with Artificial Intelligence (AI), there are some similarities: A Machine capable of operating on its own that requires an external factor (a human) to provide the initial inputs and ensure things are working as expected.

Advanced AI has taken the world by storm. And, like Pandora's box, it's not something that can be undone, but learn from it and adapt. To benefit from this change, you first need to understand how it works and what this new tool is capable of. Below, you will find some insights and examples of how you can use an AI and fly with it during Frontend development.

Define a Context
Break Down the Problem
Define an Outcome
Prompt Examples
Conclusion

For this purpose, the examples are based on the GitHub Copilot Chat, but it should work similarly to any other AI tool.

1. Define a Context

For effective use of the AI, provide context, especially with a new project. Treat interactions as a conversation, breaking down the problem and discussing solutions, akin to pair programming. Start with a broad goal before diving into details.

For example, when building a calculator with Vue, you could write a comment like this.

/*
Create a calculator component with the following features:
- use Vue 3 composition API
- use TypeScript
- Show results as I type
- Support all basic math operations
*/

GitHub Copilot can quickly generate the base code for the new component.

2. Break Down the Problem

Communicate your main goal and the steps to achieve it. Breaking down the process helps it be understood better. Let it generate code after each step instead of all at once.

Continuing with the calculator example, you could now add the Numpad and their styles as a next step.

create a numpad with basic operators in html using tailwind, the buttons should be squared, rounded and with the gray color

3. Define an Outcome

Learning from examples benefits both humans and AI pair programmers. For example, we might want to extract names from an array and store them in a new array. By giving examples, we can help GitHub Copilot understand our intent.

/* 
Map through an array of objects
Example: Extract names from the data array
Desired outcome: ['Harry', 'James', 'Potter']
 */

4. Prompt Examples

Here are some prompt examples of how to interact with it and give you ideas to create your own.

As a rule of thumb: Always validates the content/code generated by an AI. It is not perfect and can generate things that do not make sense (Hallucinates) or do not work.

Prototyping

The AI code generation accelerates prototyping, allows quick design iterations, early problem detection, and boosts team collaboration.

Create a Method

Create a function that does something.

create a function to sort product by name

Create a Regex

Regex can be hard to write, but the AI can help you with that.

create a regex to validate email address

Convert X to Y

You can use the following example to convert a JSON object to Typescript, or even another language like Swift, C# or Python.

convert the following json to typescript and order properties alphabetically
{
  id: 1,
  name: 'John Doe',
  birthday: '1990-01-01',
  city: 'Berlin,
  country: 'Germany'
}

Or transform a value into something else. For example, convert a hex color to its equivalent RGBA.

equivalent rgba color for #ff0033

Code Refactoring

The AI can help you optimize your code by suggesting better ways to do things.

improve the function_name function

Or get some suggestions on how to refactor a method into smaller ones.

make the function_name function smaller by splitting it into smaller chunks

Debugging

The AI can identify software issues by scrutinizing code patterns, logs, or anomalies that could lead to bugs.

Explain a Method

explain the function_name function

Code Insight

Where is the error in the function dateRange when executing it with the following parameters: '2022-01-01', '2022-12-31', { interval: 'ME' }

Documentation

The AI can analyze code and related resources to automatically generate concise, contextual documentation for developers.

Document a Method

generate documentation for the function function_name

Testing

The AI can automate testing creation and help you quickly analyze code, identify potential vulnerabilities, and simulate various test scenarios.

Create Test

Create a unit test for a method.

create unit test for the function_name function

or for a component.

create unit test for the component_name.vue component

Add Test Cases

You can also add test cases to an existing test.

test function_name function against undefined, null, empty string or numbers.

Learning

The AI can help you learn new things by providing you with documentation and examples.

How To

You can ask for documentation on how to use a method, or even set a context such as I'm learning javascript and I'm going to ask questions about the language and its built-in methods, and then processed and type only Array.reduce().

how to use the Array.reduce() method in javascript

Is it also possible to clarify a topic.

What is the difference between "for of" and "for in" in javascript

4. Conclusion

AI tools like GitHub Copilot can significantly enhance the process of software development. By defining a context, breaking down the problem, defining an outcome, and using the correct prompts, developers can effectively communicate with the AI to improve their development experience. However, it's crucial to remember that AI is not infallible. Always validate the generated content and code to ensure it meets your requirements and expectations. As we continue to adapt and learn from these advanced AI tools, they will become an increasingly integral part of our development workflows, acting as a reliable copilot in our coding journey.

What are your thoughts on AI? How do you use it? Let us know in the comments below!

Automated Frontend Workflow

Helmuth Saatkamp — Fri, 16 Dec 2022 00:09:34 +0000

In a world where robots have not yet taken our place, we still have to deal with repetitive tasks. We are constantly trying to find the easiest and laziest way to accomplish something, some people call it efficiency. By letting the machine do the tedious part, it could give us more time to work or spend on interesting stuff.

An automated frontend workflow is a set of processes and tools that are used to manage and streamline the development of a website or application. This typically involves tasks such as code linting (e.g. Prettier, ESLint), building, testing (e.g. Jest), and deployment, and is designed to make it easier for developers to work on the front end without having to worry about these details. Automated frontend workflows can be created using a variety of tools, such as build tools (e.g. Webpack, Vite), and continuous integration platforms (e.g. Jenkins, GitHub Actions).

In short, automation for software development means reducing complexity to something that anyone could use and understand.

In this article, you will learn how to create, add and automate common frontend tools within your workflow.

If you are interested in learning about some of these tools you can check my other article about Testing in JavaScript

Project
1. Setup
2. Prettier
3. Sass
4. TypeScript
5. Vite
6. Vitest
7. VitePress
8. Storybook
9. ESLint
10. StyleLint
Git
1. Git setup
2. Git hooks
  1. Lefthook
GitHub Actions
1. Code Analysis
2. Linters
3. Testing
4. Branch Protection
5. Docs
Conclusion

Project

The goal is to build a modern monorepo project using the following stack:

Vue: An approachable, performant, and versatile framework for building web user interfaces.
Sass: CSS with superpowers.
TypeScript: A strongly typed programming language that builds on JavaScript.
Vite: Fast bundler to create web projects
Vitest: A Vite-native fast unit test framework.
VitePress: Modern SSG framework built on top of Vite.
Storybook: Storybook is a frontend workshop for building UI components and pages in isolation.
Prettier: An opinionated code formatter.
ESLint: Statically analyzes your code to quickly find problems.
Stylelint: A modern linter that helps you avoid errors and enforce conventions in your styles.

Most steps can be manually adjusted to your preferred JS library or framework, like React, Svelte or Angular. You can check the final result at the following link: https://github.com/helmuthdu/automated-frontend-workflow

Setup

To start, let's create a new project. Open the terminal, create a new folder and initialize the project.

mkdir automated-frontend-workflow
cd automated-frontend-workflow
npm init

After completion. Open the newly created package.json file and add the workspaces config to set it as a monorepo.

...
"workspaces": [
  "packages/*"
]

A monorepo is a single repository that contains multiple projects. The main reason for it is to streamline work within a dev team that maintains multiple apps using shared pieces of code, for example, a User Interface library.

Next, you have to install and configure the common tools which will be used during the development.

Prettier

Install Prettier:

npm i -D prettier

Create a .prettierrc file.

{
  "arrowParens": "avoid",
  "bracketSameLine": true,
  "bracketSpacing": true,
  "htmlWhitespaceSensitivity": "ignore",
  "printWidth": 120,
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "none",
  "useTabs": false,
  "vueIndentScriptAndStyle": false
}

You can find more information about these options in the official documentation.

Sass

Install Sass:

npm i -D sass

TypeScript

Install TypeScript:

npm i -D typescript

Create a tsconfig.json file.

{
  "compilerOptions": {
    "target": "ESNext",
    "useDefineForClassFields": true,
    "module": "ESNext",
    "moduleResolution": "Node",
    "strict": true,
    "jsx": "preserve",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "esModuleInterop": true,
    "lib": ["ESNext", "DOM"],
    "skipLibCheck": true,
    "noEmit": true,
    "types": ["vitest/globals"]
  },
  "ts-node": {
    "compilerOptions": {
      "module": "ESNext"
    }
  }
}

Vite

Install Vite:

npm i -D vite @vitejs/plugin-vue vue vue-tsc

Create a vite.config.ts file.

import { defineConfig } from 'vite';
import vue from '@vitejs/plugin-vue';

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [vue()]
});

Vitest

Install Vitest:

npm i -D vitest jsdom @vue/test-utils

Create a vitest.config.ts file.

/// <reference types="vitest" />

import { defineConfig } from 'vite';
import Vue from '@vitejs/plugin-vue';

export default defineConfig({
  plugins: [Vue()],
  test: {
    globals: true,
    environment: 'jsdom'
  }
});

Update the scripts in the package.json file by adding a new command:

"scripts": {
  ...
  "test": "vitest",
},

VitePress

Install VitePress:

npm i -D vitepress

Create a docs/.vitepress/config.ts file.

export default {
  title: 'Automated Frontend Workflow',
  description: 'Frontend Tooling made Easy',
  base: 'https://helmuthdu.github.io/automated-frontend-workflow/'
};

The base property should reflect your git project.

Create a docs/index.md file.

# Hello VitePress

[Go to Storybook](https://helmuthdu.github.io/automated-frontend-workflow/storybook)

Update the scripts in the package.json file by adding these new commands:

"scripts": {
  ...
  "docs:dev": "vitepress dev docs",
  "docs:build": "vitepress build docs",
  "docs:preview": "vitepress preview docs"
},

Storybook

Install Storybook:

npx sb init --builder @storybook/builder-vite

Open the .storybook/.main.js file and configure it as follows.

module.exports = {
  stories: ['../packages/**/*.stories.mdx', '../packages/**/*.stories.@(js|jsx|ts|tsx)'],
  addons: ['@storybook/addon-links', '@storybook/addon-essentials', '@storybook/addon-interactions'],
  framework: '@storybook/vue3',
  core: {
    builder: '@storybook/builder-vite'
  },
  features: {
    storyStoreV7: true
  },
  async viteFinal(config, options) {
    config.base = './';
    return config;
  },
  env: config => ({
    ...config,
    STORYBOOK_BASE_URL:
      process.env.NODE_ENV === 'production' ? 'https://helmuthdu.github.io/automated-frontend-workflow/storybook/' : ''
  })
};

The STORYBOOK_BASE_URL property should reflect your git project.

Create a .storybook/manager-head.html file.

<!-- .storybook/manager-head.html -->
<base href="%STORYBOOK_BASE_URL%" target="_blank" />
<meta name="description" content="Components for my awesome project" key="desc" />

Update the package.json file to output the build result to the docs/public/storybook folder, this will be important to deploy our docs and the storybook on the same GitHub page.

"scripts": {
   ...
   "storybook": "start-storybook -p 6006",
   "storybook:build": "build-storybook -o docs/public/storybook"
},

ESLint

Install ESLint with Prettier, TypeScript and Vue support, and add a package to output the result as sarif format which will be used later for the GitHub integration.

npm i -D eslint @typescript-eslint/eslint-plugin @typescript-eslint/parser @microsoft/eslint-formatter-sarif eslint-config-prettier eslint-plugin-prettier eslint-plugin-vue vue-eslint-parser @vue/eslint-config-typescript

Create a .eslintrc.cjs file.

module.exports = {
  root: true,
  env: {
    browser: true,
    es2021: true,
    node: true
  },
  parser: '@typescript-eslint/parser',
  parserOptions: {
    parser: '@typescript-eslint/parser',
    ecmaVersion: 2021
  },
  plugins: ['@typescript-eslint', 'prettier'],
  extends: [
    'eslint:recommended',
    'plugin:@typescript-eslint/recommended',
    'plugin:prettier/recommended',
    'plugin:storybook/recommended'
  ],
  rules: {
    'no-console': process.env.NODE_ENV === 'production' ? 'warn' : 'off',
    'no-debugger': process.env.NODE_ENV === 'production' ? 'warn' : 'off',
    '@typescript-eslint/no-unused-vars': [
      'off',
      {
        argsIgnorePattern: '^_'
      }
    ],
    'prettier/prettier': 'error'
  },
  overrides: [
    {
      files: ['*.ts', '*.tsx'],
      rules: {
        // The core 'no-unused-vars' rules (in the eslint:recommeded ruleset)
        // does not work with type definitions
        'no-unused-vars': 'off'
      }
    },
    {
      files: ['**/__tests__/*.{j,t}s?(x)', 'packages/**/src/**/*.spec.{j,t}s?(x)'],
      env: {
        jest: true
      }
    },
    {
      files: ['packages/**/src/**/*.vue'],
      parser: 'vue-eslint-parser',
      parserOptions: {
        extraFileExtensions: ['.vue'],
        ecmaFeatures: {
          jsx: true
        },
        ecmaVersion: 2021
      },
      extends: ['plugin:vue/vue3-recommended', '@vue/typescript/recommended', 'plugin:prettier/recommended']
    }
  ]
};

Update the scripts in the package.json file by adding these new commands:

"scripts": {
  ...
  "lint": "npm run lint -ws",
  "lint:report": "eslint --ext .jsx,.js,.ts,.tsx,.vue --fix --format @microsoft/eslint-formatter-sarif --output-file eslint-results.sarif packages/**/src",
},

Stylelint

Install Stylelint along with the standard configs, Prettier, Sass, and Vue support.

npm i -D postcss postcss-html stylelint stylelint-config-prettier stylelint-config-recommended-vue stylelint-config-standard-scss

Create a .stylelintrc file extending these configs. It is included an optional rule to check if the CSS selector follows the BEM Name Convention.

{
  "extends": ["stylelint-config-standard-scss", "stylelint-config-recommended-vue/scss", "stylelint-config-prettier"],
  "rules": {
    "selector-class-pattern": [
      "^.([a-z0-9-]+)?(__([a-z0-9]+-?)+)?(--([a-z0-9]+-?)+){0,2}$",
      { "resolveNestedSelectors": true }
    ]
  }
}

Git

Git is a distributed version control system for tracking changes in files and can be used for collaboratively developing source code during software development.

Git setup

Create a new repository in GitHub, open the terminal inside the project, initialize git, add a commit and a remote, then push the changes.

git init
git add README.md
git commit -m "feat: project setup"
git branch -M main
git remote add origin https://github.com/$GITHUB_USER/$REPO_NAME.git
git push -u origin main

Replace the $GITHUB_USER and the $REPO_NAME variables with your GitHub user and repository name.

Git hooks

Git has a way to fire off custom scripts when certain actions occur, such as commit and push. There is a variety of hooks available, but you can start with these:

commit-msg: Check the commit message format or spelling errors.
pre-commit: Check for errors and enforce project coding standards.
pre-push: Run tests to ensure working software

You can create them manually, or use Lefthook to simplify the process.

Lefthook

Lefthook is a fast and powerful Git hooks manager for Node.js and any other type of project written in Go.

To install, open the terminal in your project:

npm install -D lefthook

After installation, it will generate a lefthook.yml file which can be customized to perform a static code analysis before committing the code. For example, it can ensure that the git commit follows the git-conventional-commits, and use Prettier, ESLint, and Stylelint to check, format, and fix any file which will be committed and run any test related with Vitest depending on the filetype and run each in parallel.

For .html, .json, and .yml files, reformat with Prettier
For .css and .scss files, check the styles with Stylelint and Prettier after.
For .js and .ts files, excluding tests, run ESLint and check related tests with Vitest after.
For .spec.js and .spec.ts tests files, run ESLint, and the tests with Vitest after.

To start, initialize the git-conventional-commits by running the npx git-conventional-commits init command, and then update the lefthook.yml as follows:

commit-msg:
  commands:
    validate:
      run: >
        npx git-conventional-commits commit-msg-hook {1}

pre-commit:
  parallel: true
  commands:
    lint:misc:
      glob: '*.{html,json,yml}'
      run: npx prettier --write {staged_files}
    lint:css:
      glob: '*.{css,scss}'
      run: >
        npx stylelint --fix {staged_files} &&
        npx prettier --write {staged_files}
    lint:js:
      glob: '*[!.{spec,test}].{[tj]s,[tj]sx}'
      run: >
        npx eslint --fix {staged_files} && 
        npx vitest related {staged_files} --passWithNoTests --run --environment jsdom
    test:unit:
      glob: '*.{spec,test}.{[tj]s,[tj]sx}'
      run: >
        npx eslint --fix {staged_files} &&
        npx vitest {staged_files} --run --environment jsdom

That's it, now every time you commit your code these commands will run automatically

GitHub Actions

GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. You can create workflows that build and test every pull request to your repository, or deploy merged pull requests to production.

The GitHub Actions workflows are located in the .github/workflows folder and are composed of:

Workflow: A workflow is a configurable-automated process that will run one or more jobs.
Events: An event is a specific activity in a repository that triggers a workflow run.
Jobs: A job is a set of steps in a workflow that executes on the same runner. Each step is either a shell script that will be executed or an action that will be run.
Runners: A runner is a server that runs your workflows when they're triggered. Each runner can run a single job at a time.
Actions: An action is a custom application for the GitHub Actions platform that performs a complex but frequently repeated task.

Do not worry, you will understand better those processes with the examples below showing common cases.

Code Analysis

To ensure code quality, the code should be checked, tested, and reported.

Start by creating a new file in your GitHub repository called .github/workflows/code-analysis.yml. This file will define the workflow that your GitHub Action will follow.
In the .github/workflows/code-analysis.yml file, you can use the on keyword to specify when the workflow should be triggered. For example, you might want to trigger the workflow when a new code is pushed to the repository with the option to trigger it manually. You can do this by adding the following lines to the file:

   on:
     push:
       branches:
         - 'main'
     # set this property to enable manual trigger option in GitHub
     workflow_dispatch:

You can set the concurrency property to run only one instance, so if it is running while a new commit is pushed it will be canceled and restarted. You can use the contexts to define a proper key.

   # github.workflow context to determine the current workflow name
   # github.ref context to determine the current branch name
   concurrency:
     group: ${{ github.workflow }}-${{ github.ref }}
     cancel-in-progress: true

Furthermore, it is required to set some permissions to read and write content. You can check all available permissions by clicking here.

   permissions:
     # required for all workflows
     security-events: write
     # only required for workflows in private repositories
     actions: read
     contents: read

Actions can be cached to accelerate the process. For example, in the Node.js setup action, it is possible to cache the NPM packages, so it won't have to fetch everything every time the job is running.

   - name: Setup Node.js
     uses: actions/setup-node@v3
     with:
       node-version: 16
       cache: 'npm'

To complete, in the job section, specify the steps that the GitHub Action should perform. For example, you might want to first check out the code from the repository, generate a code analysis report and upload it to GitHub:

   # code-scanning.yml
   name: Code scanning

   on:
     push:
       branches:
         - 'main'
     workflow_dispatch:

   concurrency:
     group: ${{ github.workflow }}-${{ github.ref }}
     cancel-in-progress: true

   jobs:
     eslint:
       name: Eslint
       runs-on: ubuntu-latest
       permissions:
         # required for all workflows
         security-events: write
         # only required for workflows in private repositories
         actions: read
         contents: read
       steps:
         - name: Checkout Repository
           uses: actions/checkout@v3

         - name: Setup Node.js
           uses: actions/setup-node@v3
           with:
             node-version: 16
             cache: 'npm'

         - name: Install dependencies
           run: npm ci

         - name: Run linter
           run: npm run lint:report
           continue-on-error: true

         - name: Upload analysis results to GitHub
           uses: github/codeql-action/upload-sarif@v2
           with:
             sarif_file: eslint-results.sarif
             wait-for-processing: true

After creating the workflow, you can go to your GitHub repo and run it manually to check the results. You can trigger this action by clicking in the Actions Tab -> Code scanning Workflow -> Run workflow Dropdown -> Run workflow Button.

To see the result, go to the Security -> Code scanning section.

The missing part is that these checks should also run on any code which will be submitted through a PR in the project and block any change which does not follow the required rules.

Linters

Linters, in short, are tools to help you improve your code. It can be configured to run on every Pull Request (PR) to guarantee that any new code has the same standards defined.

Similar to the previous workflow, start by creating a new file in your GitHub repository called .github/workflows/linter.yml.
In the on keyword, set it to run on pull_request.

   on: [pull_request]

Configure the concurrency to have only one workflow running at a time.

   # github.workflow context to determine the current workflow name
   # github.ref context to determine the current branch name
   concurrency: ${{ github.workflow }}-${{ github.ref }}

Define the Runner. Usually, the ubuntu-latest runner is a safe choice.

   jobs:
     eslint:
       runs-on: ubuntu-latest

Additionally, add all steps to perform a checkout action to fetch the code, do another action to setup-node with the node-version 16 with the cache enabled for all npm packages, install all dependencies with npm ci command and finally run the linters with npm run linter command

# linter.yml
name: Linter

on: [pull_request]

# github.workflow context to determine the current workflow name
# github.ref context to determine the current branch name
concurrency: ${{ github.workflow }}-${{ github.ref }}

jobs:
  eslint:
    name: Eslint
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v3

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 16
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run linter
        run: npm run lint

Testing

It should run similarly to the Linters workflow but executing the npm run test command instead.

# testing.yml
name: Testing

on: [pull_request]

# github.workflow context to determine the current workflow name
# github.ref context to determine the current branch name
concurrency: ${{ github.workflow }}-${{ github.ref }}

jobs:
  vitest:
    name: Vitest
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v3

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 16
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm run test

Branch Protection

Adding the workflows is just one step, you also need to configure the branch rules. Open your repository in GitHub and go to Settings -> Branches.

Click in the Add rule button, insert the repo name your want this rule to be associated with at the beginning, and make sure the workflows are set as required in the Require branches to be up to date before merging option.

To complete, click on the Create button at the bottom of the page.

Docs

For the documentation, we have a scenario where there is VitePress and Storybook need to publish together. Before creating the workflow, enable the pages in the repo settings.

Similar to the previous workflow, start by creating a new file in your GitHub repository called .github/workflows/docs.yml.
In the on keyword, set it to run on push to the main branch, also add the option to trigger it manually with workflow_dispatch.

   on:
     # Runs on pushes targeting the default branch
     push:
       branches:
         - 'main'
     # Allows you to run this workflow manually from the Actions tab
     workflow_dispatch:

Define the Runner to the ubuntu-latest.

   jobs:
     eslint:
       runs-on: ubuntu-latest

Add all actions to perform a checkout to fetch the code, do another action to setup-node, install all dependencies with the npm ci command, build storybook with the target to the public folder inside the docs, so when VitePress runs the build command it will copy the storybook files together and after everything is built trigger an action to setup GitHub Pages and update generated page artifact.
To complete, add another job, grant the permissions to write, and call the deployment action.

# docs.yml
name: Docs

on:
  # Runs on pushes targeting the default branch
  push:
    branches:
      - 'main'
  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

jobs:
  build:
    name: Build
    # Specify runner + deployment step
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v3

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 16
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Build Storybook
        run: npm run storybook:build

      - name: Build VitePress
        run: npm run docs:build

      - name: Setup pages
        uses: actions/configure-pages@v2

      - name: Upload artifact
        uses: actions/upload-pages-artifact@v1
        with:
          path: 'docs/.vitepress/dist'

  deploy:
    name: Deploy
    # Add a dependency to the build job
    needs: build
    # Specify runner + deployment step
    runs-on: ubuntu-latest
    # Grant GITHUB_TOKEN the permissions required to make a Pages deployment
    permissions:
      pages: write # to deploy to Pages
      id-token: write # to verify the deployment originates from an appropriate source
    # Deploy to the github-pages environment
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v1

Conclusion

The tooling used as part of the frontend development process ensures everything is working or is done as expected, and automation is designed to make it easier for developers to work without having to worry about these details.

This is just the tip of the iceberg, to learn more, check the GitHub Actions documentation and take a look at some starter workflows.

Use Tailwind Without Tailwind

Helmuth Saatkamp — Tue, 23 Aug 2022 14:38:00 +0000

Tailwind is one of those very controversial things, some people argue that it is the best since sliced bread, others it is a tool sent by the devil itself. Nonetheless, this is not an article about if you should use it or not, there are already plenty of those articles about the pros and cons on the internet.

What makes Tailwind good is the documentation, you may not agree on the “naming” but for every class that you can use there is an equivalent showing how to use it with CSS, for that, the team has done an outstanding job.

Tailwind is super fun to work with after you pass the initial learning threshold, but as a Developer, you still need to understand CSS to use it correctly.

CSS is not hard nor is broken.

In the end, it is just a tool to help you to write CSS, and as a tool, it limits the options of what you could do, for example, you would never be able to use a custom grid layout with Tailwind only, as the one below:

Mobile	Desktop

^{Source: https://webkit.org/demos/css-grid/}

In this article, you will learn how to use Tailwind documentation to write your CSS styles. The following topics will be discussed:

Preflight
Theme
Styles

The idea is to have the full power to write your CSS together with the cool ideas and patterns created by the Tailwind team. So let's get started.

Preflight

Preflight is a set of base styles for Tailwind projects that are designed to smooth over cross-browser inconsistencies and make it easier for you to work within the constraints of your design system.

Here you have basically to copy the preflight.css created by them.

/* preflight.css */
*,
::before,
::after {
  box-sizing: border-box;
  border-width: 0;
  border-style: solid;
  border-color: currentcolor;
}

html {
  line-height: 1.5;
  text-size-adjust: 100%;
  tab-size: 4;
  font-family: system-ui;
}

body {
  margin: 0;
  line-height: inherit;
}

hr {
  height: 0;
  color: inherit;
  border-top-width: 1px;
}

abbr:where([title]) {
  text-decoration: underline dotted;
}

h1,
h2,
h3,
h4,
h5,
h6 {
  font-size: inherit;
  font-weight: inherit;
}

a {
  color: inherit;
  text-decoration: inherit;
}

b,
strong {
  font-weight: bolder;
}

code,
kbd,
samp,
pre {
  font-family:
    "fontFamily.mono",
    ui-monospace,
    SFMono-Regular,
    Menlo,
    Monaco,
    Consolas,
    "Liberation Mono",
    "Courier New",
    monospace;
  font-size: 1em;
}

small {
  font-size: 80%;
}

sub,
sup {
  font-size: 75%;
  line-height: 0;
  position: relative;
  vertical-align: baseline;
}

sub {
  bottom: -0.25em;
}

sup {
  top: -0.5em;
}

table {
  text-indent: 0;
  border-color: inherit;
  border-collapse: collapse;
}

button,
input,
optgroup,
select,
textarea {
  font-family: inherit;
  font-size: 100%;
  font-weight: inherit;
  line-height: inherit;
  color: inherit;
  margin: 0;
  padding: 0;
}

button,
select {
  text-transform: none;
}

button,
[type="button"],
[type="reset"],
[type="submit"] {
  appearance: button;
  background-color: transparent;
  background-image: none;
}

:-moz-focusring {
  outline: auto;
}

:-moz-ui-invalid {
  box-shadow: none;
}

progress {
  vertical-align: baseline;
}

::-webkit-inner-spin-button,
::-webkit-outer-spin-button {
  height: auto;
}

[type="search"] {
  appearance: textfield;
  outline-offset: -2px;
}

::-webkit-search-decoration {
  appearance: none;
}

::-webkit-file-upload-button {
  appearance: button;
  font: inherit;
}

summary {
  display: list-item;
}

blockquote,
dl,
dd,
h1,
h2,
h3,
h4,
h5,
h6,
hr,
figure,
p,
pre {
  margin: 0;
}

fieldset {
  margin: 0;
  padding: 0;
}

legend {
  padding: 0;
}

ol,
ul,
menu {
  list-style: none;
  margin: 0;
  padding: 0;
}

textarea {
  resize: vertical;
}

input::placeholder,
textarea::placeholder {
  opacity: 1;
  color: #9ca3af;
}

button,
[role="button"] {
  cursor: pointer;
}

:disabled {
  cursor: default;
}

img,
svg,
video,
canvas,
audio,
iframe,
embed,
object {
  display: block;
  vertical-align: middle;
}

img,
video {
  max-width: 100%;
  height: auto;
}

That's it, just add this CSS to your project.

Theme

The theme file is where you define your project’s color palette, type scale, fonts, breakpoints, border radius values, and more.

This is the most important part, getting the same idea of the tailwind.config.js file where you can customize your theme, create a theme file following the Tailwind definitions:

/* theme.css */
:root {
  --size-0-5: 0.125rem; /* spacing:0.5 */
  --size-1: 0.25rem; /* spacing:1 */
  --size-1-5: 0.375rem; /* spacing:1.5 */
  --size-2: 0.5rem; /* spacing:2 */
  --size-2-5: 0.625rem;
  --size-3: 0.75rem;
  --size-3-5: 0.875rem;
  --size-4: 1rem;
  --size-5: 1.25rem;
  --size-6: 1.5rem;
  --size-7: 1.75rem;
  --size-8: 2rem;
  --size-9: 2.25rem;
  --size-10: 2.5rem;
  --size-11: 2.75rem;
  --size-12: 3rem;
  --size-14: 3.5rem;
  --size-16: 4rem;
  --size-20: 5rem;
  --size-24: 6rem;
  --size-28: 7rem;
  --size-32: 8rem;
  --size-36: 9rem;
  --size-40: 10rem;
  --size-44: 11rem;
  --size-48: 12rem;
  --size-52: 13rem;
  --size-56: 14rem;
  --size-60: 15rem;
  --size-64: 16rem;
  --size-72: 18rem;
  --size-80: 20rem;
  --size-96: 24rem;
  --size-xs: 20rem; /* 320px */
  --size-sm: 24rem; /* 384px */
  --size-md: 28rem; /* 448px */
  --size-lg: 32rem; /* 512px */
  --size-xl: 36rem; /* 576px */
  --size-2xl: 42rem; /* 672px */
  --size-3xl: 48rem; /* 768px */
  --size-4xl: 56rem; /* 896px */
  --size-5xl: 64rem; /* 1024px */
  --size-6xl: 72rem; /* 1152px */
  --size-7xl: 80rem; /* 1280px */
  --size-full: 100%;
  --size-fit: fit-content;
  --size-min: min-content;
  --size-max: max-content;
  --size-auto: auto;
  --size-none: none;
  --size-prose: 65ch;
  --size-screen-width: 100vw;
  --size-screen-height: 100vh;
  --size-screen-xs: 480px;
  --size-screen-sm: 640px;
  --size-screen-md: 768px;
  --size-screen-lg: 1024px;
  --size-screen-xl: 1280px;
  --size-screen-2xl: 1536px;
  --grid-1: repeat(1, minmax(0, 1fr));
  --grid-2: repeat(2, minmax(0, 1fr));
  --grid-3: repeat(3, minmax(0, 1fr));
  --grid-4: repeat(4, minmax(0, 1fr));
  --grid-5: repeat(5, minmax(0, 1fr));
  --grid-6: repeat(6, minmax(0, 1fr));
  --grid-7: repeat(7, minmax(0, 1fr));
  --grid-8: repeat(8, minmax(0, 1fr));
  --grid-9: repeat(9, minmax(0, 1fr));
  --grid-10: repeat(10, minmax(0, 1fr));
  --grid-11: repeat(11, minmax(0, 1fr));
  --grid-12: repeat(12, minmax(0, 1fr));
  --border: 1px;
  --border-0: 0;
  --border-2: 2px;
  --border-4: 4px;
  --border-8: 8px;
  --ring: 0 0 0 var(--border);
  --ring-2: 0 0 0 var(--border-2);
  --ring-4: 0 0 0 var(--border-4);
  --ring-8: 0 0 0 var(--border-8);
  --rounded: 0.25rem;
  --rounded-sm: 0.125rem;
  --rounded-md: 0.375rem;
  --rounded-lg: 0.5rem;
  --rounded-xl: 0.75rem;
  --rounded-2xl: 1rem;
  --rounded-3xl: 1.5rem;
  --rounded-full: 9999px;
  --shadow: 0 1px 3px 0 rgb(0 0 0 / 10%), 0 1px 2px -1px rgb(0 0 0 / 10%);
  --shadow-sm: 0 1px 2px 0 rgb(0 0 0 / 5%);
  --shadow-md: 0 4px 6px -1px rgb(0 0 0 / 10%), 0 2px 4px -2px rgb(0 0 0 / 10%);
  --shadow-lg: 0 10px 15px -3px rgb(0 0 0 / 10%), 0 4px 6px -4px rgb(0 0 0 / 10%);
  --shadow-xl: 0 20px 25px -5px rgb(0 0 0 / 10%), 0 8px 10px -6px rgb(0 0 0 / 10%);
  --shadow-2xl: 0 25px 50px -12px rgb(0 0 0 / 25%);
  --shadow-inner: inset 0 2px 4px 0 rgb(0 0 0 / 5%);
  --font-weight-thin: 100;
  --font-weight-extralight: 200;
  --font-weight-light: 300;
  --font-weight-normal: 400;
  --font-weight-medium: 500;
  --font-weight-semibold: 600;
  --font-weight-bold: 700;
  --font-weight-extrabold: 800;
  --font-weight-black: 900;
  --line-spacing-xs: 1rem;
  --line-spacing-sm: 1.25rem;
  --line-spacing-md: 1.5rem;
  --line-spacing-lg: 1.75rem;
  --line-spacing-xl: 1.75rem;
  --line-spacing-2xl: 2rem;
  --line-spacing-3xl: 2.25rem;
  --line-spacing-4xl: 2.5rem;
  --line-spacing-5xl: 1;
  --line-spacing-6xl: 1;
  --line-spacing-7xl: 1;
  --line-spacing-8xl: 1;
  --line-spacing-9xl: 1;
  --text-xs: 0.75rem;
  --text-sm: 0.875rem;
  --text-md: 1rem;
  --text-lg: 1.125rem;
  --text-xl: 1.25rem;
  --text-2xl: 1.5rem;
  --text-3xl: 1.875rem;
  --text-4xl: 2.25rem;
  --text-5xl: 3rem;
  --text-6xl: 3.75rem;
  --text-7xl: 4.5rem;
  --text-8xl: 6rem;
  --text-9xl: 8rem;
  --color-canvas: #f9fafb; /* gray:50 */
  --color-contrast: #27272a; /* zinc:800 */
  --color-contrast-50: #fafafa; /* zinc:50 */
  --color-contrast-100: #f4f4f5; /* zinc:100 */
  --color-contrast-200: #e4e4e7; /* zinc:200 */
  --color-contrast-300: #d4d4d8; /* zinc:300 */
  --color-contrast-400: #a1a1aa; /* zinc:400 */
  --color-contrast-500: #71717a; /* zinc:500 */
  --color-contrast-600: #52525b; /* zinc:600 */
  --color-contrast-700: #3f3f46; /* zinc:700 */
  --color-contrast-800: #27272a; /* zinc:800 */
  --color-contrast-900: #18181b; /* zinc:900 */
  --color-primary-backdrop: #bfdbfe; /* blue:200 */
  --color-primary-focus: #93c5fd; /* blue:300 */
  --color-primary: #2563eb; /* blue:600 */
  --color-primary-content: #1e40af; /* blue:800 */
  --color-primary-contrast: #fff;
  --color-error-backdrop: #fecdd3; /* rose:200 */
  --color-error-focus: #fda4af; /* rose:300 */
  --color-error: #f43f5e; /* rose:600 */
  --color-error-content: #9f1239; /* rose:800 */
  --color-error-contrast: #fff;
  --color-success-backdrop: #bbf7d0; /* green:200 */
  --color-success-focus: #86efac; /* green:300 */
  --color-success: #22c55e; /* green:600 */
  --color-success-content: #166534; /* green:800 */
  --color-success-contrast: #fff;
  --color-content-heading: #111827; /* gray:900 */
  --color-content-body: #1f2937; /* gray:800 */
  --color-content-secondary: #374151; /* gray:700 */
  --color-content-tertiary: #6b7280; /* gray:500 */
  --color-content-disabled: #9ca3af; /* gray:400 */
  --color-content-contrast: #d1d5db; /* gray:300 */
}

@media (prefers-color-scheme: dark) {
  :root {
    --color-canvas: #27272a; /* zinc:800 */
    --color-contrast: #fff;
    --color-contrast-50: #18181b; /* zinc:900 */
    --color-contrast-100: #27272a; /* zinc:800 */
    --color-contrast-200: #3f3f46; /* zinc:700 */
    --color-contrast-300: #52525b; /* zinc:600 */
    --color-contrast-400: #71717a; /* zinc:500 */
    --color-contrast-500: #a1a1aa; /* zinc:400 */
    --color-contrast-600: #d4d4d8; /* zinc:300 */
    --color-contrast-700: #e4e4e7; /* zinc:200 */
    --color-contrast-800: #f4f4f5; /* zinc:100 */
    --color-contrast-900: #fafafa; /* zinc:50 */
    --color-primary-backdrop: #93c5fd; /* blue:300 */
    --color-primary-focus: #3b82f6; /* blue:500 */
    --color-primary: #2563eb; /* blue:600 */
    --color-primary-content: #1e40af; /* blue:800 */
    --color-primary-contrast: #fff;
    --color-error-backdrop: #fda4af; /* rose:300 */
    --color-error-focus: #f43f5e; /* rose:500 */
    --color-error: #e11d48; /* rose:600 */
    --color-error-content: #9f1239; /* rose:800 */
    --color-error-contrast: #fff;
    --color-success-backdrop: #86efac; /* green:300 */
    --color-success-focus: #22c55e; /* green:500 */
    --color-success: #16a34a; /* green:500 */
    --color-success-content: #166534; /* green:800 */
    --color-success-contrast: #fff;
    --color-content-heading: #f9fafb; /* gray:50 */
    --color-content-body: #e5e7eb; /* gray:200 */
    --color-content-secondary: #d1d5db; /* gray:300 */
    --color-content-tertiary: #6b7280; /* gray:500 */
    --color-content-disabled: #4b5563; /* gray:600 */
    --color-content-contrast: #374151; /* gray:700 */
  }
}

@custom-media --xs (min-width: var(--size-screen-xs));
@custom-media --sm (min-width: var(--size-screen-sm));
@custom-media --md (min-width: var(--size-screen-md));
@custom-media --lg (min-width: var(--size-screen-lg));
@custom-media --xl (min-width: var(--size-screen-xl));
@custom-media --xxl (min-width: var(--size-screen-2xl));

To use those variables, you can declare as follows:

.example {
  padding: var(--size-3); /* p-3 */
  border-radius: var(--rounded-lg); /* rounded-lg */
  box-shadow: var(--shadow-lg); /* shadow-lg */
  font-size: var(--text-sm); /* text-sm */
  line-height: var(--line-spacing-sm); /* text-sm */
}

You can define your CSS variables to have the same values defined in the Tailwind, so you can get through their docs and use their style. But you wouldn't need to define a variable for every single class, some classes like inline-flex can be directly translated to display: inline-flex.

The good thing is that is one dependency less in your project, no matter how fast the tailwind (re)builds the CSS it will never the faster than having it directly declared, and the main point is that gives to the developer the full control. The downside is that you lose their syntax sugar.

Styles

Taking what you learned and applying it to a real-world scenario: Imagine you are building a UI Library. You start to build a badge component. This component should have options to change the size, color, and format, so you can create the following style:

/* badge.css */
.badge {
  display: inline-flex;
  flex-wrap: wrap;
  align-items: center;
  justify-content: center;
  white-space: nowrap;
  padding: var(--size-1) var(--size-2);
  text-align: center;
  vertical-align: middle;
  font-size: var(--badge-font-size, var(--text-md));
  line-height: var(--badge-line-height, var(--line-spacing-md));
  font-weight: var(--font-weight-semibold);
  border: var(--badge-border, var(--border) solid var(--color-contrast-200));
  border-radius: var(--badge-border-radius, var(--rounded-lg));
  background-color: var(--badge-background-color, var(--color-contrast-50));
  color: var(--badge-color, var(--color-content-body));

  &.is-pill {
    --badge-border-radius: var(--rounded-full);
  }

  &.is-xs {
    --badge-font-size: var(--text-xs);
    --badge-line-height: var(--line-spacing-xs);
  }

  &.is-sm {
    --badge-font-size: var(--text-sm);
    --badge-line-height: var(--line-spacing-sm);
  }

  &.is-lg {
    --badge-font-size: var(--text-lg);
    --badge-line-height: var(--line-spacing-lg);
  }

  &.is-xl {
    --badge-font-size: var(--text-xl);
    --badge-line-height: var(--line-spacing-xl);
  }

  &.is-info {
    --badge-border: var(--border) solid var(--color-primary-focus);
    --badge-background-color: var(--color-primary);
    --badge-color: var(--color-primary-contrast);
  }

  &.is-error {
    --badge-border: var(--border) solid var(--color-error-focus);
    --badge-background-color: var(--color-error);
    --badge-color: var(--color-error-contrast);
  }

  &.is-success {
    --badge-border: var(--border) solid var(--color-success-focus);
    --badge-background-color: var(--color-success);
    --badge-color: var(--color-success-contrast);
  }

  &.is-contrast {
    --badge-border: var(--border) solid var(--color-contrast-800);
    --badge-background-color: var(--color-contrast-700);
    --badge-color: var(--color-content-contrast);
  }
}

Selector	Description
:host/:host(name)	Selects the shadow host element or if it has a certain class.
:host-context(name)	Selects the shadow host element only if the selector given as the function's parameter matches the shadow host's ancestor(s) in the place it sits inside the DOM hierarchy.
::slotted()	Selects a slotted element if it matches the selector.
::part()	Selects any element within a shadow tree with a matching part attribute.

DEV Community: Helmuth Saatkamp

Web Workers: The Unsung Heroes of Responsive Web Apps

Introduction

Table of Contents

What is a Web Worker?

How to Use It?

Abstracting Worker Creation

Practical Examples

1. Heavy Data Transformation

2. Image Processing

3. Offloading Search Indexing

4. Using External Libraries

When to Use Web Workers

When to Avoid Web Workers

Conclusion

GitHub Copilot in Frontend Development

1. Define a Context

2. Break Down the Problem

3. Define an Outcome

4. Prompt Examples

Prototyping

Create a Method

Create a Regex

Convert X to Y

Code Refactoring

Debugging

Explain a Method

Code Insight

Documentation

Document a Method

Testing

Create Test

Add Test Cases

Learning

How To

4. Conclusion

Automated Frontend Workflow

Table of Contents

Project

Setup

Prettier

Sass

TypeScript

Vite

Vitest

VitePress

Storybook

ESLint

Stylelint

Git

Git setup

Git hooks

Lefthook

GitHub Actions

Code Analysis

Linters

Testing

Branch Protection

Docs

Conclusion

Use Tailwind Without Tailwind

Preflight

Theme

Styles

Conclusion

Become a Master of JavaScript Testing

Testing Fundamentals

Testing with Jest

Comparing Values

Comparing Strings

Regular Expression

Length

Comparing Numbers

Comparing Arrays

Comparing Dynamic Values

Primitive Values

Objects

Arrays

Asynchronous Code

Mocking Fundamentals

The `<slot>` element