Round out chapter 1

Author: bevacqua

chapters/ch01.asciidoc

@@ -214,12 +214,20 @@ We, as developers, often over-do architecture as well, and a lot of the reasonin
 
 When we don't plan in such a long-term form, an interesting thing occurs, our systems will grow more naturally, adapting to the needs of the near-term, gradually progressing towards support for a larger application and larger set of requirements. When that progression is gradual, we'll notice a corrective behavior in how abstractions are picked up or discarded as we grow. If we settle on abstractions too early, and they end up being the wrong abstractions, we'll pay dearly for that mistake. Bad abstractions force us to bend entire applications to their will, and once we've realized that the abstraction is bad and ought to be removed, we might be so heavily invested in it that pulling out might be costly. This, paired with the sunk cost fallacy, whereby we're tempted to keep the abstraction just because we've spent a lot of time, sweat, and blood on it, can be very hazardous indeed.
 
-We'll devote an important part of this book to understanding how to identify and leverage abstractions at the right time so that we can minimize these risks.
+We'll devote an important part of this book to understanding how we can identify and leverage the right abstractions at the right time, so that the risk they incur is minimized.
 
 === 1.5 Why Modular JavaScript?
 
-..
+Due to its history, JavaScript is particularly interesting when it comes to modular design. In the early days of the web, and for a long time, there weren't any established practices and few people knew the language beyond showing alert boxes. As a highly dynamic language that wasn't yet mature enough, JavaScript was at an odd place between statically typed languages like Java or C#, and more heavily used dynamic languages like Python or PHP.
 
-=== 1.6 Future of JavaScript
+The lack of native modularity in the web -- due to the way a program is loaded in chunks using HTML `<script>` tags -- is in stark contrast with any other execution environments where programs can be made up of any number of files and modular architectures are natively supported by the language, its compiler, and its file system based environment. On the web, we're only now barely beginning to scratch the surface of native modules, something other programming environments have had since their inception. As we discussed in section 1.2, the lack of a native module loading mechanism, paired with the lack of native modules beyond just files that shared a global scope, forced the web community to get creative in its approach to modularity.
 
-..
+The native JavaScript modules specification that eventually landed into the language was heavily influenced by this community-led effort. Even as of this writing we're still probably some 5 years away from being able to use the native module system effectively on the web. This shortcoming of the web is evidenced by how patterns that were adopted universally elsewhere, like layered or component-based architectures, weren't even contemplated on the web for most of its lifetime thus far.
+
+Up until the launch of a Gmail beta client in April, 2004, which demonstrated the power of asynchronous JavaScript HTTP requests to provide a single-page application experience, and then the initial release of jQuery in 2006, which provided a hassle-free cross-browser web development experience, JavaScript was seldom regarded as a serious modern development platform.
+
+With the advent of frameworks like Backbone, Angular, Ember, and React, new techniques and breakthroughs also made an uptick on the web. Writing code under ES6 and beyond, but then transpiling parts of that code down to ES5 to attain broader browser support; shared rendering, using the same code on both server and client to render a page quickly on initial page load and continue to load pages quickly upon navigation; automated code bundling, packing the modules that comprise an application into a single bundle for optimized delivery; bundle-splitting along routes, so that there are several bundles outputted, each optimized for the initially visited route; CSS bundling at the JavaScript module level, so that CSS -- which doesn't feature a native module system -- can also be split across bundles; and a myriad ways of optimizing assets like images at compile time, improving productivity during development while keeping production deployments highly performant, are all part of the iterative nature of innovation in the web.
+
+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 accomodate 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.