Forem: Ezhil Sivaraj SR

I Tried Vinext The Build Felt Slightly Better

Ezhil Sivaraj SR — Wed, 22 Apr 2026 04:55:00 +0000

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.

When Power Centralizes in the Frontend Ecosystem — Should We Be Alarmed?

Ezhil Sivaraj SR — Sun, 01 Mar 2026 06:31:58 +0000

A research-aware analysis of Vercel's growing influence, React's direction, and the ecosystem fighting back.

Over the last few years, the frontend world has experienced an unprecedented consolidation of influence.

One company sits at the center of:

The most downloaded React framework
The primary production implementation of React Server Components
Strategic investment, sponsorship, and acquisition of competing frameworks
A deployment platform tightly integrated with those tools

That company is Vercel.

This is not an accusation. It is an architectural — and structural — observation.

When one player shapes both the framework layer and the infrastructure layer, the ecosystem shifts. The question is not whether this is malicious. The question is whether it is healthy.

The Scale of Influence

Next.js crossed 500M+ downloads in 2025. It is built and stewarded by Vercel.

But Next.js is only the most visible piece. Beyond it:

Svelte received direct backing from Vercel, with Rich Harris — Svelte's creator — joining the company.
Nuxt aligns closely through its Nitro server engine with Vercel's deployment model.
React Server Components are most mature, most documented, and most production-ready inside Next.js.
The App Router paradigm evolves in tandem with Vercel's infrastructure model.
Key React core team members — including Sebastian Markbåge, architect behind many of React's foundational innovations — migrated to Vercel starting in late 2021.

None of this violates open-source principles. All of it is legal.

But ecosystem gravity is real. When the most popular framework, the most optimized hosting, and the reference implementation of a major architectural shift all converge — centralization begins whether anyone intends it or not.

The React Server Components Inflection Point

The most important shift is not Next.js itself. It is React and the introduction of React Server Components (RSC).

RSC fundamentally changes:

Where rendering happens
How data flows between client and server
The client/server boundary
Bundle composition and size
What frameworks are expected to do

The RSC vision originated at Meta. But the practical implementation and production readiness owe an enormous debt to Vercel. The React team prototyped RSCs internally but struggled to fully iterate at scale. Vercel stepped in — re-architecting Next.js's App Router around RSCs, making server components the default experience, and deeply coupling features like Server Actions, Suspense integration, and streaming to Next.js patterns.

The result: official React docs heavily recommend Next.js. Much of the RSC guidance — demos, explanations, best practices — flows through Vercel's blog and Next.js documentation. The RSC payload format and Flight protocol are implemented in ways that shine brightest on Vercel's infrastructure.

This creates a directional influence that compounds over time:

If RSC becomes the dominant React paradigm, and Next.js remains the leading implementation, then React's architectural future becomes closely aligned with Vercel's ecosystem model.

That does not imply control. But it does imply gravitational influence — and critically, a conflict of interest. Vercel has a financial incentive to push SSR/RSC-heavy architectures that drive usage of their hosting platform. When the core library leans so heavily on one commercial player's implementation, the "open" in open source starts to feel conditional.

Why Structural Centralization Matters

Centralization is not inherently harmful. But structural concentration creates asymmetry.

Imagine one organization influencing:

Framework roadmap and architectural defaults
Deployment performance benchmarks
Edge runtime narrative and developer education
Core language feature priorities through talent concentration

They do not need to act aggressively. Influence alone shapes norms. And norms become standards.

The concern is not intent. It is leverage. Even a benevolent actor holding too much sway creates systemic fragility. Consider the risks:

Vendor lock-in: Migrating away from Vercel/Next.js can mean losing seamless RSC benefits, as other frameworks catch up slowly.
Pricing risk: A large swath of the ecosystem becomes vulnerable to pricing changes by a single provider.
Innovation bottlenecks: When one company's infrastructure model is the implicit target, architectural experimentation narrows.
Security surface: When something goes wrong — as with RSC-related vulnerabilities that surfaced in 2025 — the blast radius is enormous.

The Counterbalance: Ecosystem Resilience

Fortunately, the frontend world is not passive. Alternatives are emerging — not as reactionary forks, but as parallel visions with their own architectural philosophies.

Cloudflare and the Portability Response: ViNext

