3

Hello everyone

I'm new in the smart contract and Dapp development and I'm so confused about choosing a framework. my questions are dumb but I couldn't find the answers by myself. Here is my problem:

I started working with smart contracts with Foundry and I loved it. testing is just so easy using foundry and I didn't need any other language except solidity. since I wanted to digg more I started watching a course on the Hardhat and this is the problem I faced:

it seems like you can do much more when you're scripting with JS when you're interacting with other contracts and you can do much more different stuff and generally your hands are much more open. but I feel it's wrong and I can do it with solidity scripts too, I'm just not sure and I'm confused. can I do whatever I'm doing with JS with solidity scrips too? can I run solidity scripts on a server or I can only use node js and hardhat if I want to create Dapps having a server-side? Is there any way to use node js and JS scripts in the Foundry environment?

I really like the Foundry and I prefer it in terms of testing but it seems like it's a must to use Hardhat to achieve the full power of different tools and server-side stuff and Dapp development. what should I do?

2
  • Go with Foundry; would you test your Rust program in JavaScript? Or your Python program in JavaScript? etc. Commented Nov 29, 2023 at 13:14
  • 1
    @PaulRazvanBerg Sorry I don't understand what you mean. can I run solidity scripts on the server somehow? and can I implement features like event listening or such stuff with Foundry using JS scripts? because I think it would not be possible with solidity scripting.
    – emtothed
    Commented Nov 29, 2023 at 14:31

2 Answers 2

2

Solidity is a language for smart contract development while javascript/typescript these days, is used for frontend, backend and basically everything.

by sure, it always depends on what you want to do and I would say there is no "correct" answer, but:

Why I would prefer hardhat over foundry:
In most of the cases, you will also implement e.g. a web app which interacts with the smart contract. In that case, it is useful to have the code for testing etc. already in JS/TS as you can reuse most of it and don't have to write the same thing two times. e.g. if you have a token, you probably want to test the transfer of the token and you also want to have a token transfer function available in the web application. So the code for testing is not significantly different from the code for the web application. In this case, you can mostly reuse the code. You can also use the same code to build a separate testing application, monitoring, backend, automation (job) or whatever and if there is an error in calling the smart contract, its easier to debug it if you use the same base.

Why I would prefer foundry:
Foundry is Solidity optimized and much faster for testing, compiling etc. It is a bit easier and supports e.g. tracing or fuzz-testing which is not yet available for hardhat. If you interact with the smart contract in javascript, it could still be useful to have the code for testing in the same language as the smart contract and different to the usage. Its also easier for a Solidity developer to test the code in the same language (no context switch).

Overall I have never been a JavaScript fan, but due to the popularity of JS/TS, you will find libraries for nearly everything you need. If you want to do a web request as part of your testing (for whatever reason), followed by some fancy transformation etc., you'll most probably find JS libraries to do that. The chance is by sure higher than for Solidity.

Final conclusion for me would be:
if you do smart contract only => go with foundry because of its features (e.g. fuzz testing or tracing). If you do more than just smart contracts, so also frontend etc., or you work together with non-web3 frontend devs (people who don't know how to call a smart contract) go with hardhat.

1
  • hey there thanks a lot for your answer, I really appreciate it, I'm currently working on my hardhat/js skills not because I love it but because it seems like the market somehow prefers and expects developers to work with and be familiar with different parts of the web and be ready for the different tasks, not just solidity development. please correct me if i'm wrong. so here I am , I'm gonna learn more about hardhat but I'm gonna use hardhat-foundry plugins and work with both frameworks in a hybrid way and use the best parts of the both , thank you again for helping my friend
    – emtothed
    Commented Mar 1 at 19:57
2

Similar to web 2 programming. If you are only interested in solidity (which can be similar to the back-end in web 2), then you can prioritize working with Foundry.

But if you are a full-stack (solidity programming and web interface to interact with solidity like JS/TS) then I recommend you choose Hardhat because of its usefulness.

In addition, you can also use both Foundry and Hardhat in the same project by using Foundry to perform tests and Hardhat to program other parts. For example, using plugins @nomicfoundation/hardhat-foundry

3
  • hey there thanks a lot for your answer, I really appreciate it, I'm currently working on my hardhat/js skills not because I love it but because it seems like the market somehow prefers and expects developers to work with and be familiar with different parts of the web and be ready for the different tasks, not just solidity development. please correct me if i'm wrong. so here I am , I'm gonna learn more about hardhat but I'm gonna use hardhat-foundry plugins and work with both frameworks in a hybrid way and use the best parts of the both , thank you again for helping my friend
    – emtothed
    Commented Mar 1 at 19:57
  • @emtothed Greet. You can absolutely continue like that. Technology (like hardhat, foundry or plugins hardhat-foundry or maybe something new later) is just a tool to help you create products. If you have time, you should learn both well. Once you have a general understanding, you will easily have a clear view to choose the appropriate technology for each product developed in different cases. Let's continue that.
    – anhvietcr
    Commented Mar 3 at 2:49
  • 1
    Exactly, I was so confused for the past few months but now I see exactly what you said, after learning both tools, the best way to use them will show itself to me when I start using them in building products with enough knowledge, thank you again for spending the time and giving your priceless attention
    – emtothed
    Commented Mar 6 at 17:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.