Bevacqua - Mastering Modular JavaScript

by Nicols Bevacqua

Copyright 2018 Nicols Bevacqua. All rights reserved.

Printed in the United States of America.

Published by OReilly Media, Inc. , 1005 Gravenstein Highway North, Sebastopol, CA 95472.

OReilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://oreilly.com/safari). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com .

• Acquisitions Editor: Allyson MacDonald
• Editor: Virginia Wilson
• Production Editor: Colleen Cole
• Copyeditor: Sharon Wilkey
• Proofreader: Jasmine Kwityn
• Indexer: Angela Howard
• Interior Designer: Monica Kamsvaag
• Cover Designer: Randy Comer
• Illustrator: Rebecca Demarest

• September 2018: First Edition

See http://oreilly.com/catalog/errata.csp?isbn=9781491955680 for release details.

The OReilly logo is a registered trademark of OReilly Media, Inc. Mastering Modular JavaScript, the cover image, and related trade dress are trademarks of OReilly Media, Inc.

The views expressed in this work are those of the author and do not represent the publishers views. While the publisher and the author have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights.

978-1-491-95568-0

[LSI]

Long after the printing press was invented, publishing books remains a challenging endeavor. Yes, theres typically an author (or authors) who scribble the content wherever and whenever they find time to do so. But theres also a content editor, tasked with helping the author transform their stream of consciousness into a relatable story thats not too dry to readsomething 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 copyeditor, the typo linters of prose and last bastion of proper grammar. Thus far, however, weve barely scratched the surface: everyone mentioned here is interested mostly in the contents of the book, but there are other aspects to the bookmaking process as well. Theres also, as an example, the typesetter, whose job is to ensure that the book looks good when it goes to printbidding good riddance to orphans and widows, poorly wrapped lines of code, and so much more. Someone has to design the cover, and another person must approve the table of contents for the first draft so that the author gets a contract. In addition, several people oversee the process that culminates in the book going to press, usually referred to as production. 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, its not that complicated. The author, for example, merely has to write a few hundred words every day. Where did all that complexity go? Theres a reason the process is so compartmentalized: were not that good at handling high-level complexity. Breaking it 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 merely an examplewe could do this exercise with just about anything. Pick an object on your desk, any object. Think about 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 megastructures of the technology sector, which handle everything from search queries to payment processing. Somewhere in the midst of all this complexity, theres 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 hide solutions behind abstract interfaces, so much that they becomein our mindsthe interface. Some of these interfaces map well to the abstracted implementation, and they feel great. Others dont map all that well to the implementation, and we end up feeling confused and frustrated. Software is not at all different. We dont 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.