Cloudflare fired the most direct shot with ViNext — a reimplementation of the Next.js API surface built on Vite, designed to deploy natively to Cloudflare Workers with a single command. Built in just one week using AI-assisted development, its message was subtle but powerful:

Frameworks should not be infrastructure-bound.

The performance benchmarks back it up. On a shared 33-route App Router application:

Metric	Next.js 16.1.6 (Turbopack)	ViNext (Vite 7 / Rollup)	ViNext (Vite 8 / Rolldown)	Improvement
Production Build Time	7.38s	4.64s	1.67s	Up to 4.4x faster
Client Bundle (gzipped)	168.9 KB	74.0 KB	72.9 KB	Up to 57% smaller

Smaller bundles translate directly to better Core Web Vitals. Faster builds translate to faster developer iteration. These aren't marginal wins — they're structural advantages that challenge the assumption that tight Vercel integration is a prerequisite for performance. By enabling Next-style applications to run natively on Workers, Cloudflare weakened the perception of deployment exclusivity.

Remix: Standards-First, Framework-Light

Remix has been undergoing one of the more philosophically interesting evolutions in the React space. Rather than doubling down on RSC alignment, Remix 3 in 2026 takes a more radical step — shedding the React dependency entirely in favor of a web-standards-first, imperative model built on a Preact fork under the hood.

The focus: native browser APIs, zero-dependency lightness, and deployment portability across Node, Deno, and Bun without adapters. This is ideological diversification within the React ecosystem — a signal that you can build serious full-stack applications without betting your infrastructure on any single vendor's architectural assumptions.

TanStack Start: Optionality by Design

TanStack Start approaches full-stack React architecture differently from the ground up:

Router-first foundation built on TanStack Router
Data orchestration as a primitive
Vite-powered development with instant startup and fast HMR
Runtime flexibility and cloud neutrality

Its design philosophy reflects an awareness of structural centralization and aims to avoid reproducing it. Strong support for modern React patterns — including emerging RSC compatibility — comes without the lock-in. It positions itself as a Next.js alternative with less cognitive overhead and more portability.

Astro: Quiet Full-Stack Expansion

Astro continues expanding its capabilities while keeping framework optionality central.

React is supported — not required. Infrastructure is pluggable — not assumed. After joining Cloudflare in 2026, Astro v6 Beta introduced a redesigned dev server matching production runtime and first-class Workers support. Its islands architecture delivers zero-JS-by-default performance for content sites while enabling full-stack capabilities, and its multi-framework component strategy (React, Vue, Svelte interchangeably) acts as a decentralizing force in itself.

For many content-driven and hybrid applications, Astro is already outperforming Next.js — and its independence from React-core shifts means it sidesteps the Vercel/React entanglement entirely.

Hosting Diversity Still Exists — And It Matters

The framework layer isn't the only one that matters. On the infrastructure side, the ecosystem has real options:

Cloudflare Workers — especially with ViNext and Astro-native integrations — offers global distribution with strong cold start consistency.
Netlify remains a major frontend hosting platform with strong edge capabilities and Jamstack heritage.
Railway provides intelligent, all-in-one cloud infrastructure for apps and databases with automatic scaling.
Sevalla — a Heroku-like platform backed by Cloudflare infrastructure — offers competitive pricing and straightforward Docker deploys.

As long as multiple viable hosting providers exist, structural monopoly is prevented. The risk decreases when exit options remain healthy and credible. Competition at the infrastructure layer directly protects developers at the framework layer.

So Is This a Monopoly?

Not legally. Not absolutely.

But influence concentration is undeniable.

When the most widely adopted React framework, the primary RSC implementation, the reference documentation, and a tightly integrated hosting model all converge on one company — the ecosystem narrows. Developers who follow the "official path" end up, perhaps without realizing it, optimizing for Vercel's infrastructure model.

However, the frontend community has demonstrated resilience:

Infrastructure portability (Cloudflare Workers / ViNext)
Architectural diversification (Remix 3, TanStack Start)
Multi-framework strategies with true optionality (Astro)
Hosting plurality (Netlify, Railway, Sevalla, and others)

The web has survived previous periods of centralization — from the browser wars to platform capture attempts. Its survival mechanism has always been the same: fragmentation through innovation.

A Measured Conclusion

The concern is not that Vercel intends harm. The concern is structural concentration — and the systemic fragility it creates even when the dominant actor is well-intentioned.

