Why Web Frameworks May Not Be the Answer for Simple APIs

While reviewing Deno Deploy, the author suddenly thought, “Web frameworks are not the answer.” As a developer of the Node.js framework Midway, he acknowledges the indispensable role of web frameworks in large‑scale, enterprise applications, yet he questions their suitability for simple scenarios.

From That Code Snippet

The Deno Deploy documentation provides a concise example that inspired the author:

import { serve } from "https://deno.land/[email protected]/http/server.ts";
import { h, ssr, tw } from "https://crux.land/[email protected]";

const Hello = (props) => (
  <div class={tw`bg-white flex h-screen`}>
    <h1 class={tw`text-5xl text-gray-600 m-auto mt-20`}>Hello {props.name}!</h1>
  </div>
);

console.log("Listening on http://localhost:8000");
await serve((req) => {
  const url = new URL(req.url);
  const name = url.searchParams.get("name") ?? "world";
  return ssr(() => <Hello name={name} />);
});

The code is straightforward: it listens for HTTP requests, renders HTML with nanossr, and returns the result. The rendering flow is clear, stateless, and easily scalable in the cloud.

In contrast, using a framework such as Midway Hooks adds boilerplate for initialization, routing, and other concerns:

import { Api, Get, useContext, run } from '@midwayjs/hooks';
import { h, ssr, tw } from "https://crux.land/[email protected]";

const Hello = (props) => (
  <div class={tw`bg-white flex h-screen`}>
    <h1 class={tw`text-5xl text-gray-600 m-auto mt-20`}>Hello {props.name}!</h1>
  </div>
);

const api = Api(
  Get('/'),
  async () => {
    const { query } = useContext();
    const name = query.name ?? "world";
    return ssr(() => <Hello name={name} />);
  }
);
await run(api);
console.log("Listening on http://localhost:8000");

Because a framework introduces initialization, routing, and other abstractions, developers inevitably incur extra cognitive load and potential performance overhead.

The author reflects that while such frameworks are essential for large, complex systems, they can be overkill for simple API services or tiny rendering tasks. Over‑design and premature optimization often arise when a heavyweight framework is forced onto a minimal use case.

Self‑Q&A

Q: As a framework author, why claim that “Web frameworks are not the answer”?

A: Being close to framework development gives him deeper insight into their limits. He believes that a lightweight or no‑framework approach can lower the mental burden for developers, and the statement stems from a recent code‑driven inspiration rather than a contrarian stance.

Q: How to address concerns about architecture, maintainability, and scalability without a framework?

A: He suggests not solving them preemptively. Instead, developers should decide early whether a framework is truly needed; if not, they can refactor later when complexity grows.

Q: What concrete actions are planned?

A: He intends to experiment with simple or no‑framework designs to reduce the mental load of Web API development, aiming for transparent, trustworthy solutions rather than eliminating frameworks altogether.

Q: Where is the value?

A: The value lies in combining strong infrastructure, easy‑to‑use platforms, and low‑cognitive‑load development practices—enabling rapid start‑up, instant deployment, and confidence for developers.

Q: Are there existing products?

A: The current article itself serves as the first artifact, outlining the thought process and personal viewpoint.

Q: What challenges might arise?

A: The main challenge is restraint and reduction: as frameworks evolve, they tend to become more complex, turning into “black boxes.” The difficulty will be defining clearly what the tool offers and what it deliberately omits.

Q: The article is hard to understand—why?

A: It is a late‑night inspiration and personal note, meant to capture a fleeting idea rather than a polished tutorial.

References

Deno Deploy: https://deno.com/deploy