Developer Experience must be our #1 Priority

Governance
44

Shout out to @dennis_zoma for taking action in this area with this PR: [WIP] Add references to ink!athon Boilerplate & Restructure ink! content by wottpal · Pull Request #5241 · w3f/polkadot-wiki · GitHub

More PRs like this would be great, if anyone has anything to add that they feel developers or the community could benefit from, definitely open an issue or PR on the Wiki :slight_smile: Part of developer experience should definitely be highlighting any good resource for building something using Polkadot tech.

The Wiki is one of the first results that comes up on Google SEO, so if you want to point to a useful tool, tutorial, or course, putting it there is definitely something to be considered.

The Builders Starters Guide on the Wiki is built to reflect that, but could always use more work. It gives a high level view of all paths one could take in developing within the ecosystem. While obvious to some of us which have been engrossed in the ecosystem, to outsiders the options are often not very obvious.

3 Likes
46

Polkadot has faded into irrelevancy in the mainstream. This has been abundantly made clear from the chatter on the wider CT ecosystem.

The lack of user adoption, which is tied to the scarcity of applications that significantly impact user experiences, is a notable concern. The equation is simple: killer apps drive user adoption, which in turn re-establishes Polkadot’s presence in the market.

It boils down to two things:

  1. Is the Offer Valuable? (Does your product significantly enhance the user’s experience?)
  2. Is the Offer Visible? (Is your product getting enough eyeballs?)

But, it’s incredibly hard to build killer apps in our ecosystem(at least on the application layer).
It’s a systemic issue in our ecosystem – application developers are treated as second class citizens.

We’ve been building YieldBay on the application layer of the Polkadot ecosystem for the past two years and the dev experience has been nothing short of painful.
But, we embrace the pain and collaborate, because we love Polkadot and believe in the vision.

Building on Polkadot and its parachains has its share of difficulties. Sometimes, it even feels like parachains are not as welcoming to builders as they could be, although this is more of a perception than a blanket truth. But I do want to express my gratitude to the several teams that have been incredibly supportive and generous with their help as we navigated through these challenges.

The hurdles such as lack of smart contract support, insufficient documentation, and tooling issues have been our unique challenges to navigate.

Alright, enough whining. What can we do about it?

Prioritizing Builders on Parachains

Parachain teams might find it beneficial to prioritize and support builders working on their protocols.

While it’s understandable that parachain teams, often being application builders themselves, might perceive alternative application teams as competition, but I believe embracing a free-market spirit of healthy competition could foster innovation and growth, enriching their own ecosystem.

Elevating Tooling and Developer Support

Everybody agrees on this.

For example, wagmi & viem are miles ahead of polkadot/api in developer experience.

Simplifying tasks with the Polkadot API(or completely abstracting it away), enhancing support, and making resources easily discoverable will significantly improve the developer experience.

Cultivating a Grassroots Developer Ecosystem

Creating a welcoming atmosphere for newbie developers is crucial.

While I see experienced developers in the Polkadot space help newbies day-in and day-out – it does not move the needle.

A more structured approach involving events, workshops, and clear pathways for newbies can move the needle.

I’ve seen multiple of my friends go from being zero to a stud developer in the Solana and EVM ecosystem – eventually, creating massive value for those ecosystems.

This all happens once they’re hooked, and it’s our job to get them over the initial hump to get them hooked to Polkadot.

Exploring and Enhancing XCM Use-Cases

As @albertov19 mentioned, XCM is a pain in the ass. It’s overly complicated for an application layer developer to comprehend and then to build something meaningful with it.

Again, I think both Parity and the Parachain teams need to step up their game and foster use-cases and developer teams who’re willing to experiment and build with XCM.

I see there’s a whole wiki dedicated to XCM now, that’s a step in the right direction.

Enhancing visibility of applications through Polkadot’s channels.

As @Birdo mentioned, Parity’s cooking on this front. I’ll refrain from repeating the same feedbacks that exist in this thread on the lack of support but I echo the sentiment.

I’m glad that Parity acknowledges this as a real issue and is working towards making things better.

In closing, while the path has had its share of obstacles, the Polkadot world is far from bleak.

Thousands of developers, despite the hardships, continue to build on Polkadot. I have massive respect for all of you, for your persistence and determination to create value for Polkadot.

Building a business on Polkadot is challenging, but it’s worth it.

It’s worth it to spend our sweet time here experimenting and iterating till we strike gold.

And by striking gold, I mean, solve problems for real users, run our businesses sustainably, and add value to the Polkadot ecosystem.

When we unite, work towards a common goal, and align our incentives, Polkadot’s future is not just bright; it’s unstoppable.

A big hug to @alice_und_bob for sparking this crucial discussion. It’s pivotal for the ongoing and future success of our ecosystem.

