Modularity means multiple web3 developer journeys—we only need one | Opinion

Disclosure: The views and opinions expressed here belong solely to the author and do not represent the views and opinions of crypto.news’ editorial.

Modularity has made significant progress in expanding the web3 developer design space by unbundling the monolithic stack. Yet, with new capabilities comes new challenges that are our duty as protocol builders to overcome.

You might also like: It will take people, not tech, for modularity to succeed | Opinion

As the modular ecosystem stands today, there is no single tutorial that guides builders end to end. Developers must take on multiple journeys and educate themselves about every component part before they can start building their dApp. We must create better tools to help them interact with these technologies more productively. The onus is on us to simplify the developer journey, and we must do so by working together.

The modular developer journey

Let’s paint a picture of the current developer journey. Before a developer can start building, they must determine the infrastructure that will support their dApp. In web2, this can be as simple as selecting an operating system or even no-code software tools available online. With monolithic blockchains, it comes down to selecting the layer-1 (or layer-2) that best meets their technical and business requirements. In modular web3, the technical diversity and long-term social unknowns make choosing a protocol an already overwhelming task.

In the modular paradigm, a developer must understand how to construct the blockchain stack one layer at a time. However, many modular solutions are still in highly developmental stages, and it will take time to battle-test them for reliability and long-term relevance.

Additionally, many technical integrations and critical bridges that make modular architecture functional are incomplete or challenging to build with. Most blockchain roadmaps evolve over time; plans and priorities change, and no promises are certain.

This puts an immense cognitive load on developers to educate themselves about the differentiators of countless new protocols, associated security risks, trust assumptions, and overall technical readiness. And even once this is all figured out, there is a lack of shared resources that sufficiently guide developers on how to stack these technologies together.

DApp development is, therefore, high-risk, inconvenient, and very complex in its current form. Until we think more tactically about how these pieces fit together, it will be challenging for any developer to build consumer-friendly products.

We’ve been here before

There are plenty of lessons from the evolution of web2 that can and should be applied to web3. In its earlier phases, developers would run their own servers and might build sophisticated client-server interactions to produce web2-like applications, but it was an arduous and cumbersome process. It wasn’t until significant advances in cloud computing, JavaScript, AJAX, and responsive design that developers had fertile ground to build a web2 capable of achieving mass adoption.

Once the common traits of web2 systems were abstracted away from programmers, it became simple enough for large-scale experimentation. This eventually led to the phenomenal successful consumer applications we see today. This is what we must achieve for web3.

Building on a monolithic chain has edged closer to this state. Take Ethereum (ETH) as an example. Despite its constraints, developers have a clear understanding of how to build a dApp. It created the first true generation of web3 developers who eventually moved on to experiment with other blockchains.

Now, developers’ motivations have evolved past initial curiosity and experimentation, and they want to build sophisticated products that solve problems and create impact. These products require the flexibility and agility of modular solutions to work.

However, this flexibility introduces significantly more complexity. Exponentially, more decisions must be made when composing a modular framework. If we are to enable bolder experimentation and product development in web3, these complexities must be abstracted away in the same way they were in web2.

Building bridges, not islands

As modular protocol builders, we must acknowledge that this is a messy process but one we can systematize. We must create streamlined pathways between protocols and simplify the integration process so that any developer—web3 native or not—can build in easy steps.

There are three primary opportunities where we can collectively begin tackling these challenges.

Cross-platform networks. Core developers from different modular protocols could work together to create shared tools and interfaces that help developers build streamlined products. Developing these shared prototypes that package multiple protocols together will improve the developer experience, as they will be better able to identify the optimal setup according to their dApp’s needs, and seamlessly integrate these elements into their stack.

Shared documentation. Create content, tutorials, and documentation that clearly illustrate how to stack various modular protocols together, express how integrations function, and how one system might complement another. It will help developers better assess their needs, make more educated choices, and ultimately build stronger dApps.

Shared experiment weeks. Coordinate partnered initiatives that bring developers across multiple modular communities together and invite them to experiment and build. This would help developers better understand the dApp-building process across the modular stack, unlock new opportunities for shared development, and catalyze dApp production through experimentation.

The Cambrian explosion of modular solutions means that we see innovation in every corner, but we cannot continue to work in silos. For our protocols to achieve their fullest potential, we must move beyond the competition that consumes our time and energy at each layer and think about how we can collaborate across it. We only succeed when we reach the stage where developers can just focus on building their products, not the infrastructure we have designed to underpin them.

Source