Frontend Development Experience

Tech Talk
1

I have been following the forum post Developer Experience must be our #1 Priority where everyone agrees that the developer experience has to be improved. One of the specific pain points there is the frontend developer experience Developer Experience must be our #1 Priority - #31 by dennis_zoma.

In the last months I have been in some hackathons where people were asking me what resources exist to build the frontend app. Checking the Polkadot wiki page, I can see it has only a small section on this topic Builders Starter's Guide · Polkadot Wiki.
The aim of this post is to collect here all the tools available in the ecosystem for frontend developers to make it easy for new devs to find all resources available and for us to figure out what tools are missing to lower the entry barrier.

I’ll start listing some of the tools/examples I collected for a StackExchange question How to interact substrate node with reactjs frontend?

One of the unique points our ecosystem has is the interoperability. I believe we will see soon more and more cross-chain use cases What are some demos parachain teams would be open to collaborating on? - #5 by Sacha.
An example of a tool that can help creating cross-chain applications is the asset-transfer-api that simplifies the construction of asset transfers for Substrate based chains.

Let’s use this post to collect all the tools the community has available to make building cross-chain applications easier for developers .

18 Likes
2

Ty so much for elaborating on this, @AlexD10S :heart:

Just if you haven’t checked out the Build > Tools > Open-Source Stack page in the Polkadot Wiki yet (Open Source Stack · Polkadot Wiki). There you’ll also find a bunch of stuff (e.g. related to ink! & Frontend which I’ve just PR’ed/updated a couple of weeks ago myself).

Regarding the ink!athon Boilerplate & the useInkathon library we’re really getting more and more traction here esp. because of the recent Encode Hackathon. We also just opened a new Community-led ink! Developer Group on Telegram. :speaking_head:

