One Framework for Your Entire Stack: The HBForge Philosophy

Open a modern JavaScript project's package.json. Count the dependencies. If it is a production application with authentication, a database, email sending, PDF generation, form validation, and a search feature, you are likely looking at 60 to 120 packages in your dependency tree.

Each package is maintained by a different person or team. Each has its own release cycle, its own breaking change philosophy, its own security response timeline. Each adds to your node_modules footprint, your install time, your CI build duration, and your attack surface.

We built HBForge because we believe this fragmentation is the single largest source of friction in JavaScript development today.

The Cost of 60 Packages

Let us trace a typical request through a modern Node.js stack. A user submits a form. The request flows through:

That is 12+ packages for a single form submission endpoint. Each with different error formats, different configuration patterns, different philosophies about async handling. When something breaks at 3 AM, you are debugging across six different libraries' source code, trying to understand whose error object you are looking at.

The Security Liability

In 2024, the JavaScript ecosystem experienced 3,847 npm security advisories. The average production Node.js application had 14 vulnerabilities in its dependency tree at any given time. Not because developers are careless, but because maintaining awareness of 200+ transitive dependencies is practically impossible.

The event-stream incident in 2018 demonstrated that a single compromised sub-dependency can inject malicious code into thousands of projects. The colors and faker sabotage in 2022 showed that even widely trusted packages can become hostile overnight. Every dependency is a trust relationship, and 60 trust relationships is 60 potential points of failure.

HBForge has zero dependencies. Zero. Every line of code is written and audited by the same team. There is no supply chain to attack because there is no chain — just one codebase.

What Ships in One Import

HBForge is organized into 15 modules, each replacing multiple npm packages:

A Complete Application in One Ecosystem

// Server with auth, validation, database, email
import { createServer } from '@hyperbridge/forge/server';
import { createAuth } from '@hyperbridge/forge/auth';
import { defineSchema } from '@hyperbridge/forge/data';
import { z } from '@hyperbridge/forge/schema';
import { sendEmail } from '@hyperbridge/forge/email';

const app = createServer();
const auth = createAuth({ secret: process.env.SECRET });
const db = defineSchema({ /* models */ });

const SignupSchema = z.object({
  email: z.string().email(),
  name: z.string().min(2),
  password: z.string().min(8),
});

app.post('/api/signup', async (req, res) => {
  const input = SignupSchema.parse(req.body);
  const hash = await auth.hashPassword(input.password);
  const user = await db.User.create({
    ...input, password: hash
  });
  const tokens = auth.issueTokens({ sub: user.id });
  await sendEmail({
    to: input.email,
    subject: 'Welcome!',
    template: 'welcome',
    data: { name: input.name },
  });
  res.json({ user, tokens });
});

app.listen(3000);

Five imports, one ecosystem. Every function in that handler — the schema validation, the password hashing, the database insert, the token issuance, the email send — comes from HBForge. One coding style. One error format. One documentation site. One team to file issues with.

Why Not Just Use Good Individual Libraries?

This is the most common pushback we hear. "Zod is excellent for validation. Prisma is excellent for databases. Express is battle-tested for HTTP. Why not use the best tool for each job?"

Because the integration cost is where most developer time is spent. It is not hard to learn Zod or Prisma individually. What is hard is:

• Error normalization — Zod returns ZodError, Prisma throws PrismaClientKnownRequestError, Express uses next(err). You write a custom error handler that normalizes all three into a consistent API response format.
• Type threading — Getting a Zod schema's inferred type to flow into a Prisma create operation to flow into a response type requires careful TypeScript gymnastics.
• Version conflicts — Updating Prisma to v6 requires updating @prisma/client, regenerating types, checking compatibility with your TypeScript version, and verifying nothing breaks in your test suite that uses a different mocking library.
• Configuration sprawl — Each library has its own config file or initialization pattern. Your project has prisma/schema.prisma, jest.config.js, .eslintrc, tsconfig.json, and a dozen others. HBForge has one.

The Tree-Shaking Advantage

HBForge is not a monolith that forces you to load 35,762 lines for a simple server. Every module is independently importable. If you only use forge/server and forge/schema, your bundle only includes those two modules. The bundler strips everything else.

// Only server + schema land in your bundle
import { createServer } from '@hyperbridge/forge/server';
import { z } from '@hyperbridge/forge/schema';

// forge/pdf, forge/chart, forge/search, etc.
// are NOT included — zero overhead

Designed for Teams That Ship

When a new developer joins your team, they learn one framework instead of fifteen. The coding patterns in forge/auth are the same patterns in forge/data. Errors are structured the same way across all modules. Configuration follows the same conventions. Testing uses the built-in forge/test runner that understands the entire ecosystem natively.

This consistency compounds. Onboarding drops from weeks to days. Code reviews become faster because everyone reads the same API style. Cross-module refactoring is straightforward because there is one set of conventions, not fifteen.

The Road Ahead

HBForge today is 15 modules covering the most common needs of web application development. But the philosophy extends further. We are working on modules for real-time collaboration (CRDTs and operational transform), workflow orchestration (durable execution like Temporal, but in-process), and AI integration (embeddings, vector search, and LLM orchestration without LangChain).

Each new module will follow the same principles: zero dependencies, consistent API design, and deep integration with every other module. Because the best developer experience is not the best individual library — it is the best system.

We do not want HBForge to be the best ORM, the best auth library, or the best search engine individually. We want it to be the best way to build an application, end to end.