tweak preface because move bulk of ch01 intro into it

Author: bevacqua

chapters/ch01.asciidoc

@@ -1,17 +1,9 @@
 [[module-thinking]]
 == Module Thinking
 
-Even after the printing press was invented, publishing books remains a challenging endeavor. Yes, there's typically an author -- or authors -- who scribbled the content wherever and whenever they found time to do so. But there's also a content editor, tasked with helping the author transform their stream of consciousness into a relatable story that's not too dry to read, something to be especially careful about when it comes to technical or business books. We have the technical reviewers, watchful subject matter experts on the lookout for egregious mistakes in technical definitions or interpretations. And lastly, -- of course -- we have the copy editor, the typo linters of prose and last bastion of proper grammar. Thus far, however, we've barely scratched the surface: everyone mentioned above is mostly interested in the contents of the book, but we don't do much else. There's also, as an example, the typesetters whose job is to ensure the book looks good when it goes to print -- bidding good riddance to orphans and widows, poorly-wrapped lines of code, and so much more. Someone has to design the cover, or to approve the table of contents for the first draft so that the author gets a contract. Several people oversee the process that culminates in the book going to press, -- usually referred to as production -- as well. Once copies are printed, they need to be distributed. Eventually, the book hits the shelves (physical or otherwise) and starts selling. Someone buys the book, and finally starts to read it. We could write entire books about the purchase transaction alone.
+As discussed in the preface, complexity seems to be all around us while we're working on software projects. So are abstractions, that keep complexity hidden away from us under rocks we don't dare touching. These rocks are our interfaces to the rest of the world, so that we can get away with hardly thinking about it. JavaScript is no exception here -- on the contrary: as powerful as dynamic languages are, it is also that much easier, and even tempting, to write complex programs when we're using them.
 
-The complexity of the whole process is mind-boggling, and yet, to each individual, it's not that complicated. The author, for example, merely has to write a few hundred words every day. Where did all that complexity go? There's a reason the process is so compartmentalized. We're not that good at handling high-level complexity, and breaking it down into single responsibilities ( such as "write content", "improve how prose flows", "review technical concerns", "fix grammar mistakes", "typeset for production", or "handle purchases" ), is what makes the process simpler for individuals, working on the mammoth project that is writing a book or just about any business enterprise.
-
-Publishing is just an example, but we could do this exercise with just about anything. Pick an object on your desk, any object. Think how it got there. Now zoom out, think some more, how was it made? What is it made of? How many people were involved in manufacturing each piece, assembling it, perfecting it, and getting it to the store where it was bought? Is it a fruit? How many people were involved in planting it, fighting off pests, pruning plants, packaging the fruit, and getting it to the store where it was bought?
-
-Software is not all that different, except complexity is all around us. At the deepest zoom levels we find constraints defined by physical constants such as the speed of light, individual bits and hardware, interrupt calls, assembly language, and much more. Zooming out we find the mega-structures of the technology sector, which handle everything from search queries to payment processing. Somewhere in the midst of all this complexity, there's us developers, and the projects bestowed upon us.
-
-We hardly stop to think about the complexity underlying everyday objects and interactions, since doing so would be paralyzing. Instead, we abstract solutions behind interfaces, so much that they _become_ -- in our minds -- the interface. Some of these interfaces map well to the abstracted implementation, and they feel great. Others don't map all that well to the implementation, and we end up feeling confused and frustrated. Software is not at all different. We don't want to think about the system as a whole, and virtually everything we work with sits behind interfaces that are simpler to use and understand than their underlying implementations.
-
-This already happens at the system level, and we hardly think about it. Let's discuss how we can apply the same concepts to the work we do, so that we can minimize the amount of complexity we need to stare at when working on a project, a feature, a piece of functionality, down to the branches of a single function.
+To get started, let's discuss how we can better apply abstractions, interfaces, and their underlying concepts to the work we do, so that we can minimize the amount of complexity we need to stare at when working on a project, a feature, a piece of functionality, down to the branches of a single function.
 
 === 1.1 Introduction to Module Thinking
 

sections/preface.asciidoc

@@ -1,14 +1,24 @@
 [preface]
 == Preface
 