One important caveat here when referring back to my initial post: Substrate Frontend ≠ Substrate Frontend. Even though most of it is based on polkadot.js/* packages (unfortunately), it’s still totally different to interact e.g. with pallet-based stuff or with smart contracts. So just as a heads up, when collecting resources it’s important to highlight these differences esp. for newbies.

Example: For anyone building/starting with ink! I wouldn’t at all recommend the generic Frontend Example you linked above (contract-integration missing; lots of unecessary stuff). But instead our Full-Stack ink! DApp Boilerplate (probably biased here :stuck_out_tongue:) or maybe the useink examples.

All the best! And happy to collaborate in any of such efforts. :fire:

4 Likes
3

Thanks for sharing the Open Source Stack · Polkadot Wiki , is a great resource that for some reason I missed.

I love the idea of promoting the ink!athon Boilerplate & the useInkathon library in hackathons because most of the projects in these kind of events only need a Smart Contract and a Frontend and these tools fits perfectly for that.
I’d suggest you encourage these devs to post in https://substrate.stackexchange.com/ if they have issues/doubts using these tools, so we can grow the knowledge base of these tools and frontend development in general there.

3 Likes
4

Great topic, definitely something that is lacking. For reference, I am the one that put together the current version of the Starters Guide. Feel free to add a new section within with frontend specific tools specifically highlighted. I’d even consider making this guide its own section, covering each “track” in depth (expanding on what’s already there).

We could have multiple tracks, frontend, smart c ontract, protocol/core level dev, and ensure we point towards the tools and their respective example implementations and explain them briefly. What do you think?

Partially this mostly has to do with a simple lack of awareness of these tools, but also with a lack of examples.

These tools are great, should be covered, but ultimately it’s hard for someone new to the eco to jump in and know where to start if they don’t know their potential.

3 Likes
5

I’ve been following the engaging discussion on the forum titled “Developer Experience must be our #1 Priority”, and I couldn’t agree more.

I’d like to emphasize the importance of enhancing the Frontend Developer Experience: I think that the main target is to fight all the frustrations that UI devs have on entering the ecosystem by understanding and building everything from scratch, to connecting their UI App with the blockchain network, and providing a seemless front-end experience; Mainly to reduce the complexity of building a UI App, in polkadot using all fracture information around the web and the minimum documentation and examples;

Just a suggestion

In order to reduce our efforts on building apps, reuse the existing code and at the same time provide some guidence/docs on “how things work” we have been working on a side pet-project, with @ross (Ross Bulat), for the past few months called Polkadot Cloud - a library and platform for developing and publishing assets for Polkadot dapps. It was identified and conceptualised as a need, almost 2 years ago, started under the name “Dashboard UI” almost a year ago, and finally converted to today’s Polkadot Cloud;

The idea was this: instead of forcing developers to build everything from scratch, in order to make their UI App communicate with the blockchain network and/or integrate online or offline wallets, we can provide a stepping stone with tools and resources needed to streamline the process and allow the developers, go from zero to PoC in no-time;

It is designed to serve as a repository, hosting a wide array of assets, including data sources, graphical elements, fully functional components, and what we refer to as “recipes”, that app developers can effortlessly integrate into their codebases - but at the same time it is not meant to replace other Components solutions (such as MaterialUI, Ant.Design, Bootstrap etc etc)

“What is what”, when it come to packages:

Core - Core styles and themes for Polkadot dapps that other packages can utilise to implement the supported UI components in their respective frameworks;
Assets - Data sources and graphical assets for key ecosystem elements, such as web extension wallets and validator operators;
Utils - Common utility functions to aid in Polkadot dapp development;
React:

  • Components - Functional React components for Polkadot dapps.
  • "Recipes" - A combination of functional React components, utils, assets for structuring a reusable block, ready to plug’n’play in any JS/TS-ready dApp;
  • Providers and hooks - Reusable react providers that bring with few lines of code full functionality to a dApp (e.g. Connect Extension Provider).

It is meant to be Javascript-framework agnostic:

@polkadot-cloud/react: Functional React components for Polkadot dapps.

in the future what can be added are other famous frameworks, re-using the existing Javascript utils, assets, SCSS classes: e.g. @polkadot-cloud/vue, @polkadot-cloud/angular etc;

It is also planned and aimed for this to be API agnostic, meaning that components can be used with PolkadotJS API or the newest Polkadot API, a custom API or even without;

Note:

It’s important to clarify that this initiative is not meant to be a one-way library. Instead, it serves as a conduit for gathering reusable solutions and sharing them with the broader community and ecosystem, effectively functioning as a reference and documentation hub. The goal is to promote reusability and collaboration within the ecosystem.
This is meant to inspire and invite UI developers within the ecosystem to actively participate. You’re encouraged to develop your own components, hooks, providers, and what we fondly call “recipes.” You can then submit these as Pull Requests (PRs) in Polkadot Cloud’s repository. By doing so, you’ll be contributing to a collective pool of resources that benefits everyone. This open-source, collaborative approach is at the heart of the mission, and we look forward to seeing the community’s innovative contributions.

Goals

“Polkadot Cloud aims to fill a void in the Polkadot app developer space by providing high quality, well-maintained, critical assets for app developers.”

It should simplify the lives of UI developers and contributing to a more robust, unified and user-friendly developer experience within the Polkadot ecosystem.

The goals of Polkadot Cloud are as follows:

  • To provide a go-to platform / hub for Polkadot front-end assets, data, services, components, recipes to serve the Polkadot app-developer community.
  • To obliterate the narrative of Polkadot having bad UX.
  • To increase the quality of Polkadot apps ecosystem-wide.
  • To expedite the creation of quality Polkadot apps.
  • To provide some standard flows / behaviours for key features, like connecting to wallets and signing transactions.

The “Dream”:

One day a dev will be able to puzzle together Polkadot Cloud “recipes” and utils to create in few hours a prototype idea or a PoC;

Some facts:

  • The app, npm package structure and the majority of components have been onboarded in only 2-3 months - we’ve rapidly developed this concept in a very short period of time;
  • Polkadot Staking Dashboard and PolkaGate already using some of these tools;
  • Repository have already a couple of forks already and for what its worth - our core package has 3k weekly downloads;

Feedback and collaboration are highly welcome, and we look forward to seeing how this project can benefit the Polkadot community.

9 Likes
6

Thanks @AlexD10S for putting this forward! I’d also be super interested in what are people using the most to develop front-end applications on Polkadot.

I’ll put a non-extensive, mixed list of tools below (happy to add more things if anyone has input!), so that you can add which ones are you using and then we can compare.

  • React
  • Vue.js
  • Flutter
  • React Native
  • Kotlin
  • Swift
  • Tailwind (CSS)
  • Others (Please add below as answer :slight_smile: )
0 voters

Ideally understanding these numbers can help the community build the right tools forward that most people will use :smile:

3 Likes
7

Hi, Alex. Thank you for this great topic!
Please, also check the new IDE Sandox (the Git page is here), that our team has delivered in Oct. This is just the first step and we are planning to proceed with adding functionality, but now it is useful for developping applications with JS.

2 Likes
8

Hey everyone.
After some consideration, rewriting and thinking, and seeing the great interest coming from the ecosystem and the community, we decided to move the polkadot cloud idea to a Decentralized Futures proposal.
You can read all about it in this forum post Decentralized Futures Proposal: Polkadot Cloud

It would be great to hear more opinions and gather more feedback

2 Likes
9

I was looking to build a React JS project recently, and found the substrate-front-end-template to be a bit too much for me to jump into editing it and using it in the way I wanted. Basically, in order to make all the components more robust, they also added many layers of abstractions which made it hard to isolate the minimum working product.

More specifically, I was looking to create some front-ends which connected to multiple chains and provided cross chain capabilities. With the substrate-front-end-template, this was very hard to do.

I made another template called polkadot-react-template, which is very minimal and bare-bones, but I think can give better access for tinkerers to play with react components, and see and build an MVP. With this template, I was able to create multi-chain UIs very easily, and that is demonstrated with the starting template.

I think both templates play a good role, but will be good to see what other builders prefer to use, and what things they want to see more of.

7 Likes
10

Late to the party, but there’s a library that I’ve been brewing for a while that could help a lot with simplifying building Substrate front-end

Thinking of standardising & open-sourcing it if there’s enough interest :smiley:

1 Like