Framework Should Not Be Bloated

Jun 28, 2025

A good web framework lets developers pick the tools they need. This is because developers think about things like how fast it runs, how easy it is to use, how much community help is available, and how simple it is to maintain. So, the framework should give developers choices.

I've been using Next.js for almost 5 years. It has the best developer experience so far, and is built by a great team and community. I love it, until I need a big machine to develop and build my single web page.

Inspired by the Next.js experience, I’m trying to build my own framework. Here are some key points about the concept, idea, and more.

Tech Stack

I opted for Bun as the primary technology stack, primarily because it efficiently accomplishes the necessary tasks. Regarding the front-end library, React is my choice, given its large and highly supportive community, in addition to the numerous supporting libraries available for it.

Modularity

My framework should be capable of handling simple and advanced use cases. So, what if I only want to create a simple REST API or a webhook? This makes sense if I don't want to install React or other front-end libraries. And, if I want to build a ChatGPT-like application, it should be able to have modern web APIs.

So, I built 2 variants of it. My principle when building the framework is that it should be simple and have no unnecessary dependencies, if possible.

@buntal/http

This is a library for handling all HTTP requests. So, we can build server-side applications with it. The experience using it is similar to Express.js or Next.js—with a file-based routing system.
buntal

This is a full-stack framework that uses @buntal/http under the hood and is used to build advanced user interface applications. Of course, it should be able to handle HTTP requests.

File-based Router

By leveraging Bun's FileSystemRouter API, we can now build a seamless Next.js-like router. Developers will likely not need extensive router configuration when building applications. Therefore, this is essential for a good developer experience.

Here's the router design that supports loading pages, layouts, and APIs.

app/
├─ index.tsx
├─ layout.tsx
├─ about/
│  └─ index.tsx
└─ api/
   └─ ping/
      └─ index.ts

We can easily load all routers like this:

const router = new Bun.FileSystemRouter({
  style: "nextjs",
  dir: "/path/to/pages"
})

Now, the challenge is how to build a page that supports rendering multiple layouts, populates search queries, parameters, server-side loaded data, and so on. Well, thanks to Sonnet 4 for that.

Server-side Rendering

I want the element returned for the server to be the same as the element returned for the client-side. It's extremely important for search engines to read web pages easily. To achieve this, the framework must care about SSR and always be hydrated. Hydration is a technique associated with SSR and involves transforming a server-rendered HTML document into a fully interactive web application on the client side. ^[1]

The idea is to build a web page on the server-side and handle seamless navigation if the user requests a page with an internal link. To handle seamless navigation, we can build a router provider that works like React Router or Next.js navigation libraries.

Lifecycle

Here is the lifecycle of the framework I designed.

The left part describes the process for building root.js—the main script responsible for seamless navigation, layout rendering, front-end logic, and more. The right part explains the server-side process of rendering the requested page.

About the Name

I named it Buntal because of a mistake I made in Dec 2024.

Conclusion

Buntal JS is in active development and has 3 main sponsors: DigitalOcean, Cloudflare, and Sentry. We also accept individual sponsors to support our development efforts. The future roadmap includes a more seamless router, WebSocket support, improved documentation and examples, and more, while keeping it simple and lightweight.