DEV Community: Yuki Nishikawa

Next.js Forgot to Design APIs. Tirne Didn’t.

Yuki Nishikawa — Tue, 17 Jun 2025 14:44:44 +0000

Struggling to trace side effects in Next.js API Routes?
Tired of global middleware, nested folders, and 300ms cold starts?

Tirne is here to change that. It's not just a framework. It’s a declarative, fetch-native architectural DSL for building edge-first APIs.

Tirne doesn’t just run your code. It structures it.

✨ Core Philosophy

Declarative routes: Define your API like a schema, not scattered handlers
Explicit side effects: Middleware is opt-in, visible, testable
Edge-native speed: Designed for Bun, Workers, and zero-cold-start runtimes
Type-aligned logic: Middleware and handlers work seamlessly with types

🛠️ 1. Quick Start

npx create-tirne-app
✔ Choose your target environment: › Bun / Workers
✔ Project folder: … my-tirne-app

cd my-tirne-app
bun install or npm install
npm run dev or wrangler dev

✨ Your API will be available at http://localhost:3000.

Project Structure:

index.ts: Entry point using fetch-compatible interface
package.json: Preconfigured for Bun or Workers
tsconfig.json: Minimal but typed setup

⚡️ 2. Performance Benchmarks

bunx autocannon -c 100 -d 10 <http://localhost:3000/>

Metric	Tirne (Bun)	Next.js API Routes
❄️ Cold Start	0.02 ms	~300 ms
⚡️ First Request	0.79 ms	20-30 ms
♻️ Requests/sec	90,000+ rps	8,000-10,000 rps
📉 Avg Latency	<1ms	~15ms+

🚀 Tirne is 10x faster than Next.js API Routes — and that’s before tuning.

📀 3. Hello Tirne (Structured Example)

import { Server } from "tirne";

const server = new Server([
  { method: "GET", path: "/health", handler: () => new Response("✅ OK") }
]);

export default {
  fetch: (req: Request) => server.fetch(req),
};

▶️ Compare that to a full folder in /pages/api/health.ts and global middleware.

🔒 4. Real Auth, Architected

import { Server, json, setCookie, requireAuth } from "tirne";
import type { Route } from "tirne";

const routes: Route[] = [
  {
    method: "GET",
    path: "/login",
    handler: () => {
      const headers = new Headers();
      headers.append("Set-Cookie", setCookie("auth", "valid-token", {
        httpOnly: true,
        path: "/",
        maxAge: 3600,
      }));
      return json({ message: "Logged in" }, 200, headers);
    },
    middleware: [],
  },
  {
    method: "GET",
    path: "/private",
    handler: () => json({ message: "Secret" }),
    middleware: [requireAuth],
  },
];

const server = new Server(routes);

export default {
  fetch: (req: Request) => server.fetch(req),
};

✅ Auth isn’t magical. It’s explicit, testable, and architectural.

❗️ 5. Built-In Error Handling

// index.ts
import type { Route } from "tirne";
import { Server, TirneError } from "tirne";

const routes: Route[] = [
  {
    method: "GET",
    path: "/",
    handler: (req) => {
      const name = new URL(req.url).searchParams.get("name");
      if (!name) {
        throw new TirneError("Missing name", {
          status: 400,
          type: "bad_request",
          expose: true,
        });
      }
      return new Response(`Hello, ${name}`);
    },
  },
];

const server = new Server(routes);

export default {
  fetch: (req: Request) => server.fetch(req),
};

TirneError gives you structured error responses
Built-in error middleware maps exceptions to HTTP responses
No try/catch needed — control flow stays clean and testable

🧼 Clean APIs include clean error boundaries.

🧠 🚀 Build APIs You Can Actually Reason About

If you think API code should be structured, testable, and explicit — not scattered and magical — Tirne was made for you.

👉 ⭐ Star on GitHub — 10× faster than Next. 100× clearer.

No hidden context. No global traps.
Just architecture you can trace, test, and trust.

Star it if you’re done guessing how your middleware works.
We built Tirne because we were, too.

We don’t need bigger frameworks.
We need smaller, sharper ones.

Less framework. More logic.

Bevel.ts — The First Real Backend Framework for Bun (Still in Progress)

Yuki Nishikawa — Tue, 27 May 2025 14:37:41 +0000

Bevel.ts: The Framework Bun Deserves — And It's Just Getting Started

"Why do we have Vite for frontend, but nothing for backend?"

This was the question that sparked Bevel.ts.

As developers, we’ve seen the JavaScript ecosystem evolve at blistering speed — from CommonJS to ESM, from slow Webpack builds to lightning-fast Vite, from monolithic backends to microservices on the edge. But in the backend space, Bun has arrived like a freight train, and yet...

Where’s the framework that feels like Bun?

