DEV Community: Nilesh Kasar

Claude Skills vs Custom MCP Servers: Which to Build in 2026

Nilesh Kasar — Tue, 12 May 2026 18:04:03 +0000

When Anthropic shipped Claude Skills at the October 2025 dev summit and then expanded the marketplace in February 2026, the question my team got asked weekly stopped being "should we use Claude" and started being "should we build a Skill or run our own MCP server?" Six months and seventeen production deployments later, I have a clear answer for most cases — and a list of edge cases where the answer is the opposite of obvious.

This is the decision framework I use, with concrete examples of when each approach is right.

The Two Things Being Compared

Claude Skills are packaged, sandboxed capability bundles that Anthropic distributes through their official marketplace and that any Claude deployment can install. They run on Anthropic's infrastructure, can call out to your APIs, and are installable in one click. Anthropic vets the marketplace.

MCP (Model Context Protocol) servers are self-hosted services you run that expose tools and resources to any compatible model client over a standardized protocol. You build them, you operate them, you pay for them. They work with Claude, Cursor, Windsurf, Zed, Claude Code, and increasingly other model surfaces.

Both let an LLM use external capabilities. The differences are about ownership, distribution, and the boundary conditions. The right way to think about it: Skills are a product surface; MCP servers are infrastructure. Confusing the two leads to the most common mis-step I see — teams build a Skill expecting it to behave like infrastructure (mutable, low-latency, internally observable) and end up frustrated.

When Skills Win

Use Claude Skills when:

Distribution to many users is the goal. If you want every Claude Pro user to discover and install your capability, the marketplace is uniquely effective. There's no equivalent reach mechanism for MCP servers.
The capability is well-bounded. A single domain, a small number of tools, a clear input-output contract. Examples: a Notion search Skill, a Calendly booking Skill, a Stripe customer-lookup Skill.
You don't need to control the runtime. Anthropic decides scaling, observability, region routing. For most tools, this is a relief, not a constraint.
The data flow is API-bounded. Your Skill calls your API. Your API stays inside your perimeter. Anthropic's sandbox is the proxy.

The Notion Skill is the canonical example. It installs in seconds. It works for every Claude user. Notion didn't build sixteen redundant integration surfaces. The same logic applies to Calendly, Linear, Stripe, GitHub — every horizontal SaaS with a Claude integration has either shipped a Skill or is about to.

When MCP Servers Win

Use MCP servers when:

The capability is internal-only. You're building tools for your own engineers, not for the public marketplace. There's no upside to wrapping it as a Skill.
The runtime needs to be in your VPC. Healthcare, finance, defense. The model can still be Anthropic's, but the tools execute behind your firewall on your hardware, with your logs.
The protocol matters beyond Claude. If you want the same toolset to work in Cursor or Zed, you need MCP. Skills are Claude-only.
You need fine-grained observability. Skills give you basic execution logs through Anthropic's dashboard. MCP servers give you everything because you run them.
The tool is high-cardinality. A code-search MCP server that exposes one tool per repo, dynamically, isn't a Skill shape. Skills assume a fixed tool surface.

We built an internal Postgres-ops MCP server at one client that exposes describe-table, explain-query, top-slow-queries against their production database. There's no universe in which that's a marketplace Skill. The data is sensitive, the tools are evolving weekly, and the surface is bespoke to their schema. It's the same kind of internal-tooling pattern described in autonomous AI agents in software engineering — and MCP is the right primitive for letting an agent run against your specific stack.

A Concrete Decision Matrix

Factor	Skill	MCP Server
Public distribution	Strong fit	Weak
Internal-only tooling	Weak fit	Strong
Multi-client (Claude + Cursor + Zed)	Not supported	Strong
Data must stay in VPC	Hard to do	Native
Stable tool surface	Strong	Either works
Highly dynamic tools	Weak	Strong
Operating burden	Anthropic's problem	Your problem
Time to first deployment	Hours	Days
Auth/identity passthrough	Limited models	Whatever you build
Compliance audit trail	Anthropic's audit	Your audit
Versioning	Marketplace gates	You control

The Hybrid Pattern Most People Miss

The most interesting deployments combine both. A team ships a public Skill that wraps a thin authentication layer, and the heavy logic lives in their MCP server that the Skill calls into. You get marketplace distribution and runtime control. The Skill is a discoverable entry point; the MCP server is the engine.

Linear B did this with their incident-management integration: a Skill called linear-incident-lookup that handles auth and surface, backed by an MCP server inside their infrastructure that handles the actual analysis. Best of both worlds, at the cost of building two things.

We've also seen the inverse hybrid: an MCP server that fronts a Skill. The MCP server runs inside the customer's network, handling auth and access control, and proxies tool calls to a publicly-distributed Skill that does the heavy lifting on Anthropic's infrastructure. This is rarer but useful for enterprises that want centralized control over which Skills are available to their employees.

The Auth Story Is Different in Each

For Skills, auth happens at install time. The user OAuth flows through Anthropic to your service. From then on, the Skill calls your API with the stored token. Token refresh is on you.

For MCP servers, you decide the auth model. Many production MCP servers in 2026 use OAuth 2.1 with the device flow, since the model client doesn't have a browser. Some run with pre-provisioned service accounts. The MCP spec doesn't dictate this; it's a property of your server.

The right pattern for sensitive internal tools: bind the MCP server to the user's identity at session start (Auth.js OIDC, Okta, whatever you use), pass that identity into every tool call, and have the tool enforce least-privilege. Don't let the model bypass your access control. We've seen at least three internal MCP servers ship with implicit "the model can do anything the service account can do" auth — every one of them later had to be rewritten when security found it.

A practical pattern that works: every MCP tool call takes a user_context parameter that the server validates against the session token. If the model tries to call with a different user_context than what's in the session, refuse. This prevents the kind of injection attacks where the model is talked into impersonating a different user mid-conversation.

Cost Comparison

This is where MCP servers can look surprising:

Skills: included in Claude pricing. The user pays Claude. Anthropic absorbs the infrastructure. You pay for the API calls that your Skill makes to your backend.
MCP servers: you pay everything. Hosting, scaling, observability, the lot. For a small internal MCP server that handles 1,000 calls a day, you're looking at $40-80/month all-in. For a public-facing MCP server with millions of calls, you're looking at six figures a year.

If your Skill is doing real work — generating images, running RAG, hitting expensive APIs — the cost shows up on your side as API charges, not on Anthropic's side. The "free hosting" benefit of Skills is real but smaller than it sounds. The economic effect of choosing Skills is mostly that Anthropic eats the integration infrastructure (auth, retry logic, sandbox, distribution) but you still eat the work infrastructure (your APIs, your databases, your compute for whatever the tool actually does).

Latency Differences

In our testing, the latency overhead is roughly:

Skill execution overhead: 80-150ms typical, including auth, network, and Anthropic's invocation logic.
MCP server overhead: 20-60ms typical, since the network hop is just to your server.

If you host your MCP server in the same region as the Claude API gateway (us-east-1 today), latency is barely measurable. If your users care about sub-second response times for complex tool chains, MCP servers win by 100-200ms compounded across several calls.

The compounding matters more than the single-call difference. A six-tool-call agent loop loses 600-900ms on Skills versus a co-located MCP server. For an interactive product where the user is watching the loading spinner, that's the difference between feeling fast and feeling slow.

The Migration Path

The pattern I've seen work: start with an MCP server. Iterate fast, no marketplace review. Once the tool surface stabilizes and you have a distribution argument, wrap a thin Skill around the MCP server. The Skill becomes your marketplace presence. The MCP server stays your runtime.

The opposite migration (Skill first, MCP later) is harder. Once a Skill is in the marketplace and users have installed it, changing the tool surface is a versioning exercise. Anthropic's marketplace handles deprecation gracefully — old versions stay installable while new versions roll out — but you still own the support burden of multiple versions running in production simultaneously.

What I'd Build Today

If you're starting today with no constraints:

Public-facing capability, single SaaS tied to Claude users. Build a Skill.
Internal devtool for your engineers, sensitive data. Build an MCP server.
Capability you'll want in Cursor and Claude Code too. Build an MCP server.
You want to learn the ecosystem. Build an MCP server first; Skills second.

For developer tools especially, MCP has become the default in 2026. The same agent productivity gains documented in the Rust takeover of JavaScript tooling — fast iteration loops, low-latency dev experience — depend on tooling that runs locally or in your VPC, not in a third-party sandbox.

A Few Underrated MCP Features

