Developer Experience must be our #1 Priority

Governance
31

Gm, another application-layer dev is joining the discussion. :raised_hands:

While being aligned with most of the identified pain points above, there is one topic that feels a bit underrepresented here: ink! smart contracts. They face most of the problems described above, though they are a special case and deserve more attention.

  • Developer experience needs to be improved. Even when leveraging the existing Rust packages, creating a new ecosystem around an unknown smart contract language is tough. Naturally.
  • Frontend developer experience needs to be improved. Everyone is always identifying UX as Web3’s (and more specifically, Polkadot’s) adoption problem, but at the same time, everyone seems to be only talking about necessary protocol/baselayer tech advancements. polkadot-js/api needs to be finally replaced or abstracted away as much as possible. The entry barrier for full-stack devs needs to be reduced drastically. – We just started tackling this problem ourselves by building ink!athon (full-stack dApp boilerplate for ink! smart contracts & React frontend). But this is only one part of the overall solution.
  • Treasury funding for tools improving this developer experience needs to be secured, also retroactively.
  • (Official) education & communication around parachains ↔ smart contracts needs to be shifted by 180° to “always go smart-contract-first – maybe towards a parachain/pallet later, but only if needed”. The PBA curriculum has improved a bit into this regard recently, but the overall Polkadot developer education in the internet is still completely newby-repellent IMO.

I think it’s really worth spending even more resources tackling these pain points for ink! specifically. It’s one puzzle piece in solving some of the broader Polkadot adoption problems, because:

  • Smart contracts have a way lower entry barrier for Web3 developers than parachain development. You don’t need to understand more than 1% of Substrate to deploy a Hello World smart contract.
  • At the same time, smart contracts can be used to build 90%+ of Web3 primitives. For the other 10%, they can be used as a starting point (PoC) and then emerge into a pallet/parachain later.
  • ink!/WASM/RISC-V is not EVM. With ink! & XCM live, there are now dozens of reasons against “why not just deploy on an ETH L2”. I could now talk about why Polkadot’s GTM strategy of only supporting Solidity smart contracts was the wrong decision in the first place, but this will get too off-topic.

So, instead of focusing only on the coretime/blockspace narratives (which are awesome), we should also shift more attention to ink! & XCM (which are not only awesome but also ready and working in production right now). And later, let’s combine them: “You can already write smart contracts? Amazing, now you can deploy them (or something similar) on the relay chain.” :exploding_head:

Chiming in on Rob’s “Build together” sub0 slide, I also think that Parity/W3F should not be the ones solving all of this alone. I’m not a fan of this “Parity should fix X” attitude that some teams seem to emphasize. Instead, we should all aim to be part of the solution. OpenGov, W3F Grants, Polkadot Fellowship, … – All of this is great groundwork (ofc with some rough edges) for getting our hands dirty ourselves and tackling problems we see down the road (like we’re doing with ink!athon or the very first XCM ink! contracts).

Cheers :squid: :purple_heart:

11 Likes