Top 5 Headaches for Web3 Developers

Web3 is a new and developing homeworld for the decentralized internet. It is an infantile space, with not as strong an infrastructure as its Web2 predecessor.

The developer experience for Web3 is rife with inconveniences, including bloatedness, lack of protocol standardization, limited support for other platforms, and many more.

These issues aren’t really vocalized beyond the Web3 developer community. To bring some of these issues to light, let’s dive into some of the most common problems for Web3 builders.

1. Slow dApp Integration Pipeline

Integrating Web3 into applications today is extremely slow, especially when compared to Web2.

In Web2, complex application logic is offloaded to centralized servers. For example: when a user tweets, the app simply makes a request to Twitter’s API, which posts a tweet on the user’s behalf. This enables apps to remain lightweight and integrate dozens of APIs seamlessly.

But in Web3, applications handle this complex logic themselves, because central servers have been replaced with P2P networks and expensive smart contracts.

In order to integrate Web3 protocols into applications quickly, protocol developers maintain client-side SDKs for app developers to use. This process requires a lot of time and energy, on both the protocol developer and app developer’s behalf.

In order to understand why these client-side SDKs are required, and why they are time consuming to develop, we must first dive into the range of capabilities a typical Web3 application may want to include.

When building a dApp (decentralized application), you’re often not just interacting with smart contracts. Web3 applications often implement a variety of capabilities, such as: peer-to-peer messaging, decentralized storage, producing cryptographic signatures and proofs, interacting with side-chains, and the list goes on.

As we can see, building a Web3-enabled application is not as simple as interacting with a single endpoint on a server.

Some examples of Web3 SDKs are: libp2p, DAI.js, Ether.js, Aragon.js. When doing things this way, all changes on the backend must be manually integrated all the way through to the frontend.

This may include republishing a package that contains all of your onchain addresses, modifying & publishing the new version of the Javascript SDK, and lastly, integrating these new packages into your application while publishing that as well.

This development loop is much different from what web2 developers are accustomed to. Normally, they are able to make backend changes and have them automatically reflected in the frontend, if the service’s API stays consistent. 

2. Web3 is not Multi-Platform

Web3 has enabled a plethora of incredible innovations through browser-based Javascript applications. However, the software world is much larger than the browser.

Consider other types of applications such as: mobile, server side, video games, and IoT. In all of these use-cases, Javascript is typically not the language of choice. This is primarily due to the fact that the JS interpreter is very heavy and complex to integrate.

In order to bring Web3 to these various environments, developers are already creating and maintaining multiple SDKs. For example, you can find an IPFS SDK in JS, Python, Go, Rust, and Objective-C.

There are significant costs for creating and maintaining these libraries, making it preventatively difficult to scale protocol integrations.

Imagine having a bookshelf of hundreds of books in alphabetical order, and each new book you add means you must line up every single one of the books alphabetically, all over again.

This is the web3 developer’s headache. Each new Web3 protocol that gets developed has its own “bookshelf,” which only compounds the time needed to maintain and grow the Web3 development ecosystem.

3. Protocols are extendable, while dApps are not

So how is the ecosystem going today? Well, today we CAN publish extensions to protocols. Some great examples of this are Aragon and Yearn.

For Yearn you’re able to publish new strategies and get them added to the vaults upon consensus.

The downside is that the application does not dynamically update with details on how the strategy is working. In an ideal scenario, the Yearn Vault app would allow any user to click on a strategy, inspect its mechanics, and interact with the exposed levers and pulleys that keep it running. This instead is being done behind the scenes by a small group of maintainers and enthusiasts.

In the case of Aragon, developers can publish new pieces to the protocol on-chain, but the same scenario repeats itself where the client-side application does not dynamically update to support the new on-chain functionality.

For example, if a developer had created a new quadratic voting contract, and published it on-chain, it’d be great if the Aragon app was able to display and use it automatically (as long as it adheres to a standard interface).

The core reason why this is not possible has to do with the insecurities of Javascript. In order to have the app perform the logic described above, you’d need to dynamically inject new code within the app. This is extremely unsafe in the world of Javascript. More details on this here.

There are however ways around this, by leveraging something like WebAssembly, where it’s very easy to create a new secure VM instance. This allows for secure code injection, which enables dynamic client-side behaviour.

4. Costs of Composability 

What are the costs associated with Web3 composability? In order to understand this, we must remember the fact that integrating Web3 protocols requires client-side SDKs.

With each new SDK added, the application’s size grows. In addition to bloating the application, SDKs often have conflicting dependencies, leading to incompatibilities and many headaches.

This means that there is in fact an upper bound to how many integrations an app can have. This is much different than Web2’s microservice paradigm, where every imaginable API is a one-line HTTP request away.

In Web3, everything should be transparent, compatible, and reusable. This is the beauty and ethos of open-source. If we apply this thinking here, we’d like to imagine a future where the average Web3 application uses dozens of integrations, but this is looking unlikely if we continue down the path of client-side SDKs

5. Insecure Javascript Dependencies

Javascript is well known for being insecure. For example, one bad dependency can overwrite some other dependencies code, and inject nefarious logic that can steal all of the user’s funds.

There have been many projects that have been created by the Web3 community to try and fix this (such as LavaMoat), but these are simply bandaids on a much larger issue.

The insecurities of Javascript not only put user funds at risk, but they also hinder innovation in the space. As talked about above under section 3, application developers are unable to create the dynamic in-app experiences extendable Web3 protocols need due to Javascript’s insecurities.

Upcoming Improvements to Web3 Development

This brings us here: there is a project right now that is aiming to bring that Web2 experience to Web3 in a completely decentralized way. Web3API aims to present a single solution that can help address all of these problems.

Web3API will allow dApp developers to integrate any Web3 protocol through GraphQL, a widely used query language for Web2 developers. It will let you aggregate dozens of protocols into a dApp without bloating the size of the application, and provide the ability to interact with Web3 in any programming language through the magic of WebAssembly (Rust, J Python, Go, C,C#).

If you’d like to learn more about Web3API, follow our telegram group or fill out this inquiry form & we can set up a call.

Special shoutout to @dOrgjelli for helping me draft this article.

• Web3API Website
• Follow us on Twitter
• Join our Telegram
• Follow Ingalandia