Three things about MCP that don't get enough attention:

Resources, not just tools. MCP servers can expose resources (read-only data sources the model can reference) in addition to tools (actions the model can take). This is a cleaner mental model than wrapping every read as a "read tool" — and it lets the client cache resource contents intelligently.
Streaming responses. MCP supports streaming tool outputs back to the model. For a long-running operation (a big database query, a slow API call) the model can receive partial results and start reasoning before the operation completes.
Prompts as a first-class concept. MCP servers can ship prompts that the model can invoke as templates. This is underused. A well-designed MCP server can ship the "right way" to use its tools as a prompt — making the integration substantially less error-prone than a tools-only API.

Operating an MCP Server in Production: A Short Checklist

Once you decide to ship an MCP server, the operational discipline matters more than the protocol itself. The checklist we use:

Health endpoint. A simple /health that returns 200 if the server can reach its dependencies. Run it from your existing uptime monitor.
Request logging with model identifiers. Log every tool call with the model name and request ID so you can correlate MCP traffic against your Claude API logs.
Rate limiting per user. A misbehaving agent in a long-running loop can hammer your MCP server. Per-user rate limits protect your downstream services. We use Redis-backed token buckets at 10 calls/second per user as a default.
Graceful degradation. If your MCP server depends on a flaky third-party API, return a structured error to the model so it can reason about the failure rather than throwing an opaque 500. The model can often work around a known failure if it knows about it.
Schema versioning. Pin your MCP server to a specific protocol version and bump it deliberately. Clients update; servers should not break clients silently.
Cost attribution. If your MCP server makes paid API calls (search APIs, scraping services, paid data), tag every outbound call with the user ID so you can attribute cost. We've seen one $14K surprise bill from an MCP server that didn't have this in place.

Where Both Ecosystems Are Heading

A few trends worth tracking through the rest of 2026:

Marketplace consolidation. The Skills marketplace has roughly tripled in size since February 2026, and a long tail of low-quality Skills has emerged. Anthropic is signaling tighter review and a featured-Skills program. Expect quality differentiation to become a real factor for marketplace discovery.
MCP standardization across vendors. OpenAI, Google, and Mistral have all hinted at MCP support, though only Mistral has actually shipped a public client implementation as of May 2026. If the protocol becomes truly cross-vendor, MCP server investment looks even better in hindsight.
Sandbox-first MCP runtimes. A few startups (most notably E2B and Modal) are shipping managed runtimes for MCP servers that try to give you Skills-like operational simplicity with MCP-like control. Worth evaluating if you don't want to run the infrastructure yourself but also don't want to be Claude-locked.

Conclusion

Skills and MCP servers solve overlapping but distinct problems. The marketing makes them sound interchangeable. They're not. Skills are about distribution and managed runtime. MCP servers are about ownership, control, and cross-client portability. For most internal-facing tools, MCP wins. For most public-facing capabilities you want every Claude user to find, Skills win. Pick wrong and you'll either be locked into a marketplace you've outgrown or maintaining infrastructure for a tool that should have been one-click installable. The technical decision flows directly from the distribution question — answer that one first, and the rest follows. The teams I see succeeding with both are the ones who treat them as complementary, not competing — Skills for reach, MCP for control, and a clear architectural seam between the two.

Originally published on The Stack Stories.

Next.js 16 Cache Components: A Real Migration From a 4.2M-MAU Site

Nilesh Kasar — Tue, 12 May 2026 18:03:56 +0000

Vercel pushed Next.js 16 to stable on March 18, 2026 with a feature that quietly upends how everyone has been writing App Router code for the past three years: cache components. We migrated a 4.2-million-monthly-active-user marketing site over six weeks. Here's what actually happened, including the three production incidents we caused and what the migration is worth.

I led the migration as the senior engineer on a four-person platform team. We chose to document it in public because we couldn't find a single honest write-up of a real cache-components migration at the time — Vercel's own examples were too clean, and Twitter threads were too triumphal. What follows is the full log, with the dashboards, the cost lines, and the screenshots-in-prose. If you're considering this migration, this is the article I wish I'd had three months ago.

What Cache Components Are, and Why They Replaced `fetch`-Based Caching

If you wrote App Router code between Next.js 13 and 15, your mental model was: every fetch was cached by default, and you opted out with { cache: 'no-store' } or revalidate: 0. That was elegant when the only data source was an HTTP API. It fell apart the moment people started using Prisma, Drizzle, raw SQL clients, or third-party SDKs that didn't go through fetch.

Cache components flip the model. You explicitly mark a component (or a function) as cacheable with the new "use cache" directive. Everything else is dynamic by default.

"use cache"

export async function PopularArticles() {
  const articles = await db.article.findMany({
    where: { status: "PUBLISHED" },
    orderBy: { views: "desc" },
    take: 10,
  })
  return <ArticleList articles={articles} />
}

That component will be cached at the component boundary, independent of how its data is fetched. Prisma calls, raw SQL, the AWS SDK — they all just work. This is the change that makes the App Router actually viable for data-heavy apps that don't fit the "everything is a fetch" mold. It also resolves the longstanding inconsistency where adding cookies() to a deep child would silently switch a static page to dynamic — a footgun that ate more developer-weeks at our shop than I'd like to admit.

Our Starting Point

Before the migration we ran Next.js 15.3 on Vercel, with about 340 routes, a mix of static and ISR. The site is a publication: long-form articles, author pages, topic hubs, a paid newsletter checkout. Average TTFB 240ms p50, 680ms p95. Build time 12 minutes. Vercel bill: $4,800/month, dominated by edge function invocations from the ISR revalidations.

Our pain points coming in:

ISR revalidation thrash. We had 60+ tag-based revalidations daily, and tag misses caused stampeding herd issues on popular articles.
Inconsistent dynamic-vs-static behavior. Adding a single cookies() call somewhere deep in the tree silently turned a static page dynamic.
The fetch cache wasn't reachable from Prisma queries, so we had a homegrown LRU around our DB layer that was buggy.

A lot of this echoed what we saw teams struggle with in the verdict on Next.js vs React for enterprise — the framework had outgrown its caching model, and the workarounds were starting to outweigh the benefits.

The Migration in Six Phases

We did this incrementally over six weeks. Here's the sequence that worked:

Phase 1: Enable the flag, fix the breakage (Week 1)

Cache components is opt-in via experimental.cacheComponents = true in next.config.ts. Flipping it surfaces every route that was implicitly relying on the old fetch-cache behavior. We had 84 build-time errors and 31 runtime warnings. Most were cosmetic — pages that were "static" only because nothing in them touched a request-scoped API.

The single most useful debugging tool in this phase was the new --experimental-cache-debug build flag, which annotates the build output with a per-component breakdown of "dynamic," "cached," or "static." We piped the output into a CSV and sorted by render cost. Two unexpected items showed up at the top: a layout footer that was hitting our analytics service on every render, and a header that read headers() inside a deeply-nested component. Both were trivially fixable once visible.

Phase 2: Identify caching candidates (Week 1-2)

We graphed every server component by how often its data changed. Three buckets:

Bucket	Components	Strategy
Almost-static (changes once a day)	Author bios, category pages, navigation	`"use cache"` with long `cacheLife`
Hot data (changes every few minutes)	Trending sidebar, popular articles	`"use cache"` with short `cacheLife` + tag-based revalidation
Per-request (always dynamic)	User session, paywall state, comments	Leave untouched; explicit `unstable_noStore()` for safety

To do this systematically we exported a Prisma audit log: for every model, the rate of writes per day, the read patterns, the typical query shape. Anything below 1 write/day got long cacheLife. Anything above 100 writes/day either got fine-grained tag invalidation or was left dynamic.

Phase 3: Apply `"use cache"` to the obvious wins (Week 2-3)

We started with author pages — 11,400 of them, regenerating constantly under the old model. Adding "use cache" at the top of the page component, plus cacheTag and cacheLife calls, dropped build time from 12 minutes to 4 minutes. Author-page TTFB went from 290ms to 38ms p50.

We also moved our footer (which loaded site-wide stats like total article count and total comment count) into its own cached component with a 5-minute lifetime. That single change cut homepage TTFB by another 50ms because the footer was rendering on every request under the old model regardless of how cached the rest of the page was.

Phase 4: Tag invalidation strategy (Week 3-4)

This is where we caused our first incident.

We had a content team workflow that published 40+ articles a day. Each publish triggered revalidateTag('articles'). Under cache components, a tag invalidation cascades through every component that declared that tag. Our nav component, our footer, our sidebar — all tagged articles because they showed counts. A single publish nuked 80% of the cache.