✅ Ultra-fast by default
🧠 Feels like Vite or Next.js in setup and DX
🔥 Natively supports TypeScript, ESM, and edge runtimes
⚒️ Real CLI, not just another router
🤖 Built for the AI-native era — from day one

✨ What Makes Bevel.ts Different?

Feature	Bevel.ts	Express / Fastify	Elysia / Hono
Runtime	Bun	Node.js	Bun
Architecture	Intent-driven	REST	REST
CLI-first	✅ Yes	❌ No	⚠️ Partial
AI Native	✅ Built-in	❌ Plugin-needed	❌ None
Edge Ready	✅ Vercel / Cloudflare	❌ Limited	⚠️ Worker-optimized only
DX Philosophy	Precision & Speed	Boilerplate-heavy	Lightweight routing

🚀 Enter: Bevel.ts

Bevel.ts is my ongoing effort to build the first fullstack backend framework for Bun — designed from scratch for clarity, precision, and speed.

It’s inspired by the architectural concept of a "bevel": a clean, intentional cut that reveals the true form underneath. That’s how I believe APIs should be structured: with intent first, not REST boilerplate or GraphQL complexity.

🧠 What It Will Be

bunx bevel new my-app       # scaffold in seconds
bunx bevel generate intent  # define APIs by intention

defineIntent("user.login", schema, fn) instead of defining routes
Native OpenAI Function Calling support — automatically exportable
Playground UI to test and introspect your API intents
Deployable to Vercel Edge, Cloudflare Workers, or Bun-native servers

🧩 Think: Rails meets Vite meets GPT — on Bun.

⚠️ What It Is Right Now

Let’s be honest: it’s not ready yet.

The CLI is under construction
Some generation commands are stubs
Not all integrations are wired in

But the architecture is real. The vision is clear. And the core is moving fast.

📌 OSS is a process, not a product.

🦫 Meet the Mascot: BevelBeaver

Say hello to BevelBeaver, the sharpest, most precise backend architect in the forest.

Why a beaver?

Beavers are nature’s engineers — structured, meticulous, and fast.
Just like Bevel.ts, they carve with purpose and build with clarity.

“Code should be cut, not cluttered.” — BevelBeaver

BevelBeaver reminds us that every line of backend logic should be intentional, elegant, and fast as Bun.

🧱 All-Star Stack Behind Bevel.ts

Here's what powers Bevel.ts under the hood — a carefully curated set of modern tools that work seamlessly with Bun:

Runtime:       Bun (Edge-native, zero cold start)
Framework:     Bevel.ts (Intent-Driven)
Routing:       Hono (Ultra-fast)
Schemas:       Zod + tRPC (Type-safe and LLM-compatible)
Database:      Drizzle (SQL builder, typed, schema-first)
Auth:          Lucia (Lightweight, composable)
AI Support:    OpenAI, Claude, LangChain (Function calling-native)
UI Playground: React + shadcn/ui + Framer Motion (DX focused)
CLI Tooling:   Bevel CLI (bunx-based, zero config)

🧠 Every layer was chosen to optimize for speed, clarity, and future-proof DX.

🧭 Why Write This Now?

Because OSS isn’t about perfection. It’s about momentum.
Because I believe others might be asking the same thing:

"Where’s the framework that actually feels like Bun?"

If that’s you — come along. Watch the repo. Star it. File an issue. Or just send a 👍.

This is just the beginning.

The Modern Frontend Fantasy is Falling Apart – Astro, Qwik, and Solid Aren’t the Future

Yuki Nishikawa — Tue, 13 May 2025 13:28:38 +0000

They promised speed, simplicity, and a better DX. What we got was a set of beautiful lies, niche fantasies, and philosophical dead ends.

⚠️ Introduction: The Age of Frontend Disillusionment

Modern frontend frameworks love to sell a dream.
They’ll tell you they’re faster than React, more minimal than Vue, more elegant than Svelte.
But dig beneath the DX sugarcoating, and what you find isn’t revolution — it’s confusion, overengineering, or outright regression.

Let’s talk about the three self-proclaimed rebels of modern frontend:

Astro — The Gatsby Ghost in Island Clothing
Qwik — The Resumable Kernel That Forgot the Humans
Solid — The Signal Soloist in React's Orchestra

Together, they form the Zukkoke Three — each chasing a different ideal, but none equipped to win the war.

🏝️ Astro – The Static Dream That Dies When JS Returns

Astro sells the fantasy of zero-JS by default. Clean HTML. Minimal payloads. Islands of interactivity.
It’s compelling — until reality hits.

Astro is just Gatsby rebranded. It inherits the same flaw:

It works great until your app grows. Then you’re back to hydrating islands, shipping frameworks, and juggling scripts.

Astro’s true nature is JAMstack nostalgia with a better DX. It’s not wrong — just obsolete.
In a world of RSC, SSR, and edge rendering, static-first is a limitation, not a feature.

