What is Web3.js / @solana/kit
@solana/web3.js is Solana's original JavaScript SDK, the library used to build transactions, manage keys and query RPC nodes in a browser or on a server. @solana/kit is its successor, a ground-up rewrite that went through a brief incubation period as 'web3.js 2.0' before being renamed. By 2026, both libraries were ubiquitous - which is precisely why they were featured in the same entry.
The difference is packing a carry-on vs. bringing your whole closet along. web3.js 1.x ships as a single, monolithic bundle - import one class and your application is taking the entire library through airport security. Kit only packages what the trip needs: each function lives in its own isolated, tree-shakeable import, so the bundler automatically drops whatever code your application doesn't invoke.
How the Two Libraries Work
web3.js 1.x is class-based: instantiate a Connection class with an RPC endpoint, wrap all addresses in PublicKey instances, compose Transaction instances one method at a time. The design is a relic from Solana's infancy, which means most pre-2024 tutorials reference these classes. The penalty is paid on package install: those classes bring along dependencies that the bundler can't prune, which is why even lean wallet-connected applications must include hundreds of kilobytes of SDK even if most of that library is never touched.
@solana/kit reverses that pattern: the entire interface consists of pure functions designed to compose, the package imports zero external dependencies, and major work gets offloaded to native primitives like native BigInt in lieu of BigNumber shims and browser Web Crypto API in lieu of bundled Ed25519 logic. The outcome is far leaner bundles - the simplest possible transfer app runs at a fraction of the size of its 1.x counterpart - as well as faster signing and richer TypeScript types.
Comparison to Ethereum's Web3 vs. viem
Solana developers aren't the first to navigate this transition. Kit is to web3.js 1.x what viem is to ethers.js: a modern, functional, TypeScript-first rewrite challenging an old, class-based favorite. viem likewise opted for native BigInt, fully modularized its API, and took a multi-year coexistence phase as the ethers.js library already powered countless online code examples and tutorials. Anyone who's spent the past few months refactoring an ethers.js application into viem will find many of these parallels instantly recognizable, down to the new package names you need in order to import types.
Now to the practical impact of the transition. Imagine you're constructing a trading application which links up Phantom and Backpack wallets, as well as uses Jupiter's API for swaps. Both the official wallet-adapter packages and many older libraries expect web3.js 1.x types, while newer RPC utilities and docs now assume Kit by default. The solution is either pinning one's dependencies to 1.x for compatibility, or writing mini translators between the 1.x and Kit type systems - which is a real burden, although shrinking with every day new adapters update their code.
Why the Decision Matters
Bundle size is UX. A 200-millisecond speedup in a wallet-prompting or swap-widget will yield better engagement, and the gap between a trimmed-kit build and a 1.x monolith will be noticeable over slow mobile networks. Kit's zero-dependencies strategy also reduces the attack surface for supply chain exploits - fewer npm packages means fewer entry points for a bad actor to inject malicious code, another lesson the JavaScript community won't stop repeating.
The compromise is a smaller ecosystem. A decade of answers on Stack Overflow, reference projects, and third-party library integrations speak web3.js 1.x, and newbies following older tutorials are likely to get tripped up by type errors that stem from the SDK rather than their application. Being fluent in both dialects goes a long way to overcoming that obstacle.
Should you start with web3.js 1.x or Kit?
Focus on Kit for any new application you begin today: Kit is where the JavaScript ecosystem is headed. Still, learn to identify 1.x code at a glance, as the Connection and Transaction classes will remain in online code samples, job interviews, and documentation for years to come.