The benchmarks are now contested. The alternatives are now credible. The ideological counter-movements — portability-first, standards-first, cloud-neutral — are gaining real traction.

Power in technology becomes problematic not when someone holds it — but when no one challenges it.

Right now, the frontend world is challenging it. And that is a sign of health.

Use Vercel where it excels. But know your alternatives. The more broadly adoption spreads across frameworks, runtimes, and hosts, the more resilient — and innovative — the ecosystem stays.

Sources synthesized from ecosystem research, Cloudflare engineering benchmarks, and community analysis across developer forums and technical blogs.

Microsoft Azure Static Web Apps: The Art of Sucking, Web App Horror Story

Ezhil Sivaraj SR — Sun, 27 Jul 2025 13:47:59 +0000

❗️Disclaimer

This is a random rant by a junior dev who experienced hell with azure so don't come to conclusion.
If You have any POV on my rant leave it in the comments definitely i will take your view.

🖕 Intro: Drop & Deploy? More Like Drop & Die

I built a static web app. A beautiful React-Router v7 (Remix based) app with SSR. What I wanted was simple — something like Netlify, Vercel, or even AWS Amplify. Just drag, drop, and deploy. Clean. Simple. Painless.

Then I met Microsoft Azure Static Web Apps — and my life started flashing before my eyes.

At first I thought, “Hey, Microsoft’s been doing this cloud thing for a while. Maybe they’ve figured out a nice flow.”
But Microsoft — bless their clueless hearts — said:

“Hmm, we are Microsoft. We always suck. Let’s make deployment feel like debugging in production… blindfolded.”

🚽 1. No Support for Remix? Because Microsoft Can’t Be Bothered

Let’s address the elephant in the package.json: Remix — a proper React framework with excellent SSR support — is completely ignored by Azure.

Where’s the preset mode for Remix like the one Azure provides for Angular, Vue, Gatsby, Next.js, Svelte, Hugo, Jekeyll, Nuxt, Blazor etc.?

Oh, there isn’t one. Because Remix isn’t “cool enough” to be given a preset — not by Azure’s internal “blessed frameworks” club.

Leave Blazor its microsoft own stuffs

And fine — you’re forcing me to use Azure Functions for SSR. Cool. Then where the hell is the wrapper library for Remix?

Actually there is one from @scandinavianairlines/remix-azure-functions
but is not working properly i don't know why, but yeah i am trying to build on my own

Microsoft thinks “static” equals “Next.js.” Nothing else matters. Not even the fact that Remix is open-source, React-based, and used by real teams in production.

And this isn’t just incompetence — it’s negligence. Remix is open-source, React-based, and being used in enterprise apps. But Microsoft still treats it like an exotic stack nobody asked for.

This isn’t developer tooling.
This is a clique — and if you’re not in the cool kid circle, you’re left to rot in documentation hell.

🤡 2. SSR/SSG with Azure Static Web Apps? LMAO No.

Netlify: Just mark a route for SSR.
Vercel: Just export getServerSideProps.
Azure: “Write a function. Yes, an actual Azure Function with HTTP trigger. For your SSR. And wire it to your static site manually.”

Let me get this straight.

I want to serve a blog, not launch a satellite. But Microsoft goes:

“Hmm. We suck better when you suffer more. Please spin up a managed function to serve your homepage.”

Why?

Why the actual f**k would a static asset be routed through a serverless function? You know what’s faster than that? Literally anything. A potato with a USB stick.

And then the punchline hits:

“Don’t worry. It’s behind a CDN.” – Microsoft, doing PR damage control

Oh, wow! Thanks! So now it’s a slow function and a CDN mystery box. Very cool.

🧪 3. Azure CLI & Local Testing – The Great Gaslight

Okay, fine. Let’s run it locally and test it.
I fire up Azure CLI, hit swa start and try to run my Remix build.

Does it behave like production?

“Hmm, we’re Microsoft. We always suck. Our CLI is only for decoration.”
Nothing matches.
Routing fails.
API proxies break.
Your managed function doesn’t even start unless you give it a sacrifice and half your CPU.

What the hell is this platform?

Even Firebase Hosting does better — and that shit is older than Stack Overflow.

💩 4. Pricing – You Pay for the Abuse

Now let’s talk cost.

You think: “Oh, it’s just a static web app, this should be free or cheap, right?”

Nope.

Microsoft be like:

“Hmm, we suck your wallet too. Enjoy charges for:

Function executions

Bandwidth

Storage

Your will to live” Meanwhile, others give you:

Free tier that actually works
Preview deployments that don’t randomly break
Functions that aren’t tied to Azure’s flavor of the month

Azure? You’ll be debugging why your cost spiked and why your function deployed without logs at the same time. God help you if you’re running an open-source project with limited budget.

🪦 5. Reliability? What’s That?

Let’s say, by some miracle, you get your Remix site deployed. It works! For a while.

Then the 6th commit rolls in.

“Hmm, we are Microsoft. We suck your source control too. Let’s silently corrupt your deployment!”
Poof. It’s gone. No logs. No rollback. Just broken deployments and a message: “Resource unavailable.”

Now let me tell you my own personal hell:
The first time I tried deploying, Azure yelled at me with a tsc build error. Confused, I popped the hood to see what was happening. Turns out the error came from an internal dependency: @azure/functions — a library that Microsoft themselves maintain. Sounds promising, right?

So I added a custom build step to ensure it was properly installed. That’s when the real shitshow began.

💥Boom.

“Package not found on npm.”

Yes, a Microsoft-managed library… wasn’t even on the registry at that moment. You heard that right — the official function library used by their entire static app ecosystem… gone. Vanished. Poof. 404’d into oblivion.

I tried again. Different setup. Same result. And eventually?
The entire Static Web App resource got corrupted. Deployment wasn’t just failing — the whole Azure resource was now broken. Unusable. Bricked like a bootlooping Android phone.

You think I’m exaggerating? Go ahead and try it. Make six commits to your working Remix project and watch it fall apart.

So now, guess what?

I had to recreate the Static Web App resource from scratch, update my CI, fix the repo permissions, and start over — all because Microsoft can’t even maintain their own deployment infra.

I don’t even have words for this. You know what works better? GitHub Pages.

I pray for Microsoft Azure’s slow and public demise. Not because I hate Microsoft — but because they clearly hate developers.

📛 6. Real Dev Confessions

I’ve seen real developers ask:

“Why is Azure Static Web App not picking my SSR route?”
“Why does it break after pushing a commit?”
“Why does it only work if I use VS Code and deploy from there?”

Answer:

Because Microsoft only wants you to use Microsoft tools with Microsoft defaults while worshiping the shrine of Satya in Visual Studio.
Even the error messages are passive-aggressive:
“Your build failed.”
“Where?”
“Yes.”

🕵️‍♂️ A Side Note: Vercel’s Quiet Monopoly

Funny how Microsoft only supports frameworks touched by Vercel.

Next.js? First-class support.
Svelte? Funded by vercel.
Nuxt.js? Merged with Vercel.
HUGO? Microsoft is closely working with Go.
Jekeyll? Works with Nitro underthehood - (Nitro funded by Vercel).

Remix? Dead to them.
Astro? Don’t even ask.

Makes you wonder — is the frontend world slowly being eaten alive by one player?

Or its just me felt like this with wrong intension

We’ll talk about that how open source is being turned into a walled garden in the next blog.

☠️ Final Words: Azure Static Web Apps Shouldn’t Exist

Microsoft had a chance.

They could’ve built a great alternative to Vercel and Netlify.
Instead, they built a bloated, poorly documented, slow-as-f**k platform that punishes you for trying to do anything non-Next.js.

“We are Microsoft. We always suck. But this time, we suck harder.”

My suggestion

Please, if you’re a junior dev: stay the hell away from Azure Static Web Apps.
☠️ DANGER AHEAD ☠️

Use Cloudflare, Vercel, Netlify, or even bare metal hosting. Anything but this.

I genuinely hope Microsoft kills Azure Static Web Apps and starts over — or at least admits they don’t care about frontend devs.

Because if this is the future of frontend cloud hosting…

Lets go for some other work.

Vike 6: The Underrated Meta-Framework That Lets You Choose Your Own Stack

Ezhil Sivaraj SR — Thu, 03 Apr 2025 15:58:00 +0000

Vike 6, a powerful meta-framework that's shaking up the way we build modern web applications. If you're looking for a flexible solution for Server-Side Rendering (SSR) and Static Site Generation (SSG) that lets you choose your favorite UI framework, Vike 6 is worth your attention.