7 Likes
47

I want to provide a summary of what I see has been discussed so far. It’s hard to capture all aspects of the discussion in a succinct way, but I want to provide a starting point here. I think some of those points eventually should lead to bounties to allow developers in the eco to provide solutions.

End-to-end thinking is missing

Many Parity folks in this discussion were mostly concerned about Substrate developers (to the extent that their language only revolves around Substrate). On the other end of the spectrum, we had dapp developers who expressed not being seen and recognized by Parity and even parachain teams.

This observation matches with the original mindset of (in my words) “Parity builds Polkadot, Parachains build businesses”, but has in effect lead to these problems:

  • Duplication of effort: parachain teams have to re-implement the same QA processes, middleware, frontend solutions
  • Non-integrated solutions: While logically a separation of concerns should separate dapp development from parachains, there are several UX issues originating from this separation.
    • Users have to manage several accounts, while they are based on the same seed and could be represented as the same account, at least user-facing
    • Users have to manage several fee tokens, which are hard to acquire

A change of mindset can be noted. While originally it was thought that “Parity builds Polkadot, Parachains build businesses”, with the paradigm shift to the “ubiquitous computer” and the conception of new work types and the actor model for Polkadot, it no longer makes sense to treat everything as its own. Functionality in Polkadot is interdependent and we need to adopt an integrated view. This means thinking end-to-end, starting with the end-user experience in mind and building layers that actually work towards catering to users.

Proposed Solutions

  • provide more AI-supported documentation over the full Polkadot development space
  • more explicitly define conventions of how things should be done (e.g. using the xtoken standard in such and such manner) to reduce heterogeneity where it is not useful
  • improve tooling over the whole development process
  • parachains should start to accept DOT/KSM as gas token. This can be implemented in addition other native tokens. It makes sense economically too, since parachains will need DOT to pay for coretime on Polkadot.
  • We might want to agree to present a unified account ID to the user to reduce confusion
  • special hackathons that focus on integrating 2 or more parachain features within a single app would foster innovation and highlight integration issues that are still present when building apps on Polkadot.
  • provide standardized frameworks that connect to multiple chains easily and let users pick and use all available Polkadot wallets
  • Provide middleware that abstracts away account management for the user and/or requires them to sign fewer transactions, or enable use cases that force users to seemingly only create an account after they have used a product for a certain time (while it might already have existed and automatically signed transactions in the user client)

Reduce the Complexity of Building in Polkadot

Some issues in this area are already being addressed, such as

  • the Substrate codebase changing too frequently → addressed by stable long-term support versions of Polkadot
  • bootstrapping collator networks is a lot of effort → addressed by Tanssi
  • documentation

Proposed solutions

  • Direct devs to first build smart contracts before they build parachains. If they don’t know if they should build a smart contract or a parachain, default to suggest smart contracts (since they obviously haven’t hit a real barrier yet and are still only conceptualizing)
  • Improve Developer onboarding and support
    • visible and available videos, course, resources, docs
    • accelerator DAO
    • Key accounts from Parity, even for builders/teams that are only onboarding
  • reduce the complexity of XCM/interop, such that chains opening channels becomes far easier. The theoretical limit here is users opening channels permissionlessly and transferring assets. This is often not the actual goal, but if the system becomes this easy to use, a lot is achieved.
  • make it easy to implement actual chain-to-chain APIs, such that it becomes as simple as doing REST calls.

Substrate

Raised issues:

Proposed solutions:

XCM

@albertov19 pointed out that weight calculation is hard and XCM construction is complex. Suggested solutions include to request the destination chain to calculate the weight via a runtime API call and to create wrappers around XCM that make construction easier.

10 Likes
48

Tanssi would make it easier to deploy a parachain, but does not reduce complexity. Complexity is about the number and inter-connection of (non-orthogonal) concepts that you need to be aware of, which is not the same as “amount of efforts”.
Tanssi adds complexity by adding yet another concept (its own existence) that you have to learn about in order to deploy a parachain.

On the other hand, I’ve been trying to reduce complexity by trying to kill the concept of RPC nodes (with smoldot) and the concept of bootnodes (RFC 8).

It’s only by reducing the number of “things that exist” that you effectively make things more simple and effectively solve the long-term problem, not by adding more tools.

For the same reason, I don’t think that Vision for cleaner substrate-node's developer-facing interface · Issue #5 · paritytech/polkadot-sdk · GitHub solves anything for example.

I’m focusing on the client side because it’s my area, but please realize that you can’t solve the problem “things are too difficult” by adding even more “things”. You can only solve it by removing things or by hiding these things behind non-leaky abstractions.

4 Likes
49

There is a difference between system complexity and the complexity required to be understood by a dev to get a job done.

