Developer Experience must be our #1 Priority

Governance
23

We have been trying to resolve this problem with diversity on Polkadot by creating a package and API that allows for unified message construction for a while now. We are getting very little support from the community however due to the fact, that everyone wants to use fancy UI dashboards to do this stuff. Noone cares about this core lower-level stuff sadly.
Feel free to check out our work:

There is also currently a proposal for 5 months of maintenance funding to get us going (Feel free to check it out you might find information that will interest you)

1 Like
24

Thanks!

TBH I don’t have the technical expertise to understand where this component would sit. I would say in the XCM executor side of things?

Similar to Polkadot.js SDK that you have tx.paymentInfo(sender), it would be ideal that you would have something similar that allows you to programmatically know the weight and fees for a given XCM interaction.

Right now, the Moonbeam xcm-sdk relies on static, hardcoded values. For weight and token transfer it is normally not an issue because you just do BuyExecution with Unlimited- But, you need to know the minimum amount of execution you have to buy, etc. In the SDK, we check this manually either in the code or reviewing an XCM message, bump this to have some room, and hardcode this value. If there is a runtime upgrade in one of the chains, it just breaks.

I was speaking with @kckyeung about this at Token 2049 - Some API that provide fees on specific XCM messages is a must!

I don’t want to focus this thread only on XCM because I believe there are many other problems tho.

2 Likes
25

Here is the view from the bottom of the “food chain”. This is my view as an end-user-facing application developer on Polkadot.

I am a real Polkadot fan - but must also run a business. Lately, the thought of looking for a future elsewhere has grown. For our peers, but also for us. Alice_und_Bob, you described it very accurately in your intro. You could argue the ones struggling might not have the best business models. But this is only partly a financial issue. It’s a cultural problem of not being recognized as valuable members of this polkadot society.

Polkadot is ahead in Tech. But history has shown even the greatest technologies fold to inferior ones. We as a Polkadot society do not seem to care enough about the users and the app developers down low in the food chain, and every decoded reflects that. Have you tried talking to people about end-user-facing apps? It’s like selling ice to Eskimos. You get this alienated look before most Parity people disappear in the next Parachain Onboarding workshop.

We do struggle heavily with the responsibility gap between Parity and Parachains in fixing this. Although we really like what Moonbeam and Ajuna are doing to counteract it, we see the need for Parity to act now, before too many business applications migrate/die and no new ones are incentivized to join, making the food chain a quite fitting showcase of consequence.

Even this discussion here goes back to Tech after 3 comments and @rphmeier you are suggesting SDK as the solution. It brings me to tears to see great discussions about strategic focus repeatedly shifting to code in the comments. That’s as Polkadot as it can get.

Developers are not just Coders. Thats what heavily irritated me in the Developer survey as well. They are teams of creative individuals, taking big personal risks, and following a business plan that lives on short runways and sleepless nights. We should recognize these seemingly unimportant weirdos on the lower levels of the food chain and invite them in. Maybe build them a comfortable room or two. Right now they are camping in the garden while Parity is refining the building inside “to be the best - no, no, the perfect residence for the future”. The Users and the Applications sip on their warm teas in the rain and are hoping for the best.

I heavily care about Polkadot, but feel something is fundamentally threatening it’s success. And that is the “The Tech will fix it” culture. That’s why I want to embrace the suggestion @darkfriend77 has made. It implies a big change, but it would be a sensible and necessary course correction. It would probably hurt Ajuna, who suggested it the most to be consolidated into a Parity-driven Gaming vertical. But I truly believe we need to consolidate the Builders into verticals and give them less sleepless nights.

Greetings,
Deckard from the Evrloot Team

9 Likes
26

Edit*

I need to add that we have been in contact with Parity Ecosystem Marketing, namely Emily, and that we feel steps are being made in the right direction.

From my corporate past a cultural change like I described can’t be delegated to a unit alone, even with loose budget constraints. If top leadership is not actively pushing, you will move inches, not miles.

So my kind ask to Parity Management is:
You have taken steps in the right direction. It’s a topic that should be on your desk every week to make Polkadot successful. A good ecosystem Marketing alone will not solve the issue above.

Let’s build these save spaces for Apps and Users. Please.

Thank you!

27

It’d be nice to see them posting their views, approaches and strategies here in the way @shawntabrizi and @rphmeier do.