Originally known as Vue-SSR, Vike has evolved into a framework-agnostic beast, supporting React, Vue, Solid, and more. This transformation, spearheaded by Sébastien Chopin and a team of dedicated contributors, marks a significant milestone in the framework's journey. Vike 6's release brings a refined developer experience and empowers you to build high-performance web apps without being tied to a specific framework. Check out the project on Vike's GitHub 🏗️!

❓ Why Vike 6 Isn't Getting More Exposure

Despite its powerful features and flexibility, Vike 6 hasn't gained mainstream adoption. Here's why:👇

1. 🌍 The Frontend Ecosystem is Saturated
Developers and companies have already invested in Next.js, Nuxt, SvelteKit, and SolidStart - all of which offer similar SSR/SSG features with strong communities. Vike lacks differentiation beyond being framework-agnostic.

2. 📢 Lack of Awareness and Marketing
Unlike Next.js (backed by Vercel) or Nuxt (backed by NuxtLabs), Vike doesn't have a strong marketing push. Many developers simply haven't heard of it.

3. 🏢 Companies Don't Prioritize Meta-Framework Changes
While developers rapidly switched from Node.js to Bun or Deno, frontend migrations are harder to justify. Companies are more cautious about migrating entire frontend architectures compared to switching JS runtimes.

4. 📚 Learning Curve and Documentation
While Vike is powerful, its documentation is not as polished as competing frameworks. New users might struggle to grasp its concepts compared to Next.js's polished guides.

5. 💰 Pricing Model and Monetization Uncertainty
Vike doesn't have a clear business model like Vercel's hosting for Next.js. Developers are hesitant to adopt tools that lack long-term funding or support.

❓ Can Vike Gain Traction

For Vike to become mainstream, it needs:

💪🏻 Stronger marketing efforts (community building, tutorials, and real-world case studies).

👍🏻 Better onboarding experience with improved documentation and DX.

✍🏻 Clear differentiation from existing meta-frameworks.

Until then, developers and companies are hesitant to adopt it, despite its strong technical merits.

🎨 Framework Agnostic - Choose Your Own Framework

One of Vike's most compelling features is its framework-agnostic core. Unlike other meta-frameworks that are tightly coupled with a specific UI library, Vike provides a set of core functionalities that are independent of your chosen framework. This 'choose your own adventure' approach gives you the freedom to use the tools you love.

🚀 Getting Started Quickly
Vike provides a CLI scaffold tool that helps you set up a project quickly with your preferred UI framework. This eliminates the hassle of manually configuring SSR, routing, and data fetching.⚡

Creating a New Vike Project
To create a new Vike project, you can use the npm create command:

npm create vike@latest

You'll be prompted to select a framework, such as React, Vue, Solid, Svelte, or even a custom setup.

✔ Select your UI framework:
❯ React
  Vue
  Solid
  Svelte

Once selected, Vike generates a starter template with the appropriate configurations for your chosen framework. 🎯

Example: Setting Up a React Project ⚛️

npm create vike@latest my-vike-app
cd my-vike-app
npm install
npm run dev

This initializes a React-based Vike app with SSR and SSG capabilities already configured.

Understanding the Scaffolded Structure

🏗️ What's Inside the Scaffolded Project?

The generated project includes:

🧿 A minimal project structure tailored for your chosen framework.
🧿 Vike configuration files to manage SSR, SSG, and routing.
🧿 A default page setup with +Page.js and +server.js files.
🧿 This means you can start building immediately, without worrying about complex configurations.🎉

Vike's scaffold command ensures that developers can get started quickly while keeping the project structure clean and maintainable.

my-vike-app/
├── pages/
│   ├── index/+Page.js  # Home page
│   ├── about/+Page.js  # About page
│   ├── products/+Page.js  # Dynamic Route Example
│   ├── products/+server.js  # Server-Side Data Fetching
├── renderer/  # Custom Rendering Logic
├── vite.config.js  # Vite Configuration
└── package.json

Each page has a +Page.js file, and optional +server.js for data fetching. This makes it easy to add new pages and manage SSR efficiently.

Customizing the Setup
For advanced users, you can scaffold a barebones project and configure everything manually:

npm create vike@latest -- --empty

This gives you a minimal setup where you can add your own custom integrations and structure the project however you like.

⚡ SSG and SSR: Best of Both Worlds

Vike excels at both Static Site Generation (SSG) and Server-Side Rendering (SSR), giving you the flexibility to choose the best approach for your application's needs. 🔄

