Web3.js - Past, Present & Future

Hi everyone, it's Nazar here and today we are going to discuss the web3js, one of the most famous and widely used library in the Ethereum community. So we will be discussing some past aspects of the library and some future aspects as well as some present milestones that we have achieved currently. So let's get started. So first of all, we're going to explore the past about the library. Most of you had been using this library a lot, but maybe not aware of how this library was actually started. So this web3js library was started in 2014 by a solo contributor, Jeff Wickel. And in 2016, it was moved to another solo maintainer, Samuel Furter. And from 2018, EthereumJS from the Ethereum Foundation were maintaining it. And since two years, our company ChainSafe has been responsible to maintain this library. And if you look on the facts that this library has been maintained for over eight years, it has over a hundred contributors overall and have 17,000 more than 1,700 pull requests. And so far, 172 versions were released and out of which 90 were the pre-release version. That means this library had very thorough investigation and debugging and testing from the community during the pre-release versions. 90 pre-release version is a large number. And this library has 600,000 weekly downloads as well. And it's all because of the community who is using and trusting this library. And there are some fun facts about the library past. So version one of the library, web3js has been living in beta for two years and people have been using v1 beta in the production environment for many years because this v1 was in extensive testing and thorough debugging process. And we started to have a v2 rewrite in past and it was a failed and abundant rewrite attempt because of some aspects I will discuss in further slides. And we started v3 rewrite with some extensive features and which never lasted a lot. And since then, v1 is the only version which whole community has been using so far. This is quite an interesting aspect as well. And considering that like two rewrite attempts or two version attempts have been failed so far, but it doesn't mean that the library v1 version has been unstable. So v1 has been maintained and supported so far and had been doing it. And if you look at the aspect that v1 lived for the two years in beta, I think this is the most longest time after another project, ExpressJS version 5 being in the beta. It was almost more than two years. And there were some challenges we were facing in the web3js version 1. Most of you can understand it because you may have already reported some of the issues or have been also encountered or facing those issues. It was very upscaled code base. The code base was being maintained by over 100 contributors I explained earlier. So the code base was not using some standard process or standard patterns. The modules inside the code were very tightly coupled. There were a lot of technical challenges to maintain this code and there was a lot of difficulties to introduce a new features, particularly in the library v1. And most of you guys have already been using the TypeScript, hopefully. So there were a lot of decoupled types, decoupled types for the web3js version 1. And because of that, there were a lot of TypeScript issues being reported by the community. And if I look on the logs, I can see around 60 or 60 issues being reported of the mismatching or inaccurate types, which was one of the biggest challenges for us. And from the community perspective, the build size became around the bottleneck and for the dev development, because this library was bundled in a huge single package file and that package file was being bundled in every dev. And this was causing a lot of problems during the dev development by a lot of community as well. And on the larger spectrum, the web3js community and the tool chain has been advanced a lot. A lot of new frameworks, new patterns and new tools have been introduced in the community, in the ecosystem, but web3js could not get way forward because of those challenges I discussed earlier. So are we going to stick with the version 1 or are we going to do something about it? Despite the two attempts or failed attempts, we are still hopeful that we are going to present the current improvements in the library. And with that said, this is the new era for the web3js, the version 4. And this is not some speculation. It's been under development for over a year now and we are almost ready to release. Hopefully it's been released this month. But you can already explore directly from the GitHub. So version 4 is going to be a huge, huge, huge milestone for the web3js lifespan and it's going to address a lot of stuff that we've been discussing in the community and all those people have been addressing those things. So version 4 will come with a native TypeScript support and it will have a reduced build size. We have decoupled a lot of code and the complexity has been reduced since we are doing this rewrite completely from the scratch. So the code readability has been improved a lot and we try to make it extensible so that in the future we can add more features very easily and even the community can extend the library for their own use. And we focus on the test coverage for the version 4 and hopefully once, right now we are working on writing the system test for the library. And within a month when we will release the first alpha for the v4, it will be having a lot higher test coverage compared to the version 1 and compared to any other competitive library in the ecosystem. So the question is, does all these goals that we defined to rewrite for the version 4, are these good enough or we achieved it or not? Yes, we have achieved all these goals and the most important thing is that we achieved all these goals with a v1 parity API. So you don't need to be worried about that your projects are going to break. There could be slight changes that we will be documenting and sharing with the community in the change log or the migration guide, but those changes will not be a lot. Overall API of the version 1 remains the same. We explicitly decided this architecture change so that, or this pattern, so that a lot of community does not break their projects and they can easily migrate to the version 4, which is more recent. And the question is like, does it just rewrite of the v1 with the same API or does it include some new features as well or not? Yes, it is. It contains a lot of new features. It's not just the rewrite. Rewrite was the first objective, but during the rewrite, we focused on creating more features within the libraries so that we can be future safe and we can extend the library very easily in the future. And some of the features which I'm going to present here, which is very unique for the version 1, version 4 for the web3js library is unique in the Ethereum ecosystem. No other package or the utility as of now, which I remember so far may have introduced such features and hopefully you guys will like them. So the first of thing, the most important feature within our rewrite is this new introduction of the new validator because data is so important for any dev particularly and data validation has been an extensive job for the maintainers of the different devs. And we decided to create a brand new layer of the declarative validation for the community and we use this validator within our library as well and it is also available for you to use in your devs. So what is a declarative validator? So most of you know that JSON schema or JSON data is kind of a de facto data format for the JS community. JSON schema is also a de facto data standard for validation and communities already adopted it. So we use both of these schemes as a JSON data and the JSON schema and merge them together for the Ethereum community and you don't need to have no if else anymore and all of the validation that you're going to do using the JSON schema will be tightly coupled with the Ethereum types. So you don't need to remember the Ethereum native types or compared to the JavaScript native types. It will work seamlessly and this validator is also compatible with the Ethereum ABI schema. So if you have such an ABI it will also validate the data based on the ABI as well. Let's jump to some examples. So here you can see some example. So we have some data and which contains some addresses in an array and some balance and if I go with the imperative validation which we had been doing in previous library versions, you can see that we have some loops going on and then we are validating by using function calls and then throwing some errors and same for the balance field that we have we are particularly validating by using some function call. But if we go with a declarative approach you can see that we have schema defined for the data and this schema is going to present the whole anatomy of the data and if you notice that the data that we are going to present is very particular for the Ethereum. So we have an address array we have UN256 these are Ethereum types and we can validate this data based on this schema and there are different formats of the schema and hope you can explore further. So there is another feature that we introduce in version 4 rewrite and this is going to change the way you look into your data. So the question is that every dApp that you develop is not the same. So the need for every dApp is also different. Someone developing an app or using a library where he needs numbers in the beginning someone wants numbers in the number or someone wants just numbers to be a number string similarly for the bytes. So there can be different formats of the same data that you can use but previous version was very strict and very restrictive to the one data format which was not counter which was counterintuitive for the different dApps which were using different data formats. So we try to cover this as well and we are creating a dynamic data format which is quite easy. All of the Ethereum web3js library interfaces are going to return are going to support this custom data formatting and let's say we have this get balance and by default this get balance will return you a balance in the hex string format but if you want that the balance function should return the balance into different formats you can define your own data format specifying the format for the numbers and specifying the format for the bytes and passing these formats to the every function call is the last parameter and you will be get the data in that particular format that you define and you can use this formatting logic in your own project as well our library is extensively using it. So one more important feature maybe everyone should be relying it and I think this is one of the unique feature which web3js version 4 is going to introduce is a typeset for the contracts but without any transpiling so you don't need to transpile anything you can all you need is your API declaration in the typescript project. So there is no need for the transpiling of the APIs or creating or doing some command line execution of any other third party tools you just need to copy your ABI declare them into the typescript project and you will be ready to have a complete typeset contract instance. Let's say we have this ABI and all you need is to have this ABI declared and the trick is here that you have to declare them as a const so the typescript does not infer them as generic types rather have a strong type for each declaration and once you have declared this ABI as a const then you can create your contract instance and this contract instance will be completely typeset and there is no transpiling required and if you ever change the ABI or update your ABI your types will automatically reflect those change and typescript can detect the validations on the compile time. This is a unique feature and I would love that we will be sharing some feedback on it and there is another feature that we're going to introduce is easy extensibility for our API so the web 3 modules have introduced a different or consistent API to support all modules so when I'm referring to the modules you may be aware that web 3 has different modules like contracts, ethereum, ssh, ABI, ENS so these are different modules so we introduce a consistent API for all of the modules so that you don't have a different compatibility issues using them and you can also create your own modules if you want and the feature is very simple and like straightforward to introduce you just need to we have consistent object called web 3 context and all you need is to declare your component or the module which is extended from the web 3 context and then you have a library instance web 3 you just call them and use and you will get an instance of the component which will have all of the main component of the library linked for example a provider will be linked, a request manager, a subscription manager and a lot more will be linked to your component and that will easily so you can use your component easily with the same consistent API which we had been using in the ethereum or contract or ABI or ENS packages so this is all from the version 4 so the question is like this is all the features that we're going to introduce I think not there are a lot of future like lot of future improvements a lot of refactoring a lot of things going on in the version 4 and I will left all those to you that you can explore in the version 4 and the version 4 will is in the alpha hopefully this month and but you don't need to wait it you can go to the github and check out 4.x branch and it will be all up for you to install directly from the github and use it and yeah so what is the future so after the v4 alpha launch what we are going to do with the web3js library what future aspects we have so our main focus is to mature the v4 version 4 and release a production ready version this year with that said we are not going to deprecate the v1 right away we will still be supporting v1 but we will encourage everyone in the community to use version 4 and share their feedback with us and in the future we are going to introduce more flexible modularization in the library and we will be improving the tree shaking to minimize the dap build size so let's say your dap is going to use one function from the library so you don't need to rely on the whole library package you can just be using that one function and we will be improving tree shaking to achieve this particular aspect and for the developer I guess the login is most life-saving thing so in the future after maturing the v4 alpha we're going to introduce the comprehensive logging support to the library and we will also support out of the box integration for the different frontend tools like react, angular or vuejs so this library will be supporting all of these frontend tools out of the box and once that is been done then we will start supporting other ethereum projects as well so web3js will not just be the native ethereum client it could also be available to connect to the other ethereum projects as well and use the same library that you have been using for years and love it yeah that's all for the future and if you have any question I encourage everyone to join our community on the github on the discord the qr codes are here you can scan them and log in if you want and in particular a question you can also reach to me on the twitter and I will happy to answer those questions I look forward to everyone to test version 4 which is on the github and which will be alpha released in this during this month and I would like to get more feedback from you guys on the discord and on the other community channels and I'm happy to answer any questions after this presentation and hope to see you guys in person yeah thank you