I have been building a full-stack mentor app with Bun, tRPC, and Next.js. The project is not very large, but it has the usual pieces you would expect in a modern full-stack application: authentication flow, dashboard pages, scheduled classes, signup, server-side logic, and API communication through tRPC.
The development experience with Next.js was smooth overall. I was not struggling with the framework, and I was not trying to move away from it because of one major problem. But during regular development, one small thing kept coming back into my mind: the production build time.
It was not painfully slow. It did not block me for minutes. But when I was making small changes, testing them, and running builds again and again, even a few seconds started to matter. A build that feels fine once can start feeling heavy when it becomes part of your daily feedback loop.
That is what made me try Vinext.
I was not trying to write a deep benchmark report. I was not trying to prove that one framework is better than another. I simply wanted to take the same kind of app, run it through Vinext, and see how the build experience felt.
This post is just that: a practical view from one developer trying Vinext with an app built using Bun and tRPC.
Why Build Time Started to Matter
Build time is one of those things we usually ignore until it starts interrupting our rhythm.
When a project is small, we expect everything to feel quick. We expect the development server to start fast, changes to reflect quickly, and production builds to finish without making us wait too long. But modern full-stack frameworks do a lot of work behind the scenes. They compile client code, prepare server code, collect route information, generate static pages where needed, and perform type checks or framework-specific analysis.
None of that work is wrong. In fact, most of it is useful. The problem is that during active development, the feeling of speed matters almost as much as the actual number.
If I run a build once before deployment, five seconds may not feel like a big deal. But if I run builds many times while testing changes, comparing outputs, or checking production behavior, the waiting becomes more noticeable.
That was the situation in my project. The Next.js build was acceptable, but I wanted to see whether Vinext could make that loop feel lighter.
The App Setup
The app I tested was a mentor platform built with a modern TypeScript stack. The important pieces were:
- Bun as the runtime and package manager
- Next.js as the original framework
- tRPC for type-safe API communication
- A few practical app routes such as dashboard, scheduled classes, and signup
This matters because I was not testing Vinext with an empty starter template. I wanted to try it against the type of app I actually build.
At the same time, I want to be clear: this was still a small project. The result should be understood as a local observation, not as a universal statement about every Next.js or Vinext application.
The Next.js Build Output
Here is the build output I got from Next.js:
$ next build
▲ Next.js 16.1.6 (Turbopack)
✓ Compiled successfully in 4.7s
✓ Finished TypeScript in 2.3s
✓ Collecting page data using 7 workers in 343.7ms
✓ Generating static pages using 7 workers in 178.8ms
The first number that stood out to me was the 4.7s compile time. After that, the build still had to finish TypeScript, collect page data, and generate static pages.
To be fair, this is not a bad build time. For many projects, this would be completely acceptable. But for the size of this project, I expected the build to feel a little quicker.
❗️The important detail here is that I am not calling this a complete benchmark of Next.js. I am only looking at the build output from my own project and describing how it felt during repeated development.
What I Wanted to See From Vinext
Before trying Vinext, I had a simple question:
Can a Vite-powered Next.js-like framework make this build feel lighter?
That was the entire motivation. I was not expecting a miracle. I was not expecting the build to drop from seconds to milliseconds. I just wanted to see whether the experience felt cleaner and whether the output showed any practical improvement.
Vinext was interesting to me because it tries to keep a familiar mental model while using a different build pipeline. For someone who already works with Next.js, that matters. A tool becomes easier to try when it does not ask you to forget everything you already know.
Since my app was already using Bun and tRPC, this was also a useful test for my actual workflow.
Trying Vinext
I ran the project with Vinext and looked at the build output carefully. Again, this was not a formal benchmark suite. I did not run multiple cold builds, average them, or test across different machines.
This was a direct local test: run the build, observe the output, compare the visible numbers, and see how the process feels.
For a first experiment, that was enough. Sometimes you do not need a perfect benchmark to notice whether a tool feels worth exploring further.
Vinext Performs Slightly Better
Here is the Vinext build output from my test:
$ vinext build
[1/5] analyze client references...
[2/5] analyze server references... → built in 567ms
[3/5] build rsc environment... → built in 899ms
[4/5] build client environment... → built in 1.69s
[5/5] build ssr environment... → built in 743ms
Build complete.
When I added the visible Vinext build stages, the total came to roughly 3.9s. Compared with the 4.7s compile number I saw from Next.js, this was not a huge difference, but it was still noticeable.
The difference was around 0.8s based on those visible numbers. On paper, that may look small. In practice, it was enough to make the build feel slightly lighter.
That is the main point of this post.
Vinext did not completely change the experience. It did not make the build instant. But it did give me a slightly better build result in this project, and the output made the process feel clearer.
The Build Output Felt Easier to Read
One thing I liked about Vinext was how the build process was separated into visible stages.
Instead of only looking at one big build step, I could see what was happening:
- client references were analyzed
- server references were analyzed
- the RSC environment was built
- the client environment was built
- the SSR environment was built
This made the build output feel more understandable. I could immediately see where time was being spent and how the framework was preparing different parts of the app.
That kind of clarity is useful. Even when the time difference is small, good output helps developers understand the system better.
Why I Am Calling It "Slightly Better"
I am intentionally using the phrase "slightly better" because that is the honest way to describe this result.
The improvement was real in my test, but it was not dramatic. I do not want to turn a small local observation into a huge claim. Next.js is still mature, powerful, and widely used. Vinext is still something I am exploring.
But small improvements are still worth noticing.
In daily development, performance is not only about large wins. Sometimes it is about shaving off small delays, making output easier to understand, and reducing the friction that appears when you repeat the same task many times.
That is where Vinext felt good to me.
What I Liked About Vinext
The first thing I liked was the build clarity. The output showed each stage separately, and that made the process easier to follow.
The second thing was the slight improvement in build time. A difference of less than a second may not sound exciting, but when the build already runs in only a few seconds, even a small improvement is visible.
The third thing was that the setup felt promising with Bun and tRPC. I did not have to think about it as a completely different way of building apps. It still felt close to the Next.js mental model, which made the experiment more comfortable.
The fourth thing was the feeling of direction. Vinext feels like an attempt to bring the speed and simplicity people like from Vite into a full-stack React framework style. That idea itself is interesting.
What I Would Not Claim Yet
There are a few things I do not want to overstate.
I am not saying Vinext is always faster than Next.js. I tested one project, in one setup, from my local environment.
I am not saying everyone should migrate immediately. A framework decision is not only about build time. It is also about stability, documentation, deployment, ecosystem support, debugging, and long-term maintenance.
I am also not saying a 0.8s improvement will matter equally to every developer. For some people, it may not matter at all. For others, especially those who care about tight feedback loops, it may be enough to explore further.
The honest statement is simple: in my app built with Bun and tRPC, Vinext gave me a slightly better build experience.
Where Vinext Still Needs Improvement
Vinext still needs more improvement before I would speak about it as a confident production choice.
It needs more real-world testing. It needs stronger documentation. It needs more examples. It also needs better out-of-the-box support for different project structures and use cases.
That is not a negative point. That is how open-source tools grow.
Every framework starts with rough parts. The difference between a tool that disappears and a tool that becomes useful is often the community around it. If developers only wait for tools to become perfect, those tools move slowly. But if developers try them, find issues, fix what they need, and send pull requests, the tool improves faster.
Vinext feels like the kind of project where that mindset matters.
If something is missing and the project is open source, the answer should not always be to complain or wait. Fork it. Understand the code. Add the support you need. Open a pull request.
This is where I think the mindset of many Indian developers starts falling apart. We use open-source tools every day, but we often stay only on the consumer side. We depend on frameworks, libraries, runtimes, CLIs, and deployment tools, but when we find a gap, we rarely take the next step of contributing back.
That is a bigger topic, and I want to write about it separately. But Vinext reminded me of it clearly: if we want better tools, we should not only wait for someone else to improve them. We should also build the habit of participating.
Final Thought
For my app built with Bun and tRPC, Vinext gave me a slightly better build experience than what I saw with Next.js. The improvement was not huge, but it was enough to make me interested.
The Next.js build was acceptable. The Vinext build felt a little lighter. The output was clearer, and the staged build process made the experience easier to understand.
I would not say everyone should migrate immediately. I would say Vinext is worth trying if you are curious about Vite-powered builds in a Next.js-like setup.
It still needs improvement, but that is also the point. Good tools do not become mature only because people wait for them to become perfect. They improve when developers test them, report issues, and contribute back.
Top comments (0)