conclusions

Author: bevacqua

chapters/ch01.asciidoc

@@ -247,4 +247,4 @@ With the advent of frameworks like Backbone, Angular, Ember, and React, new tech
 
 This explosion of innovation doesn't stem from sheer creativity alone but also out of necessity: web applications are getting increasingly complex, as is their scope, purpose, and requirements. It follows logically, then, that the ecosystem around them would grow to accommodate those expanded requirements, in terms of better tooling, better libraries, better coding practices, architectures, standards, patterns, and more choice in general.
 
-While there are heaps of books on proper application design, there isn't a lot of material to be found on the topic of modular application design, let alone modular JavaScript application design -- hence this book. While the ample majority of the advice, musings, and teachings in this book aren't at all specific to JavaScript, the fresh focus on JavaScript means you'll be learning about how to write modular web applications while keeping in consideration the quirks that make the web such a unique platform, and JavaScript, special in many ways.
+In the next chapter we'll break down the meaning of complexity, and start building fortifications against complexity in the programs we write. By following a few rules around how we encapsulate logic across layers upon layers of components, we'll commence our journey to simpler program design.

chapters/ch04.asciidoc

@@ -720,3 +720,5 @@ Splitting logic into a few files under the same directory helps us prevent an ex
 The alternative, placing logic related to a particular aspect of our application such as blog posts directly in the components where it's needed, will cause trouble if left unchecked. Doing so might be beneficial in terms of short-term productivity, but longer-term we need to worry about coupling logic, strictly related to blog posts in this case, together with entirely different concerns. At the same time, if we sprinkle a bulk of the logic across several unrelated components, we become at risk of missing critical aspects of functionality when making large-scale updates to the codebase, and because of this we might end up making the wrong assumptions, or mistakes that only become evident much further down the line.
 
 It's acceptable to start out placing logic directly where it's needed at first, when it's unclear whether the functionality will grow or how much. Once this initial exploratory period ellapses, and it becomes clear the functionality is here to stay and more might be to come, it's advisable that we isolate the functionality for the reasons stated above. Later, as the functionality grows in size and in concerns that need to be addressed, we can componentize each aspect into different modules that are still grouped together logically in the file system, making it easy to take all of interrelated concerns into account when need be.
+
+Now that we have broken down the essentials of module design and how to delineate interfaces, as well as how to lockdown, isolate, and drive down complexity in our internal implementations, we're ready to start discussing JavaScript-specific language features and an assortment of patterns that we can benefit from.

chapters/ch05.asciidoc

@@ -653,3 +653,5 @@ Although we can easily serialize our `rwanda` instance with `JSON.stringify(rwan
 JSON -- nowfootnoteref:[json-grammar,Up until recently, JSON wasn't -- strictly speaking -- a proper subset of ECMA-262. A recent proposal has amended the ECMAScript specification to consider bits of JSON that were previously invalid JavaScript to be valid JavaScript. Learn more at: https://mjavascript.com/out/json-subset.] a subset of the JavaScript grammar -- was purpose-built for this use case, where we often have to serialize data, send it over the wire, and deserialize it on the other end. Plain JavaScript objects are a great way to store data in our applications, offer frictionless serialization out the box, and lead to cleaner data structures because we can keep logic decoupled from the data.
 
 When the language on both the sending and receiving ends is JavaScript, we can share a module with all the functionality that we need around the data structure. This way, we don't have to worry about serialization, since we're using plain JavaScript objects and can rely on JSON for the transport layer. We don't have to concern ourselves with sharing functionality either, because we can rely on the JavaScript module system for that part.
+
+Armed with a foundation for writing solid modules based on your own reasoning, we now turn the page to operational concerns such as handling application secrets responsibly, making sure our dependencies don't fail us, taking care of how we orchestrate build processes and continuous integration, and dealing with nuance in state management and the high-stakes decision-making around producing the right abstractions.

chapters/ch06.asciidoc

@@ -281,3 +281,5 @@ A middle layer could leverage a normalized query from the consumer, such as the
 The same case could, and should, be made for the data structures returned from either of these backing services. By normalizing the data into a structure that only contains information that's relevant to our consumers, and augmenting it with the derived information they need (such as the airline name and details as explained earlier), the consumer can focus on their own concerns while leveraging a data structure that's close to their needs. At the same time, this normalization empowers our abstraction to merge results from both backing services and treat them as if they came from a single source: the abstraction itself, leaving the backing services as mere implementation details.
 
 When we rely directly on the original responses, we may find ourselves writing view components that are more verbose than they need be, containing logic to pull together the different bits of metadata needed to render our views, mapping data from the API representation into what we actually want to display, and then mapping user input back into what the API expects. With a layer in between, we can keep this mapping logic contained in a single place, and leave the rest of our application unencumbered by it.
+
+Mastering modular JavaScript isn't strictly about following a well-defined set of rules, but rather about being able to put yourself on the shoes of your consumers, foreplanning for feature development that may be coming down the pipe, -- but not too extensively -- and treating documentation with the same respect and care that you should be putting into interface design. The internals, as the implementation details that they are, can always be improved later. Of course, we'll want to patch or at least abstract away those sources of complexity, but it is in their shell that beautiful modules truly shine.

sections/preface.asciidoc

@@ -25,6 +25,8 @@ Though, I couldn't find any books that addressed the subject from a JavaScript p
 
 This book tries to explain how you could be writing modular code without being overt. Instead, we'll try to shed light into the fundamentals behind modular architecture, and it's history when it comes to JavaScript, so that you earn a better understanding of what it means to write modular applications, and what's to be gained from doing so.
 
+While there are heaps of books on proper application design, there isn't a lot of material to be found on the topic of modular application design, let alone modular JavaScript application design -- hence this book. While the ample majority of the advice, musings, and teachings in this book aren't at all specific to JavaScript, the fresh focus on JavaScript means you'll be learning about how to write modular web applications while keeping in consideration the quirks that make the web such a unique platform, and JavaScript, special in many ways.
+
 Rather than rely on long-winded, pages-long, thoroughly analyzed, concrete examples, the book hopes to challenge you to apply its passages to the problems that you're trying to address in your own programs, and coming to your own realizations by weighing the benefits and drawbacks of taking one of a few possible approaches. In software, there is no such thing as one-size-fits-all, and you're often going to leverage your own best judgement to decide how to write it. All software adapts to the context that surrounds it, and if you've done any work at all involving software deployments or releases, then you surely are intimate with exactly how hard it is to cram the same piece of software into different execution environments.
 
 Just like with Practical Modern JavaScript, -- the first in the Modular JavaScript series -- this book has the goal of establishing a baseline we can take for granted in the rest of the Modular JavaScript series. After having learned all about the latest language features in Practical Modern JavaScript, and all about modular design thinking in this book, we'll be all set to discuss solution-specific concerns in Universal JavaScript and then testing and deployment in subsequent books, without necessarily delving too deeply into concepts taught in previous books. This incremental and modular approach is meant to be pervasive across the series, each book, each chapter, and each section.