Fix: tag with intent, not entity. We split into articles:latest, articles:counts, articles:by-author:{authorId}, articles:by-topic:{topicSlug}. Granular invalidation. Cache hit rate recovered to 97%. The lesson generalizes: never tag a component with a noun unless the noun is itself a noun-phrase indicating which change in the entity matters.

Phase 5: Per-user-but-cacheable patterns (Week 4-5)

The tricky case: components that depend on the user but not on the specific user. Example: "Recommended for you" can be cached at the segment level (logged-in vs logged-out, free vs paid). Cache components let you do this with cacheKey:

"use cache"
import { cacheKey } from "next/cache"

export async function Recommendations({ segment }: { segment: string }) {
  cacheKey(segment)
  const recs = await getRecsForSegment(segment)
  return <RecsList items={recs} />
}

We collapsed our recommendation tiers from 4.2M unique user caches to 11 segment caches. Edge function invocations dropped 96%. That alone saved $2,200/month.

A subtler case: per-region content (different stories for European vs North American users). We added a third cacheKey dimension for region, taking us from 11 to 33 segment caches. Still trivially small compared to the per-user explosion.

Phase 6: Production rollout and the incidents (Week 5-6)

We caused three incidents during cutover. Documenting them so you don't repeat them.

Incident 1 — Stale paywall state. A reader who upgraded to paid saw the paywall for 8 minutes after upgrading. We had cached the <PaywallGate/> component without realizing it inherited the parent route's cache directive. Fix: explicit "use cache: false" on the gate. Time to detect: 3 minutes after the first complaint in support. Time to mitigate: 18 minutes (revert the offending PR).

Incident 2 — Cache poisoning via cookies. A misconfigured A/B test wrote a cohort cookie that we accidentally included in the cache key. One cohort variant got served to everyone for ~40 minutes. Fix: never read cookies inside a "use cache" boundary; pass cohort as a prop from a dynamic parent. We added a lint rule afterward that fails the build if cookies() is called inside a file with "use cache".

Incident 3 — Build-time database overload. Static generation tried to pre-render 11,400 author pages in parallel during deploy. Neon's connection pool melted at 2 AM. Fix: experimental.staticGenerationMaxConcurrency: 8 in the config. We learned this the way you do — by getting paged.

The Numbers After Migration

Metric	Before (Next 15.3)	After (Next 16.0)	Delta
TTFB p50	240ms	71ms	-70%
TTFB p95	680ms	198ms	-71%
LCP p75 (mobile)	2.1s	1.2s	-43%
Build time	12m 14s	4m 38s	-62%
Vercel edge invocations / day	18.4M	1.9M	-90%
Vercel monthly bill	$4,800	$1,720	-64%

The bill cut was the biggest surprise. We expected speed gains. We didn't expect to save $36K/year. Core Web Vitals also moved into "Good" thresholds on all three metrics for the first time in the site's history, and search-console impressions started ticking up about three weeks after we deployed — probably attributable to the LCP improvement rather than any content change.

What Cache Components Don't Solve

Three things to be honest about:

Mental overhead is higher than the old model. "Every fetch is cached" was simpler to reason about, even if it was leaky. The new model is more correct but you have to think about every component boundary. Onboarding a new engineer now requires a 30-minute walkthrough of the cache topology that we never needed before.
Debugging stale caches is still hard. When a reader complains they're seeing yesterday's data, you still have to trace tags through the tree to find the culprit. Vercel's cache inspector in the dashboard helps but doesn't surface tag relationships well. We built a small internal CLI that prints the tag tree for a route — saved at least four debugging hours so far.
The Pages Router isn't going away. If you're still on Pages Router, none of this applies. Vercel signaled at the March 2026 launch that Pages would be supported through at least 2028, but no new features are coming there. Migration to App Router is a prerequisite — non-trivial for any large legacy site.

The Bundler Implications

A side effect we didn't anticipate: cache components changed our bundle. Components marked "use cache" get extracted into separate chunks at build time so they can be shipped independently. Our app/_app.js shrank from 188 KB to 142 KB. First-load JS dropped enough to bump our PageSpeed score 4 points. None of the cache-components documentation mentions this; we noticed it inspecting the build output.

Combined with the Rust-based bundler improvements that landed in the Rust takeover of JavaScript tooling, our cold-start dev experience is now legitimately fast — next dev warm time dropped from 14 seconds to 4 seconds.

Should You Migrate?