⚡ SSG: Blazing Fast Performance
Vike pre-renders static HTML at build time, resulting in lightning-fast page loads and excellent SEO. You can pre-render specific pages or your entire site:

// Example page config for SSG
export const prerender = true;

🌐 SSR: Dynamic and Up-to-Date
Vike renders pages on the server and sends fully rendered HTML to the client, improving initial load times and SEO. Server-side data fetching ensures your pages are always fresh.

🗿 The Power of `pageContext`

At the heart of Vike's data management is pageContext. This central data object is available on both the server and client, facilitating seamless data sharing across different parts of your application. Think of it as a universal data store for your pages.

pageContext contains different types of data:

pageContext.data - Holds fetched data for the page.
pageContext.config - Stores configuration settings.
pageContext.routeParams - Contains dynamic route parameters.
pageContext.urlOriginal - Stores the original URL.
pageContext.exports - Includes exports from the page component.

This structured approach makes data access and management seamless in your application.

Custom Routing with pageContext
With Vike, you can define your own routing while ensuring the routes are hydrated on both the server and client using pageContext. Here's an example:

Step 1: Define a Custom Route

Create a +Page.js file inside a directory, for example, /pages/products/.

// /pages/products/+Page.js
export { default } from './ProductPage';
export const route = '/products/:id';

Step 2: Create the Page Component

Use pageContext.routeParams to dynamically fetch the product data based on the route parameter id.

// /pages/products/ProductPage.js
import { useData } from 'vike-react';

export default function ProductPage({ pageContext }) {
  const { id } = pageContext.routeParams;
  const data = useData();

  return (
    <div>
      <h1>Product {id}</h1>
      <p>{data.description}</p>
    </div>
  );
}

Step 3: Fetch Data on the Server
Modify the +server.js file to fetch data dynamically before rendering.

// /pages/products/+server.js
export { onBeforeRender };

async function onBeforeRender(pageContext) {
  const { id } = pageContext.routeParams;
  const data = await fetch(`https://api.example.com/products/${id}`).then(res => res.json());
  return {
    pageContext: { data }
  };
}

How It Works:

Custom Route Definition - The route export in +Page.js defines a dynamic route (/products/:id).

Data Fetching on the Server - onBeforeRender fetches data based on routeParams.

Hydration on the Client - useData() hook allows client components to access the server-fetched data.

This approach gives you complete control over routing while ensuring server-side rendering and hydration work seamlessly.

💸 Pricing Structure

While Vike itself is open-source and free to use, it does have a tiered pricing model for additional services and features. Here's how it works:🏷️

🎟️ Free Tier (For Individual Hobbies & Startups)
✅ Full access to the core framework
✅ SSR & SSG functionality included
✅ Unlimited personal & open-source projects
✅ Basic community support via GitHub discussions

💼 Paid Tier (For Enterprises & Premium Features)
Vike offers paid plans for businesses that need additional functionality and support:

💎 Enterprise Support: Priority bug fixes, dedicated support channels.
📊 Advanced Analytics: Insights into page rendering performance.
☁️ Managed Hosting (if applicable): Optimized Vike deployment solutions.

The exact pricing details haven't been heavily marketed, which contributes to uncertainty among developers and companies.

🎯 Conclusion

With Vike 6, you get the power of SSR, SSG, framework-agnostic flexibility, and seamless data management. Whether you're building a static blog📝 or a dynamic web app, Vike provides the tools to make it happen efficiently.💡

However, its lack of marketing, developer awareness, and the reluctance of companies to rethink frontend stacks means adoption has been slow. Additionally, uncertainty around its monetization model makes some developers hesitant to commit.🤔

Ready to give it a try ❓

Check out Vike's documentation and start building!🚀

The LAMP Lock-in: Why NIC Still Won’t Upgrade in 2025?

Ezhil Sivaraj SR — Tue, 11 Feb 2025 19:37:12 +0000

It's 2025, yet a significant number of Indian government websites and web apps are still running on the LAMP (🐧 Linux, 🌐 Apache, 🐬 MySQL, 🐘 PHP) stack. While LAMP has been a go-to architecture for decades, its continued dominance in mission-critical applications raises serious concerns about ⚡ performance, 📈 scalability, and 🎭 user experience.

## The Persistence of LAMP in NIC’s Web Infrastructure

