Forem: Will Medina

Pulse: A Single Command Palette for Neovim

Will Medina — Tue, 24 Feb 2026 17:57:12 +0000

If you use Neovim, you know how useful quick search and navigation tools like fuzzy finders and symbol pickers are. I built pulse.nvim because I wanted a single command palette to switch between different kinds of searches, without multiple keymaps and complex setups.

With AI, context switching has become a thing, with so many tools to manage. I am spending more and more time reviewing code than writing it, and I wanted a tool that would let me quickly jump to the code I needed without breaking my flow.

What Pulse Is

Pulse is a lightweight command palette and jump panel for Neovim. Instead of splitting every search or picker into its own command, plugin, and or different plugins, Pulse consolidates them under a single, consistent interface with prefix-based mode switching.

You can use it to quickly jump to:

File search
Command execution
Git status
Diagnostics
Symbols (current buffer and workspace)
Live grep
Fuzzy search (current buffer)

How it Works

Pulse uses a simple prefix system to switch between modes. For example, you can type a prefix followed by a query:

Commands (:)

It wouldn't be a command palette without the ability to run commands. Just type : followed by your command and Pulse will execute it.

Files (no prefix)

To search for files, you don't need a prefix just open the panel and start typing:

Open the command palette with a keymap (e.g., p)
Start typing to search for files in the current workspace
Use arrow keys or fuzzy matching to select a file
Press Enter to open the selected file
When empty the active buffers and recent files will show up

Git Status and Diagnostics (~, !)

Pulse will show you the current git status of your project:

Open the command palette with a keymap (e.g., p)
Type ~ to switch to git status mode or ! for diagnostics
See a list of modified, added, and deleted files
Use arrow keys to navigate the list
A preview will show for the selected file
Press Enter to open the selected file