And when complexity grows, you're back in the hydration swamp, writing client scripts to patch static reality.

Verdict: A beautiful façade. But scale it, and the illusion breaks.

⚙️ Qwik – C for the Web, Not for the People

Qwik is genius — technically.
It introduces resumability, serializing the execution context of the app. Like pausing a program mid-run and continuing it in the browser.

That’s not frontend. That’s compiler-level thinking.
It’s not designed for humans. It’s designed for machines.

Qwik doesn’t care about your joy, your structure, or your aesthetics. It cares about cold start time.

Everything is driven by performance obsession. No visual language, no design philosophy, no ergonomics. Just speed.

Qwik is the C of frontend frameworks.
Fast, low-level, and terrifyingly efficient. But like C, it doesn’t care if you enjoy writing it.

Qwik is like inventing inline assembly for UI — impressive, but no one wants to write it.

Frontend developers didn’t ask for a compiler playground. They asked for clarity, structure, and joy. Qwik gave them ASTs and resumable closures.

Verdict: A backend brain wearing a frontend mask. Brilliant but inhuman.

🧱 Solid – The Signal Soloist in React's Orchestra

Solid claims to be a faster, more precise React. And it is — technically.
Signal-based fine-grained reactivity is elegant and performant.

But beyond that, Solid changes very little:

JSX stays
Component patterns stay
Developer experience is React-adjacent

Solid is trying to perfect React, not replace it.

In fact, Solid is a signal engine with a UI wrapper. Its only true innovation is reactivity granularity. Everything else is just React with better internals.

What does that mean for the rest of us?

No new architecture.
No new model for state or data.
No bold vision.

Solid is a one-trick pony. A brilliant trick, yes — but a pony nonetheless.

Verdict: Strong tech, weak narrative. Safe, not transformative.

🧠 Why None of These Will Win

Each of these frameworks optimizes for something:

Astro for simplicity
Qwik for performance
Solid for developer familiarity + reactivity

But none of them solve the core problem of modern frontend:

Too much freedom, not enough clarity.

They tinker at the edges of performance or DX, but they don’t bring structural relief. They don’t help you scale, collaborate, or reason clearly about your app’s shape.

The next real winner in frontend won’t be the fastest, or the most minimal.
It will be the one that brings structure back to chaos.

✨ What Comes After the Fantasy?

To move forward, we need a framework that understands:

Structure > flexibility
Intent > abstraction
Clarity > cleverness

The future isn’t in reinventing rendering engines or micro-optimizing hydration. It’s in giving developers a map.

A place for everything. And everything in its place.

What if we had a framework where:

Component trees were statically validated like type systems?

Layout, dataflow, and permissions were declared, not inferred?

Server & client boundaries were structural, not file-based?

That’s the revolution we’re waiting for.

🖚 Closing Thoughts

Astro is elegant but brittle.
Qwik is brilliant but alien.
Solid is fast but single-minded.

We’ve wandered through the forest of frontend fantasies. What we need now is architecture.

The frontend revolution won’t be won by performance. It will be won by structure.

Stay tuned. Or better yet: start designing it.

🚀 “Next.js Made Me Slower” — Why I’m Building Refraim.ts

Yuki Nishikawa — Tue, 13 May 2025 13:00:33 +0000

Currently in active development. Follow along as we reshape how fullstack Next.js apps are built — with structure, clarity, and momentum.

🧠 I Wanted Simplicity, Not Freedom — Why I’m Building Refraim.ts

Next.js 14 gave us power. But that power came wrapped in abstraction, complexity, and the App Router.

I didn’t want endless flexibility. I wanted to build fast — and enjoy it. But instead, I found myself battling routing trees, file conventions, and mental friction at every turn.

The App Router? Too abstract. Too clever. Too slow for real work.

I missed the magic of Rails. The clarity of Laravel. The joy of just building.

So I built Refraim.ts.

⚠️ The Problem: Next.js 14 Slows You Down

React, Next.js, and their ever-expanding constellation of meta-frameworks offer flexibility — in the form of total architectural ambiguity.

Choose your own file structure
Decide how to separate concerns
Build your own rules

But this freedom comes at a steep cost:

⏳ Slower velocity
😵 Team confusion
🔁 Endless decision fatigue

What used to be “just the V in MVC” is now an everything-machine that asks you to wire up everything yourself.

App Router tries to be powerful — but ends up being confusing.

✨ The Vision: Make Web Dev Joyful Again

Building a fullstack app shouldn’t feel like defusing a bomb made of config files.
It should feel like typing your intent and watching your app come to life.

My philosophy:

✅ Structure should be generated, not improvised
✅ Intent should become code
✅ Clarity > flexibility

