Team and Background
Since 2017 I’ve been involved with user-facing blockchain applications. As any DApp developer knows, the first thing you do when building a DApp is run
npm i web3. I’ve debugged web3.js at a library level enough to help with troubleshooting and bug fixing on GitHub. I also created a wrapper library, called web3-yeet, which only exposes what 80% of DApps actually need, with a better DX.
Project and Justification
Technical Specification and Implementation
The absolute must of “porting” web3.js over to Nervos is to preserve the API surface. The package need to behave almost as transparently to developers as passing in a “platform” parameter. We need to think of developers as our adoption audience, and not confuse their target audience with ours.
The implementation will keep the Typescript support, and it will adapt wherever Ethereum and Nervos differ, just enough to make the difference clear without having to learn anything new.
The primary goal is to deliver a web3.js port that interacts with Nervos nodes.
A rough workplan may look as shown below:
- Determine which API surface to freeze for the spec.
- Port the RPC layer. Preserve the API surface, but make calls to Nervos.
- Refactor package structures to match Nervos’s naming and branding.
Specifically step 2 and 3 will require development and QC iterations to ensure that the package isn’t buggy. (web3.js often receives complaints of being a mess, so if Nervos can provide a superior DX, we give developer adoption yet another advantage.)
It is important not to lose sight of who the target audience is: developers. If we look at tooling provided by Google Cloud Platform for example, we can see a reflection of the project it represents. Even if the platform is top quality, if developers feel frustrated with trying to interact with it, they will look for alternatives. Nervos needs to provide an SDK with a familiar and ergonomic feel so that developers won’t just test the platform: they will test and stay.