Choosing a Smart Contract Development Environment

Hardhat and Foundry and Ape, oh my!

Any programming work you do is done in the context of a development environment or framework. This consists of the tooling you need to compile, run, test, and finally deploy your code.

Developing Ethereum smart contracts is the same way. You need compilers, a local blockchain simulator, and frameworks to conduct testing. When I was getting started, I was pretty confused about what development framework I should use. Let’s dispel your confusion with an up-to-date list of what’s actually being used today, and what I’d use myself if I had to start over.

F-Tier

To start with, let’s chop off the low-hanging fruit - frameworks you should ignore.

If you see a guide which references dapptools, saddle, or truffle, that guide is outdated.

These frameworks are not used in new production environments anymore, and you are not likely to encounter them unless you get into the codebase of an OG DeFi protocol.

Similarly, Hardhat (a popular framework we’ll get to in a second) used to be called buidler. If you see a guide talking about buidler, it’s outdated.

You should also be wary about guides which talk about directly using Ganache. Ganache is a local node tool which lets you run simulation blockchains locally. It is under the hood of Hardhat’s node tool, and often used by other tools under the hood for testing and other local simulation needs.

Once upon a time, you might have used Ganache directly. Now, it’s rare except for advanced use cases. If you see an intro-level guide which advocates using Ganache directly, it’s probably outdated.

Now that that’s out of the way, let’s talk about what you actually want to use. There are three main frameworks which see active production use right now: Hardhat, Foundry, and Ape/Brownie.

Hardhat

Hardhat is the most common development framework you’ll see in production use. Developed by Nomic Foundation, it uses a Javascript/Typescript base, so your testing and scripting will be written in JS/TS using the ethers.js or web3.js libraries for blockchain interaction. In practice, this really means ethers.js, I rarely see web3 used.

The upsides: Hardhat is lindy. Framework bugs are rare, and the platform is mature, full-featured, and flexible. This makes it especially suited for multichain deployments, Diamond proxy contracts, and other use cases which require more complex devops.

Hardhat has a robust plugin system, which is used for both officially-supported and community-developed plugins for things like coverage testing, gas analysis, transaction tracing/debugging, and more. It supports both Solidity and Vyper development. You’re also more likely to get intelligent suggestions from GitHub Copilot, due to the larger volume of Ethers.js code in its corpus vs. Foundry.

The downsides: Hardhat’s development as a framework is relatively slow, and while its maintainers have kept up with critical things like new EVM versions, etc, the rate of new features is pretty glacial. This can lead to some frustration if you are pushing the tool’s limits, as those limits are likely to be there for a while.

The slow development pace also causes some security risk, as Hardhat workflows often rely on private keys in .env files. Brownie/Ape have had encrypted keystores for a long time, and Foundry has recently added this functionality. There are a few plugins, but generally support for hard wallets or encrypted key file in Hardhat is not great.

In general, you are reliant on plugins for a lot of functionality. Some plugins like the Etherscan verification tool are officially maintained by Nomic and are plugins in name only, effectively core code. Other plugins, like a transaction tracer which has saved me many times, are maintained by third parties. If they stop maintaining for whatever reason, you can lose functionality.

Hardhat also does not have a native fuzz testing tool. Not everyone needs this, but those who do will have to use external tools like the Echidna fuzzer from Trail of Bits.

Foundry

Foundry is a newer framework, developed by Paradigm. It boasts high performance and a robust and expanding feature set.

Foundry’s major strength (and major drawback) is that everything is done in Solidity. All your tests and scripts are written in Solidity. This removes some annoying abstraction layers and is attractive to new developers who don’t have to learn another language, but places some limits on what you can do. This limitation is particularly glaring when it comes to devops. File I/O is like walking over hot glass.

You should be forewarned: installing Foundry on Windows will drive you to the bottole. You have to build it from source on Windows and unless you already have a working Rust install on your machine, it’s not going to be a fun time. I highly recommend using a Linux environment for Foundry.

The positives: Foundry has a lot of good features. If you’re on a Linux machine it installs easily. It’s fast and highly performant, powered by a Rust backend. It has native fuzz-testing, gas reporting, and coverage reporting capabilities that are seamless to use.