Laravel nailed this. Rails was built on it. Refraim brings that magic — to the Next.js + TypeScript ecosystem.

🚀 Introducing Refraim.ts — A Framework That Chooses For You

Refraim.ts is a batteries-included fullstack framework on top of Next.js 14 that:

📁 Generates a clear project structure automatically
🔤 Uses a declarative routing DSL (defineRoute())
🔃 Separates schema, service, controller, and UI
🛠️ Offers CLI tools to scaffold features with smart defaults

No more wiring things by hand.
No more "Where should this code live?"
No more "It depends."

🧭 Refraim Philosophy: Schema. Service. Structure.

A new MVC for modern fullstack apps.

Each file has a single, clear responsibility
Features are self-contained and expressive
UI expresses intent, motion, and clarity
You never touch the App Router manually

🔍 What Refraim Does Differently

Compared to Next.js

✅ Opinionated routing structure
✅ CLI-generated features
✅ Fully typed page + controller generation

Compared to tRPC

✅ No magic proxies or hidden behaviors
✅ Explicit service layers and controller logic

Compared to Remix

✅ No nested route confusion
✅ Clear separation of domain logic and UI

🎨 Rebirth UI — Visual Clarity, Instantly

Tailwind CSS, Radix UI, and Framer Motion are powerful — but integrating them consistently takes real expertise.

Refraim wraps them into a single, tokenized design system you can trust:

npx rebirth-ui:init

Get:

🎨 Design tokens
🧩 Accessible UI components
💫 Built-in motion primitives

Most kits give you pieces. Rebirth gives you a philosophy.

🧙 CLI Magic: Rails-Like Momentum for Next.js

npx refraim make:feature users

Creates:

schema.ts (Zod)
service.ts (Prisma logic)
controller.ts
route.ts
Optional typed pages

npx refraim routes:generate

Automatically transforms route.ts into actual Next.js App Router files. Zero boilerplate. No ambiguity.

“You write intent. Refraim writes the app.”

🎯 Who It’s For: The Builders Who Want to Ship

Refraim.ts is built for:

👩‍💻 Indie developers who want to launch SaaS apps fast
🧑‍🤝‍🧑 Early-stage product teams moving without PMs
🧪 Makers who are tired of battling config, routes, and folder hell

If you want to:

Move fast without sacrificing structure
Build apps without stopping to Google folder naming debates
Actually enjoy shipping again

You’re who we’re building for.

🧭 In Closing: Next.js Made Us Free. Refraim Helps Us Move.

React gave us freedom.
Next.js gave us abstraction.
Refraim gives us flow.

Frameworks should protect us from unnecessary choice.
Refraim.ts is my answer to the chaos:

💡 A system that embraces clarity
⚙️ A structure that gets out of your way
🏃 A tool that turns motion into momentum

Freedom is beautiful. But clarity builds things.

If this resonates with you, follow along. Refraim.ts is coming soon.

🚀 Refraim.ts Is Coming. Join the Movement.

This project is still in early development — but if this vision resonates with you:

🌟 Give it a star on GitHub to follow progress and show your support.

→ Star Refraim.ts on GitHub

Your early support helps shape the future of fullstack development.

Next.js is just PHP with a React hoodie. We rebranded MVC. We reinvented routing. We added complexity — and called it progress. Let's stop pretending.

Yuki Nishikawa — Thu, 01 May 2025 11:09:16 +0000

Yuki Nishikawa

Apr 22 '25

Next.js Is Just Fancy PHP for People Who Fear Simplicity

#discuss #nextjs #php #laravel

Comments 15

2 min read

Web Backend Development Is a Lie: The Lost 15 Years of Betrayal　Part Ⅱ Dia.ts: Forging the New Backend Era

Yuki Nishikawa — Wed, 30 Apr 2025 12:49:20 +0000

⚔️ Part II — Dia.ts: Forging the New Era

"The clock isn't just ticking. It’s almost out of time."

That’s where we left off. And now, we rebuild.

🧱 The Philosophy: Intent Over Endpoints

Every major backend framework gives you options — too many of them.

REST, RPC, GraphQL, decorators, middlewares, services, DAOs...

Dia.ts rejects all of it.

There is only one way to define an API: As an intent.

export const api = defineAPI({
  input: z.object({ name: z.string() }),
  async handler({ input }) {
    return { message: `hello ${input.name}` }
  }
})

Because freedom without structure becomes chaos.

APIs are not CRUD functions. They are contracts that fulfill intent.

✅ Enforced by design:

Type-safe contracts from client to server
Pure functional middleware with AbortSignal support
Zero dynamic routing — everything precompiled

This isn’t “minimalism.”
This is intentional design — APIs as behavioral declarations.

🧠 Query as Intent

What if instead of asking for data, clients could declare what they want to happen?

"I want to mark this task as done."

Not: "Give me todos where done = false"

