chengyixu

Modern CSS Layout Patterns That Replace JavaScript

By Wilson Xu | May 5, 2026

---

The front-end landscape has shifted. For years, the reflex was: need a dynamic layout? Reach for JavaScript. Need an animation triggered by scroll position? IntersectionObserver. Need a custom dropdown? Fifty lines of event handlers and DOM manipulation.

That era is ending. Modern CSS has absorbed so many patterns that previously required JavaScript that a significant chunk of your client-side code may now be dead weight. Browsers have shipped features that handle layout, animation, interactivity, and even state management declaratively -- and they do it faster, with less code, and without blocking the main thread.

chengyixu

The React 19 Compiler: How Automatic Memoization Changes Everything

Author: Chengyi Xu Date: 2026-05-09 Word Count: ~2,800 Target: SitePoint / Smashing Magazine / LogRocket

---

Introduction

chengyixu

---

title: "Postgres for Frontend Developers: The Database You Can't Avoid in 2026" estimated_rate: "$400-500" target_outlets:

• "DigitalOcean Community — $400, submissions: write@digitalocean.com"
• "LogRocket Blog — $350, submissions: editors@logrocket.com"
• "CSS-Tricks — $300, submissions: editors@css-tricks.com" word_count: 3100 slug: postgres-for-frontend-developers-2026 date: 2026-05-07

chengyixu

CSS Container Queries in Production: Lessons Learned After One Year

Author: Cheng Yi Xu
Target Publication: Smashing Magazine
Date: May 5, 2026

---

Container queries shipped across all major browsers in early 2025. A year later, they have fundamentally changed how front-end teams build responsive interfaces. But the migration path has been bumpier than the spec authors hoped, and the patterns that work in production are not always the ones you see in conference demos.

chengyixu

htmx in 2026: Production Patterns That Actually Work

Word count: ~2,600 | Code examples: 8 | Target: Intermediate-to-senior web developers

---

htmx is no longer the shiny new toy. It is four years old, shipping in production at scale, and the patterns that survive are not the ones from conference talks -- they are the ones that solve real problems without introducing new ones. This article is about those patterns: the ones that hold up under real traffic, real teams, and real deadlines.

I have spent the past two years building with htmx across a fintech dashboard, a CMS back-office, and a multi-tenant SaaS admin panel. Here is what actually works.

chengyixu

---

title: "Postgres for Frontend Developers: The Database You Can't Avoid in 2026" estimated_rate: "$400-500" target_outlets:

• "DigitalOcean Community — $400, submissions: write@digitalocean.com"
• "LogRocket Blog — $350, submissions: editors@logrocket.com"
• "CSS-Tricks — $300, submissions: editors@css-tricks.com" word_count: 3100 slug: postgres-for-frontend-developers-2026 date: 2026-05-07

chengyixu

Event Sourcing in TypeScript: Building Audit-Ready Systems

Author: Chengyi Xu Date: 2026-05-09 Target: LogRocket / SitePoint / Smashing Magazine Status: ready

---

Picture this: your payment service processed a refund twice. The customer is angry, the finance team is confused, and nobody can tell you exactly what happened because the state says "refunded" and your audit log was a best-effort afterthought that someone forgot to update in the second code path. If this scenario keeps you up at night, you need event sourcing.

chengyixu

Building CLI Tools in TypeScript: From Script to Product

Word Count: ~3,100 | May 9, 2026

---

Every developer has a folder called scripts/. Inside: a dozen .ts files that solve real problems but will never be shared. They lack argument parsing, error handling, tests, and distribution. A script becomes a product when another developer can npm install -g it and have it work on the first try.

TypeScript has matured into a first-class CLI language. Node.js 24 ships with native TypeScript support via type stripping. The ecosystem around CLI construction -- argument parsing, output formatting, configuration management, testing -- has converged on production-tested patterns. This article walks through building a CLI tool that another engineer would pay for, not just one that runs on your machine.

chengyixu

Observability-Driven Development: From Logs to Telemetry in TypeScript

You ship a feature at 4:37 PM on a Friday. At 4:42 PM, PagerDuty fires. Users are seeing HTTP 500s. You SSH into the production box, tail the logs, and see... nothing useful. The error message is Cannot read properties of undefined. No stack trace beyond your own code. No request ID to trace through the upstream services. No metric to tell you whether this affects 3 users or 30,000.

This is the moment you realize that console.log is not observability.

Observability-driven development (ODD) is the practice of instrumenting your application as you build it — not after it breaks. It treats logs, traces, and metrics as first-class deliverables, not afterthoughts. This article walks through a production-ready observability stack for TypeScript/Node.js using OpenTelemetry, structured logging with Pino, and metrics with Prometheus.

The Three Pillars, TypeScript Edition

chengyixu

Beyond try/catch: Railway-Oriented Programming in TypeScript for Reliable Backends

Introduction

Every production outage I've debugged in the past three years shares one root cause: an unhandled exception somewhere in the call stack that propagated silently, corrupted state, or crashed the process entirely. A database connection dropped mid-transaction. An external API returned an unexpected shape. A file that should have existed didn't. In each case, the code relied on try/catch blocks scattered across the codebase like bandaids -- and each time, something slipped through.

The problem with try/catch is not that it fails to catch errors. It's that try/catch treats errors as a separate control flow mechanism, invisible to the type system and invisible to anyone reading the function signature. You look at function processOrder(id: string): Order and have no idea it can fail. The compiler won't warn you. Your IDE won't autocomplete the error case. The only way to know is to read the implementation or wa