Build Section Reorg - "Polkadot Developer Portal"

[CrackTheCode016]

This PR aims to reorganize and breathe life into the builder's section of the Polkadot Wiki. It will separate and focus on three aspects of building on Polkadot:

• Clientside/Frontend Development
• Smart contracts (and their place within Polkadot)
• Protocol development

To be clear, this is NOT development documentation, but moreso an overview of all tools to point a developer to the direction they want to go.

vision

When reviewing / reading this, I want you to think:

A developer who wants to tinker and get to know Polkadot, doesn't have a deep desire to learn web3, but is interested. They know about smart contracts, Ethereum, and what Solidity is (but perhaps have not used it). Unfortunately, friction, aka, not being able to easily see all options, can be a big deterrent to someone attempting to try developing on Polkadot.

This developer usually falls into one of three categories:

1. "I want to develop an application on top of Polkadot and its parachains. How do I do that?"
2. "I want to learn about creating blockchains (parachains or solo). How do I start?"
3. "I want to deploy contracts on Polkadot. Can I? Why not? Where can I deploy contracts? Why would I use an EVM-based chain over actual EVM?"

As mentioned earlier, the job here is not to be developer documentation but to be a set of pointers to reliable resources.

problem with current structure (slightly opinionated)

Each page is far too long. For someone new, it can take a long time to, let's say, find a front-end library and start developing. In-depth information should exist, but tools vs.s information should be separate.

It should also avoid any 'salesy' talk about why Polkadot is the best solution (IMHO). It should offer technical details relevant to building, and why those are secure/fast/scalable, but not to the extent of trying to convince someone.

current / old

new / refractored (wip)

[CrackTheCode016]

For those who may review / context for those who are viewing this pr:

Adopting the DRY (don't repeat yourself) principle here is pretty important imo. For example, lets look at several sections here:

• We explain runtime upgrades here: https://wiki.polkadot.network/docs/learn-runtime-upgrades
• However, we also explain it here in the "Build" section: https://wiki.polkadot.network/docs/build-protocol-info#runtime-upgrades

It is acceptable that these two exist, however these are now two explanations that need to be maintained! We should choose a master explanation for the high level, and link away a guide/spec for the build context.

This kind of repetitiveness could present confusion, but also unnecessary bloat to a page that makes it hard to digest and make useful conclusions from the content.

[CrackTheCode016]

Besides high level currency stuff, most of build-protocol-info can be deleted and instead point to the developer hub.

PS: this should be done for most content in order to keep the scope of the Wiki intact. Applications / usages of the tech is fine, exact details which may change later (ala, extrinsic encoding, runtime versioning/upgrades) should point elsewhere

[filippoweb3]

this is awesome! :)