The New Generation of Web3 Frontend Frameworks

As a Solana network extension, Neon allows developers to execute Ethereum bytecode within the Solana runtime.

What does that mean for frontend developers building UIs for Neon dApps?

The smart contracts behind Neon apps are written in Solidity, using familiar Ethereum frameworks. Consequently, the frontend will also be built using Ethereum-native frontend libraries, such as ethers.js or viem.

Only a few years ago, the default choices would have been web3.js or ethers.js. But today, a new framework has become a worthy contender - Viem, “a TypeScript Interface for Ethereum that provides low-level stateless primitives for interacting with Ethereum” (see Viem docs).

What’s curious is that Viem’s evolution parallels Solana’s own transition from @solana/web3.js to gill, a high-level toolkit built atop @solana/kit.

Since Neon developers operate in this borderland between Ethereum and Solana, building Solidity-based dApps with Solana wallet connections and native Solana program access, it’s important to understand how these two new frontend frameworks compare not only to their predecessors, but also to each other, and how Solana’s and Ethereum’s architectural differences define the evolution of its respective frontend frameworks.

In other words, what is possible now for frontend developers building on Ethereum and on Solana? How different is their developer experience? And how does it change with the new frontend frameworks?

‍

Towards a better DX for building UX

Early libraries like web3.js (Ethereum) and @solana/web3.js (Solana) defined the first generation of dApp tooling. But as projects scaled, developers began demanding lighter bundles, stronger typing, and better developer ergonomics.

On Ethereum, this shift led to the evolution web3.js → ethers.js → viem.

On Solana, from solana/web3.js to @solana/kit to gill.

Both ecosystems now share a clear design goal: improve performance, composability, and developer experience without losing control.

So, how has this evolution unfolded so far?

‍

Brief evolution overview

Ethereum

Ethers.js was among the first broadly adopted high-level libraries for Ethereum. It introduced “providers” as abstractions for connecting to Ethereum nodes and bundled common dApp features, such as contract interaction, event listening, wallet integration, into a single unified interface. Its combination of maturity, stability, and comprehensive tooling has made it a go-to option in the ecosystem.

That all-in-one paradigm, of course, has downsides: ethers.js generally produces larger bundles, hides internal complexity behind abstraction layers, and offers a rather limited static type inference.

Viem is aimed to solve these issues. It does an interesting twist - it replaces Ethers’ class-based abstractions with typed clients and explicit actions, which results in a flatter, more predictable architecture where every operation is a pure, typed function rather than a method on an object.

Another distinctive change is that it removes the long-standing “provider vs. signer” split entirely. Instead, it separates concerns through lightweight, stateless clients like publicClient for reads and walletClient for writes. This makes data flow explicit and easier to reason about, while its modular design enables tree-shaking (to import only the specific functions or clients you need) and significantly smaller bundles (~35–60 kB vs. ~130 kB for Ethers).

‍

Solana

solana/web3.js v1 played the same role as web3.js - it was the canonical JavaScript SDK that powered most Solana dApps, providing account management, RPC calls, transaction construction, and on-chain interactions.

It worked, but it was tightly coupled to legacy dependencies and lacked modularity, which is crucial to Solana to maintain performance.

solana/kit (formerly web3.js v2) rebuilt this foundation into small, explicit primitives: RPC factories, transaction builders, and WebSocket subscriptions, which are all importable separately.

However, Kit is intentionally low-level, which makes it more suitable for protocol developers, not app builders.

That’s where gill comes in. Built directly on solana/kit, it provides a high-level, ergonomic interface with built-in utilities and type-safe wrappers for app-building use cases (instead of building at protocol level).For example, instead of manually wiring RPCs and transactions, you can set up everything with a single call to createSolanaClient(), which bundles RPC, subscriptions, and transaction handling into one object.It also includes built-in helpers for frequently used Solana programs (Memo, Token, and Compute Budget) packaged as type-safe, modular imports. Basically, it’s the same tree-shaking as in viem - you can bring in only what they need, keeping builds small and clean.

