The Ethereum blockchain offers plenty of excellent features that make perfect sense for Blockchain applications: immutability, transparency, and verified distribution across the globe.
But as a developer experience? Oof, it’s not fun. There are a number of tools and frameworks out there that support building a program that runs on the Ethereum virtual machine (EVM). Unfortunately, they all suffer, to a lesser or greater degree, from a lack of maturity. As a result, when developing day-to-day I spend just as much time wrestling with tooling issues as with my smart contracts.
The most important tool is the Solidity compiler which is the canonical method of generating machine code for the EVM. The compiler itself, in my experience, is pretty solid. Then again, we use Solhint before every test we run so any errors I have in my contracts are usually caught before it gets too far.
Documentation is the biggest failing here: the information is there but the structure makes it hard to quickly find basic information. As a short example, I wanted to verify that now, the built-in global variable, returns a timestamp in Unix epoch seconds. But instead of there being a reference page that has an alphabetical list of functions, variables, etc, I have to dive down several levels in the documentation to see it grouped in with other global variables in the Block and Transaction Properties section.
Compiling your Solidity contracts and generating EVM opcodes is only one part of developing for the Ethereum blockchain. We need to be able to deploy our contract to the blockchain too. It’s entirely possible to create an ad-hoc build and deploy system from shell scripts or whatever your favourite automation method might be. This being the wonderful world of open source though, we have several frameworks that aim to take away the grunt work.
There are a few of them out there, the most popular being:
Choosing which framework is difficult because each have their own pros and cons. We chose Truffle in the end due to the extensive documentation and good automated testing support. But there’s a difference between evaluating a tool and using it in anger.
Truffle’s built-in migration system supports automatic deploy of contracts to any blockchain. But, due to the aforementioned lack of maturity, it doesn’t have all the features you might expect from a well-rounded migration system (like Django’s DB migrations, Liquibase, etc.). For example, you might have written several migrations but only want to deploy the first two to the mainnet because the third is still under development. The only way to do this is manually move the offending migration out of the migrations directory temporarily while you run the `migrate` command.
I’ve been an advocate of automated testing for many years now. The times tests have saved me from myself numbers in the thousands. Therefore, the test features of Truffle really appeal to me. Being able to write Solidity unit test contracts to test other contracts is an excellent feature, even if they are hamstrung by the nature of the EVM environment.
These are just a small sample of the issues you’ll come across as you grok the Ethereum developer toolchain. A lot of these problems come from a lack of understanding of how the tools work and, sometimes, an incorrect assumption of how they should work based on the similarity to JS tooling. But the documentation on the tools could do with explaining and highlighting these differences too.
Hopefully, Ethereum documentation and tooling will mature with time so it reaches the same level as Python, Java, et al. For now though, here be dragons!
Check out the blog below to know more on Ethereum.