The Chisel tool which comes with Foundry is a powerful REPL that makes it easy to check things like interface IDs, type casting behavior, etc, without writing a bunch of one-off utility scripts and console logging like you’d have to do in Hardhat. This feature is particularly useful for auditors.

The negatives: Foundry is in active development. While new features do come out frequently, instability is correspondingly more frequent. I’ve been bitten by bugs introduced in new Foundry versions a few times.

It’s also harder to extend Foundry. Due to the inventive ways that the Foundry team tortures the EVM to let you write your tests and scripts in Solidity, you’re largely reliant on the maintainers for features, instead of a plugin system like Hardhat. More advanced testing or more complex protocols may require the development and maintenance of extensive custom test harnesses for the Solidity-native environment to behave itself.

Finally, Foundry does not natively support Vyper, as you may guess given that you write your tests in Solidity. A proof-of-concept allowing you to use Vyper contracts does exists, but I do not know if it is ready for production use. Foundry also uses a Git submodules approach to dependency installation, which I have personally not found to be as seamless an experience as the well-characterized npm package management used with Hardhat.

Ape/Brownie

Ape Framework is the actively-developed spiritual successor to Brownie, the original (but stagnant) Python-based smart contract development framework. Ape will be a total replacement, but does not have the full feature set of Brownie yet, and devs may mix and match the two somewhat in practice. Ape supports Vyper and Solidity, but is often used by Vyper developers since Vyper is a Pythonic language.

Since Ape scripts and tests are written in Python, it’s very easy to integrate it with offchain workflows. It often finds use with people doing on-chain analytics. They can seamlessly access their usual data science tools like Pandas and Numpy, without having to pipe things across to scripts written in other languages. Bots are also easy to write and run.

Ape supports encrypted keystores, and since scripts are written in python, devops and file I/O is fully flexible.

Ape does not have a native fuzzer, developers would use Echidna or similar tools.

Comparison

All three frameworks mentioned are viable options to learn. Don’t split hairs about it if you’re on the fence, just pick one up!

On a number-of-projects-using basis, Ape is the least popular of the three. There are very reputable, serious projects like Yearn, Curve, and Lido using it, however, so if you do use it for your project you are in good company. Ape is also used a lot in less public-facing cases like data analytics, MEV bots, etc. My good friend and colleague

BowTiedDevil

uses Ape and Brownie in his bots over at

Degen Code

, a publication which I fully recommend.

Foundry is extremely popular among the newer cohort of smart contract professionals, especially auditors and optimizer specialist types. New devs often pick it up just because it’s the new hotness at the top of the tutorial list, but it has some features which make it very attractive for specialists. In particular the Chisel repl tool, seamless fuzz testing, and Solidity-native scripting makes it very easy for auditors and whitehats to test contract behavior and create proof-of-concept examples. Gas optimizers enjoy the robust native gas reporting capabilities and speed of the test suite.

Hardhat is less flashy but it’s an absolute workhorse. Many, many protocols run on hardhat, especially mid-aged ones from the DeFi summer era. If you throw a dart at the blockchain, you’re much more likely to hit a Hardhat project than anything else. This makes it a good play from an employability standpoint. Even if you don’t use it for your own work, you should be familiar with how it works to be able to read other codebases.

I’ve used both Hardhat and Foundry for production projects, and would use either one again. They have their foibles and strengths, but you can consider them relatively interchangeable.

If I were starting from zero as a new smart contract dev, I’d probably pick Foundry as my framework. I say that for several reasons.

One, it would be what my peer cohort is using. Two, it’s well-suited for auditing, and my recommended roadmap involves doing audit contests to develop your skills. Three, you’ll have to write portfolio projects and your initial paid projects will likely be smaller in scope. All my complaints about Foundry (devops, etc) are not going to be an issue for an NFT project or anything of similar size.

Note that “you only have to use one language” is NOT part of my reasoning. I picked up all the JS I needed to use Hardhat on the job. Learning new languages is not a barrier if you know how to code.

Whatever framework you pick is ultimately not that important. If you understand the EVM, and you know how to write smart contracts, then you can pick up the other types of scaffolding as needed. Just choose one and start learning!