If you're on App Router and your site is data-heavy or you have a large content surface, yes — the ROI is unambiguous. If you're on a small SPA-style App Router app with mostly dynamic content, the upside is smaller (you still get better mental model, but the bill won't move much). If you're on Pages Router, wait until you'd be doing a major rewrite anyway.

Our advice for teams about to start: do the migration as a series of small PRs, not a big-bang. The flag is opt-in for a reason. Migrate one route segment at a time, measure, ship. Anyone who tells you they migrated their whole site in a weekend either had a tiny site or is going to file three Sev-1 tickets next week.

A reasonable order of operations: enable the flag and fix breakages first (1-2 weeks), then add "use cache" to your hottest read paths (1 week), then tackle tag granularity and incident-proof your invalidation logic (1-2 weeks), then handle segment caching for personalized content (1 week). Total: 4-6 weeks for a meaningful site. Less if you're small, more if you're enterprise.

Conclusion

Cache components are the rare framework migration where the benefits exceed the marketing. The mental model is cleaner, the performance is real, and the bill goes down. The cost is six weeks of careful work and the willingness to pay attention to tag granularity. If you're already on App Router, this should be the next thing on your roadmap. The team that ships the cache-components migration in Q3 will out-perform the team that doesn't on every metric that matters — TTFB, LCP, build time, and the line item on the Vercel invoice that finance asks you about every quarter.

Originally published on The Stack Stories.

Fly with the Pilot

Nilesh Kasar — Tue, 12 May 2026 18:03:31 +0000

Fly with the Pilot

In 2020, a commercial airliner was on course to land at New York's John F. Kennedy International Airport when its crew reported a sudden loss of communication. Despite being in the midst of a densely populated airspace, air traffic controllers were able to quickly locate the aircraft using real-time flight tracking data and 3D visualization, guiding it safely to the ground. This incident highlights the significance of modern surveillance technologies like Automatic Dependent Surveillance-Broadcast (ADS-B) in ensuring air travel safety.

The ability to track planes in real-time and view their cockpits in 3D is made possible by advancements in ADS-B technology. This innovation has been driven by the aviation industry's need for enhanced safety and efficiency. Companies like Flightradar24 and Plane Finder have been at the forefront of this development, providing real-time flight tracking services to the public. The increasing availability of high-resolution satellite imagery has also contributed to the growth of this technology.

The key takeaway here is that ADS-B technology is not just about tracking planes; it's about using machine learning algorithms to predict potential flight disruptions, enabling more efficient air traffic management.

Predictive Maintenance: The Future of Air Traffic Management

ADS-B technology is integrated with machine learning algorithms to analyze real-time aviation data, predicting potential flight disruptions. This enables air traffic controllers to proactively manage air traffic, reducing delays and increasing overall efficiency. For instance, a study by the Federal Aviation Administration (FAA) found that the use of ADS-B technology reduced flight delays by 10% in 2020 alone. By leveraging this technology, airlines can minimize the impact of disruptions and ensure a smoother flying experience for passengers.

Search and Rescue Operations: A New Era of Response Time

When a plane goes missing, every minute counts. The use of real-time aviation data and 3D visualization can significantly improve the response time and effectiveness of search and rescue operations. By visualizing the aircraft's last known location, search teams can pinpoint potential crash sites, reducing the search area by up to 90%. This technology has been successfully used in several high-profile search and rescue operations, including the 2019 disappearance of Malaysia Airlines Flight 370.

Beyond Aviation: Unleashing the Potential of ADS-B Technology

The application of ADS-B technology extends beyond the aviation industry. Environmental monitoring, disaster response, and urban planning are just a few areas where this technology can have a significant impact. For example, researchers have used ADS-B technology to study bird migration patterns, providing valuable insights into the impact of climate change on ecosystems. Additionally, the FAA is exploring the use of ADS-B technology in disaster response, enabling first responders to quickly identify areas of need and allocate resources more effectively.

The Real Problem: Balancing Data Availability with Data Protection

While ADS-B technology has revolutionized the aviation industry, it raises concerns about privacy and national security. The increased availability of real-time flight data and 3D cockpit views may compromise sensitive information about airline operations, crew communications, and passenger data. As a result, companies like Flightradar24 and Plane Finder have implemented robust data protection measures to ensure that sensitive information is kept confidential. This highlights the importance of developing and implementing effective data protection policies to balance the benefits of ADS-B technology with the need to safeguard sensitive information.

What Most People Get Wrong: The Limitations of ADS-B Technology

Many people assume that ADS-B technology provides real-time data on every flight, everywhere in the world. However, this is not the case. ADS-B technology relies on satellite signals, which can be affected by weather conditions, interference, and other factors. Additionally, not all aircraft are equipped with ADS-B technology, and some countries have limited or no ADS-B coverage. This means that there are still significant gaps in our understanding of global air traffic patterns, highlighting the need for continued investment in this technology.

Conclusion: Embracing the Future of Aviation Surveillance

As the aviation industry continues to evolve, ADS-B technology will play an increasingly important role in ensuring safety, efficiency, and transparency. By embracing this technology and addressing the challenges associated with data protection, we can unlock its full potential and create a safer, more efficient air travel experience for all. To capitalize on this opportunity, airlines and aviation authorities should invest in robust data protection measures and continue to develop and implement effective ADS-B technology solutions.

Originally published on The Stack Stories.

Mac OS X on Wii

Nilesh Kasar — Tue, 12 May 2026 18:03:25 +0000

Mac OS X on Wii: Theoretical Possibilities and Technical Feasibility

When discussing homebrew development and modification of consumer electronics, one fascinating concept often surfaces: porting Mac OS X to the Nintendo Wii. This might seem far-fetched, but numerous experts have confirmed that, theoretically, such a port is possible. To understand why, we need to delve into the similarities between the PowerPC-based Wii processor and the PowerPC architecture used in older Macintosh computers.

The Wii's Broadway processor, a variant of the PowerPC 750, shares a significant amount of code with the G3 and G4 processors used in older Macs. This shared architecture makes it theoretically possible for developers to adapt Mac OS X to run on the Wii. However, this is not a trivial task. The Wii's hardware configuration is unique, and the operating system's kernel and device drivers would require significant modifications to accommodate it.

The key takeaway is that, despite the technical challenges involved, a successful port of Mac OS X to the Wii would demonstrate the versatility of open-source operating systems and the ingenuity of the homebrew development community. This project highlights non-obvious connections between the gaming industry and the broader field of computer science, particularly in areas like reverse engineering and low-level programming.

The Wii's Hardware Configuration

The Nintendo Wii's hardware is centered around its PowerPC-based processor, the Broadway. This processor is a variant of the PowerPC 750, which was widely used in older Macintosh computers. The Broadway is a 90nm SOI (Silicon on Insulator) process, with 128-bit floating-point operations and a maximum clock speed of 729 MHz. The Wii also features 88MB of RAM, which is dedicated to the GPU and 512MB of external RAM for the CPU.

The Wii's hardware configuration is what makes it theoretically possible for developers to adapt Mac OS X to run on the device. The shared PowerPC architecture between the Wii and older Macs provides a foundation for adaptation. However, the Wii's use of an external RAM module and a unique GPU requires significant modifications to the operating system's kernel and device drivers.

The Porting Process

Porting Mac OS X to the Wii would require a deep understanding of both the Wii's hardware configuration and the inner workings of the operating system. Developers would need to modify the kernel and device drivers to accommodate the Wii's unique hardware. This would involve rewriting significant portions of the operating system to ensure compatibility with the Wii's processor, RAM, and GPU.

The porting process would also require a thorough understanding of PowerPC assembly language and low-level programming. Developers would need to be familiar with the Wii's hardware registers, interrupts, and memory management unit (MMU) to ensure proper operation of the operating system.

What Most People Get Wrong

Many people assume that porting Mac OS X to the Wii would be a trivial task, simply a matter of copying the operating system onto a storage device and booting it. However, this is far from the truth. The Wii's hardware configuration is unique, and the operating system's kernel and device drivers would require significant modifications to accommodate it.

The real problem is not the technical feasibility of the port, but rather the time and effort required to complete it. Porting an operating system to a new platform is a complex task that requires a deep understanding of both the hardware and the software. It is not a task for the faint of heart, and it is certainly not something that can be completed in a matter of weeks or months.

The Benefits of a Successful Port

A successful port of Mac OS X to the Wii would have significant implications for the homebrew development community. It would demonstrate the versatility of open-source operating systems and the ingenuity of developers who push the boundaries of what is possible.

Furthermore, a successful port would inspire similar projects for other embedded systems. It would show that even the most complex and seemingly intractable problems can be solved with enough time, effort, and determination. This would have a positive impact on the broader field of computer science, particularly in areas like reverse engineering and low-level programming.

Conclusion and Recommendations

In conclusion, porting Mac OS X to the Wii is a challenging but theoretically possible task. While the technical requirements are significant, a successful port would have a positive impact on the homebrew development community and the broader field of computer science.

If you're interested in exploring this project further, I recommend starting by studying the Wii's hardware configuration and PowerPC assembly language. From there, you can begin to explore the inner workings of Mac OS X and how it can be adapted to run on the Wii.

But be warned: this project is not for the faint of heart. It requires a deep understanding of both the hardware and the software, as well as a significant amount of time and effort. If you're up for the challenge, however, it could be a rewarding and enlightening experience that pushes the boundaries of what is possible with homebrew development.

Originally published on The Stack Stories.

Unlocking Tmux Customization for Developers: A Comprehensive Guide

Nilesh Kasar — Tue, 12 May 2026 18:03:00 +0000

Unlocking Tmux Customization for Developers: A Comprehensive Guide

71% of developers rely on the terminal as their primary interface for development. Despite its importance, the default terminal experience often falls short of expectations. This is where Tmux comes in – a terminal multiplexer that has revolutionized the way developers work. With over 1,000 packages available on the Tmux Plugin Manager (TPM), the possibilities for customization are endless.

Tmux's impact extends beyond the development community. Traders and analysts in finance rely on complex terminal interfaces for real-time data analysis, mirroring the need for a seamless and customizable experience. The rise of remote work and the increasing need for developers to manage multiple projects and tasks simultaneously have fueled Tmux's growth. As we'll explore, there's more to Tmux customization than just aesthetics – it's about unlocking increased productivity and efficiency.

For those new to Tmux, it's essential to grasp the core concept: a terminal multiplexer is a single process that can manage multiple terminal sessions and windows. This fundamental idea sets the stage for the customization possibilities we'll delve into. With Tmux, you can create a tailored environment that boosts your productivity and makes your workflow more enjoyable.

Creating a Custom Tmux Environment: Getting Started

To unlock the full potential of Tmux, you need to configure it to your liking. This involves setting up the basic layout, including the number of windows, panes, and the initial layout. You can achieve this by modifying the ~/.tmux.conf file. Here's a basic example to get you started:

# Set the initial window layout to 2x2
set -g mode-keys vi
bind h select-pane -L
bind j select-pane -D
bind k select-pane -U
bind l select-pane -R

This configuration sets up a basic 2x2 layout using vi mode. You can customize this further by adding more bindings and mappings to suit your needs.

Customizing Tmux: Themes and Plugins

Tmux's popularity has led to the development of a thriving ecosystem of plugins and themes. With over 1,000 packages available on the TPM, you can find a wide range of options to suit your taste. Some popular themes include the Dracula theme, which offers a dark and sleek design, and the Material theme, which provides a modern and minimalist aesthetic.

In addition to themes, plugins offer a wealth of functionality. Some popular plugins include:

tmux-resurrect: allows you to save and restore your Tmux sessions
tmux-save-buffer: saves the buffer contents to a file
tmux-persist-on: keeps the terminal session alive even when the connection drops

When selecting plugins, consider the specific use cases and features you need. For example, if you work with multiple projects, you might want to use tmux-resurrect to save and restore your sessions.

What Most People Get Wrong

Many developers struggle with Tmux because they focus on aesthetics rather than functionality. This is where most people go wrong – they get caught up in making their Tmux environment look pretty, but neglect to optimize its performance. In reality, the most effective Tmux configurations are those that prioritize functionality and ease of use.

A common mistake is to over-complicate the configuration by adding too many plugins and mappings. This can lead to a cluttered and confusing interface, ultimately defeating the purpose of using Tmux in the first place. Instead, focus on the essential features and mappings that enhance your productivity.

Tmux Productivity Hacks

To take your Tmux setup to the next level, consider the following productivity hacks:

Use tmux-continuum to create a continuous, infinite loop of terminal windows
Employ tmux-session-manager to manage and organize your Tmux sessions
Utilize tmux-clipboard to copy and paste text between Tmux windows

These hacks can significantly improve your workflow by streamlining essential tasks and reducing the time spent switching between windows.

Conclusion: Unlocking Tmux Customization

Tmux has revolutionized the way developers work by offering a customizable and seamless experience. By unlocking its full potential, you can increase your productivity and make your workflow more enjoyable. With this comprehensive guide, you've learned how to create a custom Tmux environment, customize your layout with themes and plugins, and optimize your performance with productivity hacks.

Originally published on The Stack Stories.

CadQuery Simplifies 3D Modeling

Nilesh Kasar — Tue, 12 May 2026 18:02:52 +0000

CadQuery Simplifies 3D Modeling

In the past year, the CadQuery open-source library has grown by 20% month-over-month, with over 1,000 new users joining its community. What's driving this growth? A combination of factors, including CadQuery's unique strengths in parametric design and its Pythonic API, which has made it a go-to choice for industries like aerospace and automotive. But beyond its technical merits, CadQuery's rise reflects a broader shift towards open-source and collaborative development in the CAD industry.

At its core, this shift is about customizability, flexibility, and cost-effectiveness. Traditional CAD software vendors like Autodesk and SolidWorks charge premium prices for their products, often limiting users to a specific set of features and workflows. In contrast, CadQuery's open-source nature allows users to modify and extend the library to suit their specific needs. This has significant implications for industries where complex geometries and iterative design processes are common.

The key takeaway here is that CadQuery is not just another tool for 3D modeling – it's a game-changer for industries that require customization and flexibility. With its growing community and increasing adoption, CadQuery is poised to disrupt traditional CAD software markets dominated by proprietary vendors.

Parametric Design

One of the most significant implications of CadQuery's parametric design capabilities is for industries like aerospace and automotive. In these fields, complex geometries and iterative design processes are common, and the ability to easily modify and optimize designs is essential. CadQuery's parametric design capabilities make it possible to create complex models using a high-level, object-oriented syntax. This is a major departure from traditional CAD software, which often relies on low-level, procedural code.

For example, consider a typical aircraft fuselage design. With CadQuery, a designer can create a parametric model that takes into account factors like aerodynamics, weight, and structural integrity. This model can be easily modified and optimized using a variety of techniques, from numerical methods to machine learning algorithms. The result is a highly customized design that meets the specific needs of the project.

Integration with Data Science and Machine Learning

CadQuery's Python interface has facilitated integration with popular data science and machine learning frameworks like NumPy, pandas, and scikit-learn. This has enabled new applications in fields like generative design and design optimization. For example, a designer can use CadQuery to generate a set of parametric models, and then use machine learning algorithms to optimize the design for specific criteria like weight, cost, or performance.

This integration is not limited to data science and machine learning. CadQuery can also be used with popular libraries like Blender and FreeCAD, enabling a wide range of applications from computer-aided design to computer-aided engineering.

Security and Reliability

Contrary to conventional wisdom, the open-source nature of CadQuery may actually enhance its security and reliability. A community-driven development process can lead to more rigorous testing and bug fixing, as multiple developers and users work together to identify and resolve issues.

In fact, a study by the Linux Foundation found that open-source software tends to have fewer vulnerabilities and bugs than proprietary software. This is because open-source projects are often driven by a community of developers who are motivated to improve the software, rather than a single vendor trying to maximize profits.

What Most People Get Wrong

Many people assume that open-source software is inherently insecure or unreliable. However, this couldn't be further from the truth. In reality, open-source software is often more secure and reliable than proprietary software, due to the collaborative nature of the development process.

Another common misconception is that open-source software is only suitable for hobbyists or enthusiasts. However, CadQuery is used by industry professionals and researchers alike, and its capabilities are unmatched by many proprietary CAD software tools.

The Real Problem

The real problem with traditional CAD software is that it's often too rigid and inflexible. Users are limited to a specific set of features and workflows, and customizability is often non-existent. This can lead to a range of issues, from design inefficiencies to cost overruns.

In contrast, CadQuery offers a highly customizable and flexible solution that can be tailored to meet the specific needs of any project. Whether you're a hobbyist or an industry professional, CadQuery is an essential tool for anyone working with 3D modeling and CAD design.

Conclusion and Recommendation

The rise of CadQuery reflects a broader shift towards open-source and collaborative development in the CAD industry. With its parametric design capabilities, integration with data science and machine learning frameworks, and secure and reliable open-source nature, CadQuery is poised to disrupt traditional CAD software markets dominated by proprietary vendors.

If you're working with 3D modeling and CAD design, I highly recommend giving CadQuery a try. Its Pythonic API and open-source nature make it an ideal choice for anyone looking for a highly customizable and flexible solution. Whether you're a hobbyist or an industry professional, CadQuery is an essential tool that can help you create complex models with ease.

Originally published on The Stack Stories.

Cloud Repatriation: The Hidden Costs of Public Cloud Architecture

Nilesh Kasar — Sat, 09 May 2026 07:19:02 +0000

When 37signals reported in late 2024 that they had saved over $2 million by leaving AWS, a wave of CTOs ran the numbers and quietly came to the same conclusion: for predictable, steady-state workloads, the public cloud has gotten expensive in ways that are hard to defend on a finance call.

Two years later, repatriation is not a fringe move. It is a default consideration on any infrastructure review at a company past Series B with stable demand.

The Three Cost Drivers Behind Repatriation

The math has not really changed. The visibility of the math has.

Egress Fees

AWS charges roughly $0.09 per GB out to the internet beyond the first 100 GB. For a company moving 200 TB/month, that is over $18,000 monthly — for the privilege of letting your data leave. Hetzner charges zero. Cloudflare R2 charges zero. The egress tax is now the single most cited reason for moving.

GPU Markups

H100 instances on AWS list at roughly 3-4x the bare-metal cost amortized over depreciation. For AI workloads, this delta is often the entire margin of the business.

Predictability Premium

Cloud is priced for elasticity. If your workload is not elastic, you are paying for an option you never exercise.

When Repatriation Does Not Pay

Repatriation is a trap for:

Pre-Series-A startups (your time is more valuable than the savings)
Genuinely bursty workloads (the cloud was actually designed for these)
Compliance-heavy industries without dedicated platform staff
Teams without at least one engineer who has run a fleet before

The Modern Hybrid Stack

The teams getting this right do not pick a side. They run a hybrid:

Workload	Where it runs
Steady-state web tier	Hetzner / OVH / colo
GPU training	Lambda Labs, Crusoe, dedicated
Bursty traffic	AWS, Cloudflare Workers
Object storage	Cloudflare R2, Backblaze B2
Edge	Cloudflare, Vercel

Tooling like Pulumi, Crossplane, and the maturing Talos Linux distribution have made multi-environment Kubernetes nearly turnkey for teams of any size.

The Real Takeaway

Cloud repatriation is not about hating AWS. It is about matching workload shape to pricing shape. The cloud is exquisite for spiky, unpredictable demand and miserable for steady-state at scale. Most companies have both — the question is whether your bill reflects that.

Sustainable Tech: Why Green Datacenters Are Non-Negotiable

Nilesh Kasar — Sat, 09 May 2026 07:18:45 +0000

The Hidden Carbon Cost of Artificial Intelligence

The explosive growth of generative AI has brought about a silent environmental crisis. Training a single massive frontier model consumes as much electricity as thousands of homes use in a year. Furthermore, the inference required to answer millions of daily AI queries requires an unprecedented density of GPU clusters.

Data centers, which once accounted for a negligible fraction of global power consumption, are now straining municipal power grids worldwide. The tech industry can no longer ignore its carbon footprint. The pivot to Green Datacenters is no longer a PR initiative; it is a regulatory and operational necessity.

The Death of Traditional Air Cooling

To understand the energy crisis, one must look at how data centers are cooled. Historically, massive HVAC systems pumped chilled air through server racks. This method is incredibly inefficient. As GPU architectures (like Nvidia's Blackwell series) push thermal limits to extremes, air cooling is physically incapable of dissipating the heat.

The industry standard has shifted to Direct-to-Chip Liquid Cooling and Immersion Cooling. By submerging server motherboards entirely in non-conductive, dielectric fluid, data centers can remove heat with near-perfect efficiency. This eliminates the need for massive fans and air conditioners, drastically lowering the Power Usage Effectiveness (PUE) ratio of the facility.

Strategic Location and Renewable Microgrids

You can no longer build a data center anywhere. The new strategy is geographic optimization. Tech giants are placing new infrastructure directly adjacent to stranded renewable energy sources:

Geothermal in Iceland: Tapping into the earth's natural heat to power servers with zero emissions.
Hydroelectric in Scandinavia: Utilizing massive, consistent water flow to power and cool server farms simultaneously.

Additionally, we are seeing the rise of Nuclear-Powered Data Centers. Small Modular Reactors (SMRs) are being co-located with server farms to provide 24/7, zero-carbon baseload power that wind and solar cannot guarantee.

The Path to Net-Zero

Major cloud providers have pledged to become carbon negative by 2030. Achieving this requires not just green energy, but circular hardware lifecycles—recycling rare earth metals from decommissioned GPUs and repurposing excess server heat to warm local municipal buildings.

Conclusion: Sustainability is the new frontier of tech infrastructure. Companies that fail to optimize for energy efficiency will find themselves crippled by soaring power costs and strict government carbon taxes.

Originally published on The Stack Stories.

The Demise of the 9-to-5: How Async Work is Winning

Nilesh Kasar — Sat, 09 May 2026 07:18:29 +0000

The Remote Work Hangover

When the pandemic forced the corporate world into remote work, companies made a fatal architectural error: they simply digitized the physical office. Instead of walking into a conference room, employees logged into back-to-back Zoom calls. Instead of tapping a colleague on the shoulder, they sent rapid-fire Slack messages demanding instant replies.

We achieved remote work, but we lost deep work. The constant context-switching of synchronous communication has led to unprecedented employee burnout. The correction is finally here: the transition to Asynchronous Work.

The Asynchronous Advantage

Asynchronous (async) communication operates on a simple premise: information is exchanged without the expectation of an immediate response. This respects the maker's schedule and allows global teams to collaborate seamlessly across twelve different time zones without forcing someone to wake up at 3:00 AM for a status update.

Companies that master async work—like GitLab, Automattic, and Doist—report massively higher output quality. When employees are given the space to focus for four uninterrupted hours, they produce better code, better designs, and better strategies.

The New Async Tool Stack

The tools that define a company's culture are changing. We are moving away from ephemeral chat and video calls toward persistent, structured communication:

Async Video (Loom): Replacing the "quick 15-minute sync" with a 3-minute screen recording that the recipient can watch at 1.5x speed whenever they have downtime.
Structured Decision Logs (Notion, Linear): Moving away from making decisions in messy Slack threads to using centralized, searchable documents where context is preserved forever.
Threaded Communication (Twist, Campfire): Replacing chaotic chat channels with strictly threaded conversations, ensuring that discussions stay on topic and don't require constant monitoring.

The Cultural Shift: A Writing Culture

Transitioning to async is not a software problem; it is a cultural problem. Async work absolutely requires a Writing Culture.

If you cannot communicate clearly, concisely, and completely in written form, you cannot survive in an async environment. Every proposal, bug report, and strategy document must contain enough context that the reader can fully understand the issue without needing to ask a clarifying question.

The Future: The 9-to-5 schedule was an artifact of the industrial revolution. In the knowledge economy, forcing everyone to think at the same time is wildly inefficient. The future belongs to organizations that measure output, not hours spent in a Zoom grid.

Originally published on The Stack Stories.

Cybersecurity in the Era of Deepfakes and AI Phishing

Nilesh Kasar — Sat, 09 May 2026 07:17:39 +0000

In February 2026, a finance employee at a Hong Kong subsidiary of Arup wired $25 million to attackers after a video call with what appeared to be the company's CFO and several colleagues. Every face on the call was synthetic. The voices were synthetic. The mannerisms had been trained on YouTube earnings calls.

This is not a hypothetical anymore. The FBI's Internet Crime Complaint Center logged $1.4 billion in deepfake-driven business email and voice compromise in 2025 alone. The defensive playbook that worked in 2023 — "call back on a known number" — is no longer sufficient because the known number can be spoofed and the voice on the other end can be cloned in real time.

What Changed in 2026

Three things hit production-grade quality almost simultaneously:

Real-time face-swap on consumer GPUs (sub-50ms latency)
Voice cloning from <5 seconds of audio (ElevenLabs Flash v2, similar)
Open-source models that match closed-source quality

The threat actor's marginal cost dropped to near zero. Defense had to industrialize.

The Modern Defense Stack

Layer	Tooling
Identity provenance	C2PA content credentials, device attestation
Liveness detection	Persona, Onfido, Stripe Identity
Voice biometrics	Pindrop, Nuance Gatekeeper
Real-time deepfake detection	Reality Defender, Sensity, Truepic
Process controls	Out-of-band confirmation, dual-authorization

Cryptographic Provenance Wins Long-Term

The most durable defense is not detection — it is provenance. C2PA-signed media, hardware attestation on capture devices, and authenticated cameras on phones flip the model: instead of trying to spot fakes, you require proof of authenticity. Adobe, Sony, Nikon, and (as of late 2025) Apple's iPhone capture pipeline all support C2PA signing now.

Process Beats Technology

The Arup attack succeeded despite the company having strong endpoint security. The control that would have stopped it — mandatory out-of-band verification of any wire transfer above a threshold — was a process control, not a technology one. Mature security programs are leaning back into procedures the technology era tried to eliminate.

The AI-vs-AI Arms Race

Detection vendors and synthesis vendors are now in a continuous catch-up loop. Reality Defender publishes detection improvements; the next open-source diffusion model defeats them within weeks. This pattern will not stabilize. Treat detection as defense-in-depth, not a primary control.

The Takeaway

The era when "I saw it with my own eyes" was a sufficient verification primitive is over. The replacement is layered: cryptographic provenance for media, process controls for authorization, and AI detection as one signal among several. Any single-layer defense is one model release away from obsolete.

Rust Quietly Took Over JavaScript Tooling: A 2026 Map of What Replaced What

Nilesh Kasar — Sat, 09 May 2026 07:17:32 +0000

The day my CI pipeline went from 11 minutes to 90 seconds

Last month I migrated a 240K-line TypeScript monorepo from a Node-based toolchain — Webpack, ESLint, Prettier, Jest, tsc — to an almost entirely Rust-based one: Turbopack, Oxc, Biome, Vitest with Rolldown, and tsgo. CI fell from 11 minutes 14 seconds to 1 minute 28 seconds. Local dev startup went from 8.4 seconds to 0.6.

This is not an isolated number. It is the tail end of a quiet, three-year rewrite of the JavaScript toolchain in Rust and Go. As of mid-2026 the rewrite is mostly done. Here is the practical map for working developers.

What got replaced, by tool

The state of play, with what most teams should actually be running:

Job	Old (Node)	New (Rust/Go)	Status May 2026
Bundler (app)	Webpack, Rollup	Turbopack, Rspack, Rolldown	GA, ship it
Bundler (lib)	Rollup, tsup	Rolldown, tsdown	GA, ship it
Dev server	Vite (esbuild)	Vite 7 + Rolldown	GA, default
Linter	ESLint	Biome 2, Oxlint	GA, ship it
Formatter	Prettier	Biome 2	GA, ship it
Type checker	tsc	tsgo (Go), stc (Rust)	tsgo beta May 2026
Test runner	Jest, Vitest	Vitest + Rolldown	GA
Package manager	npm, yarn	pnpm, Bun	GA
Monorepo	Lerna, Nx (JS)	Turborepo, Nx (Rust core)	GA
Minifier	Terser	swc, Oxc minify	GA

If you are still on Webpack and ESLint in mid-2026, you are not behind in some abstract sense. You are paying real money in CI time and developer minutes every day.

The big four to know

Four tools dominate the new landscape. Knowing what each one is for clarifies the rest.

Oxc

Oxc is a Rust-based JavaScript and TypeScript toolchain from a small team led by Boshen. It includes a parser, linter (Oxlint), resolver, and minifier. Oxlint is roughly 50-100x faster than ESLint on equivalent rule sets. As of v1.0 in early 2026, it covers roughly 85% of common ESLint rules and runs as a drop-in pre-pass in many setups.

Biome

Biome 2 (released February 2026) is a Rust-based linter and formatter that aims to fully replace ESLint and Prettier. It is opinionated, fast, and trades off some ESLint plugin compatibility for coherence. For a greenfield project, Biome is the default I would pick. For an existing project, Oxlint is often easier to slot in alongside ESLint.

Rolldown and Turbopack

Rolldown is a Rust port of Rollup with Vite compatibility, now powering Vite 7 by default. Turbopack is Vercel's Rust bundler, the engine inside Next.js 15+. They are not really competitors: Rolldown is the universal library and app bundler, Turbopack is tightly integrated into Next.js dev and build.

For most Vite users, the migration to Rolldown is invisible — it just becomes the default. For Next.js users, Turbopack is now the default in dev and stable for production builds as of Next.js 15.4.

tsgo

tsgo is the Go rewrite of the TypeScript compiler that Microsoft began publicly previewing in March 2025 and which entered beta in early 2026. On large codebases, type checking is roughly 10x faster. It is not yet GA for production type checking but is increasingly safe for editor IntelliSense and CI parallel checks. The plan, per the official roadmap, is parity with tsc by late 2026.

Real performance numbers

On the same 240K-line monorepo, before and after migration:

ESLint over the whole repo: 94s. Oxlint: 1.7s.
Prettier check: 41s. Biome check: 0.9s.
tsc full check: 76s. tsgo full check: 8s.
Webpack production build: 6m 12s. Turbopack: 41s.
Jest full suite: 3m 30s. Vitest with Rolldown: 1m 5s.
Total CI: 11m 14s to 1m 28s.

The wins compound. Faster lint encourages stricter rules. Faster type checks encourage smaller, more incremental PRs. Faster builds enable preview deploys per commit instead of per merge. The cultural shift from these tools is at least as valuable as the raw seconds saved.

What to be careful about

A few traps I hit personally:

Biome plugin parity is not 100%. If you depend on niche ESLint plugins (eslint-plugin-jest-dom, custom internal plugins), audit before migrating. Oxlint is a softer landing because it can run alongside ESLint.
Rolldown breaking changes are still landing. It is GA in Vite 7 but expect occasional plugin incompatibilities through Q3 2026. Pin versions in libraries.
tsgo is beta. Use it for editor and CI parallel checks. Do not rely on it as your only type-check gate yet.
Bun vs Node in production. Bun is fast, but production parity with Node is still imperfect for some npm packages. We use pnpm in CI and Node in production, with Bun only in local scripts.
Editor extension lag. Some editor integrations — VS Code in particular — picked up Biome and Oxlint quickly, but JetBrains and Neovim plugins lagged by several months. If your team standardizes on a non-VSCode editor, check support before committing.
Source map fidelity. Rust bundlers have caught up but historically had subtle source map bugs that broke Sentry-style error reporting. Verify your error monitoring still works post-migration. We caught a 3-week window where stack traces were one line off after a Turbopack upgrade.

The migration we got wrong

Not every swap was painless. Our first attempt to move from Jest to Vitest broke 47 snapshot tests because Vitest's snapshot serialization differs subtly from Jest's. We accepted the new snapshots wholesale, which masked one real regression that customer support eventually surfaced. The lesson: when changing a test runner, do not accept a wave of snapshot changes blindly. Either migrate snapshots one suite at a time with manual review, or treat the first post-migration release with extra production monitoring.

The second mistake was migrating the linter and the formatter in the same week. When CI started failing differently, we could not isolate which tool was at fault. Stagger toolchain swaps. One change per week, ideally one per fortnight, with a clean baseline between them.

Why Rust won the tooling layer

Rust did not win because of language ideology. It won because three properties matched the work:

Predictable performance with no GC pauses, which matters for incremental tooling that runs on every keystroke.
Strong concurrency primitives that map well to multi-core lint and build work.
A coherent ecosystem (swc, oxc, biome) where teams build on each other's parsers and ASTs.

Go has carved out a parallel niche, mostly via Microsoft picking it for tsgo because of its ecosystem fit at Microsoft. The future is plural: Rust dominates the broader tooling, Go owns the type checker, and JavaScript itself remains the language we write.

The interesting open question is what happens to authoring. So far the rewrite has been about tools that operate on JavaScript, not the language itself. But TypeScript 6, expected later in 2026, will ship with the tsgo runtime as the default in some configurations, which means even the language tooling we touch every day will have a non-JavaScript core. Five years ago that would have felt strange. In 2026 it feels obviously correct.

The ecosystem cost of speed

One concern worth voicing: the Rust toolchain, while faster, is harder for casual contributors to extend. ESLint plugins are JavaScript files anyone can write. Oxlint and Biome rules require Rust knowledge, and the contributor pool is smaller. Long-term, this could slow down the rate of new rule innovation in linters specifically. The maintainers are aware of this and both Oxc and Biome are working on plugin systems that allow JavaScript extensions, but neither is fully landed as of May 2026.

This is a real trade-off, not a deal-breaker. Most teams use a small, stable set of rules and benefit from the speed far more than they suffer from harder-to-write plugins. But if your codebase depends on dozens of niche or in-house ESLint rules, weigh the migration cost honestly.

What this means for you

A practical 2026 migration order for an existing JS/TS project:

Replace Prettier with Biome formatter. Lowest risk, instant win.
Add Oxlint as a pre-pass alongside ESLint. Catch the easy stuff fast.
Move to Vite 7 (or stay on it; Rolldown is now under the hood).
Adopt Vitest if you are still on Jest.
Try Turbopack if you are on Next.js 15+.
Add tsgo for editor and CI parallel type checks; keep tsc as the gate.
Evaluate full Biome (linter + formatter) and full Oxlint replacement once your plugin audit allows.

The era of "JavaScript tooling written in JavaScript" is ending not because of fashion but because the math no longer favors it. The Rust toolchain is faster, more reliable, and increasingly easier to adopt. The good news is that for most application developers, this migration is not a rewrite. It is a series of small, low-risk swaps that quietly hand back hours of your week.

FAQ

Originally published on The Stack Stories.

React 19 Server Actions in Production: A Year of Lessons From a 4M-User App

Nilesh Kasar — Sat, 09 May 2026 07:16:57 +0000

The PR that deleted 12,000 lines of API routes

In April 2025, I merged a PR that removed 12,387 lines of /api route handlers, tRPC procedures, and useMutation hooks. We replaced all of it with React 19 Server Actions on Next.js 15.4. Twelve months later, with 4 million monthly active users on the platform, I have a clear-eyed view of what that decision bought us and what it cost.

Short version: I would do it again. With caveats.

What Server Actions actually are

Server Actions, finalized in React 19 (December 2024), let you call a server function directly from a client component as if it were local. You annotate a function with "use server", import it, and call it. React handles the network, serialization, and revalidation.

"use server";
export async function updateProfile(formData: FormData) {
  const name = formData.get("name") as string;
  await db.user.update({ where: { id: userId }, data: { name } });
  revalidatePath("/profile");
}

That is the whole API. It is genuinely simpler than tRPC, REST, or GraphQL for the 80% case.

What got better immediately

A few wins showed up within the first sprint:

Form code shrank by 60%. Pairing useActionState with the native <form action> attribute removed a tower of onSubmit, useState, isPending, and useMutation boilerplate.
Progressive enhancement came back. Forms work without JavaScript. Our Lighthouse accessibility scores climbed from 89 to 97 across the funnel.
Type safety end-to-end without codegen. Functions are imported, so TypeScript flows naturally. We deleted our entire OpenAPI generator pipeline.
Smaller client bundles. Removing tRPC client code shaved roughly 38KB gzipped from our home route. LCP on slow 4G dropped 240ms.

What bit us

Now the honest part.

Validation is your problem

Server Actions do nothing for validation. You will validate input yourself. We standardized on Zod 4 with a thin wrapper:

export const action = createAction(
  z.object({ email: z.email(), name: z.string().min(1) }),
  async (input, ctx) => { /* ... */ }
);

Without that wrapper, every action grew its own ad-hoc validation. After three of those, we wrote the wrapper. Do this on day one.

Error handling is awkward

Throwing inside a Server Action surfaces as a generic error to the client. You lose structured error info. The community pattern, and the one we adopted, is to return a typed result object instead of throwing:

return { ok: false, error: "EMAIL_TAKEN" } as const;

Combined with useActionState, this gives clean per-field error rendering. But it means every action needs explicit return-type discipline.

The N+1 mutation trap

Server Actions feel cheap to call. They are not. Each one is a POST to your origin with a full RSC payload roundtrip. Inline-editing 50 list items by firing 50 actions in parallel will hammer your server. We caught this in load testing at 3,200 RPS. The fix is the same as REST: batch on the client, expose a bulkUpdate action.

Caching and revalidation is the real frontier

revalidatePath and revalidateTag are powerful and easy to misuse. Calling revalidatePath("/") from a settings action invalidates the entire site. We wrote a lint rule that flags broad revalidations and forces tag-based invalidation for anything beyond a single route.

Auth context inside actions

A subtle gotcha: Server Actions run on the server, but they are reachable by anyone who can call the function. They are public endpoints. We saw one team ship an admin-only deleteUser action without a permission check, assuming "it's only called from the admin page." It was not. A curious user found the action endpoint in the network tab and triggered it. Treat every Server Action as a public API endpoint and gate it accordingly. Our createAction wrapper now requires an explicit auth policy argument; you cannot create an action without declaring who can call it.

File uploads and large payloads

Server Actions serialize arguments as a multipart form payload, which makes File and FormData first-class citizens. That is genuinely nicer than JSON-encoded base64 in REST. But the platform default size limit is 1MB on Vercel, easy to bump but easy to forget. For multi-megabyte uploads we still use signed URLs to S3, then call a Server Action with just the resulting key. Server Actions are excellent for control-plane operations and awkward for raw data transfer.

The patterns that survived

After a year, these are the conventions that stuck:

One action per file in /app/_actions. Discoverable, easy to grep.
Typed return objects, never throws. {ok: true, data} or {ok: false, error}.
Zod-validated inputs through a shared createAction wrapper.
useActionState for forms, plain async calls for non-form mutations.
Tag-based revalidation only. Path-based is too coarse at scale.
Optimistic updates via useOptimistic. Worth the API surface; users feel the difference.

How Server Actions compare to alternatives

Approach	DX	Type safety	Bundle cost	Fits well for
Server Actions	Highest	Native	Lowest	Forms, mutations, internal apps
tRPC v11	High	Native	Medium	Complex client orchestration
REST + OpenAPI	Medium	Via codegen	Medium	Public APIs, mobile clients
GraphQL	Medium	Via codegen	Highest	Multi-consumer, federated graphs

If your client is only your own Next.js app, Server Actions win. The moment you need to serve a mobile app or a third party, you still want a real API. We kept tRPC for our public partner endpoints.

What about React Query?

The most common question we get from teams considering this migration: do Server Actions kill TanStack Query? Mostly no. Server Actions handle mutations beautifully. Queries — especially client-driven, polling, infinite-scroll, or cache-heavy queries — still benefit from TanStack Query on top. A pragmatic split is RSC + Server Actions for reads that align with the page lifecycle, and TanStack Query for genuinely client-driven async state. Our app uses both, deliberately.

Performance numbers from production

Comparing the same checkout flow before (tRPC + REST hybrid) and after (Server Actions on Next.js 15.4):

Median time-to-mutation-success: 412ms to 287ms
p95 client JS for the route: 184KB to 121KB gzipped
Form abandonment rate: 11.2% to 8.7%
Cold-start function duration on Vercel: roughly equivalent, both around 90ms

The bundle and abandonment wins were larger than the latency win. That tracks: Server Actions remove client work, not server work.

Testing strategy for Server Actions

Testing was the question I had no good answer to for the first three months. The patterns that survived:

Unit-test the action body, not the action. Extract the core logic into a plain async function that the action calls. Test that function with normal mocks. The "use server" wrapper is glue.
Integration tests via Playwright. Real form submissions in a real browser. Slower, but catches the things unit tests cannot — serialization, auth, revalidation behavior.
Type-level tests with expectTypeOf. Server Actions are imported, so misuse shows up at compile time. Add typed contract tests where the return shape matters.

We deleted our entire MSW-based mock layer. With Server Actions there is no fetch to mock; the function is the function. The testing simplification alone justified the migration for our team.

A year of metrics worth sharing

Beyond the per-flow numbers above, the broader engineering health metrics moved in the right direction over twelve months:

Average PR size in the web app: down 22%, because feature scaffolding takes less code.
New-engineer time-to-first-merged-PR: from 9 days to 4 days. Less infrastructure to learn.
Production incidents tagged "API" or "client/server contract": down 38%.

Correlation, not causation, but the direction is consistent.

What this means for you

If you are starting a Next.js project in 2026, default to Server Actions for mutations. Do not build a parallel API layer until you have a second consumer.

If you have an existing tRPC or REST codebase, do not migrate everything. Migrate one feature, get the patterns right, then expand. Our migration took six months and we still have a small /api surface for webhooks, mobile, and partners.

The biggest mindset shift: stop thinking about endpoints. Start thinking about server functions you can call from anywhere in your component tree. That is the actual upgrade React 19 delivered, and it changes how you design features more than any individual API improvement of the last five years.

One closing observation: Server Actions have changed how new engineers on our team learn the codebase. They no longer have to mentally trace a click through a fetch hook, an API route handler, a controller, and a service. They follow an import. Onboarding documentation that used to need a sequence diagram now needs a paragraph. That alone is worth more than any of the performance numbers above. The best frameworks make the right thing the obvious thing, and for the first time in years, doing mutations the right way in React feels like the path of least resistance instead of the path of most ceremony.

FAQ

Originally published on The Stack Stories.

DEV Community: Nilesh Kasar

Claude Skills vs Custom MCP Servers: Which to Build in 2026

The Two Things Being Compared

When Skills Win

When MCP Servers Win

A Concrete Decision Matrix

The Hybrid Pattern Most People Miss

The Auth Story Is Different in Each

Cost Comparison

Latency Differences

The Migration Path

What I'd Build Today

A Few Underrated MCP Features

Operating an MCP Server in Production: A Short Checklist

Where Both Ecosystems Are Heading

Conclusion

Next.js 16 Cache Components: A Real Migration From a 4.2M-MAU Site

What Cache Components Are, and Why They Replaced fetch-Based Caching

Our Starting Point

The Migration in Six Phases

Phase 1: Enable the flag, fix the breakage (Week 1)

Phase 2: Identify caching candidates (Week 1-2)

Phase 3: Apply "use cache" to the obvious wins (Week 2-3)

Phase 4: Tag invalidation strategy (Week 3-4)

Phase 5: Per-user-but-cacheable patterns (Week 4-5)

Phase 6: Production rollout and the incidents (Week 5-6)

The Numbers After Migration

What Cache Components Don't Solve

The Bundler Implications

Should You Migrate?

Conclusion

Fly with the Pilot

Predictive Maintenance: The Future of Air Traffic Management

Search and Rescue Operations: A New Era of Response Time

Beyond Aviation: Unleashing the Potential of ADS-B Technology

The Real Problem: Balancing Data Availability with Data Protection

What Most People Get Wrong: The Limitations of ADS-B Technology

Conclusion: Embracing the Future of Aviation Surveillance

Mac OS X on Wii

Unlocking Tmux Customization for Developers: A Comprehensive Guide

Creating a Custom Tmux Environment: Getting Started

Customizing Tmux: Themes and Plugins

What Most People Get Wrong

Tmux Productivity Hacks

Conclusion: Unlocking Tmux Customization

CadQuery Simplifies 3D Modeling

Parametric Design

Integration with Data Science and Machine Learning

Security and Reliability

What Most People Get Wrong

The Real Problem

Conclusion and Recommendation

Cloud Repatriation: The Hidden Costs of Public Cloud Architecture

The Three Cost Drivers Behind Repatriation

Egress Fees

GPU Markups

Predictability Premium

When Repatriation Does Not Pay

The Modern Hybrid Stack

The Real Takeaway

Related Reading

Sustainable Tech: Why Green Datacenters Are Non-Negotiable

The Hidden Carbon Cost of Artificial Intelligence

The Death of Traditional Air Cooling

Strategic Location and Renewable Microgrids

The Path to Net-Zero

The Demise of the 9-to-5: How Async Work is Winning

The Remote Work Hangover

The Asynchronous Advantage

The New Async Tool Stack

The Cultural Shift: A Writing Culture

Cybersecurity in the Era of Deepfakes and AI Phishing

What Changed in 2026

The Modern Defense Stack

Cryptographic Provenance Wins Long-Term

Process Beats Technology

The AI-vs-AI Arms Race

The Takeaway

Related Reading

Rust Quietly Took Over JavaScript Tooling: A 2026 Map of What Replaced What

What Cache Components Are, and Why They Replaced `fetch`-Based Caching

Phase 3: Apply `"use cache"` to the obvious wins (Week 2-3)