Symbols (@, #)

Quickly navigate to symbols in your code:

Type @ to search symbols in current buffer, or # for workspace
See a list of symbols in the current buffer or workspace
Use arrow keys to navigate the list
A preview will show for the selected symbol
Press Enter to jump to the selected symbol

Live Grep & Fuzzy Search ($, ?)

For more powerful searching, Pulse has live grep and fuzzy search modes:

Type $ for live grep across the workspace or ? for fuzzy search in current buffer
See matching results update in real-time
Use arrow keys to navigate the results
A preview will show for the selected result
Press Enter to open the selected file or jump to the match

Why I Built It

Part of the fun of using Neovim is customizing it to fit your workflow. I love the flexibility of Neovim, but I also wanted to reduce the cognitive load of managing multiple tools for searching and navigation.

I wanted one entry point, much like Spotlight in MacOS:

Fast to launch
Minimal config
Predictable UX
One interface for all searches
In other words: less context switching in my workflow, and a cleaner mental model.

Example

Say you want to live grep for TODOs across your project: just open :Pulse and hit $ to switch to live grep mode or assign a keymap l.

Then Start typing TODO, The panel filters immediately, and hitting previews results while keeping the panel open, letting you pick before jumping.

Why Not Telescope?

Telescope is powerful. It has a vast collection of pickers with many features and extensions.

But that’s exactly what I didn’t want. I didn’t want multiple entry points. I didn’t want multiple panels.

I wanted one palette. One surface. One mental model. This could have been a Telescope plugin. But the goal wasn’t another picker. The goal was a unified experience and full control over how the interaction feels.

How to Install

Pulse should work with any package manager but I tested it with lazy.nvim:

{
  "willyelm/pulse.nvim",
  dependencies = { "nvim-tree/nvim-web-devicons" },
  opts = {},
  keys = {
    { "<leader>p", "<cmd>Pulse<cr>", desc = "Open Pulse" },
  },
}

It’s fast, predictable, and reduces friction when switching between different kinds of searches. Because one panel with consistent navigation, you spend less time thinking about how to do a search and more time doing it.

willyelm / pulse.nvim

A single command palette with prefix based pickers for Neovim

Pulse.nvim

One entry point. Total focus.

For more on the design motivation, see Engineering with machines.

What is Pulse

A fast command palette for Neovim. Pulse uses a prefix approach to move quickly between navigator modes:

Prefix	Mode
(no prefix)	files
`:`	commands
`~`	git
`!`	diagnostics
`@`	symbols (current buffer)
`#`	workspace symbols
`$`	live grep
`?`	fuzzy search (current buffer)
`>`	code actions (current buffer)

Requirements

Neovim >= 0.10
ripgrep (rg)
git (for git panels and previews)
nvim-tree/nvim-web-devicons (optional, recommended)

Install (lazy.nvim)

{
  "willyelm/pulse.nvim",
  dependencies = { "nvim-tree/nvim-web-devicons" },
  opts = {},
}

Setup

require("pulse").setup({
  cmdline = true, -- Enable experimental ':' cmdline replacement
  position = "top"
  width = 0.70,
  height = 0.90,
  border = "rounded",
  workspace_label = false, -- Show workspace dir

…

View on GitHub

What’s Next

This first version of Pulse is just the beginning. I think being able to review git status, better diffs, and merging tools would be a great next step, including:

Better preview layouts
More customization options (expand preview panels, multiple mode views, etc)
Integrations (git diffs, AI code review, etc)

If it fits your needs, Try it out, file issues, share your workflows. I’d love to hear how pulse fits into your stack.

Beyond Components and Design Tokens

Will Medina — Tue, 30 Sep 2025 02:24:37 +0000

Design tokens are often used to define colors, typography and other visual attributes. In this article I will explore the idea of extending this principle to define functional languages. Design tokens are not limited to UIs, they expand beyond visuals into motion, accessibility, error handling, notifications, and functional semantics.

Design tokens provide a predictable system that enables consistent communication between designers, developers, and platforms. They can also ensure AI generates personalized interfaces while staying within clear constraints.

Beyond Components
- 1. Tecnhical
- 2. Architectural
- 3. UX
Beyond Design Tokens
- 1. Language Definition
- 2. System Integration
- 3. Functional Implementation
Conlusion

Beyond Components

I recently worked on few projects where the push for consistency led organizations to centralize UI logic using headless solutions and building libraries as source of truth.

“If everyone uses the same components UIs will always be consistent”

To reduce efforts even the idea of using Web Components to support all platforms emerged. This may work if applied correctly for web only products but when systems expand to multiple platforms(iOS, Android, Windows, Linux) or new requirements such as server-side rendering, accessibility, performance optimization, platform-native features are needed then this approach falls short:

1. Technical

Web Components don’t integrate naturally with modern server rendering strategies.
Frameworks (React Native, SwiftUI, Jetpack Compose) can’t use web components directly.
Every framework needs wrappers and creating duplication and performance issues.

2. Architectural

Web Components as source of truth ties the product’s future to the limitations of the web component spec preventing adoption of innovations, new patterns and methodologies.
This encourages building products with different frameworks and libraries which requires more integration tools.

3. UX

Design evolves with brand, accessibility, and system preferences because they describe intent, not implementation.
Accessibility isn’t a one-time compliance project, it evolves with regulations, WCAG standards, and user needs.
Maintaining a color palette or moving to OKLCH for accessibility is trivial with tokens but a major refactor with components as source of truth.

The source of truth cannot be Components(React, Angular, Vue) or Web Components. It must be Design Tokens, not only to define colors and visual preferences but as a categorization system to define the design language, intent and experiences. When defined at that level creating implementation becomes straightforward.

Beyond Design Tokens

Design tokens are often used as variables for colors and typography. But as described above, When used as a design language they become more than just variables. They become the source of truth and primitives for every platform and system.

This means design tokens extend beyond visual attributes to define functional semantics. These can encode motion, accessibility, error handling, notifications, and even product policies.

1. Language Definition

Creating tokens as design language can be challenging at first after all is about abstracting functionality outside of visuals. Classifying them into categories helps describe product experiences and separating concerns.

Here is a basic example that includes visual, motion, accessibility, functional, and policy semantics using JSON(friendly platform agnostic format):

2. System Integration

Design tokens will continue to evolve as new platforms, technologies, and methodologies emerge. The key is to maintain them in a platform-agnostic format(JSON, YAML, XML) with their own packaging and versioning then use transforms to generate platform-specific bindings(CSS, Swift, Kotlin).

3. Functional Implementation

When embracing the same concept as we encode more functionality, the more adaptable and resilient our design system becomes. Functional implementation ensures that tokens are not just static values but dynamic properties that respond to context, user needs, and platform capabilities.

Conclusion

Design tokens should be seen not as static values, but as a semantic framework for systems. By classifying visual, behavioral, and functional semantics in one shared language, tokens become the architecture of product language, bridging design intent, user experience, and functional implementation across every platform.

Implementing design languages help communicate across teams from different areas and create a shared understanding of product behavior and appearance. I think the idea of removing hardcoded values from servers, platforms, frameworks, and libraries to a single repository(JSON design language) is the future of design systems and automation.

Read on my blog:

Beyond Components and Design Tokens | Will Medina (willyelm)

Design tokens started as a method to centralize colors, typography and other visual aspects. The same classification principle applies to how we define interactions, features, and APIs. Design tokens are not limited just to user interface design, they can be used as a categorization system of functional software across platforms.

willmedina.com

Complete React 19 setup with SSR, CSR, TailwindCSS 4, and Jest using esbuild

Will Medina — Sun, 29 Dec 2024 16:05:44 +0000

This is a continuation of my first blog post:

A Practical Guide to CSR and SSR with React 19 and esbuild

Will Medina ・ Dec 24 '24

#javascript #react #webdev #ssr

In this post I will extend the setup adding TailwindCSS for styling, Jest for unit testing.

Configuring TailwindCSS

To enable TailwindCSS we need to add PostCSS and write a small esbuild plugin to enable TailwindCSS in our css file.

First we'll need to install the following dependencies:

npm i --save-dev postcss tailwindcss @tailwindcss/postcss

Now lets create a esbuild plugin that we can add to our scripts to enable postcss and tailwindcss:

import { readFile } from 'node:fs/promises';
import postcss from 'postcss';
// esbuild Plugin to process css files with postcss
export const postcssPlugin = ({
  plugins = []
} = {}) => {
  return {
    name: 'postcss',
    setup(build) {
      build.onLoad({ filter: /\.css$/ }, async (args) => {
        const raw = await readFile(args.path, 'utf8');
        const source = await postcss(plugins).process(raw.toString(), {
            from: args.path
          });
        return {
          contents: source.css,
          loader: 'css'
        };
      });
    }
  };
}

export default postcssPlugin;

In your esbuild configuration now we can use the plugin:

import tailwindcss from '@tailwindcss/postcss';
{
  //...esbuildConfig,
  plugins: [
    postcssPlugin({
      plugins: [
        tailwindcss
      ]
    })
  ]
}

Since version 4 tailwindcss does not require a config script but instead configures it with CSS. This is a basic style.css using dynamic background and foreground colors:

@import "tailwindcss";

@theme {
  --color-background: #ffffff;
  --color-foreground: #171717;
}

@variant dark (&:where(.dark, .dark *));

@layer base {
  body {
    @apply text-foreground bg-background;
  }
  .dark {
    --color-background: #0a0a0a;
    --color-foreground: #ededed;
  }
}

Configuring Jest

To enable Jest in our project we will use @testing-library as it will facilitate the configuration and testing utilities.

Install the following dependencies:

npm i --save-dev jest jest-environment-jsdom @testing-library/jest-dom @testing-library/react @types/jest

To configure Jest with react and esbuild we'll need to create a transformer to transpile typescript and jsx.

import { transformSync } from 'esbuild';
export default {
  process(src, filename) {
    // Ensure only TypeScript and JavaScript files are processed
    if (/\.(ts|tsx|js|jsx)$/.test(filename)) {
      const result = transformSync(src, {
        loader: filename.endsWith('ts') || filename.endsWith('tsx') ? 'tsx' : 'jsx',
        format: 'esm',  // ESM format
        sourcemap: 'inline', // Inline sourcemaps for debugging
        target: 'esnext', // Set the target to latest ECMAScript
        tsconfigRaw: {
          compilerOptions: {
            jsx: 'react-jsx'
          },
        }
      });
      return { code: result.code, map: result.map };
    }
    return src;
  },
};

We'll also need a environment setup file to import jest-dom from @testing-library that way we can use the library matches like toBeInTheDocument and toBeInTheDOM.

import '@testing-library/jest-dom';

Lastly we can create a config file jest.config.json that will use our custom esbuild transformer and setup file.

{
  "testMatch": [
    "<rootDir>/**/?(*.)+(test).(ts|tsx)"
  ],
  "transform": {
    "^.+\\.(ts|tsx)$": "<rootDir>/scripts/testTransformer.js"
  },
  "setupFilesAfterEnv": [
    "<rootDir>/scripts/testSetup.ts"
  ],
  "moduleFileExtensions": ["ts", "tsx", "js", "jsx", "json", "node"],
  "extensionsToTreatAsEsm": [".ts", ".tsx", ".svg"],
  "transformIgnorePatterns": ["/node_modules/"],
  "testEnvironment": "jsdom"
}

This will allow us to run jest test files in the project. since we are using esm we have to use node --experimental-vm-modules flag.

There are also others utilities that are commonly used in react projects like importing SVG as Components and auto reload on changes. I have included these in my repository:

willyelm / react-app

A Simple react app setup with SSR, CSR, Jest, TailwindCSS and esbuild

A Simple react app setup with SSR and esbuild

This project leverages the latest features of react@19, react-router-dom@7, and others to configure SSR.

Depdendencies

react: Component-based and interactive UI library.
react-dom: Hydrates SSR content with React functionality.
react-router-dom: Handle Routes with React.
express: Node.js simple server for static and REST APIs.
esbuild: Transile TypeScript and bundle JS, CSS, SVG, and other files.
typescript: Adding Typing to our source code.
jest: Unit testing.
postcss: Preprocess css files.
tailwindcss: css utilities.
svgo: converting svg to JSX component modules.

Project Structure

react-app/             # This will be our workspace directory.
  - public/
  - scripts/           
    - build.js         # Bundle our server and client scripts.
    - config.js        # esbuild config to bundle.
    - dev.js           # Bundle on watch mode and run server.
  - src/
    - App/             # Our components will be here.
      - App.tsx        # The

…

View on GitHub

A Practical Guide to CSR and SSR with React 19 and esbuild

Will Medina — Tue, 24 Dec 2024 02:52:36 +0000

This blog explores how to create a lightweight, flexible React application with minimal tooling and frameworks by leveraging React's latest features. While frameworks like Next.js and Remix are excellent for many use cases, this guide is for those interested in having full control while retaining similar functionality.

With React 19 released and its new features to support SSR, I decided to experiment with creating a React application supporting SSR with minimal tooling but first let’s explore the essential features Next.js provides that we need to consider:

Feature	Next.js
SSR (Server-Side Rendering)	Built-in with minimal setup.
SSG (Static Site Generation)	Built-in with `getStaticProps`.
Routing	File-based routing.
Code Splitting	Automatic.
Image Optimization	Built-in with `next/image`.
Performance Optimizations	Automatic (e.g., prefetching, critical CSS).
SEO	Built-in tools like `next/head`.

Based on these features we are going to create a minimal setup; here is the step-by-step guide:

Setup
Configuring esbuild
Express App and Routing
React App
Run
Next Steps
References

Note: You can find the contents of this tutorial in my repo https://github.com/willyelm/react-app

Setup

As a prerequisite of our setup, we will need Node.js installed and the following packages:

react: Component-based and interactive UI library.
react-dom: Hydrates SSR content with React functionality.
react-router-dom: Handle Routes with React.
express: Node.js simple server for static and REST APIs.
esbuild: Transpile TypeScript and bundle JS, CSS, SVG, and other files.
typescript: Adding Typing to our source code.

Our setup will handle routing with express to serve static files, public files, and REST APIs. Then handle all the requests with react-router-dom. Once loaded in the browser our client bundle will hydrate our pre-rendered content and make our components interactive. Here is a diagram representation of this idea:

The diagram illustrates how the express app will handle requests by pre-rendering React components on the server and returning HTML. On the client side, React hydrates these pre-rendered components to enable interactivity.

With this diagram in mind, let's create a folder structure:

react-app/             # This will be our workspace directory.
  - public/            
  - scripts/           
    - build.js         # Bundle our server and client scripts.
    - config.js        # esbuild config to bundle.
    - dev.js           # Bundle on watch mode and run server.
  - src/
    - App/             # Our components will be here.
      - App.tsx        # The main application with browser routing.
      - Home.tsx.      # Our default page component.
      - NotFound.tsx   # Fallback page for unmatched routes.
    - index.tsx        # Hydrate our pre-rendered client app.
    - main.tsx         # Server app with SSR components.
    - style.css        # Initial stylesheet.   
  package.json
  tsconfig.json

Let's add our dependencies and setup our package.json:

{
  "name": "react-app",
  "type": "module",
  "devDependencies": {
    "@types/express": "^5.0.0",
    "@types/node": "^22.10.2",
    "@types/react": "^19.0.2",
    "@types/react-dom": "^19.0.2",
    "esbuild": "^0.24.2",
    "typescript": "^5.7.2"
  },
  "dependencies": {
    "express": "^4.21.2",
    "react": "^19.0.0",
    "react-dom": "^19.0.0",
    "react-router-dom": "^7.1.0"
  },
  "scripts": {
    "build": "node scripts/build",
    "dev": "node scripts/dev",
    "start": "node dist/main.js"
  }
}

Note: the "type": "module" property is required to allow node.js to run ESM scripts.

Since we will be using Typescript, We'll configure a tsconfig.json file:

{
  "compilerOptions": {
    "esModuleInterop": true,
    "verbatimModuleSyntax": true,
    "noEmit": true,
    "resolveJsonModule": true,
    "skipLibCheck": true,
    "strict": true,
    "lib": ["DOM", "DOM.Iterable", "ES2022"],
    "target": "ES2022",
    "module": "ES2022",
    "moduleResolution": "bundler",
    "jsx": "react-jsx",
    "baseUrl": ".",
    "paths": {
      "src": [
        "./src/"
      ]
    }
  },
  "include": [
    "src"
  ],
  "exclude": [
    "node_modules"
  ]
}

Configuring esbuild

Why esbuild? compared to other tools esbuild keeps things minimal, it is very fast(the fastest bundler as of today) and supports typescript and esm by default.

In this setup, we will use esbuild to create our dev and build scripts and transpile both client and server bundles. In this section we will work in the scripts folder of our workspace.

scripts/config.js: This file will contain a base configuration for the client and server bundle that will be shared for our scripts.

import path from 'node:path';
// Working dir
const workspace = process.cwd();
// Server bundle configuration
export const serverConfig = {
  bundle: true,
  platform: 'node', 
  format: 'esm',        // Support esm packages
  packages: 'external', // Omit node packages from our node bundle
  logLevel: 'error',
  sourcemap: 'external',
  entryPoints: {
    main: path.join(workspace, 'src', 'main.tsx') // Express app
  },
  tsconfig: path.join(workspace, 'tsconfig.json'),
  outdir: path.join(workspace, 'dist')
};

// Client bundle configuration
export const clientConfig = {
  bundle: true,
  platform: 'browser',
  format: 'esm',
  sourcemap: 'external',
  logLevel: 'error',
  tsconfig: path.join(workspace, 'tsconfig.json'),
  entryPoints: {
    index: path.join(workspace, 'src', 'index.tsx'), // Client react app
    style: path.join(workspace, 'src', 'style.css')  // Stylesheet
  },
  outdir: path.join(workspace, 'dist', 'static'),    // Served as /static by express
};

scripts/dev.js: This script bundles both the client, and server app and runs the main server script in watch mode.

import { spawn } from 'node:child_process';
import path from 'node:path';
import { context } from 'esbuild';
import { serverConfig, clientConfig } from './config.js';
// Working dir
const workspace = process.cwd();
// Dev process
async function dev() {
  // Build server in watch mode
  const serverContext = await context(serverConfig);
  serverContext.watch();
  // Build client in watch mode
  const clientContext = await context(clientConfig);
  clientContext.watch();
  // Run server
  const childProcess = spawn('node', [
    '--watch',
    path.join(workspace, 'dist', 'main.js')
  ], {
    stdio: 'inherit'
  });
  // Kill child process on program interruption
  process.on('SIGINT', () => {
    if (childProcess) {
      childProcess.kill();
    }
    process.exit(0);
  });
}
// Start the dev process
dev();

With this script, we should be able to run npm run dev as configured in the package.json in our workspace.

scripts/build.js: Similar to dev but we only need to enable minify.

import { build } from 'esbuild';
import { clientConfig, serverConfig } from './config.js';
// build process
async function bundle() {
  // Build server
  await build({
    ...serverConfig,
    minify: true
  });
  // Build client
  await build({
    ...clientConfig,
    minify: true
  });
}
// Start the build process
bundle();

This script will generate our dist bundle ready for production by running npm run build and running the app using npm start.

Now that we have esbuild configured to bundle both our node and our client app let's start creating an express server and implement React SSR.

Express App and Routing

This is a simple application using Express static and middleware approach to serve static files, handle server routes, and route using react-router-dom.

src/main.tsx: This is the main Node.js application that initializes the server, handles routes with Express, and implements React SSR.

import path from 'node:path';
import express, { type Request, type Response } from 'express';
import { renderToPipeableStream } from 'react-dom/server';
import { StaticRouter } from 'react-router';
import { App } from './App/App';

const app = express(); // Create Express App
const port = 3000; // Port to listen
const workspace = process.cwd(); // workspace
// Serve static files like js bundles and css files
app.use('/static', express.static(path.join(workspace, 'dist', 'static')));
// Server files from the /public folder
app.use(express.static(path.join(workspace, 'public')));
// Fallback to render the SSR react app
app.use((request: Request, response: Response) => {
  // React SSR rendering as a stream
  const { pipe } = renderToPipeableStream(
    <html lang="en">
      <head>
        <meta charSet="UTF-8" />
        <link rel='stylesheet' href={`/static/style.css`} />
      </head>
      <body>
        <base href="/" />
        <div id="app">
          <StaticRouter location={request.url}>
            <App />
          </StaticRouter>
        </div>
      </body>
    </html>,
    { 
      bootstrapModules: [ `/static/index.js` ], // Load script as modules
      onShellReady() {
        response.setHeader('content-type', 'text/html');
        pipe(response);
      }
    });
});
// Start server
app.listen(port, () => {
  console.log(`[app] listening on port ${port}`)
});

src/index.tsx: On the client side to activate our components and make them interactive we need to "hydrate".

import { hydrateRoot } from 'react-dom/client';
import { BrowserRouter } from 'react-router';
import { App } from './App/App';
// Hydrate pre-renderer #app element
hydrateRoot(
  document.getElementById('app') as HTMLElement,
  <BrowserRouter>
    <App />
  </BrowserRouter>
);

React App

The react app will handle the routes using react-router-dom, our app will consist of a Home page and a NotFound page to test hydration we will add a counter button on the home page and take advantage of React 19 we will update the meta tags title and description.

src/App/Home.tsx: A very minimal FunctionComponent.

import { useState, type FunctionComponent } from 'react';
// Home Page Component
export const Home: FunctionComponent = () => {
  const [count, setCount] = useState(0);
  const update = () => {
    setCount((prev) => prev + 1);
  }
  return <>
    <title> App | Home </title>
    <meta name='description' content='This is my home page' />
    <h1> Home Page </h1>
    <p> Counter: {count} </p>
    <button onClick={() => update()}>Update</button>
  </>;
}

src/App/NotFound.tsx: Default FunctionComponent when page not found.

import { type FunctionComponent } from 'react';
// Not Found Page Component
export const NotFound: FunctionComponent = () => {
  return <>
    <title> App | Not Found </title>
    <meta name='description' content='Page not found' />
    <h1>404</h1>
    <p> Page Not Found</p>
  </>;
}

src/App/App.tsx: Setting up our App using react-router-dom.

import { type FunctionComponent } from 'react';
import { Routes, Route } from 'react-router';
import { Home } from './Home';
import { NotFound } from './NotFound';
// App Component
export const App: FunctionComponent = () => {
  return <Routes>
    <Route path="/">
      <Route index element={<Home />} />
      <Route path="*" element={<NotFound />} />
    </Route>
  </Routes>;
}

Run

Finally, with esbuild scripts configured, the express server set up, and react SSR implemented. we can run our server:

npm run dev

This will show a message [app] listening on port 3000. navigate to
http://localhost:3000 to check it out.

Testing SSR and SEO meta tags:

You can also find the source code of this tutorial in my repo willyelm/react-app

willyelm / react-app-basic

A Simple react app setup with SSR and esbuild

This project leverages the latest features of react@19, react-router-dom@7, and others to configure SSR.

Depdendencies

react: Component-based and interactive UI library.
react-dom: Hydrates SSR content with React functionality.
react-router-dom: Handle Routes with React.
express: Node.js simple server for static and REST APIs.
esbuild: Transile TypeScript and bundle JS, CSS, SVG, and other files.
typescript: Adding Typing to our source code.

Project Structure

react-app/             # This will be our workspace directory.
  - public/
  - scripts/           
    - build.js         # Bundle our server and client scripts.
    - config.js        # esbuild config to bundle.
    - dev.js           # Bundle on watch mode and run server.
  - src/
    - App/             # Our components will be here.
      - App.tsx        # The main application with browser routing.
      - Home.tsx.      # Our default page component.
      - NotFound.tsx   # Fallback request to not found.
    -

…

View on GitHub

Next Steps

In this guide, we built a React app with SSR using esbuild and Express, focusing on a minimal and flexible setup. Using modern tools like React 19, React Router DOM 7 and esbuild, we achieved a fast and efficient workflow while avoiding the overhead of larger frameworks.

We can enhance this implementation to include the following:

TailwindCSS: Configure PostCSS and esbuild to support tailwindcss for styling.
Jest: Add unit testing with Jest and @testing-library.
SSG: Implement SSG(Static site generation) to improve performance and server loading.
HMR: Support HMR(Hot Module Replacement) with esbuild in development mode to enhance efficiency.

In the next post, we’ll complete the setup by adding CSR,
TailwindCSS for styling, Jest for testing, and live reload to
enhance the development experience.

Forem: Will Medina

Pulse: A Single Command Palette for Neovim

What Pulse Is

How it Works

Commands (:)

Files (no prefix)

Git Status and Diagnostics (~, !)

Symbols (@, #)

Live Grep & Fuzzy Search ($, ?)

Why I Built It

Example

Why Not Telescope?

How to Install

willyelm / pulse.nvim

A single command palette with prefix based pickers for Neovim

Pulse.nvim

What is Pulse

Requirements

Install (lazy.nvim)

Setup

What’s Next

Beyond Components and Design Tokens

Table Of Contents

Beyond Components

1. Technical

2. Architectural

3. UX

Beyond Design Tokens

1. Language Definition

2. System Integration

3. Functional Implementation

Conclusion

Beyond Components and Design Tokens | Will Medina (willyelm)

Complete React 19 setup with SSR, CSR, TailwindCSS 4, and Jest using esbuild

A Practical Guide to CSR and SSR with React 19 and esbuild

Will Medina ・ Dec 24 '24

Configuring TailwindCSS

Configuring Jest

willyelm / react-app

A Simple react app setup with SSR, CSR, Jest, TailwindCSS and esbuild

A Simple react app setup with SSR and esbuild

Depdendencies

Project Structure

A Practical Guide to CSR and SSR with React 19 and esbuild

Table of Contents

Setup

Configuring esbuild

Express App and Routing

React App

Run

willyelm / react-app-basic

A Simple react app setup with SSR and esbuild

A Simple react app setup with SSR and esbuild

Depdendencies

Project Structure

Next Steps

Complete React 19 setup with SSR, CSR, TailwindCSS 4, and Jest using esbuild

Will Medina ・ Dec 29 '24

References