Sunrising Web3.js: Reuniting Solana's TypeScript Ecosystem

For half a decade, @solana/web3.js has been the default way developers, applications and users interact with Solana. Not because it was perfect; it never was, but because it represents us.

It bares the scars of a multitude of historical decisions; many of which were deeply misguided. Its class-heavy abstractions and un-tree-shakeable internals provide the beautiful, convenient, left-curve monolith intellisense craves, and its inconsistent method names and quirky abstractions gave even the most rational developer pause to ponder deep philosophical questions about the universe, like: “What does it truly mean to allowOwnerOffCurve?”

Despite all of its rough edges, for better or for worse, to most TypeScript developers building on Solana, Web3.js remains their default mental model.

Connection. PublicKey. Transaction. sendAndConfirmTransaction.

These aren’t just arbitrary classes and methods you can hand-wave away with modern functional Typescript magic — they are muscle memory. They are Stack Overflow answers, docs, examples, tutorials, SDKs, codebases, dashboards, wallets, and critical production systems. They are the surface area through which a generation of Solana developers learned the chain and have transitioned from a mere library to a pillar of Solana application infrastructure.

As such, it should come as no surprise to anyone that the planned obsolescence of Web3.js was always going to be a very high friction event for the developer ecosystem.

Kit Got The Internals Right

The thesis underpinning Kit is directionally correct: The legacy Web3.js architecture comes with real costs. Larger bundle sizes, complex dependency trees and degraded performance are all problems of pivotal importance if we want to enable developers to create the most performant decentralized applications in Web3.

Protocol development has surged ahead at breakneck speed, the original Typescript library has failed to keep pace. This is where Kit has really delivered, addressing the core issues of Web3.js head on.

Modular internals. Clearer type boundaries. Explicit primitives. Tree-shakeability. These design decisions are all in total philosophical alignment with the direction Solana is headed in. We want to go fast, and that is what Kit has delivered.

Unfortunately, despite Web3.js falling into disrepair, with the gap between its features and the protocol growing wider by the day, without any additional stepping stones to bridge the divide between Solana’s past and its future, Kit adoption has been much slower than we had hoped for, and this has led to a painful fragmentation of Solana’s Typescript ecosystem.

The Rewrite Tax

Rational developers don’t just automatically adopt a new SDK overnight because it is architecturally cleaner. So long as the cost of switching is higher than the cost of staying where they are, Newton’s first law tends to prevail.

In the case of Kit, the benefits are clear: smaller bundles, better performance, stronger primitives, modern internals.

The trade-offs involved are also clear: Completely new APIs, far more verbose grammar, incompatible types, new edge cases, new documentation gaps, and a whole new set of decisions to make — all of this before even starting your scratch rewrite just to be able to continue shipping what you already have today.

This is the part we have to be honest about: Web3.js has not remained dominant because it is better than Kit in any way. It’s because it’s familiar, far less verbose to write, and have become critical infrastructure for the vast majority of Solana applications in production today.

For brand new projects who are AI-driven, don’t have to consider the sunk cost of replacing their critical production infrastructure and have the leisure of relearning how to interact with Solana in dozens of lines of functional patterns instead of a handful of class methods, the benefits clearly outweigh the trade-offs.

For all of the applications currently in production however, it’s a really hard sell, and trying to strong-arm them into switching by abandoning Web3.js has been a huge misstep on our behalf as an ecosystem.

Kit Clients Were a Symptom

The ecosystem made many valiant attempts to smooth over the sharp edges of Kit’s API over the past two years.

Kite, Gill, and other Kit clients emerged because of the obvious demand to have Kit’s benefits without paying the cognitive cost of its interface. Every “Kit, but simpler” client proved the same thesis: The internals are extremely valuable, but the developer experience failed to meet developers where they were at.

All of these efforts were a rational response of a healthy ecosystem trying to heal. Without a clear winner, however, an obvious dilemma loomed: For each new client that emerged trying to heal this divide, our Typescript ecosystem became a little more fragmented.

Credit: XKCD, "Standards"

Now developers had to ask the question: Should I use Web3.js? Kit? Kite? Gill? A framework-specific wrapper? A wallet SDK abstraction? Something else entirely? This is where things really break down, as docs and tutorials would have to choose between supporting multiple alternatively, or picking a side, and neither felt like the right choice to be making.

Ethereum Already Warned Us

Ethereum already went through their own TypeScript library civil war.

For years, developers lived in the world of web3.js and ethers. Then viem arrived with a compelling argument: better TypeScript, better performance, smaller bundles, more predictable primitives, and a cleaner foundation for modern Ethereum apps.

Technically, a lot of that argument was right.

But the transition still created a split. Examples fractured. Tutorials aged overnight. Frameworks picked sides. Teams had to migrate from providers and signers to public clients and wallet clients. Some libraries moved quickly. Others stayed on ethers. Application developers were left gluing worlds together.

The lesson is not that viem was wrong. The lesson is that the best technical layer still needs an adoption path that respects existing software.

One of the primary reasons why Solana is so great is because Ethereum already made all of these mistakes for us so we do not have repeat them. This is just one more cautionary tale.

Reuniting The Typescript Ecosystem

The uncomfortable truth is that Web3.js had the API people wanted and the internals people did not, whereas Kit had the internals people needed and the API many did not want to relearn.

The obvious question became: Why are these separate things to begin with? What if Web3.js itself became the Kit client?

Not another wrapper. Not another competing standard. The standard developers already use, rebuilt on the internals the ecosystem actually needs and wants.

That is why we created Web3.js 3.0.

Preserve the developer muscle memory. Reduce the bundle size. Shrink the dependency tree. Improve performance. Catch the library back up to the protocol. Give developers a migration path that feels less like switching religions and more like an uneventful software upgrade.

And the results are already tangible.

Convergence Beats Fragmentation

The goal is not to win an SDK war. Kit is here to stay, and for better or worse, so is Web3.js. Solana doesn’t need dozens of competing TypeScript clients, each making slightly different bets on ergonomics, correctness and protocol fidelity. It needs a clear default path forward, not just for new developers starting from scratch, but for existing teams, wallet adapters, infra providers, application frameworks, and protocol engineers.

That is Web3.js 3.0. This is our convergence point. Kit as the foundation. Web3.js as the front door to our Typescript ecosystem.

By preserving the API surface developers already know and replacing the internals with Kit, today, we give the Solana TypeScript ecosystem what it always deserved: Modern Solana primitives, without a community-wide rewrite tax, and a clear path forward for Kit adoption.