Gabi - Web3 DevX: Building better developer focused products

Hi guys. So I'm Gabby. I'm a full stack engineer at sequence and I've been web three for like five years and I worked on pretty much everything. So from front end, back end, smart contracts, SDKs, some DevOps. uh and I think this gave me a nice chance to see how the developer thinks and what we need in point of like developer experience in all of these fields.

So today I'm here to talk about web 3x something that is not very um popular I would say nowadays but I think it's like really really important. So let's see how to build better uh developer focused products. [Music] Does this work? Oh, yeah. Okay.

So, what is Dex, right? Okay. Thinking about it, it's how a developer feels when he's trying to build with your product. Now, yeah, developers and feelings. Well, yes, we do have feelings.

And that's how I look when I work with a tool that has bad documentation. And to be now to get more serious, a dev should be able to use your tool without having to ping you, you or support. A lot of teams forget that um good Devex is actually free marketing. And that's because if you have good Devex, they just like to talk about your tool. they like to promote it especially when you talk about um big influencer devs I would say so like I don't know if any of you know Patrick Collings he's a big yeah big dev and big uh image of the web three space and he does talk about great tools and yeah you can have the most powerful tech but if it's painful to use then it won't go anywhere um and yeah no will know how to use it.

Now the problems are so this is taken from a web tree library called Vim or VM. So it it says that the current state of low-level um Ethereum interface abstractions lack in at least one of the following areas which is developer experience stability, bundle size or performance and it's it's a quadrilmma as they like to say. Now I think developer experience is the most important but also stability because I wouldn't use something that is not stable in production and bundle size and performance like they are also important but not so much maybe bundle size is very important if you use the tool on the client side on the front end side now currently web three dev still leaves a lot to be desired and I want to start with an example which is ethers Does anybody know about it? Did you use the library? Okay.

So, it's the most used web library right now, but it still lacks a lot in point of deex. Like the documentation, it's awful. They have almost no guides, no examples. And yeah, the docs are just huge. So, if you go there to learn how to use the tool, it's like very hard, especially if you don't have already web three knowledge.

uh it has been around for eight plus years. Um so it has a massive community and it's super stable and mature. That's true. But because it's so big and yeah, because it's so big and old, it does feel outdated and I don't think they will add a lot of DevX improvements uh because just because it's so big and it will take a lot of time for them to change the code to update the docs to create guides to create um migration guides and basically teach you the developer how to use it. They had an upgrade which is from V5 to V6 but it didn't feel like an upgrade.

It they just added a few use changes I think because they didn't cause any improvement on the user side. Most there was there were mostly um internal things for them. Now I like to talk about Vim um as an example for good deex. I'm not paid by them even though I wouldn't say no but they are as as they say um an an alternative to its etherjs and webjs with a focus on reliability efficiency and excellent developer experience um I think that's very true uh and ma mainly that's because they took a different approach so ethers as a webt library they took this approach of using um providers and signers. Now, Vimh instead of using providers, they use clients and actions and instead of using signers, they use accounts.

Um, there are specific reasons why, and you can find that in their documentation. Um, now we can clearly see that new devs are starting with Vimh because it's so much more readable, so much more easy to use and even the OG's like the old devs, some of them are switching to Vim. U yeah, for a very good reason. I like to say that Vim is like more than an MPM library and it that it is more like a language or framework and that's because they introduced a very clear and readable and beginner friendly way to um interact with the blockchain and the team behind it didn't just build a library. We build more than that because once you learn Vim, you also know how to use their u react hooks library which is Wagmei.

And I say that because it uses the same uh concepts like actions, wallet clients, uh the same code structure, the same documentation structure and yeah, it's really easy to use it once you know Vim and also with this small thing here ox. It's their newest library which is like a few months old and it allows you to pretty much have lower level control or just build your own library with it. So Vim is built with ox and then wagmi it's built with Vim. So yeah they just build their own framework ecosystem. Um yeah once you know Vim we already know everything I guess.

Uh this is an screenshot from the repository of examples. So you can just see how many of them are here. So let's say I'm a developer and I want to do something on ENS. I'll just go here. I'll find this folder ENS and I'll just find how to use VM to do stuff with ENS which is very powerful and very easy.

And I just love this. Um this is a screenshot from the bundle size. So basically it takes 31 kilobytes from Vim to just start with it. It takes 83 for ethers and 157 for um webjs. This is a comparison for the um iterations uh sorry the speed it takes for to encode AI parameters with all these libraries and you can see just how fast Vim is.

