Hey everyone — Bader here! Finally — the Web3 series continues. It has been a couple of weeks I’m aware — however, I can assure you that I have some pretty exciting announcements around things I’ve been building in the space.
Most of which will end up fueling the content for these guides!
For now, however, let’s just jump straight into Part 2 of How to Web3. This one is focused primarily on developers that already have some experience with development.
If you’re interested, read the last article on a general guide to the web3 space. This one will get more into the nitty-gritty of becoming a web3 developer, what you need to learn, and what to focus on.
Without further ado, let’s hop in!
Becoming a Web3 developer is not some mystical, unattainable thing. You’re still writing regular old code in your favorite programming languages, building beautiful UI/UX, and making sure your unit tests run.
Also, Web3 Development does not always equate to crypto. It’s more adoption of a change of mind on how you view the relationship between the user and the service.
Web3, in theory, is supposed to eliminate the service provider in the relationship between the service and the user. Essentially, as web3 developers, we ensure that it’s purely just the service and the user, with nothing else intercepting them. And to do that, we use a new set of protocols and methodologies to accomplish that goal.
Keep in mind this is still relatively new to get into. Much of Web3 is undefined, however, I will do my best to bestow whatever experience I have into what to learn, how to learn it, and the dos and don’ts of Web3 development.
When we build a full-stack web2 application, we often have a pretty traditional setup for most projects. While it does vary, every full stack application usually has the same core components: the backend, a database, and a frontend. Your backend is hosted on some centralized server (usually), talks with your database, and your frontend retrieves that info to display the users and make your service — well usable. In a small to medium-scale full-stack app, everything is managed by at most two to three servers.
With web3, this changes a little bit. We still have those components, just altered a bit. Oh yeah, we have blockchain now too — which implements some of the key parts behind web3’s main philosophy — giving control back to the user.
Essentially, your stack changes, but mostly on the backend side of things. Instead of using a centralized database — you’re usually using a decentralized database implementation that self-replicates itself across a bunch of nodes. This is how most off-chain storage solutions work.
Along with this, we have the addition of a blockchain. Now before you riot on why blockchain is a waste of energy and space — it actually introduces quite a few useful functions when developing web3 applications, such as an immutable record, fault tolerance, surefire user identity, and more.
From the graph above, you can mix and match different platforms to build the application you need. Here are two godly web3 combinations I would recommend learning (these may change over time!). Learning these will take you far into other protocols as well, as once you learn one stack, all the concepts pretty much apply everywhere:
The “Meats & Potatoes” Stack — Ethereum Smart Contracts, IPFS, and Web3.js. You can build some pretty cool apps using these, and there is a lot of existing support for them. This setup is pretty traditional, and you’ll learn a ton about how web3 works.
The “True Maker” Stack — Substrate, Polkadot.js, & Storj. A ton of customizability is here, however you’re going to be spending time figuring out how to run your own blockchain instance and customizing it to your liking. Teaches you a ton though! This is currently what I’m using for my projects. You can also take advantage of ink! Smart contracts to avoid blockchain core development.
By the way, you don’t necessarily need to use Ethereum or Substrate — you can use something like NEAR or Solana, which both can do the same thing, more or less. I’d also like to mention Ceramic, which is a pretty cool way to define data for off-chain use — which is something you would want to do for sure.
The best way to learn web3 is to start with one protocol and expand from there on what you need next to build your application.
Right now — there are few popular languages to focus on for web3, some more obvious than others:
Rust — Used on a protocol level, most web3 tech stacks use this at their core. If you’re looking to understand some core code over at Substrate, or even chains like Solana, then Rust is a must-learn for the future of Web3. Rust’s native WebAssembly support is uber-powerful, allowing it to seamlessly be used for cross-platform use cases. Rust is also being increasingly being used in smart contract development for blockchains like Solana and Substrate / Polkadot
Not too many changes in the realm of the front end. Your UI and UX stay mostly the same. The only thing you may have to account for is UI and UX related to wallets and managing crypto keys and accounts. I may do a separate article on this, as it’s a pretty imperative part of starting out in web3.
For front-end development, I’d highly recommend focusing on a framework like Ionic or React Native that lets you build for web, Android, and iOS. This way, you can have the most interoperability for your web3 apps.
Now, here comes a potentially conversational part. This list is just from my personal experience from building on web3:
That’s about wraps! It’s quite a bit of information, I know, but remember — the web3 space needs developers. Even Ethereum, the largest active smart contract platform in the world, has a measly few thousand active developers at the time of this writing.
This presents a huge opportunity — besides the fact that you can be a part of building the next iteration of the Internet as we know it.
Expect comprehensive guides on how to put projects together, and detailed use cases, as well as providing general direction in this growing and new space.
Feel free to contact me about anything at any time.
Also published here.