This forum is the most popular app in the ecosystem…

3 Likes
28

Thanks @alice_und_bob for creating this topic!
I strongly agree with the way you address the pain points, especially the point that Governance needs to focus on dev teams resonates greatly with me and I find the comments in proposals, that the teams should “stop draining the treasury” utterly disappointing and harmful on the long run.

I can also add to the suggestions mentioned above the need to create an easy to follow onboarding plan for dev teams. One of the outcomes of my discussions with dev teams in the past was the lack of clear user journey for those who are not interested in building a Parachain (as those mostly land with Parity programs anyway), but plan to build apps.
Please correct me if I am wrong and the situation changed for the past year, but the outcome of previous researches was that it took quite some time and effort for devs new to the ecosystem to onboard when starting from the Polkadot website. So it may be more of a call to action to the maintainers of Polkadot website to make a visual and clear path that devs can follow.

3 Likes
29

OMG I thought this was the problem too … until this month when I read the CoreJam/CorePlay new stuff. I now think “The Tech will fix it”. If you’re a real developer or want to really improve developer experiences, you should figure out what the guys are talking about here when they say this:

I think chains are an old concept anyway with coreplay :P 
the level of experimentation this would provide is pretty immense
basically, just turn polkadot into a global, secure map-reduce computer.

We all know these guys are all substance. I’m very excited as a developer what this means and I hope you all will take a VERY good look inside to figure it out like your entire Polkadot life depends on it.

If your parachain ain’t growing ( that’s 80%+ of parachains ), you might need to pivot to this map-reduce computer / CorePlay and let your parachain die. The Tech will not fix your parachain for you.

You can be part of the problem, or part of the solution. Pick one.

3 Likes
30

Hi sourabhniyogi. I get what you are saying, but I respectfully disagree with your suggestion that being part of the solution only means waiting for a revolution yet again. We can do more. There are multiple actors in an Ecosystem. Especially as a business owner, I have to make business decisions to pay my employee’s salaries. But let me emphasize one word to find an agreement. The tech won’t fix it alone. We have seen how a superior concept like Parachains shows problems in adoption. I think we can agree on that.

I assume this was partly due to the trust of superior technology to be the sole solution. My ask has nothing to do with revolutionizing Polkadot in parallel. It is a request for Polkadot Leadership to spend 2 hours/week on the application layer. I am not at all saying “do not pursue this great idea”.

As I wrote above, not everyone is a parachain in this ecosystem. We are a Dapp on Polkadot, dying to bring users here because we love Polkadot. Also you implying ‘I just did not understand the greatness of this vision’ perfectly emphasizes the point I made on Polkadot Culture.

“What does this guy want? He just needs to wait another XXX and we are there. Cmon, get lost with your ‘Business’.” See my point? As the small light I am, I would like to announce a small code red on Polkadot Culture.

1 Like
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
32

Thanks for this post, super interesting.

What would be the places you’d like to see more thought leadership in (currently working on this, so happy to hear specifics too)? Both the channels (podcasts / blogs / events) and the type (Tech? Web3? Specific ones, e.g. composability / decentralised decision making? Building in Web3?)

33

Blog posts of CorePlay Actor progression working examples (of AVFs) from @bkchr et al that is about the new Polkadot 2.0 programming model. This promises to make developer experiences more “natural”, similar to how you write a normal program.

The core thing is to be less blockchain-centric. We need to learn what that means.

This is SUPER Polkadot 2.0 WIP and surely will take a few months to bake, but will usher in new developer experiences in 2024.

In addition: CoreJam’s CRJA, Polkadot’s DA vs competition relative to EIP-4844 and its improvements, the new storage chain relative to EthStorage, and how these do and do not connect to each other.

All this is in the “The Tech Will Fix It” category:

  1. Programming Model. CorePlay => CoreJam = you want to buy CoreTime, right?
  2. Performance. If you enjoy hype backed by observation ala Tesla Ludicrous mode, some of the DA probably IS ludicrously better and storage chain hopefully in similar ways but we don’t know. 2023 brought in a new concept of cores and its expected to grow, but the core big bang needs visibility.
  3. Business Owners. Someone who may be thinking about building something like dydx circa 2023 is now choosing between conduit.xyz (OP Stack) vs Tanssi (Substrate) and is in the market for a ludicrously better not L2 chain but better designed system generally because of 1+2.

