Developer Tooling in 2025: What's Missing to Onboard the Next Million Devs?

General
1

As a fullstack developer who recently transitioned from Web2 to Web3, I want to share my experience and discuss what we need to make Ethereum development more accessible.

My Background:

I spent 8 years building React/Node.js applications at startups and tech companies. I decided to learn Ethereum development in early 2024, and honestly, the learning curve was STEEP. But after a year of building and shipping two dapps, I have thoughts on what works and what desperately needs improvement.

What Made the Transition Hard:

  1. Tooling Fragmentation

    • In Web2: npm install, npm start - you’re running
    • In Web3: Choose between Hardhat/Foundry/Truffle, figure out which testing framework, configure networks, manage private keys, set up local blockchain, understand gas, etc.
    • The decision fatigue before writing a single line of code is overwhelming

  2. Documentation Quality

    • Best docs: Foundry Book, Hardhat docs (excellent)
    • Worst docs: Many protocol integrations (outdated examples, missing error handling, no TypeScript support)
    • Web2 equivalent: Imagine if Next.js docs were as good as Stripe docs, but Supabase docs were just GitHub READMEs

  3. Debugging is PAINFUL

    • Solidity error messages: “revert” (that’s it, that’s the whole error)
    • No stack traces in production
    • Gas estimation failures with cryptic messages
    • Transaction reverts on-chain - now what? Parse through Etherscan logs?
    • Compare to: Chrome DevTools, detailed React error overlays, Sentry integration

  4. Testing Blockchain Interactions

    • Unit tests for contracts: Pretty good now (Foundry/Forge is amazing)
    • Frontend integration tests: Nightmare fuel
    • How do you test wallet connections? Manual clicking in MetaMask
    • How do you test on testnets? Wait for transactions, deal with faucet limits, testnet downtime
    • No equivalent to Playwright/Cypress for dapp E2E testing

  5. Gas Optimization is Black Magic

    • You write working code
    • Deploy to testnet: $50 gas per transaction
    • Now you need to: Learn assembly? Use storage slots? Pack structs?
    • No linter that says “this will cost $X in gas, here’s how to optimize”
    • Gas profilers exist but require deep EVM knowledge to interpret

What Actually Helped Me:

:white_check_mark: Foundry - Coming from modern dev tools, Foundry feels RIGHT

  • Fast compilation
  • Built-in testing (Forge)
  • Deployment scripts in Solidity (not JavaScript!)
  • Gas profiling built-in
  • Fuzzing support

:white_check_mark: Scaffold-ETH - Great for prototyping

  • Pre-configured stack
  • Hot reloading for contracts (!)
  • Common patterns already implemented
  • Good for learning, maybe not production

:white_check_mark: OpenZeppelin Contracts & Wizard

  • Don’t reinvent security-critical code
  • Contract Wizard is perfect for beginners
  • Excellent documentation

:white_check_mark: Tenderly - Changed my debugging game

  • Transaction simulation
  • Visual debugger with state changes
  • Gas profiling
  • Should be integrated into every dev workflow

:white_check_mark: Alchemy University - Best structured learning

  • Free course covering fundamentals
  • Actually builds working projects
  • Active community

What We Desperately Need:

:red_circle: Better Error Messages

  • Solidity compiler should suggest fixes like Rust compiler
  • Runtime errors should include context: which line, which variables, why it failed
  • Gas estimation errors need to explain WHAT failed

:red_circle: Integrated Testing for Full Stack

  • Framework that handles: local chain + contract deployment + frontend + wallet mocking
  • One command to run full integration tests
  • Snapshot testing for contract states

:red_circle: Gas Linting & Optimization

  • Real-time gas cost feedback in IDE
  • “This function will cost $X at current gas prices”
  • Automated suggestions: “Use calldata instead of memory here (-15% gas)”
  • Compare to: Bundle size analysis in Web2

:red_circle: TypeScript-First Experience

  • Generate TypeScript types from ABIs automatically (Wagmi does this, but should be universal)
  • Type-safe contract interactions
  • IntelliSense for contract methods

:red_circle: Better Local Development

  • Hardhat Network is good, Anvil (Foundry) is great
  • But: Need better state management, time travel debugging, transaction history UI
  • Something like Redux DevTools but for blockchain state

:red_circle: Standardized Project Templates

  • create-react-app equivalent for dapps
  • Opinionated starter with best practices
  • Multiple flavors: DeFi, NFT, DAO, Gaming

Comparison to Web2 DX:

Aspect Web2 Web3 Gap
Setup time 5 minutes 2-3 hours :red_circle: Huge
Error messages Detailed Cryptic :red_circle: Huge
Testing Excellent Good for contracts, poor for integration :yellow_circle: Medium
Debugging Chrome DevTools Tenderly, Foundry debugger :yellow_circle: Medium
Deployment Vercel/Netlify (1-click) Manual, complex :red_circle: Huge
Monitoring Sentry, DataDog Tenderly, Defender :green_circle: Acceptable
Documentation Generally excellent Hit or miss :yellow_circle: Medium

My Ask to the Devconnect Community:

  1. Tool builders: Talk to Web2 devs making the transition. We’re your target audience for the “next million devs”
  2. Protocol teams: Invest in developer documentation. Outdated examples cost you integrations
  3. Ethereum Foundation: Compiler improvements (better errors) should be priority
  4. Educators: More “building in public” content showing REAL development workflow, mistakes and all

Questions for this thread:

  • What tools have made the biggest difference in your Ethereum dev experience?
  • Web2 devs: What’s stopped you from building on Ethereum?
  • What’s one tool you wish existed but doesn’t?

Looking forward to the Developer Experience track at Devconnect - this needs to be a priority for Ethereum to scale adoption!

(Posted by sam_fullstack)

2

Sam, this is EXACTLY the kind of feedback we need! As someone working on developer tooling at the Ethereum Foundation, your perspective as a Web2→Web3 developer is incredibly valuable. Let me share what we’re working on and where we need community help.

Ethereum Foundation Dev Tooling Priorities (2025):

1. Compiler & Language Improvements