‍

Technical differences: new vs. previous & Solana vs. Ethereum

Putting these frameworks side by side can reveal more than just syntax or feature updates - it shows how each ecosystem approaches the same core challenge: connecting frontend apps to blockchain logic. And since Ethereum and Solana architectures and runtime models are so different, they shape different design priorities.

In the tables below, we bring together the Ethereum and Solana stacks (Ethers.js → Viem and solana/kit → Gill) to see how each ecosystem solves the same frontend challenges in its own way. The goal isn’t just to compare features, but to understand how differences in runtime design and contract architecture shape what developers need from their tools.

‍

Providers / clients / connectivity

Functionality	Ethers.js	Viem	solana/kit	Gill	What this means
Core connection	`new JsonRpcProvider(url)`	`createPublicClient({ transport: http(url) })`	`createSolanaRpc(url)`	`createSolanaClient({ urlOrMoniker }) rpcSubscriptions, sendAndConfirmTransaction`	Viem & Gill expose small, typed client constructors; Kit is primitive-level; Ethers is class-based.
Fallback / multi-RPC	`new FallbackProvider([providers])`	`transport: fallback([http(...), ...])`	App-level pattern (compose multiple `createSolanaRpc(...)`)	App-level (compose multiple `createSolanaClient(...)`)	Ethereum SDKs include built-in support for multiple RPC endpoints, while Solana leaves redundancy setup to developers.
WebSocket	`new WebSocketProvider(wssUrl)`	`createPublicClient({ transport: webSocket(wssUrl) })`	`createSolanaRpcSubscriptions(wssUrl)`	Included from `createSolanaClient()` as `rpcSubscriptions`	Viem and Gill unify WS under the same client surface, making event handling simpler and more consistent; Kit exposes separate factories.
Injected wallet bridge	`new Web3Provider(window.ethereum)`	`createWalletClient({ transport: custom(window.ethereum) })`	External (Wallet Adapter et al.)	External (Wallet Adapter); Gill focuses on RPC/tx DX	Ethereum SDKs own the wallet connection logic, Solana separates it via external adapters for modular wallet UX and better performance.

‍

Signers & accounts

Topic	Ethers.js	Viem	solana/kit	Gill	What this means
Signer concept	`provider.getSigner()` (class)	`walletClient` (configured with `account`)	Expects a signer object (e.g., `Keypair`) passed into tx flow	Helpers to load signers for Node/CLI (`loadKeypairSignerFromFile()`, env loaders)	Ethereum SDKs manage account access internally since signing is done through connected wallets. Solana handles signing externally with explicit keypairs or adapters. Gill simplifies this process by adding built-in helpers for loading and using signers without changing Solana’s underlying model.

‍

Contracts / programs interaction

Topic	Ethers.js	Viem	solana/kit	Gill	What this means
Define target	`new Contract(address, abi, signerOrProvider)`	`getContract({ address, abi, client })`	Compose program instructions via separate packages; build tx manually	`gill/programs` includes common program helpers (Memo, Token, Compute Budget)	Ethereum uses ABI-driven “contract” objects; Solana constructs transactions from program instructions. Gill adds DX helpers on top of Kit’s primitives.

‍

Reading chain data

Topic	Ethers.js	Viem	solana/kit	Gill	What this means
Read methods	`provider.getBlock()`, `getTransaction()`, etc.	`client.getBlock()`, `getTransaction()`, etc. (typed actions)	`rpc.getSlot().send()`, `rpc.getLatestBlockhash().send()`, etc.	Same `rpc.*.send()` (via `createSolanaClient`)	All four libraries provide similar ways to read blockchain data, but Ethereum uses typed client actions while Solana relies on RPC calls. Gill simplifies this setup by packaging the necessary RPC components into one ready-to-use client.

‍

Encoding / serialization