You do need to tease the above so its written by the engineers for the engineers – throughput/latency, DAGs, coscheduling for the “developer” brain, the why choose polkadot for another kind of brain.

Then, Polkadot being more than a relay chain is substantive narrative with CoreTime + ICC will be appropriate for non-engineers and the general public.

34

We are in early stages. Nothing is set into stone. We have some ideas and hopes that stuff will work out in a way that it will be useful to improve the developer experience. We will also see some of this stuff “becoming real” around next year. However, I don’t expect that everything will be finished next year. There is quite a lot of stuff to do. Thus we should for now focus on the current stack and what we have at our hands right now.

We for sure need to improve the developer experience around building your on chain and whatever. However, maybe we should more focus on the user facing side. I have to admit that I’m not that familiar with the current state of the stack there, but as for everything, I assume we have room for improvements. We for sure need to improve quite a lot on using light clients more for communicating with the chains. Maybe @josep can chime in and give some of his insights on what he is working on to make it easier to write light client friendly UIs. One thing that we currently don’t tackle are indexers and how to make them work in a decentralized way. I know that there are some zk indexers for ETH, but not sure if someone in our ecosystem is already working on something like this.

Ty! This and 100000000 times this! We as Parity are here to help, but we can not fix everything. We are also much more concentrated on the low level stuff and are better in providing show cases/prototypes for people. I hope that we can finally find a way to put more stuff into the ecosystem, because only a working ecosystem will make Polkadot a success, not an ecosystem that is just Parity et all. Parity should be a minority, an actor in the ecosystem and not more!

6 Likes
35

I think we always circulate back to “Parity fix this” as this would be binary.
I specifically stated that we need Parity to care. No one insisted in Parity fixing this over night. But Polkadot continuing being Tech only is not the solution either, so lets agree that there needs to be more visibility for End-User-Facing struggles.

Amen.

1 Like
36

But Polkadot not being just Parity :wink: I think we care and we have great people like @josep et all working on the “more userland” side of things to make your life easier. I’m really not an UI person, so I can not say that much. Maybe you can speak more about the biggest problems you see when it comes to UI? I hope that someone listens here and can help you or you help yourself :wink: (Don’t want to push this onto you, especially as I don’t know the complexity) Maybe there could be some OpenGov bounty or whatever to help improving this stuff.

37

Thank you for your answer. I do not have any specific UI problems. The problem statement I posted cannot be solved with development. It could be solved with Co-Marketing of meaningful ecosystem showcases, builders programs (beyond tech), connection to a VC network like typically done through Accelerator programs, a user hub to guide people in the ecosystem what use case can be found where, consolidation of the same value propositions into one more powerful value proposition, etc.

These are all ideas and I am happy to explore more! But they have little to do with Tech, and having to reiterate that every answer emphasizes my point that it can be quite alienating as a business on Polkadot.

38

Okay, but then you are maybe in the wrong thread. I mean there are threads like: Support for businesses building in/around the ecosystem
Which sound more fitting to the things you want to discuss?

39

Loving this thread. I appreciate this only addresses a small part of the bigger question but if there are company/teams/primitives that you think would benefit the broader Polkadot ecosystem and would address the challenge of improving the developer experience, I would welcome these names. As Parity BD, we can target these teams, when relevant pull in Parachains into the engagement, or guide the prospect through a Treasury proposal, or potentially try and unlock funding elsewhere if needed, or at least leverage our technical teams to answer their questions about how best to engage with Polkadot. TL:DR: if you suggest actionable steps, Parity BD is here to help contribute to this initiative. :slight_smile:

1 Like
40

It all comes back to the essential challenge, how can we build unique & amazing products (tech), talk about them (marketing), AND make them sustainable in the current market (core offering ecosystem, crowdloan, parachain model, evm, non-evm, CoreJam, Parathread, Blockspace … and and and).

Which is a challenge in more or less every area that we have been touching in this thread.

The current groups are centered around Parachains and their founders, the round tables. However, I think this should be opened up, and organized around verticals, so that the stakeholders from each vertical can create working groups to find pain points and solutions. In the gaming vertical, this seems now slowly forming, which is a great thing. I suggest that we work out these verticals and groups and assign responsibilities in there. I’m convinced that if we bring the right people together, we will find solutions, not for everything but for the long run. (I’m up to elaborate and work on this, just ping me)