Dia.ts supports Intent-based APIs — where the handler isn’t just a fetcher, but a fulfillment engine.

// intent: "mark_done"
export const api = defineAPI({
  input: z.object({ id: z.string() }),
  async handler({ input }) {
    return markTodoDone(input.id)
  }
})

This structure:

🌟 Aligns better with product UX
📚 Logs like event history
🛡 Centralizes auth & validation
🧠 Enables future AI/LLM integrations

APIs stop being endpoints. They become declarative interfaces for action.

⚙️ The Architecture: Composable, Cancelable, Clear

Dia.ts runs 54,000+ RPS — but performance is the result, not the purpose.

Core principles:

🧠 CancelableTask<T> model: every request is interruptible
🔁 Middleware is functional: (ctx, next) => task
📦 Locals are immutable: extend context cleanly
🛑 AbortSignal for timeout-aware computation

This isn’t about middleware stacking — this is about intent pipelines.

🧨 No More Backend Theater

We don’t need another Express clone.
We don’t need dynamic scaffolding that decays over time.

We need a backend that reflects how apps actually evolve:

🌐 Real-time logic from the start
🧩 State = Event history, not mutable props
📖 Logic = Structured intents
🛠 DX = Typed. Pure. Predictable.

Dia.ts is not a toolchain. It’s a philosophy.

📊 Benchmarks Are Proof — Not the Point

Yes, we beat Bun + Elysia.

Yes, we use native Node + no magic.

But that’s not why Dia.ts exists.

We didn’t optimize the old model. We rejected it — and rebuilt something better.

It’s fast because it’s pure.

It’s safe because it’s structured.

It matters because it’s different.

🌱 It’s Early — and That’s the Best Part

Dia.ts is still pre-alpha:

CLI needs polish
Docs are sparse
Surface is evolving

But:

✅ The intent engine works
✅ The cancellation model is solid
✅ The vision is sharp

If you’ve ever thought “Why is backend still like this?” — this is your exit.

🛠 Try It (Experimental)

npm install dia-ts
npm install -g tsx
mkdir -p gen && npx dia-ts init --with client
📄 routes/hello.post.ts
import { z } from "zod"

export const api = defineAPI({
  input: z.object({ name: z.string() }),
  async handler({ input }) {
    return { message: `hello ${input.name}` }
  }
})
npx dia-ts generate-client

GitHub
npm
Status: pre-alpha — but the fire is lit 🔥

🔭 A Glimpse at What’s Next

Dia.ts is just the beginning.
One day, it won’t just be a framework — but a language.
A language built not for “general purpose,”
but for Web backend, and nothing else.

Fully typed. Fully cancelable.
No Node. No legacy. Just intent.

🧨 Why “Web-only” Matters

Web backend isn’t a toy problem.
It’s real-time, stateful, cancelable, multi-tenant, and deeply coupled to product UX.

General-purpose languages like Go or Java weren’t designed for that.
They’re great for infra, not interaction.

The truth is: Web deserves its own language.
One built not for threads or goroutines — but for structured intent, timeout-aware flows, and type-safe UX alignment.

Dia.ts isn’t trying to do everything.
It’s doing the only thing that matters now — Web backend, the right way.

Fast. Safe. Intentful.

Welcome to the Dia.ts era.

Backend systems haven’t evolved with the rest of the tech world. This is a call to rethink it all — not just patch the past.

Yuki Nishikawa — Tue, 29 Apr 2025 23:24:14 +0000

Yuki Nishikawa

Apr 29 '25

Web Backend Development Is a Lie: The Lost 15 Years of Betrayal　Part I: The Silent Collapse

#backend #node #api #go

Comments 4

2 min read

We wasted 15 years duct-taping old backend tech. It’s time to burn it down and rebuild from scratch.

Yuki Nishikawa — Tue, 29 Apr 2025 13:54:32 +0000

Yuki Nishikawa

Apr 29 '25

Web Backend Development Is a Lie: The Lost 15 Years of Betrayal　Part I: The Silent Collapse

#backend #node #api #go

Comments 4

2 min read

Web Backend Development Is a Lie: The Lost 15 Years of Betrayal　Part I: The Silent Collapse

Yuki Nishikawa — Tue, 29 Apr 2025 13:01:10 +0000

🔹 Part I: The Silent Collapse

If you zoom out and look at the evolution of backend development from 2009 to today, a chilling realization strikes with merciless clarity:

"The world transformed. Backend development did not."

In the same era where AI transcended human imagination, where mobile technology rewired societal behavior, and where cloud computing reached omnipresence — backend architecture remained tragically stagnant.

Node.js and Go, both children of the late 2000s, still dominate the conversation. Frameworks like Express.js, relics engineered for problems of yesterday, are still being duct-taped into "modern" systems with a mix of nostalgia and desperation.

