docs: Feedback from #15613. NFC (#15652)

site/source/docs/compiling/Building-Projects.rst

@@ -261,19 +261,19 @@ In some cases it makes sense to modify the build scripts so that they build the
 Faux Dynamic Linking
 --------------------
 
-Emscripten's goal is to generate the fastest and smallest possible code, and for
-that reason it focuses on generating a single JavaScript file for an entire
-project. For that reason, dynamic linking should be avoided when possible.
+Emscripten's goal is to generate the fastest and smallest possible code. For
+that reason it focuses on compiling an entire project into the single file,
+avoiding dynamic linking when possible.
 
-For this reason, by default, when the `-shared` flag use used to build a shared
-library, Emscripten will produce an ``.so`` library that is actually just a
-regular ``.o`` object file (Under the hood it uses `ld -r` to combine objects
-into a single larger object).  When these faux "shared libraries" are linked
-into your application they are effectively linked as static libraries.  When
-building these shared libraries *Emcc* will ignore other shared libraries on the
-command line.  This is to ensure that the same dynamic library is not linked
-multiple times in intermediate build stages, which would result in duplicate
-symbol errors.
+By default, when the `-shared` flag is used to build a shared library,
+Emscripten will produce an ``.so`` library that is actually just a regular
+``.o`` object file (Under the hood it uses `ld -r` to combine objects into a
+single larger object).  When these faux "shared libraries" are linked into your
+application they are effectively linked as static libraries.  When building
+these shared libraries *Emcc* will ignore other shared libraries on the command
+line.  This is to ensure that the same dynamic library is not linked multiple
+times in intermediate build stages, which would result in duplicate symbol
+errors.
 
 See :ref:`experimental support <Dynamic-Linking>` for how to build true dynamic
 libraries, which can be linked together either at load time, or at runtime (via

site/source/docs/compiling/Dynamic-Linking.rst

@@ -77,7 +77,7 @@ the problem as follows: There are two types of shared modules:
 
 A project should contain **exactly one** main module. It can then be
 linked at runtime to multiple side modules. This model also makes other
-things simpler, like only the singleton main module includes the
+things simpler.  For example, only the singleton main module includes the
 JavaScript environment and side modules are pure WebAssembly modules.
 
 The one tricky aspect to this design is that a side module might depend on a
@@ -104,7 +104,7 @@ we describe the procedure now.
 Load-time Dynamic Linking
 -------------------------
 
-Load-time dynamic linking refers to case when the side module are loaded
+Load-time dynamic linking refers to the case when the side modules are loaded
 along with the main module, during startup and they are linked together
 before your application starts to run.