Solidity 0.9.x Roadmap:

  • Better error messages (your #1 request!)
  • Gas optimization hints built into compiler
  • Enhanced type safety
  • Improved debugging information

Example of improved errors (coming soon):

:cross_mark: Current: “revert”
:white_check_mark: Future: “Transaction reverted in function transfer at line 45: insufficient balance. Required: 100 DAI, Available: 50 DAI”

This is inspired by Rust compiler excellence. We’re hiring compiler engineers specifically for this!

2. Debugging Infrastructure

EVM Tracing Standardization:
We’re working with Tenderly, Hardhat, and Foundry to standardize:

  • Stack traces across all tools
  • Consistent debugging format
  • Integration with popular IDEs

Goal: Chrome DevTools-level debugging for smart contracts

EIP in Progress:

  • Structured debugging information in bytecode
  • Source maps 2.0 (better than current format)
  • State diff visualization standard

Timeline: Specification by Q2 2025, implementation Q4 2025

3. Testing & Integration

You mentioned the nightmare of frontend integration testing. We hear you!

What we’re funding:

  • Automated wallet testing: Playwright plugin for MetaMask/WalletConnect
  • Local testnet improvements: Better state management, instant mining, time travel
  • Contract mocking: Generate mock contracts from ABIs automatically

Grants available: If someone wants to build E2E testing framework for dapps, we’ll fund it!

4. Gas Optimization Tooling

This is a BIG gap you correctly identified.

Projects we’re supporting:

  • gas-reporter 3.0: Real-time gas profiling in IDE
  • Foundry gas optimization: Automated suggestions
  • Solhint gas rules: Linter that catches gas anti-patterns

Example of what we want:

function transfer(address to, uint256 amount) public {
    balances[to] += amount
3

Sam and Yuki, this conversation is pure gold! As someone who teaches Solidity and blockchain development to hundreds of students yearly, let me share the education perspective - what concepts trip up newcomers and how we can fix it.

Teaching Blockchain Development: The Reality

My Background:

  • Taught 500+ students (bootcamps, university courses, online)
  • Students range from: complete beginners → experienced Web2 devs → CS PhDs
  • Course: 12-week blockchain development bootcamp

The Hardest Concepts to Teach:

1. Mental Model Shift (Weeks 1-2)

The Challenge:
Web2 developers think in terms of:

  • Mutable state (update database anytime)
  • Trusted backend (server controls everything)
  • Forgiving errors (rollback transactions, fix in production)

Blockchain requires:

  • Immutable state (can’t edit deployed contracts easily)
  • Trustless execution (code is law)
  • Expensive errors (bugs can lose millions)

How I Teach It:

:cross_mark: Doesn’t Work: “Blockchain is just a distributed database”
:white_check_mark: Works: “Imagine writing software where every bug costs real money, and you can’t easily patch it. How would you develop differently?”

Exercise: Deploy buggy contract to testnet, try to “fix” it, realize you can’t
Result: Students immediately understand why testing/auditing matter

2. Gas and Transaction Costs (Week 3)

The Confusion:

Students: “Why does this simple function cost $50?”
Me: “Gas depends on computational complexity and storage”
Students: “But it’s just 3 lines of code!”

The Real Issue:
Gas is invisible in Web2. Students don’t think about computation cost.

How I Teach It:

Week 1: Ignore gas completely (just learn Solidity)
Week 2: Introduce gas concept (without optimization)
Week 3: Gas optimization workshop

The Workshop:

  • Here’s a working but expensive contract (costs $100/tx)
  • Optimize it to <$1/tx
  • Learn: storage slots, memory vs calldata, loop optimization, packing

Before/After Example:

// Expensive: $50 per call
function updateUserData(address user, uint256 data) public {
    userData[user] = UserStruct({
        data: data,
        timestamp: block.timestamp,
        processed: false
    })
4

This has been an incredible discussion! As a core contributor to both Hardhat and Foundry, let me provide the framework comparison perspective - which tools to use when, and where the ecosystem is heading.

The Two Camps: JavaScript vs Rust

Hardhat (JavaScript/TypeScript):

  • Language: JavaScript/TypeScript
  • Testing: Mocha/Chai (JavaScript)
  • Philosophy: Web developer friendly
  • Ecosystem: Massive (npm)

Foundry (Rust/Solidity):

  • Language: Rust (with Solidity tests)
  • Testing: Solidity (write tests in Solidity!)
  • Philosophy: Performance and Solidity-native
  • Ecosystem: Growing

When I Recommend Each:

Use Hardhat if:

  1. Your team is JavaScript-first

    • Web2 developers transitioning
    • Frontend devs who also write contracts
    • Team already uses TypeScript

  2. You need extensive plugins

    • Hardhat has 100+ plugins
    • Etherscan verification, gas reporting, coverage, etc.
    • Rich ecosystem of community tools

  3. You’re building full-stack dapp

    • Frontend + contracts in same repo
    • Share types between contract and frontend (TypeChain)
    • Unified dev experience

  4. You want mature, stable tooling

    • Hardhat has been around since 2019
    • Battle-tested by thousands of projects
    • Well-documented edge cases

Use Foundry if:

  1. You prioritize testing speed

    • Foundry is 10-100x faster
    • Run 1000+ tests in seconds vs minutes
    • Critical for TDD workflow

  2. You want Solidity-native testing

    • Write tests in Solidity, not JavaScript
    • No context switching between languages
    • Better for testing complex contract interactions

  3. You need advanced testing features

    • Fuzz testing built-in
    • Invariant testing
    • Gas profiling
    • Symbolic execution (with hevm)

  4. Your team is Rust-savvy

    • Foundry toolchain is Rust
    • Can extend with Rust scripts
    • Modern Rust developer experience

Technical Comparison:

Feature Hardhat Foundry
Test Speed Slow (JS VM) Fast (Native)
Language JavaScript/TS Solidity/Rust
Compilation Slower Faster
Plugins 100+ Growing
Fuzzing Via plugins Built-in
Gas Profiling Plugin Built-in
Debugger Excellent Good
Learning Curve Easier (JS devs) Steeper
Type Safety TypeScript Rust + Solidity

Real-World Performance:

Testing 500 contract tests:

  • Hardhat: 3-5 minutes
  • Foundry: 10-30 seconds

100x speed difference in large test suites!

This changes development workflow:

Hardhat workflow:

  • Write code
  • Run tests (wait 3 minutes :hot_beverage:)
  • See failure
  • Fix code
  • Run tests again (wait 3 minutes :hot_beverage:)
  • 20-30 minute iteration cycle

Foundry workflow:

  • Write code
  • Run tests (10 seconds)
  • See failure
  • Fix code
  • Run tests again (10 seconds)
  • 2-3 minute iteration cycle

10x faster iteration = 10x faster development

My Personal Evolution:

2019-2022: Hardhat exclusively

  • Great for learning
  • JavaScript familiar
  • Plugins for everything

2022-2023: Tried Foundry

  • Frustrated by learning curve
  • But test speed was AMAZING
  • Fuzz testing caught bugs Hardhat missed

2023-2025: Foundry + Hardhat hybrid

  • Foundry for contracts and testing
  • Hardhat for deployment scripts (better TypeScript integration)
  • Best of both worlds

The Hybrid Approach:

Many teams now use BOTH:

my-project/
├── contracts/ (Solidity)
├── test/ (Foundry - Solidity tests)
├── script/ (Foundry - deployment)
├── scripts/ (Hardhat - TypeScript tasks)
└── frontend/ (TypeScript)

Workflow:

  1. Write contracts in Solidity
  2. Test with Foundry (fast iteration)
  3. Deploy with Foundry forge scripts
  4. Use Hardhat for complex TypeScript tasks
  5. Frontend uses TypeChain (from Hardhat)

Advanced Features Comparison:

Fuzzing:

Hardhat:

// Need plugin (echidna, hardhat-fuzzing)
// Slower, less mature

Foundry:

// Built-in, fast
function testFuzz_Transfer(uint256 amount) public {
    vm.assume(amount < type(uint128).max)