It isn't just stagnation.

⚡️ It’s betrayal.

🔍 What Is Backend Development? (For Beginners)

Backend development refers to the server-side logic, database interactions, authentication, real-time updates, and API (Application Programming Interface) management that power modern applications.

If the frontend is what users see, the backend is the invisible machinery that makes it all work.

Typical backend responsibilities include:

📲 Receiving and processing user input
📂 Storing and retrieving data securely
🌐 Enforcing business logic and permissions
🔗 Communicating with third-party services
🔄 Serving the right data, in the right shape, at the right time

A backend must be fast, reliable, scalable, secure, and maintainable.

📊 How We Got Trapped

🔫 Node.js and Go: A Revolution That Stopped

Node.js allowed developers to write server-side code in JavaScript with an event-driven, non-blocking I/O model.
Go introduced simplicity, speed, and powerful concurrency primitives.

Both were revolutionary, but neither fundamentally rethought backend architecture for the real-time, distributed, mobile-first world.

🐟 The Microservices Mania

"Break the monolith into tiny services!"

The idea was intoxicating. The reality?

💔 Deployment nightmares
🙈 Versioning chaos
🔈 Communication overhead
🤦 Debugging hell

Microservices promised paradise but delivered bureaucratic complexity.

🔮 The API-First Delusion

"Design beautiful APIs first!"

Yes, tools like Swagger/OpenAPI helped document endpoints. But designing pretty endpoints does not solve:

❌ State management over time
❌ Modeling transitions safely
❌ Handling failures and retries robustly

APIs became glossy veneers masking fragile logic underneath.

🔥 Serverless and BaaS: The Mirage

"No backend needed!"

Serverless (AWS Lambda) and BaaS (Firebase, Supabase) made grand promises… but:

❌ Customization limitations
❌ Vendor lock-in nightmares
❌ Hidden cold start issues
❌ Opaque performance bottlenecks

Easy at first. Painful forever after.

🔥 Backend-as-a-Service sold us shortcuts and stole our future.

Meanwhile, the computing world evolved:

💪 CPUs became 10x faster.
📡 Networks became miracles.
🔄 Distributed theory matured.
📲 Users demanded real-time dynamism.

Backend? Still stuck in 2010.

🧙‍♂️ The False Prophets: Bun and Deno

"At last, the saviors!"

Bun: lightning fast ✨, but tied to npm's ancient ghosts.
Deno: pure philosophy 💜, but retreated toward Node.js compatibility to survive.

💥 Speed without revolution is nothing.

Bun and Deno fixed minor pains.

They left the core rot untouched.

⏱️ Is This Merely a Lost Decade?

No.

It’s worse.

Without a radical reset, backend development faces a Lost Twenty Years.

Nothing will save us if we don't rebuild the foundation:

💔 Shiny frameworks won't.
🚫 Faster Node.js forks won't.
❌ Newer BaaS platforms won't.

"The clock isn't just ticking. It is almost out of time."

✨ [To be continued: Part II — Dia.ts: Forging the New Era]

Next.js Is Just Fancy PHP for People Who Fear Simplicity

Yuki Nishikawa — Tue, 22 Apr 2025 12:52:22 +0000

How We Rebranded MVC, Reinvented Routing, and Declared It a Revolution

Every few years, we reinvent the web. Or at least, we like to think we do.

Next.js is often praised as the "future of web development." It promises performance, scalability, and developer experience. But beneath the surface, it’s not revolutionary. It’s PHP — in a React costume — running on Node.js.

And somehow, we all pretend it’s something new.

The MVC We’ve Seen Before (and Denied)

Model. View. Controller.

We’ve seen this pattern before. Praised it. Then discarded it as “legacy.” But here we are again, rebuilding the same house with newer bricks:

Model: Prisma, Drizzle, or your ORM of choice.
View: React components. Fancy templates.
Controller: getServerSideProps, middleware, server actions.

In essence, it’s the same pattern PHP developers used in the early 2000s. Laravel did it better. Ruby on Rails made it elegant. Now we’re back to it — but with useEffect and cache invalidation hell.

The structure never changed. Only the syntax, tooling, and branding did.

Routing Isn’t Innovation — It’s Nostalgia

Next.js’s file-based routing is praised for its “DX.” But PHP had this in the early 2000s. Laravel, CodeIgniter, and even plain index.php could handle this elegantly.

What’s new? React-style folder naming. That’s it.

It’s not innovation. It’s the past, wearing a hoodie.

Good UX ≠ New Architecture

People confuse user experience with actual technical evolution.

Sure, Next.js provides great UX — but so did server-rendered apps in PHP, Rails, and Django. They rendered fast. They were easy to debug. They didn’t need a flight manifest, suspense boundaries, or streaming strategies.