The National Informatics Centre (NIC) is responsible for hosting and maintaining a large portion of 🇮🇳 India’s government websites and portals. From 📜 public service portals to 🏛️ administrative tools, NIC continues to rely on LAMP despite the existence of more modern, scalable, and efficient alternatives.

While LAMP is a decent choice for 🏗️ static websites or simple operations, the real issue arises when it's used for highly 📊 data-driven applications—especially those meant for government services. These systems require high availability, rapid response times, and scalability, all of which LAMP struggles to deliver effectively in 2025.

## Why This Matters: LAMP's Limitations in Data-Driven Applications

The problem isn’t just about sticking to an old-school 🏚️ tech stack. The issue lies in how LAMP is being used for applications that demand:

🚀 High Concurrency Handling – Government portals often experience traffic spikes, especially during 📅 exams, 📄 registrations, and 🗳️ elections. LAMP’s monolithic nature struggles with such loads compared to modern architectures like microservices with Node.js or Go.
📏 Scalability – Scaling a PHP-based application running on LAMP isn’t as seamless as with modern frameworks. Horizontal scaling with PHP-FPM and MySQL replication is possible, but it's far from the cloud-native, auto-scaling capabilities of Kubernetes with containerized applications.
🐢 Performance Issues – Slow government portals are not just frustrating but also hinder critical services. PHP, while improved over the years, still lacks the performance optimizations that modern frameworks like Next.js (Node.js) or Angular (Typescript) offer.

## Case Study: Poorly Optimized Government Websites

Some major Indian government websites highlight these concerns:

🛂 Indian Passport Website – Used by lakhs of users, this website runs on JSP (Java Server Pages). While JSP was a good option years ago, it struggles with today’s enormous traffic load. Developed & maintained by TCS, the website is wrapped in outdated table-based UI structures, showing a lack of proper frontend development.
🛢️ BharatGas, 🚘 Sarathi Parivahan, 📜 NSDL Portals – These platforms also lack a modern UI/UX approach. They rely on outdated table-based layouts that hinder user experience, showing an evident need for better frontend frameworks.

If these services can be offered, why not transition to modern frameworks like Angular, React, or Laravel for PHP-based applications?

NIC should not force reliance on JSP or LAMP when better alternatives exist.

Running Cheap is Not Always the Best Option

One of the key reasons LAMP is still widely used is cost-cutting. NIC's focus on running services as cheaply as possible has led to the continued reliance on older technology. However, running a tech stack just because it’s cost-effective isn’t always a good idea—especially when it results in slow, inefficient applications that affect millions of users daily.

In contrast, many modern government services worldwide have embraced cloud-native and microservices architectures, leveraging frameworks like Spring Boot (Java), FastAPI (Python), and serverless solutions to ensure scalability and performance.

The Way Forward: What NIC Should Consider

If the goal is to improve digital governance and citizen experience, NIC needs to rethink its approach. Some potential steps include:

🏗️ Adopting Microservices: Breaking down monolithic PHP applications into microservices can drastically improve scalability and performance.
☁️ Leveraging Cloud Infrastructure: Instead of hosting everything on NIC's data centers, adopting cloud-native services can improve reliability.
🖥️ Choosing the Right Frameworks: For data-driven applications, using frameworks optimized for high performance, such as Next.js, Spring Boot, or Golang, can significantly enhance user experience.
⚡ Prioritizing Performance Optimization: A well-optimized backend, along with caching strategies (Redis, CDN), can mitigate slow response times.
🎨 Improving UI/UX: Hiring skilled front-end developers and using modern UI frameworks (React, Angular, Vue) can drastically improve usability of government websites.

Final Thoughts: NIC Needs to Change

NIC has a responsibility to modernize, ensuring better digital services for millions of Indians. It’s time for a change—what’s stopping it?

While LAMP has served its purpose, its continued dominance in NIC’s infrastructure is no longer justifiable in 2025. Data-driven applications require frameworks that are built for modern needs, not just solutions that were good two decades ago. If NIC aims to enhance digital public services, it must embrace newer, scalable, and high-performance technologies instead of staying in its comfort zone with LAMP.

Additionally, a better UI/UX focus is necessary. Government websites must hire skilled front-end developers to improve accessibility, user experience, and navigation.

What do you think? Should NIC finally move on from LAMP, or is there a case for keeping it around? Let’s discuss!