various small edits to dapps

Author: aantonop

dapps.asciidoc

@@ -12,11 +12,11 @@ Unlike a traditional application, a Decentralized Application (DApp) does not be
 
 A typical DApp stack would consist of Front-end, Back-end and Data Storage. There are many advantages to creating a DApp that a typical centralized architecture could not provide:
 
-1) Resiliency: Having the business logic written on a smart contract means that a DApp backend will be fully distributed and managed on the Blockchain. Unlike deploying an application on a centralized server, a DApp will have no downtime and will continue to persist as long as the Blockchain is still operating.
+1) Resiliency: Having the business-logic written on a smart contract means that a DApp backend will be fully distributed and managed on the Blockchain. Unlike deploying an application on a centralized server, a DApp will have no downtime and will continue to persist as long as the Blockchain is still operating.
 
-2) Transparency: The open source nature of a DApp allows anybody to fork the code and have the same application running on the Blockchain. On the same note, any interaction with the Blockchain will be stored forever and anyone with a copy of the Blockchain can gain access to it. Notice that it may not be possible to de-compile the bytecodes into source and fully understand the contract's code. Developers who seek to offer full transparency about the contract behavior must publish the source code for users to read, compile and verify.
+2) Transparency: The open source nature of a DApp allows anyone to fork the code and have the same application running on the Blockchain. On the same note, any interaction with the Blockchain will be stored forever and anyone with a copy of the Blockchain can gain access to it. It’s worth noting that it may not be possible to de-compile the bytecodes into source and fully understand the contract's code. Developers who seek to offer full transparency about the contract behavior must publish the source code for users to read, compile and verify.
 
-3) Censorship Resistance: As long as a user has access to an Ethereum node, he/she will always be able to interact with a DApp without interference from a centralized control. No service provider or even the owner of the smart contract could alter the code once it is deployed on the network.
+3) Censorship Resistance: As long as a user has access to an Ethereum node, the user will always be able to interact with a DApp without interference from a centralized control. No service provider, or even the owner of the smart contract, could alter the code once it is deployed on the network.
 
 [[components_of_a_dapp_sec]]
 === Components of a DApp
@@ -28,18 +28,18 @@ TODO: add paragraph
 [[blockchain_smart_contracts_sec]]
 ==== Blockchain (Smart Contracts)
 
-The smart contract is used to store the business logic, the state and the computation of your decentralized application, think of it as a server side component in a regular application.
+The smart contract is used to store the business logic, the state and the computation of your decentralized application; think of a smart contract as a server-side component in a regular application.
 
-One advantage of deploying server side logic on Ethereum smart contracts is that you could build a more complex architecture where a smart contract could read and write data off one another. After deploying your smart contract, your business logic could well be used by many other developers in the future, without ever requiring you to manage and maintain the code.
+One advantage of deploying server-side logic on Ethereum smart contracts is that you could build a more complex architecture in which a smart contract could read and write data off one another. After deploying your smart contract, your business logic could well be used by many other developers in the future, without ever requiring you to manage and maintain the code.
 
 One major problem of running smart contract as core business logic functionality is the inability to change the code once it is deployed. Furthermore a really large monolithic smart contract may cost a lot of gas to deploy and function. Therefore some applications may choose to have off chain computation and external data source. Keep in mind however, that having core business logic of the DApp be dependent on external data or server would mean your users will have to trust these externalities.
 
 [[front_end_web_ui_cec]]
 ==== Front end (Web User Interface (UI))
 
-Unlike the business logic of the DApp that requires a developer to understand EVM and new languages such as Solidity, the client side interface of a DApp uses basic web front end technologies (HTML, CSS, JavaScript). This allows a regular web developer to utilize tools, libraries and frameworks they are used to. Interactions with the DApp such as signing messages, sending transactions and key management are often done through the browser itself using tools such as Mist browser or the Metamask browser extension.
+Unlike the business logic of the DApp that requires a developer to understand EVM and new languages such as Solidity, the client side interface of a DApp uses basic web front end technologies (HTML, CSS, JavaScript). This allows a traditional web developer to utilize the tools, libraries and frameworks they are familiar with using on a regular basis. Interactions with the DApp such as signing messages, sending transactions and key management are often conducted through the browser itself using tools such as Mist browser or the Metamask browser extension.
 
-Although it is possible to create a mobile DApp as well, currently there are no best practices to create mobile DApps front-ends due to the lack of mobile clients that can serve as a light client with key management functionality.
+Although it is possible to create a mobile DApp as well, currently there are no best practices to create mobile DApp front-ends due to the lack of mobile clients that can serve as a light client with key management functionality.
 
 [[data_storage_sec]]
 ==== Data storage
@@ -49,7 +49,7 @@ Due to high gas costs, smart contracts are currently not suited to store large a
 The hashes of the content are often stored as bytes within the smart contract, using key value mapping. The asset would then be retrieved through your front end applications calling on the smart contract for urls of each asset.
 
 [[on_chain_vs_off_chain_data_sec]]
-===== On chain vs. off chain 
+===== On chain vs. off chain
 
 ////
 TODO: add paragraph
@@ -109,7 +109,7 @@ https://github.com/ethereum/wiki/wiki/Whisper-Overview
 [[dapp_frameworks_sec]]
 === DApp frameworks
 
-There are many different Development frameworks and libraries written in many languages which allows for better Developer experience in creating and deploying a DApp.
+There are many different Development frameworks and libraries written in many languages which allows for better developer experience in creating and deploying a DApp.
 
 [[truffle_sec]]
 ==== Truffle
@@ -147,15 +147,15 @@ With Embark you can:
 * Easily manage complex systems of interdependent contracts.
 
 ** Decentralized storage (IPFS)
-* Easily store & retrieve data on the DApp through EmbarkJS. Including uploading and retrieving files.
+* Easily store & retrieve data on the DApp through EmbarkJS, including uploading and retrieving files.
 * Deploy the full application to IPFS or Swarm.
 
 
 ** Decentralized Communication (Whisper, Orbit)
 * Easily send/receive messages through channels in P2P through Whisper or Orbit.
 
 ** Web Technologies
-* Integrate with any web technology including React, Foundation, etc..
+* Integrate with any web technology including React, Foundation, etc.
 * Use any build pipeline or tool you wish, including grunt, gulp and webpack.
 
 Getting started & documentation; https://embark.readthedocs.io