We’ve taken what was simple and abstracted it into complexity — and then called that complexity “modern.”

Streaming, RSC, server/client boundary management, React compiler pipelines. All to serve HTML. Like PHP did.

The Cult of Modern and the Fear of Legacy

We fear being outdated. So we run from anything labeled “legacy.”

PHP didn’t die because it was bad. It died because it wasn’t fashionable.

Next.js is fashionable PHP. With TypeScript and an aggressive marketing team.

When Vercel demos a fullstack app in 30 minutes, it’s not because of technical revolution — it’s because they’ve rebranded the past and made it slick.

What you’re seeing is the same MVC structure with a modern DX wrapper.

And that wrapper? It’s built on years of overcomplicated abstraction, often requiring senior-level devs just to achieve what junior devs did in 2005.

Honest Web, Not Reinvented Web

Let’s stop pretending every abstraction is progress. Let’s stop worshipping complexity for its own sake.

Next.js is powerful, yes. But it’s not new. It’s not futuristic. It’s not revolutionary.

It’s just PHP, with better branding and more GitHub stars.

And maybe that’s okay — if we can just be honest about it.
I also shared this on X (Twitter)

What if React never needed JavaScript? Introducing NO JS 🧠

Yuki Nishikawa — Tue, 01 Apr 2025 01:37:56 +0000

NO JS – A Syntax Operating System for the Web

What if you could build full web apps — with no JavaScript at all?

🧪 Try the Playground

🌐 GitHub Source

✨ The Idea

NO JS is a meaning-driven syntax OS.

You write .nojs files that describe structure, state,

and flow — then compile them to pure HTML using Zig.

page "home" {
  state.username = "Yuki"
  div {
    h1 { text "Welcome, {username}" }
  }
}

Compile it:

nojs build examples/hello.nojs

And get this:

<div><h1>Welcome, Yuki</h1></div>

No JavaScript. No runtime. No framework.

💡 Why I Built It

Modern web tools are amazing — but what if we could write

the web with just meaning?

🚀 Live Demo

🧪 Try NO JS

Try editing .nojs code and see instant HTML output.

No build tools, no client-side JS.

🧠 Philosophy

Code tells machines what to do.

Syntax tells the world what you mean.

Would love thoughts, ideas, or reactions 🙌

This is still v0.1 — just the beginning!

🚀I build JetScript — the focused, modern successor to JavaScript for MVPs, educators, and indie devs.

Yuki Nishikawa — Wed, 26 Mar 2025 23:56:08 +0000

Tired of configs, boilerplate, and frameworks that make your MVP

feel like a PhD thesis?

🔗 GitHub: https://github.com/jetscript-lang/JetScript
I built JetScript — a lightweight scripting language designed for:

🧑‍🚀 Startup founders launching MVPs

🧑‍🎨 Indie hackers building fast and solo

🧑‍🏫 Educators teaching core web concepts

🤖 LLM developers who want clean, generative syntax

No npm. No toolchains. No JSX.

Just one file, readable code, and instant feedback.

🤔 Why JetScript?
JavaScript (and TypeScript) has evolved beautifully — but for solo
builders, it often feels like overkill:

Endless tooling: vite, tsc, babel, eslint, jest, ...

Boilerplate and complexity everywhere

JSX fatigue and component hell

Hooks, routing layers, global state chaos

What if there was a language made just for founders and rebels?

✨ What is JetScript?

JetScript is a new scripting language that reimagines

frontend+backend+state logic in a single file.

⚡ Built-in state, routing, and rendering

💡 Syntax that flows like natural thought

🌀 Powered by Bun — instant runtime, zero build

🔥 No imports, no toolchains, no ceremony

📦 Hello Counter Example

route "/" do
  state count = 0

  view:
    h1 "Count: #{count}"
    button { onclick: inc(count) } "＋"

✔️ No JSX
✔️ No useState, useEffect
✔️ Just flow

🗺 Roadmap
Version Features
v0.1 Core runtime + DSL (✅ released)

v0.2 fn, if, improved AST

v0.3 CLI (jets) + Playground

v0.4 Module system (JetModules)

Yes, CLI is coming soon! 🛠️

🌱 The Philosophy

“JetScript is built not just to run fast,

but to let your ideas flow as code.”

We believe programming should be simple, expressive, and joyful.

JetScript is built on the poetic principles of Mizulang — reimagined for

the startup era.

📡 Try it out / Follow the journey

🔗 GitHub: https://github.com/jetscript-lang/JetScript

🧵 X / Twitter: @structax

If you like it, drop a ⭐ — it helps me a ton.

And feel free to ask questions, suggest features, or just say hi!

Happy building, rebels.

DEV Community: Yuki Nishikawa

Next.js Forgot to Design APIs. Tirne Didn’t.

✨ Core Philosophy

🛠️ 1. Quick Start