3 Likes
41

+1 from our side

43

:wave: everyone!

It’s Josep from Parity :raising_hand_man:.

I had initially planned for my debut post in this forum to delve into the exciting projects my team at Parity has been engrossed in over the recent weeks. I was looking forward to revealing this in a few weeks from now, anticipating some truly groundbreaking showcases. But, given the mentions by @bkchr, it seems apt to at least provide a brief introduction about our current endeavors, our approach, and the vision driving us.

Before diving into that, I’d like to resonate with some poignant thoughts shared in this discussion. I particularly align with this insight by @tomaka and this comment by @bkchr:

We as Parity are here to help, but we can not fix everything. We are also much more concentrated on the low level stuff and are better in providing show cases/prototypes for people. I hope that we can finally find a way to put more stuff into the ecosystem, because only a working ecosystem will make Polkadot a success, not an ecosystem that is just Parity et all. Parity should be a minority, an actor in the ecosystem and not more!

Contradictory? Not in my view. I -like @bkchr- also really hope that we “can find a way to put more stuff into the ecosystem”. In my perspective, the inception lies in providing an accurate and up to date specification.

On a thrilling note, thanks mainly to @tomaka’s contributions, we now possess a light-client friendly JSON-RPC spec. This sets the stage for some of the most exciting developments from my team. But without further ado, let’s delve into what exactly we are formulating.

In essence, we’re focusing on crafting a composable, modular, and “light-client first” alternative to PJS. Our paramount aim is to equip dApp developers with the tools necessary to construct genuinely decentralized applications, all while ensuring a stellar developer experience. This is achievable thanks to our simple yet powerufl API complemented by robust typings.

Additionally, through a CLI, types will be auto-generated, enabling dApp developers to select the chain interactions vital to them, such as storage entries, transactions, events, constants, and errors. These “descriptors,” as I presently term them, represent the minimal units describing a specific chain interaction. This flexibility extends further, allowing developers to choose descriptors across multiple chains for crafting multichain dApps. Even descriptors from different runtimes could be utilized, ensuring dApps are prepared for particular runtime upgrades.

Our client will offer an API that will signal in real-time which of the provided descriptors align with the runtime of the currently connected chain. This real-time communication allows dApp developers to adapt to runtime upgrades as per their requirements.

Moreover, we aspire to ensure this top-level library, designed for “ordinary” dApp developers, is underpinned by small, composable building blocks. These blocks are intended to assist advanced developers in creating their unique tooling or bespoke solutions.

There’s a plethora of additional details I’m eager to unveil about our ongoing work. Rest assured, I will elaborate further on these soon, certainly before the year concludes, and likely in about a month or so.

You might be wondering why I haven’t used this forum earlier to shed light on these developments to the community. Personally, I lean more towards action rather than words. I firmly believe in letting our work speak for its caliber and impact. This doesn’t mean that comprehensive documentation will be overlooked. On the contrary, while striving for a tool that’s intuitive and straightforward for the fundamental and prevalent functionalities, we will ensure that ample resources are available for understanding and utilizing the full scope of our project.

My emphasis is on dedicating time to refine and enhance our work rather than promoting it prematurely. This stance doesn’t diminish the significance we place on feedback. Active engagement with various teams within the ecosystem is a consistent effort, ensuring our direction aligns with the collective needs and expectations. Showcasing our progress to these teams allows us to corroborate that our path is attuned to the larger goals of the community.

I invite you to observe our ongoing work at our GitHub repository. Despite the absence of official documentation at this juncture – a reflection of our compact team (3 devs) and the prioritization of development pace – advanced developers can glean substantial insights into our current accomplishments by exploring the public APIs, package tests, and contents within the “experiments” folder of the monorepo. In fact, I’m aware of at least one team in the ecosystem which is already using our work :slightly_smiling_face:.

In closing, while numerous aspects and details have not been covered in this brief overview, rest assured, a more systematic and comprehensive explanation is on the horizon. Your patience and continued support are immensely valued as we navigate this journey of innovation and growth at Parity. Stay tuned for more detailed updates coming your way soon!

6 Likes