Polkadot.JS API UI enhancements
Beneficiary:Introduction:
At LimeChain, we propose the introduction of an a number of new features for the UI of Polkadot.js API. We understand the pivotal role that developer tools play at the adoption of blockchain protocols, simplifying developers' workflows and leaving a positive impression on their experience with building on top of the protocol. As frequent users of the current application, we recognize its usefulness, but also see opportunities for improvement in UX and functionality.
We envision creating an application that serves as a daily tool for a wide range of users, including Hosts, Runtimes, Dapp, and Parachain developers. Our plan is to enhance the positive aspects of the existing application while addressing its shortcomings. For example, we aim to elevate the existing JS Console into a custom-tailored IDE for Polkadot.js API prototyping. By combining intuitive UI with cutting-edge yet reliable technologies, we aim to create a next-gen developer tools application for Polkadot.js API.
Key Features include:
Enabling seamless exploration of the Polkadot Ecosystem: The application will serve as the primary platform for developers to explore on-chain information across the entire Polkadot ecosystem, including blocks, chain state, referenda, xcm, and more.
Introduction of an integrated IDE for Rapid Prototyping: Users will be able to create quick proof of concepts within the browser tab, with pre-loaded dependencies tailored to their requirements, facilitating a complete Polkadot experience.
The application will be designed with adaptability in mind, ensuring longevity and adaptability as the Polkadot ecosystem evolves over time. The codebase will be open source under the Apache 2.0 license and contributed as repositories to the Polkadot-js GitHub organization.
We outline the following milestones for our project:
- Polkadot.js API Sandbox IDE: Create an integrated development environment for Polkadot.js API prototyping.
- Real-time Block Explorer: Develop a tool for real-time exploration of blockchain data.
- Chain State, RPC, and Runtime Calls: Handle various types of calls related to chain state, RPC, and runtime operations.
- Polkadot.js API Support: Dedicate time to address high-priority issues in the Polkadot.js API ecosystem.
For a detailed description of our proposal, please visit: Proposal Document
Company Background:
LimeChain is a software development company founded in 2017. We are positioned to handle end-to-end product development, and we have the capability to manage projects from conceptualisation and design to the complete implementation of a certain product. We specialize in blockchain technology, with emphasis in developing blockchain-related and infrastructure solutions.
In the context of the Polkadot ecosystem, we possess considerable expertise in developing various tools, including
Gosemble, a framework for building Substrate compatible Runtimes in Go,
Fruzhin, a Host implementation in Java, a framework for runtimes in AssemblyScript, a framework for runtimes in AssemblyScript. On top of that, we have implemented a
Comments (8)
Proposal Failed
3
of 3Summary
0%
Aye
0%
Nay
Aye (48)0.0 DOT
Support0.0 DOT
Nay (46)0.0 DOT
Comments (8)
The current status of Polkasot.JS is that it is somewhat in maintenance mode owing to Jaco stepping back from it, with the focus being on bugfixes and necessary changes to keep it working.
One of the reasons for it being less actively developed is that it may prove difficult to port PolkadotJS to use the new JSON-RPC APIs that you mention in milestone 5 (https://github.com/paritytech/json-rpc-interface-spec/). Eg see this post: https://forum.polkadot.network/t/new-json-rpc-api-mega-q-a/3048. As such, new libraries like Polkadot-API are being developed which focus much more on using the new RPCs and being light client friendly (ie https://github.com/polkadot-api/polkadot-api).
With this in mind, there are a couple of potential issues that I'd like to raise:
- Given that PJS is in maintenance mode, how will the new tooling and things be supported going forwards? Would you propose to take on the maintenance of the PJS tools for instance?
- Given that PJS is currently tied to the legacy RPC APIs, and it's not clear how easy it will be to port it, then all of the things built on top might also not be future proof and get stuck on these legacy RPCs.
One option might be to first attempt to port PJS API library to using the new APIs (which we are still in the process of stabilising). If this is attempted early on, then we will learn whether it's viable before building additional things on top of it.
Another option might be to fork or rework the PJS UI to use a library like PAPI instead, which is built on top of the new RPC methods and will accomodate changes to them as they stabilise. Then you have some future proofing.
A final option might be to start from scratch and build a new UI from the ground up on top of PAPI and related libraries.
In any case, I'd love to know your thoughts on this all :)
Hi thanks for submitting this proposal. Could you provide what developer feedback you collected lead you to propose such milestones?
I have not talked to anyone in the polkadot devleoper ecosystem that expressed the need for a "Polkadot.js API Sandbox IDE", nor do i believe there is a need for one.
In addition for a "Real-time Block Explorer", we already have tools like Subscan.
https://www.subscan.io/
For "Chain State, RPC, and Runtime Calls", this is something the polkadotjs ui already supports so I don't seem the problem here.
With regards to "Polkadot.js API Support", I support what James wrote.
The current status of Polkasot.JS is that it is somewhat in maintenance mode owing to Jaco stepping back from it, with the focus being on bugfixes and necessary changes to keep it working.
One of the reasons for it being less actively developed is that it may prove difficult to port PolkadotJS to use the new JSON-RPC APIs that you mention in milestone 5 (https://github.com/paritytech/json-rpc-interface-spec/). Eg see this post: https://forum.polkadot.network/t/new-json-rpc-api-mega-q-a/3048. As such, new libraries like Polkadot-API are being developed which focus much more on using the new RPCs and being light client friendly (ie https://github.com/polkadot-api/polkadot-api).
With this in mind, there are a couple of potential issues that I'd like to raise:
One option might be to first attempt to port PJS API library to using the new APIs (which we are still in the process of stabilising). If this is attempted early on, then we will learn whether it's viable before building additional things on top of it.
Another option might be to fork or rework the PJS UI to use a library like PAPI instead, which is built on top of the new RPC methods and will accomodate changes to them as they stabilise. Then you have some future proofing.
A final option might be to start from scratch and build a new UI from the ground up on top of PAPI and related libraries.
In any case, I'd love to know your thoughts on this all :)
Hi thanks for submitting this proposal. Could you provide what developer feedback you collected lead you to propose such milestones?
I have not talked to anyone in the polkadot devleoper ecosystem that expressed the need for a "Polkadot.js API Sandbox IDE", nor do i believe there is a need for one.
In addition for a "Real-time Block Explorer", we already have tools like Subscan.
https://www.subscan.io/
For "Chain State, RPC, and Runtime Calls", this is something the polkadotjs ui already supports so I don't seem the problem here.
With regards to "Polkadot.js API Support", I support what James wrote.