⚡️ 2. Performance Benchmarks

📀 3. Hello Tirne (Structured Example)

🔒 4. Real Auth, Architected

❗️ 5. Built-In Error Handling

🧠 🚀 Build APIs You Can Actually Reason About

Bevel.ts — The First Real Backend Framework for Bun (Still in Progress)

Bevel.ts: The Framework Bun Deserves — And It's Just Getting Started

✨ What Makes Bevel.ts Different?

🚀 Enter: Bevel.ts

🧠 What It Will Be

⚠️ What It Is Right Now

🦫 Meet the Mascot: BevelBeaver

Why a beaver?

🧱 All-Star Stack Behind Bevel.ts

🧭 Why Write This Now?

The Modern Frontend Fantasy is Falling Apart – Astro, Qwik, and Solid Aren’t the Future

⚠️ Introduction: The Age of Frontend Disillusionment

🏝️ Astro – The Static Dream That Dies When JS Returns

⚙️ Qwik – C for the Web, Not for the People

🧱 Solid – The Signal Soloist in React's Orchestra

🧠 Why None of These Will Win

✨ What Comes After the Fantasy?

🖚 Closing Thoughts

🚀 “Next.js Made Me Slower” — Why I’m Building Refraim.ts

🧠 I Wanted Simplicity, Not Freedom — Why I’m Building Refraim.ts

⚠️ The Problem: Next.js 14 Slows You Down

✨ The Vision: Make Web Dev Joyful Again

🚀 Introducing Refraim.ts — A Framework That Chooses For You

🧭 Refraim Philosophy: Schema. Service. Structure.

🔍 What Refraim Does Differently

Compared to Next.js

Compared to tRPC

Compared to Remix

🎨 Rebirth UI — Visual Clarity, Instantly

🧙 CLI Magic: Rails-Like Momentum for Next.js

🎯 Who It’s For: The Builders Who Want to Ship

🧭 In Closing: Next.js Made Us Free. Refraim Helps Us Move.

🚀 Refraim.ts Is Coming. Join the Movement.

Next.js is just PHP with a React hoodie. We rebranded MVC. We reinvented routing. We added complexity — and called it progress. Let's stop pretending.

Next.js Is Just Fancy PHP for People Who Fear Simplicity

Web Backend Development Is a Lie: The Lost 15 Years of Betrayal Part Ⅱ Dia.ts: Forging the New Backend Era

⚔️ Part II — Dia.ts: Forging the New Era

🧱 The Philosophy: Intent Over Endpoints

✅ Enforced by design:

🧠 Query as Intent

⚙️ The Architecture: Composable, Cancelable, Clear

Core principles:

🧨 No More Backend Theater

📊 Benchmarks Are Proof — Not the Point

🌱 It’s Early — and That’s the Best Part

🛠 Try It (Experimental)

🔭 A Glimpse at What’s Next

🧨 Why “Web-only” Matters

Backend systems haven’t evolved with the rest of the tech world. This is a call to rethink it all — not just patch the past.

Web Backend Development Is a Lie: The Lost 15 Years of Betrayal Part I: The Silent Collapse

We wasted 15 years duct-taping old backend tech. It’s time to burn it down and rebuild from scratch.

Web Backend Development Is a Lie: The Lost 15 Years of Betrayal Part I: The Silent Collapse

Web Backend Development Is a Lie: The Lost 15 Years of Betrayal Part I: The Silent Collapse

🔹 Part I: The Silent Collapse

"The world transformed. Backend development did not."

⚡️ It’s betrayal.

🔍 What Is Backend Development? (For Beginners)

📊 How We Got Trapped

🔫 Node.js and Go: A Revolution That Stopped

🐟 The Microservices Mania

🔮 The API-First Delusion

🔥 Serverless and BaaS: The Mirage

🔥 Backend-as-a-Service sold us shortcuts and stole our future.

🧙‍♂️ The False Prophets: Bun and Deno

💥 Speed without revolution is nothing.

⏱️ Is This Merely a Lost Decade?

"The clock isn't just ticking. It is almost out of time."

✨ [To be continued: Part II — Dia.ts: Forging the New Era]

Next.js Is Just Fancy PHP for People Who Fear Simplicity

How We Rebranded MVC, Reinvented Routing, and Declared It a Revolution

The MVC We’ve Seen Before (and Denied)

Web Backend Development Is a Lie: The Lost 15 Years of Betrayal　Part Ⅱ Dia.ts: Forging the New Backend Era

Web Backend Development Is a Lie: The Lost 15 Years of Betrayal　Part I: The Silent Collapse

Web Backend Development Is a Lie: The Lost 15 Years of Betrayal　Part I: The Silent Collapse

Web Backend Development Is a Lie: The Lost 15 Years of Betrayal　Part I: The Silent Collapse