near-docs.io should focus on the standalone version

[gagdiez]

Newcomers use AS because it is simpler to learn than RUST. One advantage of learning how to make AS contracts is that every single concept learnt while making AS contracts can be directly translated to RUST contracts. This does not only include "smart contract" concepts (environment, storage, etc) but also the life of the smart contract (how to deploy it, interact with it, update it, and delete it).

Javascript is the perfect candidate to substitute Assemblyscript as our main educational resource. However, its main educational downside is that the life of a JS contract is not similar at all to RUST/AS contracts (as brought up by @BenKurrek here, here, here, here).

Having to split our documentation on "here is how you deploy/interact/update/delete a RUST contract", "here is how you deploy/interact/update/delete a JS contract" will bring more troubles than benefits. Specially if at some point people want to switch from JS to RUST. Because of this I propose to mainly use the docs the "standalone" version of JS, i.e. we assume that people will create wasm files of 500kb.

Newcomers (and junior devs) will be able to learn in no time how to make contracts and deploy/interact/update/delete them in testnet in the same way as RUST. Once they want to deploy it to mainnet, we can explain them that they have 2 options:

• Pay 5 NEAR for storage (which, for serious projects is not so terrible).
• Use the VM with its advantages (synchronous calls, less storage payment) and disadvantages (different deploy, interaction, update and delete).

If we do take this approach we could literally implement all the examples in the documentation by next week. This will also simplify presentations of "developing smart-contracts in NEAR" on all future talks.

[AustinBaggio]

Interesting, just to clarify the specific ask it's the following two options, we should pick one:

1. Create a stand-alone JS SDK "life of a contract" documentation microsite. The focus is not on concepts, but on installation, build, deploy, test, and interaction.
2. Update current documentation to have JS concepts beside the RS concepts

Did I get that right?

[BenKurrek]

I think what Guillermo was suggesting is to give users the option to either use the wasm version of the SDK (which is much more expensive since the wasm files are ~5x larger afaik) or users can use the JSVM version when deploying to mainnet. In docs, however, we would focus solely on the standalone (wasm) version because it makes the most sense from an integrations and flow perspective. All the commands are the same, no NAJ changes need to be made, the contract lifecycle is the same and we wouldn't have to introduce conditional documentation based on whether or not the users are using JS.

I personally am much more a fan of the standalone (wasm) version and I think users would be willing to sacrifice the extra ~3 $NEAR when deploying to mainnet (especially if they're serious projects) because at the current moment, I just don't see the JSVM version as being a feasible option for new devs. Having JS as the introductory language makes so much sense but when you consider all the downsides and differences of the enclave version, it sort of defeats the main purpose of introducing JS smart contracts (those being ease of use and targeting new devs).

[gagdiez]

I modified the message above to clarify.

I tried to say: by default in our example projects we compile JS-contracts in a "standalond-way" (creating wasm files that include the VM inside, and occupy a minimum of 500kb). In this way deploying, interacting, updating and deleting contracts is the same in JS and RUST.

Then, we make a separate microsite explaining that you can also deploy js-contracts within a VM (saving on storage, and making cross-contract calls synchronous), and showing the different way to deploy/interact/update/delete contracts in this environment.

note: I see now the message of @BenKurrek, and that's exactly what I was trying to say.

[AustinBaggio]

Got it. trying to organize the feedback on the JSVM v Standalone route now.