Yeah. related to the others. This is a tweet from a software engineer at abstract chain. So he basically said that Vim just released a new version that improved the polling time because previously they wait they're way uh they were waiting for seconds which is great for Ethereum but is not good for others like others layer layer 2s that are faster. So right now they added this new version where they listen to the block time and it's actually faster based on the chain.

This another great like improvement. Now what does excellent Devx means? Where first of all it's high quality docs um with step-by-step guides examples. Uh but yeah keep it simple. Don't don't make it too big, right?

you you get bored when you see bad and big documentation. Um fully type code like TypeScript TS doc. I will explain later what that is. Um and how it works. Then have demos of the tool that you know show how to integrate it, how to use it.

Um be compatible. So VHIM is compatible with this with ERC437 with 7702 with ZK sync opt and more. So basically what this means is if you want to send a user operation with Vim it's really easy you just so they are integrated with providers like by economy pimico and so on and you can with a few lines of codes just send a user operation and the same thing with EAP7702 so you can sign authorization and send a transaction uh very easily with a few lines of code um be active with the community X. Um, yeah, this one might feel maybe not so much needed, but it's actually very very important because it builds trust. Uh, it builds trust with the developers that are using your tool.

Uh, it also lets them talk one to one to another maybe in the comment section and help each other and it just shows that you are active and that you keep working you keep working on it. Um, now optimize the bundle size. Yeah, make your library three shakeable. This is also very important. And what three shakable means is if I want to use just three methods from an SDK, I don't want to use the entire size of the SDK.

I just want to use, you know, whatever I need to use for those three methods like that logic. And this is what three shakable means. And don't use too many dependencies because if there's a problem with one, there's a problem with yours too. um and you are dependent on too many dependencies. Yeah, that's why they are called dependencies.

Um be modular and always up to date with the latest trends. So Vim has this concept of experimental features and basically they add things that are not yet ready in their docs, but they allow you to learn how to use them before they get released. So when they get released, you already know how they work. Of course, like some things might change, but you already have the idea of how they work. This is a video of like me.

I don't know if I can post this. I don't think it was to post, but yeah. U so yeah, you see how I'm using the Vim SDK and I'm doing I want to use this send transaction method, right? So I write send transaction whatever. But then at the time when I hover over that function, it shows me documentation and a real like example on how to use that function.

So I don't have to go to the documentation and you know find there how it works. Maybe it's not even documented with a bad SDK. Let me play it again quickly. So yeah, you see I type send transaction now I just hover over it I get the explanation what it does etc the example I copy pasted and this is all done with uh TS do which is very powerful and also allows you to just um if you want you can quickly generate documentation only based on this. So you see the function is declared here and then you write the documentation inside the SDK code and then if you want to generate fast docs you can just run a script and then it generates you the documentation based on that.

Now how to build great tools. So the best way to build a library is to use a documentation and testdriven development approach which yeah leads to predictable APIs. Now, what documentationdriven development means is basically if you don't document a feature, it doesn't exist. And if the feature is documented incorrectly, then it's broken. No one knows how to use it except you.

If it works in your code, then it's great for you. But no one knows that it works if if it's not documented. Right? Now, good library is also fully typed. So this is what I was showing before with TypeScript documentation.

Explain arguments, examples, and always aim for 95 plus test coverage. Please don't push to production code that is not tested. That's uh that's very bad. And yeah, that's kind of it. You can follow me on X or um LinkedIn.

So if there's any questions, let me know.

Okay, cool. Um, so I'm familiar with uh testdriven development where you write tests, you start running tests and then you get an error back which tells you what to implement. How would you apply this to documentationdriven development?

Um, so no, yeah, maybe I said it wrong. Uh, documentationdriven development is uh something and then the test-driven development is something else, right? So documentation driven development is like you don't push a feature if it's not documented yet. So if if it's not documented, it doesn't exist. But then for testdriven development is like you don't push a feature if it's not tested, right?

And the process is like you test it. I mean you write the feature, you test it, you see if it works well, you go back, then test it again and then so on, right?

Um like testdriven development, it's in the name. You write the test and then you write the implementation. And I was kind of expecting like documentation driven development. Maybe you start from the how you expect the the feature to run from a documentation point of view and then you write the implementation.

Uh no for documentation driven development development is like you don't push a feature if it's not yet documented and that's the concept.

Can you enforce this somehow with um CI workflows or in some kind of way?

