doc: clarity to available addon options

doc/api/addons.md

@@ -8,20 +8,25 @@ _Addons_ are dynamically-linked shared objects written in C++. The
 [`require()`][require] function can load addons as ordinary Node.js modules.
 Addons provide an interface between JavaScript and C/C++ libraries.
 
-There are three options for implementing addons: Node-API, nan, or direct
-use of internal V8, libuv, and Node.js libraries. Unless there is a need for
-direct access to functionality which is not exposed by Node-API, use Node-API.
+There are three options for implementing addons:
+
+* Node-API
+* `nan` ([Native Abstractions for Node.js][])
+* direct use of internal V8, libuv, and Node.js libraries
+
+Unless there is a need for direct access to functionality which is not\
+exposed by Node-API, use Node-API.
 Refer to [C/C++ addons with Node-API](n-api.md) for more information on
 Node-API.
 
-When not using Node-API, implementing addons is complicated,
-involving knowledge of several components and APIs:
+When not using Node-API, implementing addons becomes more complex, requiring\
+knowledge of multiple components and APIs:
 
 * [V8][]: the C++ library Node.js uses to provide the
-  JavaScript implementation. V8 provides the mechanisms for creating objects,
-  calling functions, etc. V8's API is documented mostly in the
+  JavaScript implementation. It provides the mechanisms for creating objects,
+  calling functions, etc. The V8's API is documented mostly in the
   `v8.h` header file (`deps/v8/include/v8.h` in the Node.js source
-  tree), which is also available [online][v8-docs].
+  tree), and is also available [online][v8-docs].
 
 * [libuv][]: The C library that implements the Node.js event loop, its worker
   threads and all of the asynchronous behaviors of the platform. It also
@@ -35,10 +40,10 @@ involving knowledge of several components and APIs:
   offloading work via libuv to non-blocking system operations, worker threads,
   or a custom use of libuv threads.
 
-* Internal Node.js libraries. Node.js itself exports C++ APIs that addons can
+* Internal Node.js libraries: Node.js itself exports C++ APIs that addons can
   use, the most important of which is the `node::ObjectWrap` class.
 
-* Node.js includes other statically linked libraries including OpenSSL. These
+* Other statically linked libraries (including OpenSSL): These
   other libraries are located in the `deps/` directory in the Node.js source
   tree. Only the libuv, OpenSSL, V8, and zlib symbols are purposefully
   re-exported by Node.js and may be used to various extents by addons. See
@@ -148,8 +153,8 @@ invocation of `NODE_MODULE_INIT()`:
 * `Local<Value> module`, and
 * `Local<Context> context`
 
-The choice to build a context-aware addon carries with it the responsibility of
-carefully managing global static data. Since the addon may be loaded multiple
+Building a context-aware addon requires careful management of global static data
+to ensure stability and correctness. Since the addon may be loaded multiple
 times, potentially even from different threads, any global static data stored
 in the addon must be properly protected, and must not contain any persistent
 references to JavaScript objects. The reason for this is that JavaScript
@@ -255,7 +260,7 @@ such as a main thread and a Worker thread, an add-on needs to either:
 * Be declared as context-aware using `NODE_MODULE_INIT()` as described above
 
 In order to support [`Worker`][] threads, addons need to clean up any resources
-they may have allocated when such a thread exists. This can be achieved through
+they may have allocated when such a thread exits. This can be achieved through
 the usage of the `AddEnvironmentCleanupHook()` function:
 
 ```cpp
@@ -1273,7 +1278,7 @@ class MyObject : public node::ObjectWrap {
 #endif
 ```
 
-The implementation of `myobject.cc` is similar to before:
+The implementation of `myobject.cc` remains similar to the previous version:
 
 ```cpp
 // myobject.cc