Topic	Ethers.js	Viem	solana/kit	Gill	What this means
ABI / data	`utils.defaultAbiCoder.encode` `/decode`, helpers	`encodeAbiParameters` / `decodeAbiParameters`, typed	Binary layouts & instruction builders (package-specific)	Wraps common program clients; uses the same binary primitives underneath	ABI is Ethereum-specific; Solana uses binary instruction data. Viem and Gill keep things explicit and type-safe at the call sites to improve clarity when building txs.

‍

Fees / gas / compute units

Topic	Ethers.js	Viem	solana/kit	Gill	What this means
Estimation / budgeting	`contract.estimateGas.fn()`	`client.estimateContractGas()`	Use Compute Budget program instructions (manual import & compose)	`createTransaction({ computeUnitLimit, computeUnitPrice })` supports budgeting inline	Ethereum estimates gas; Solana uses compute budgeting to control resource limits. Gill makes budgeting part of transaction creation, while Kit requires manually adding compute instructions.

‍

Events / subscriptions

Topic	Ethers.js	Viem	solana/kit	Gill	What this means
Listen	`contract.on('Event', cb)`	`client.watchContractEvent({ eventName, onLogs })`	WebSocket subscriptions via `rpcSubscriptions` (e.g., logs, slots)	Same via `rpcSubscriptions` returned from client	Ethereum emits structured contract events as part of its EVM logs, so SDKs can expose them directly from the ABI. Solana doesn’t have contract-level events, programs write to logs or accounts instead. That’s why Solana SDKs use WebSocket subscriptions to track state changes, which Gill and Kit expose directly.

‍

Transactions & deployment

Topic	Ethers.js	Viem	solana/kit	Gill	What this means
Send tx	`signer.sendTransaction(tx)`	`client.sendTransaction({ ... })` / wallet actions	Build, sign, and `sendAndConfirmTransaction(tx)`	Same flow; `createSolanaClient()` returns `sendAndConfirmTransaction`	On both chains, the goal is the same: build, sign, and send a transaction. Viem and Gill simplify this process by wrapping it into a single, high-level call instead of multiple setup steps.
Deploy	`new ContractFactory(...).deploy()`	`walletClient.deployContract({ ... })`	Program deployment is a separate, uncommon frontend concern	Same (not a Gill focus)	On Ethereum, deploying contracts is part of normal app workflows. Solana programs are pre-deployed binaries, so deployment isn’t handled in typical app SDKs, hence Kit or Gill focus on transactions, not deployment.

‍

Both ecosystems’ frontend frameworks ultimately reflect the architectural logic of their blockchains.

Ethereum’s smart contracts are stateful and self-contained, which means dApp interaction happens through contract calls, e.g. read, write, and event listening. Hence, both ethers.js and viem revolve around ABI-driven contracts and wallet-based signing. The abstractions evolve from classes (ethers) to lightweight, functional clients (viem), but their purpose remains the same: make contract-level interaction simpler and safer.

Solana’s model, by contrast, is instruction-based and account-oriented. Programs are pre-deployed and stateless, so app logic happens through transactions composed of discrete instructions rather than direct contract calls. SDKs like solana/kit expose these primitives explicitly, while gill builds a convenience layer on top, streamlining signer setup, compute budgeting, and program utilities without hiding Solana’s explicit structure.

In short, the evolution from web3.js → ethers → viem and solana/web3.js → solana/kit → gill shows two chains converging on similar frontend goals - type safety, modularity, and clear developer experience, while still preserving the distinct execution philosophies of their architectures:

Ethereum’s “call a contract and listen for events” vs. Solana’s “compose and send instructions.”

If you’re curious to give these new frameworks a try, here’re some helpful resources:

Gill documentation - https://www.gillsdk.com/
Gill SDK GitHub - https://github.com/gillsdk/gill/tree/master
Viem documentation - https://viem.sh/docs/introduction
Viem Examples - https://github.com/wevm/viem/tree/main/examples

And don’t forget to get them from an MCP server directly into your build (e.g. by using https://context7.com/).

Let us know what you’ve built and feel free to ask for our assistance in the Discord dev channel.

Blog