-I started toying with Node.js -- and, unbeknownst to me, getting into a serious relationship with JavaScript -- at about the same time as I discovered open-source and fell in love with its practices. Coming from the closed-source landscape in C#, the open-source ecosystem around Node.js gave me a new perspective and joy in figuring out how to write robust code that others find pleasant enough to consume. It's with this background that I find myself always pondering about how an interface should be defined, who would be consuming it, and how they'd like to spend their time doing something else than figuring out what we originally intended them to do.
+Even after the printing press was invented, publishing books remains a challenging endeavor. Yes, there's typically an author -- or authors -- who scribbled the content wherever and whenever they found time to do so. But there's also a content editor, tasked with helping the author transform their stream of consciousness into a relatable story that's not too dry to read, something to be especially careful about when it comes to technical or business books. We have the technical reviewers, watchful subject matter experts on the lookout for egregious mistakes in technical definitions or interpretations. And lastly, -- of course -- we have the copy editor, the typo linters of prose and last bastion of proper grammar. Thus far, however, we've barely scratched the surface: everyone mentioned above is mostly interested in the contents of the book, but we don't do much else. There's also, as an example, the typesetters whose job is to ensure the book looks good when it goes to print -- bidding good riddance to orphans and widows, poorly-wrapped lines of code, and so much more. Someone has to design the cover, or to approve the table of contents for the first draft so that the author gets a contract. Several people oversee the process that culminates in the book going to press, -- usually referred to as production -- as well. Once copies are printed, they need to be distributed. Eventually, the book hits the shelves (physical or otherwise) and starts selling. Someone buys the book, and finally starts to read it. We could write entire books about the purchase transaction alone.
+
+The complexity of the whole process is mind-boggling, and yet, to each individual, it's not that complicated. The author, for example, merely has to write a few hundred words every day. Where did all that complexity go? There's a reason the process is so compartmentalized. We're not that good at handling high-level complexity, and breaking it down into single responsibilities ( such as "write content", "improve how prose flows", "review technical concerns", "fix grammar mistakes", "typeset for production", or "handle purchases" ), is what makes the process simpler for individuals, working on the mammoth project that is writing a book or just about any business enterprise.
+
+Publishing is just an example, but we could do this exercise with just about anything. Pick an object on your desk, any object. Think how it got there. Now zoom out, think some more, how was it made? What is it made of? How many people were involved in manufacturing each piece, assembling it, perfecting it, and getting it to the store where it was bought? Is it a fruit? How many people were involved in planting it, fighting off pests, pruning plants, packaging the fruit, and getting it to the store where it was bought?
+
+Software is not all that different, except complexity is all around us. At the deepest zoom levels we find constraints defined by physical constants such as the speed of light, individual bits and hardware, interrupt calls, assembly language, and much more. Zooming out we find the mega-structures of the technology sector, which handle everything from search queries to payment processing. Somewhere in the midst of all this complexity, there's us developers, and the projects bestowed upon us.
+
+We hardly stop to think about the complexity underlying everyday objects and interactions, since doing so would be paralyzing. Instead, we abstract solutions behind interfaces, so much that they _become_ -- in our minds -- the interface. Some of these interfaces map well to the abstracted implementation, and they feel great. Others don't map all that well to the implementation, and we end up feeling confused and frustrated. Software is not at all different. We don't want to think about the system as a whole, and virtually everything we work with sits behind interfaces that are simpler to use and understand than their underlying implementations.
 
 === Who Should Read This Book
 
 This book is meant for developers, enthusiasts, and professionals with a working knowledge of JavaScript and ES6footnote:[ES6 effected a profound change in the JavaScript language, introducing multiple syntax improvements, a few handfuls of new methods. This book assumes familiarity with JavaScript after ES6. You can learn more about ES6 syntax by visiting the following link for a crash course: https://mjavascript.com/out/es6.]. These developers, and anyone interested in learning more about writing modular code that's readable, maintainable, and scalable, even beyond the JavaScript language, shall benefit from reading _Mastering Modular JavaScript_.
 
 === Why Modular JavaScript?
 
+I started toying with Node.js -- and, unbeknownst to me, getting into a serious relationship with JavaScript -- at about the same time as I discovered open-source and fell in love with its practices. Coming from the closed-source landscape in C#, the open-source ecosystem around Node.js gave me a new perspective and joy in figuring out how to write robust code that others find pleasant enough to consume. It's with this background that I find myself always pondering about how an interface should be defined, who would be consuming it, and how they'd like to spend their time doing something else than figuring out what we originally intended them to do.
+
 The goal of this book is to offer an affable way of becoming a successful module author. It's not that writing JavaScript modules is particularly hard, but following sound design practices to ensure we deliver the right amounts of simplicity and flexibility so that consumers can rely on modules to be simple most of the time, but flexible when it matters, -- while keeping internal complexity in check -- is hardly a trivial task. I wrote bits and pieces about proper application design in JavaScript Application Designfootnote:[JavaScript Application Design is a book I published through Manning in 2015. It revolves around build processes, but also features chapters on managing complexity, on sensible asynchronous flow control code, on REST API design, and on JavaScript testing concerns. Learn more at: https://mjavascript.com/out/jad.] and for the Pony Foo blog, but I've been yearning to publish something more comprehensive that was exclusively dedicated to reasoning about, designing, and writing modular code.
 
 Though, I couldn't find any books that addressed the subject from a JavaScript point of view, you can easily find other books that touch on the subject of modular code, such as Code Complete or Clean Code, and leverage their teachings in your JavaScript development efforts. Mastering Modular JavaScript is an attempt to draw attention from what you should be doing, and instead focus on you coming to your own conclusions about what you should be doing and why -- without imposing axiomatic rules that only contribute to what artificially self-proclaims and positions itself as "clean code".