Yeah. So TS do dark that I was um speaking about before. Oh, I can't there was a video. So you can write TS doc for Okay. Yeah, this one.

All right. So it's u so yeah this is a recording of me using a function from Vim and you'll see I hover over it, right? I see this documentation. Uh this is TS do TS/doc. This is how it's called.

Now if you write this in your SDK you can create CI CD whatever scripts that just after you you push the feature to a branch let's say or you merge to to master or something it generates the documentation automatically based on this. Okay. So you don't have to write the docs manually but this is mostly used for like the internal team. So your colleagues see or other people from BD or whatever see like a high level of how this works. But then for users you do want to write something more complex right with guides and stuff because this is like more technical.

Yeah that's yeah that's how it's done you can do that. So Gabby bringing that a little bit in sort of normie like me wouldn't is that a type of you can classify as a hallucination checker so you know the hallucinations are not there so you know everything is there

hallucinations

yeah often like in I don't code at all but I work with some AI companies they use a hallucination checker to make sure that the communation is correct compared to what the code says. Yeah, I think I had never heard of the term hallucinations in uh code or programming, but um I mean you can hallucinate if with a feature if it's not documented, right? So you don't know how it works. So

that's what I mean. So it's checking for the hood just crazy stuff. So yeah, that's I think can be called as a

as I said it's to dumb it down to my own level because coding I don't know. So it's the way for me to understand a little bit better from my part.

Yeah. Yeah.

Well, thank you. Do we have any more questions from Oh, we have two already.

Uh, thank you. Uh, you talked about ethers like, uh, V5. And I had a question. Uh, let's say you have a project. Would you sacrifice like a week to rewrite everything in Vim and continue developing in Vim or would you continue the project with Ethers if

Yeah. So, it depends how big the project is. But you said a week. So I will assume it takes a week, right? I will.

Yeah. If it takes one week, it usually takes more. Like if you have a bigger project in ethers uh and you want to completely write it in VH maybe it's not even a thing based on like how much time it takes. But sometimes it's like not possible because you maybe you have a package and then you have a back end or something that relies on its types. So if you change from meters to Vim in the SDK then you also have to change it in your API in your back end to be compatible with the types that Vimh uh uses.

So but yeah I will sacrifice one week. Yeah

between V5 and V6 of they drop it the big number to use the native beacon. That way they can u the bundle size gets smaller. But if your app you have lots of usage of big numbers then indeed there is the question of the time you're going to have to refactor your code to drops the begin and blah blah blah is maybe also worth fully migrating. That's a that's a good point but yeah and if I may to to answer your question about the the dog before like in the dog driven so I can maybe share what I do. So what I do with the test doc as he explained what I generally I use that to generate to automatically generate the references on the website you know like I export those text dogs to markdown and then on the on the website I I used that markdown for the list of references but next to it as he said to I also write a bit of human readable explanation you know you kind of need the boss like the the things that everybody understand but but somewhere where you can find all the reference and all the the tricks and that you need.

It sounds correct to you, right, Gabby? Have I read everything?

Perfect. It I don't know anything of it. So I So he's coming up next. So now you you have to stay to give him another question afterwards.

So amazing talk, Gabby. Good job. Uh I want I just want to ask you about uh what do you think about project versioning and uh do you believe that we should have some standards for that? because we do have standards for you know general things like how do we commit uh things on GitHub for example but is there a standard or what is the best practice you know to do project uh versioning um so there is a standard for npm libraries right for SDKs uh so the versioning is like you know how there are three numbers so let's say I have version one but version one is version 1.0.

0 Z and the standard is any uh patch or any bug fix. It's like you change the latest digit like 1.0.1. Then it's every new feature you change the middle digit.

It's 1.1.1 now. And then any breaking change should uh increase the first one. So it's 2.

1.1. And that's the standard so that you know um you know how in SDKs in the package JSON if you declare a version you can use the tilda or no I don't know how that's called it's like the triangle without the bar down u it's like you use your package JSON will automatically upgrade the version when you do a npm install um but it won't upgrade to the latest one like from one to two it will only upgrade to one from 1 to 1.1 or 1.2 or whatever.

So that's a security so that you never automatically upgrade to a bigger version because that will break your app because it has breaking changes.

Yeah.

I hope that answered everything. Do we have any more questions from the audience today? Then I want to say thank you Gabby for the amazing master class in DevX and thank you for coming on stage.

Yeah, thank you. [Applause]