Ask a dev if it’s more complex to spin up a VM or install a server from scratch.

If we can remove the burden of coordinating a collator network from incubating teams, we should definitely do so.

50

The heuristic of “reducing the number of things that exist” being the only way to improve devex seems off, although not totally inaccurate.

We should be clear whether we’re talking about encapsulated complexity or systemic complexity.

A car is highly complex but encapsulated: the operator just needs to fill it with gas, push the pedals, and turn the wheel. An automatic transmission or braking assist system adds more complexity to make the vehicle easier to drive.

An OS kernel is highly complex but encapsulated: it runs code and provides APIs.

Polkadot and Substrate are both complex, but there’s no reason why simple interfaces can’t be put on top of them to encapsulate the complexity. Those abstractions also don’t need to be

There’s no requirement to learn about Tanssi, just as there’s no requirement to learn about docker, kubernetes, terraform, helm, AWS APIs to deploy in Web2. Systems like Heroku and Vercel abstracted that all away under the hood, even though they are notionally “more” things to learn about when developing for the cloud.

10 Likes
51

As Hang said, not only the Dx experience is terrible, but the cost was several times larger than building DApps on Ethereum or EVM-compatible chains.

Underestimated developer cost in Polkadot ecosystem

52

I was very obviously talking about interfaces, in other words “encapsulated complexity”. Note that I mention “concepts that you need to be aware of”. To be honest I almost feel a bit insulted by your response. I’m not a junior who has just learned about programming 3 months ago.

It’s the first time that I hear the words “encapsulated” and “systemic” complexity. They’re usually called “interface” and “implementation”, there’s no need to make up new fancy words for this.

Yes you don’t need to know how Heroku/Vercel work under the hood, and you don’t need to learn how Kubernetes/Docker/etc. work when using them, but that’s because Heroku/Vercel provide non-leaky abstractions.

Tanssi would be a leaky abstraction. They deploy RPC nodes for you, but you still need to know what RPC nodes are and how they work. They deploy collators for you, but you still need to know what collators are and how they work. They run servers for you, but (IIUC) it’s your job to compute the weights that are appropriate for these servers that you don’t have access to.

Using Tanssi reduces the necessity to learn about how to run a server, but does not reduce in any way the number of things (RPC nodes, weights, connectivity with the p2p network, etc.) that you have to deal with as a parachain builder. They simply can’t provide non-leaky abstractions, because “a chain” is not a precisely-defined concept at the moment.

There’s an argument to make that it’s still a good thing to use Tanssi, and I don’t disagree with that.
But in practice it’s not very difficult to recruit engineers that know how to run a software on a server, meanwhile it’s very difficult to find people who know what RPC nodes/weights/peer-to-peer networks/etc. are and how they work.

If you want to make parachain builders’ lives easier, the focus should therefore not be on making it easier to run servers, as this is common knowledge in the IT world, but on making it easier to deal with blockchain-specific stuff.

1 Like
53

And to elaborate:

What should happen is precisely making it possible to write non-leaky abstractions. To “encapsulate” chains if you want.
This requires specifications.

Most of the software-related problems that Polkadot suffers from can be traced back to the lack of specification if you dig a tiny little bit.
You could say that many of these problems come from the lack of direction, but if you try to write a specification you’ll realize that you need directions as a pre-requisite.

I’ve been continuously spamming about the need for precise specifications for years at this point, raising all the time arguments in favor of this, but it doesn’t happen and at this point I don’t know how to convince people anymore that this is perhaps the most critical thing to do.

4 Likes
54

It is inspiring to see everyone’s involvement and input around this topic, Polkadot has an army of dedicated individuals aiming for the same which is its success and recognition in the world of tomorrow! We at R0GUE want to help improve the developer experience and onboarding on Polkadot. We would like to share our idea: Pop Network, and we would really appreciate everyone’s feedback!

Thanks in advance :heart:

Also feel free to contact us: gor0gue:matrix.org

4 Likes
55

Your concern makes me interested. I am nearly completely new in the Polkadot ecosystem and pursuing a path of aspiring developer relations in my region. I feel like the elephant-size you mentioned is true. Substrate marketplace is filled with feature-rich pallets but it’s hard to reuse those without building a parachain. On the mouse-size smart contract side, there is no way to reuse the pallets inside them which makes the modular attribute of the pallet system rely on the underlying parachain infrastructure. I might be wrong so correct me if I am missing anything here.

56

Yes, as a mouse-size dApp dev, it’s challenging. But products like Tanssi facilitate the Parachain part, which is a huge step forward. And with Polkadot 2.0, we probably will see, other enabling projects, that can offer mouse-size standalone projects a place to be. Always an option is to find a fitting parachain, to host your project.

1 Like