SlideShare a Scribd company logo

JavaScript Application Design A Build First Approach 1st Edition Nicolas Bevacqua

M
mechagoins28

JavaScript Application Design A Build First Approach 1st Edition Nicolas Bevacqua JavaScript Application Design A Build First Approach 1st Edition Nicolas Bevacqua JavaScript Application Design A Build First Approach 1st Edition Nicolas Bevacqua

Education
1 of 78
Download to read offline
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
JavaScript Application Design A Build First Approach 1st Edition Nicolas Bevacqua download https://ebookgate.com/product/javascript-application-design-a- build-first-approach-1st-edition-nicolas-bevacqua/ Get Instant Ebook Downloads – Browse at https://ebookgate.com
Get Your Digital Files Instantly: PDF, ePub, MOBI and More Quick Digital Downloads: PDF, ePub, MOBI and Other Formats Algorithmic Trading Systems and Strategies A New Approach Design Build and Maintain 1st Edition Viktoria Dolzhenko https://ebookgate.com/product/algorithmic-trading-systems-and- strategies-a-new-approach-design-build-and-maintain-1st-edition- viktoria-dolzhenko/ Pressure sensitive design and formulation application First Edition Benedek https://ebookgate.com/product/pressure-sensitive-design-and- formulation-application-first-edition-benedek/ Web Application Design and Implementation Apache 2 PHP5 MySQL JavaScript and Linux UNIX Quantitative Software Engineering Series 1st Edition Steven A. Gabarró https://ebookgate.com/product/web-application-design-and- implementation-apache-2-php5-mysql-javascript-and-linux-unix- quantitative-software-engineering-series-1st-edition-steven-a- gabarro/ Build an HTML5 Game A Developer s Guide with CSS and JavaScript 1st Edition Karl Bunyan https://ebookgate.com/product/build-an-html5-game-a-developer-s- guide-with-css-and-javascript-1st-edition-karl-bunyan/
Automate with Grunt The Build Tool for JavaScript 1st Edition Brian P. Hogan https://ebookgate.com/product/automate-with-grunt-the-build-tool- for-javascript-1st-edition-brian-p-hogan/ Head First JavaScript 1st Edition Michael Morrison https://ebookgate.com/product/head-first-javascript-1st-edition- michael-morrison/ Reinforced Concrete Design A Practical Approach 1st Edition Brzev https://ebookgate.com/product/reinforced-concrete-design-a- practical-approach-1st-edition-brzev/ Head First JavaScript Programming 1st Edition Eric T. Freeman https://ebookgate.com/product/head-first-javascript- programming-1st-edition-eric-t-freeman/ The Design of Mammals A Scaling Approach 1st Edition John William Prothero https://ebookgate.com/product/the-design-of-mammals-a-scaling- approach-1st-edition-john-william-prothero/
M A N N I N G Nicolas Bevacqua FOREWORD BY Addy Osmani A Build First Approach
JavaScript Application Design
JavaScript Application Design A Build First Approach 1st Edition Nicolas Bevacqua
JavaScript Application Design A Build First Approach NICOLAS BEVACQUA M A N N I N G SHELTER ISLAND
iv For online information and ordering of this and other Manning books, please visit www.manning.com. The publisher offers discounts on this book when ordered in quantity. For more information, please contact Special Sales Department Manning Publications Co. 20 Baldwin Road PO Box 761 Shelter Island, NY 11964 Email: orders@manning.com ©2015 by Manning Publications Co. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps. Recognizing the importance of preserving what has been written, it is Manning’s policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end. Recognizing also our responsibility to conserve the resources of our planet, Manning books are printed on paper that is at least 15 percent recycled and processed without elemental chlorine. Manning Publications Co. Development editor: Susan Conant 20 Baldwin Road Technical development editor: Douglas Duncan PO Box 761 Copyeditor: Katie Petito Shelter Island, NY 11964 Proofreader: Alyson Brener Technical proofreaders: Deepak Vohra Valentin Crettaz Typesetter: Marija Tudor Cover designer: Marija Tudor ISBN: 9781617291951 Printed in the United States of America 1 2 3 4 5 6 7 8 9 10 – EBM – 20 19 18 17 16 15
To Marian, for withstanding the birth of this book, your unconditional love, and your endless patience. I love you! Will you marry me?
vi
vii brief contents PART 1 BUILD PROCESSES ........................................................ 1 1 ■ Introduction to Build First 3 2 ■ Composing build tasks and flows 23 3 ■ Mastering environments and the development workflow 50 4 ■ Release, deployment, and monitoring 71 PART 2 MANAGING COMPLEXITY ........................................... 97 5 ■ Embracing modularity and dependency management 99 6 ■ Understanding asynchronous flow control methods in JavaScript 131 7 ■ Leveraging the Model-View-Controller 166 8 ■ Testing JavaScript components 211 9 ■ REST API design and layered service architectures 251
BRIEF CONTENTS viii
ix contents foreword xv preface xvii acknowledgments xix about this book xxi about the author xxv about the cover illustration xxvi PART 1 BUILD PROCESSES ............................................ 1 1 Introduction to Build First 3 1.1 When things go wrong 4 How to lose $172,222 a second for 45 minutes 5 Build First 5 ■ Rites of initiation 6 1.2 Planning ahead with Build First 7 Core principles in Build First 7 1.3 Build processes 9 1.4 Handling application complexity and design 11 1.5 Diving into Build First 15 Keeping code quality in check 16 ■ Lint in the command line 19 1.6 Summary 22
CONTENTS x 2 Composing build tasks and flows 23 2.1 Introducing Grunt 24 Installing Grunt 26 ■ Setting up your first Grunt task 28 Using Grunt to manage the build process 29 2.2 Preprocessing and static asset optimization 31 Discussing preprocessing 31 ■ Doing LESS 34 Bundling static assets 37 ■ Static asset minification 38 Implementing image sprites 41 2.3 Setting up code integrity 43 Cleaning up your working directory 43 ■ Lint, lint, lint! 44 Automating unit testing 45 2.4 Writing your first build task 46 2.5 Case study: database tasks 47 2.6 Summary 49 3 Mastering environments and the development workflow 50 3.1 Application environments 51 Configuring build distributions 51 ■ Environment-level configuration 56 ■ What’s so special about development? 58 3.2 Configuring environments 58 Storing configuration in a waterfall 59 ■ Using encryption to harden environment configuration security 61 ■ Setting environment-level configuration at the OS level 62 Merging configuration as a waterfall in code 64 3.3 Automating tedious first-time setup tasks 65 3.4 Working in continuous development 66 Waste no time, use a watch! 66 ■ Monitoring for changes to the Node app 67 ■ A text editor that cares 69 ■ Browser refresh is so Y2K 69 3.5 Summary 70 4 Release, deployment, and monitoring 71 4.1 Releasing your application 73 Image optimization 73 ■ Static asset caching 75 Inlining critical above-the-fold CSS 77 ■ Testing before a deployment 78 4.2 Predeployment operations 79 Semantic versioning 80 ■ Using changelogs 81 ■ Bumping changelogs 81
CONTENTS xi 4.3 Deploying to Heroku 82 Deploying builds 85 ■ Managing environments 85 4.4 Continuous integration 86 Hosted CI using Travis 86 ■ Continuous deployments 88 4.5 Monitoring and diagnostics 89 Logging and notifications 89 ■ Debugging Node applications 92 ■ Adding performance analytics 93 Uptime and process management 94 4.6 Summary 95 PART 2 MANAGING COMPLEXITY ................................ 97 5 Embracing modularity and dependency management 99 5.1 Working with code encapsulation 101 Understanding the Single Responsibility Principle 101 Information hiding and interfaces 104 ■ Scoping and this keyword 106 ■ Strict mode 109 ■ Variable hoisting 110 5.2 JavaScript modules 111 Closures and the module pattern 111 ■ Prototypal modularity 112 ■ CommonJS modules 113 5.3 Using dependency management 114 Dependency graphs 114 ■ Introducing RequireJS 117 Browserify: CJS in the browser 119 ■ The Angular way 120 5.4 Understanding package management 122 Introducing Bower 122 ■ Big libraries, small components 124 ■ Choosing the right module system 125 Learning about circular dependencies 126 5.5 Harmony: a glimpse of ECMAScript 6 127 Traceur as a Grunt task 127 ■ Modules in Harmony 128 Let there be block scope 129 5.6 Summary 129 6 Understanding asynchronous flow control methods in JavaScript 131 6.1 Using callbacks 132 Avoiding callback hell 133 ■ Untangling the callback jumble 134 ■ Requests upon requests 136 ■ Asynchronous error handling 138
CONTENTS xii 6.2 Using the async library 141 Waterfall, series, or parallel? 141 ■ Asynchronous functional tasks 145 ■ Asynchronous task queues 147 ■ Flow composition and dynamic flows 147 6.3 Making Promises 150 Promise fundamentals 150 ■ Chaining Promises 153 Controlling the flow 155 ■ Handling rejected Promises 156 6.4 Understanding events 157 Events and the DOM 157 ■ Creating your own event emitters 158 6.5 Glimpse of the future: ES6 generators 161 Creating your first generator 161 ■ Asynchronicity and generators 163 6.6 Summary 165 7 Leveraging the Model-View-Controller 166 7.1 jQuery isn’t enough 167 7.2 Model-View-Controller in JavaScript 170 Why Backbone? 170 ■ Installing Backbone 172 Browserifying your Backbone module with Grunt 172 7.3 Introduction to Backbone 174 Backbone views 175 ■ Creating Backbone models 177 Organizing models with Backbone collections 179 ■ Adding Backbone routers 180 7.4 Case study: the shopping list 183 Starting with a static shopping list 183 ■ This time with remove buttons 185 ■ Adding items to your cart 187 ■ Using inline editing 191 ■ A service layer and view routing 197 7.5 Backbone and Rendr: server/client shared rendering 199 Diving into Rendr 199 ■ Understanding boilerplate in Rendr 201 ■ A simple Rendr application 203 7.6 Summary 210 8 Testing JavaScript components 211 8.1 JavaScript testing crash course 212 Logical units in isolation 212 ■ Using the Test Anything Protocol (TAP) 213 ■ Putting together our first unit test 214 Tape in the browser 214 ■ Arrange, Act, Assert 215 Unit testing 216 ■ Convenience over convention 217
CONTENTS xiii Case study: unit testing an event emitter 217 ■ Testing the event emitter 218 ■ Testing for the .on method 219 Mocks, spies, and proxies 221 ■ Mocking 222 Introducing Sinon.js 223 ■ Spying on function calls 223 Proxying require calls 224 8.2 Testing in the browser 226 Faking XHR and server communication 227 ■ Case study: testing DOM interaction 229 8.3 Case study: unit testing the MVC shopping list 238 Testing the view router 238 ■ Testing validation on a view model 243 8.4 Automating Tape tests 245 Automating Tape tests for the browser 246 ■ Continuous testing 247 8.5 Integration, visual, and performance testing 247 Integration testing 247 ■ Visual testing 248 ■ Performance testing 249 8.6 Summary 250 9 REST API design and layered service architectures 251 9.1 Avoiding API design pitfalls 252 9.2 Learning REST API design 253 Endpoints, HTTP verbs, and versioning 254 ■ Requests, responses, and status codes 257 ■ Paging, caching, and throttling 260 ■ Documenting an API 263 9.3 Implementing layered service architectures 264 Routing layer 265 ■ Service layer 265 ■ Data layer 265 Routing layer 266 ■ Service layer 266 ■ Data layer 267 9.4 Consuming a REST API on the client side 267 The request handling layer 268 ■ Shooting down old requests 268 ■ Consistent AJAX error management 269 9.5 Summary 271 appendix A Modules in Node.js 273 appendix B Introduction to Grunt 276 appendix C Picking your build tool 284 appendix D JavaScript code quality guide 293 index 307
CONTENTS xiv
xv foreword The process of designing a robust JavaScript web app has gone through a roaring renaissance in recent years. With the language being used to develop increasingly ambitious apps and interfaces, this is the perfect time for JavaScript Application Design. Through concise examples, lessons learned from the field, and key concepts for scal- able development, Nico Bevacqua will give you a whirlwind tour of taking the process and design of your apps to the next level. This book will also help you craft build processes that will save you time. Time is a key factor in staying productive. As web app developers, we want to make the most of ours, and a Build First philosophy can help us hit the ground running with clean, test- able apps that are well structured from the get-go. Learning process workflow and how to manage complexity are fundamental cornerstones of modern JavaScript app development. Getting them right can make a massive difference in the long run. JavaScript Application Design will walk you through automation for the front end. It covers everything from avoiding repetitive tasks and monitoring production builds to mitigating the cost of human error through a clean tooling setup. Automation is a big factor here. If you aren't using automation in your workflow today, you're working too hard. If a series of daily tasks can be accomplished with a single command, follow Nico's advice and spend the time you save improving the code quality of your apps. Modularity is the final crucial concept that can assist with building scalable, main- tainable apps. Not only does this help ensure that the pieces composing our applica- tion can be more easily tested and documented, it encourages reuse and focus on quality. In JavaScript Application Design, Nico expertly walks you through writing modu-
FOREWORD xvi lar JavaScript components, getting asyncronous flow right, and enough client-side MVC for you to build an app of your own. Strap on your seatbelts, adjust your command line, and enjoy a ride through the process of improving your development workflow. ADDY OSMANI SENIOR ENGINEER WITH A PASSION FOR DEVELOPER TOOLING GOOGLE
xvii preface Like most people in our field, I’ve always been fascinated with problem solving. The painful thrill of hunting for a solution, the exhilarating relief of having found a fix— there’s nothing quite like it. When I was young I really enjoyed strategy games, such as chess, which I’ve played ever since I was a kid; StarCraft, a real-time strategy game I played for 10 years straight; and Magic: The Gathering, a trading card game that can be described as the intersection between poker and chess. They presented plenty of problem-solving opportunities. At primary school I learned Pascal and rudimentary Flash programming. I was psyched. I would go on and learn Visual Basic, PHP, C, and start developing websites, reaping the benefits of a masterful handle on <marquee> and <blink> tags, paired with a modest understanding of MySQL; I was unstoppable, but my thirst for problem solving didn’t end there, and I went back to gaming. Ultima Online (UO), a massively multiplayer online role-playing game (no wonder they abbreviate that as MMORPG), wasn’t any different than other games that got me hooked for years. Eventually I found out that there was an open source1 implementa- tion of the UO server, which was named RunUO and written entirely in C#. I played on a RunUO server where the administrators had no programming experience. They slowly started trusting me to handle minor bug fixes by literally emailing source code files back and forth. I was hooked. C# was a wonderful, expressive language, and the open source software for the UO server was amicable and inviting—you didn’t even 1 You can check out the RunUO website at runuo.com, although the project isn’t maintained anymore.
PREFACE xviii need an IDE (or even need to know what that was) because the server would compile script files dynamically for you. You’d be essentially writing a file with 10 to 15 lines in it, inheriting from the Dragon class, and adding an intimidating text bubble over their head, or overriding a method so they’d spit more fireballs. You’d learn the language and its syntax without even trying, simply by having fun! Eventually, a friend revealed that I could make a living out of writing C# code: “You know, people actually pay you to do that,” he said. That’s when I started developing websites again, except I wasn’t using only Front Page and piles of <marquee> tags or Java applets for fun anymore. It still feels like a game to me, though. A few years ago I read The Pragmatic Programmer2 , and something clicked. The book has a lot of solid advice, and I can’t recommend it highly enough. One thing that par- ticularly affected me: the authors advocate you get out of your comfort zone and try something you’ve been meaning to do but haven’t gotten around to. My comfort zone was C# and ASP.NET at that point, so I decided to try Node.js, an unmistakably UNIX-y platform for JavaScript development on the server side, certainly a break from my Microsoft-ridden development experience so far. I learned a ton from that experiment and ended up with a blog3 where I’d write about everything I learned in the process. About six months later I’d decided that I’d put my years of experience in C# design into a book about JavaScript. I contacted Manning, and they jumped at the opportunity, helping me brainstorm and turn raw ideas into something more deliberate and concise. This book is the result of many hours of hard work, dedication, and love for the web. In it, you’ll find practical advice about application design, process automation, and best practices that will improve the quality of your web projects. 2 The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas (Addison Wesley, 1999) is a timeless classic you should seriously consider reading. 3 You can read my blog, “Pony Foo,” at ponyfoo.com. I write articles about the web, performance, progressive enhancement, and JavaScript.
xix acknowledgments You wouldn’t be holding this book in your hands if it weren’t for everyone who sup- ported and endured me throughout the writing process. I can only hope that those who deserve acknowledgment the most, my friends and family, already know that I can’t put into words how thankful I am for their love, understanding, and frequent reassurance. Many more people contributed—directly or indirectly—a great deal of wisdom and inspiration to this book. The open source JavaScript community is an endless spring of insight, encourage- ment, and selfless contributions. They have opened my eyes to a better approach to software development, where collaboration isn’t only possible, but actively encour- aged. Most of these people have contributed indirectly by evangelizing for the web, maintaining blogs, sharing their experience and resources, and otherwise educating me. Others have contributed directly by developing tools discussed in the book. Among these individuals are Addy Osmani, Chris Coyier, Guillermo Rauch, Harry Roberts, Ilya Grigorik, James Halliday, John-David Dalton, Mathias Bynens, Max Ogden, Mikeal Rogers, Paul Irish, Sindre Sorhus, and T.J. Holowaychuk. There are also many book authors and content distributors who have influenced and motivated me to become a better educator. Through their writing and sharing, these people have significantly helped shape my career. They include Adam Wiggins, Alan Cooper, Andrew Hunt, Axel Rauschmayer, Brad Frost, Christian Heilmann, David Thomas, Donald Norman, Frederic Cambus, Frederick Brooks, Jeff Atwood, Jeremy Keith, Jon Bentley, Nicholas C. Zakas, Peter Cooper, Richard Feynmann, Steve Krug, Steve McConnell, and Vitaly Friedman.
ACKNOWLEDGMENTS xx Susan Conant, my developmental editor at Manning, deserves to be singled out. She held this book to the greatest standard of quality I could possibly create, and it’s in much better shape than it would’ve been if not for her. On top of that, she had to hand-hold me through the delicate and intimate process of writing my first book. Through her relentless, yet gentle, guidance she helped shape my lumps of ideas into a book that I’m not afraid to publish. I’ve become a better writer because of her, and I’m grateful for that. She wasn’t alone in that endeavor. All of the staff at Manning wanted this book to be the best that it could be. The publisher, Marjan Bace—along with his editorial col- lective—are to be thanked for that. Valentin Crettaz and Deepak Vohra, the technical proofreaders, were not only instrumental in ensuring the code samples were consis- tent and useful, but provided me with great feedback as well. There are also the hordes of anonymous souls that were willing to read through the manuscript, leaving their impressions and helping improve the book. Thanks to the MEAP readers who posted corrections and comments in the Author Online forum, and to the reviewers who read the chapters at various stages of development: Alberto Chiesa, Carl Mosca, Dominic Pettifer, Gavin Whyte, Hans Donner, Ilias Ioan- nou, Jonas Bandi, Joseph White, Keith Webster, Matthew Merkes, Richard Harriman, Sandeep Kumar Patel, Stephen Wakely, Torsten Dinkheller, and Trevor Saunders. Special thanks to Addy Osmani for contributing the foreword, and to everyone else who played a part. Even if they didn’t make the keystrokes themselves, they played an instrumental role in getting this book published, and one step closer to you.
xxi about this book Web development has grown out of proportion, and today it’s hard to imagine a world without the web. The web is famously fault tolerant. While traditional programming teaches us that missing a semicolon, forgetting to add a closing tag, or declaring invalid properties will have crippling consequences, the same cannot be said about the web. The web is a place where it’s okay to make mistakes, yet there’s increasingly less room for error. This dichotomy stems from the fact that modern web applications are an order of magnitude more complex than they used to be. During the humble beginnings of the web, we would maybe modestly make a minor change in web pages using JavaScript; whereas on the modern web, entire sites are rendered in a single page, powered by JavaScript. JavaScript Application Design is your guide to a better modern web development experience, one where you can develop maintainable JavaScript applications as you would if you were using any other language. You’ll learn how to leverage automation as a replacement for tedious and repetitive error-prone processes, how to design mod- ular applications that are easy to test, and how to test them. Process automation is a critical time-saver across the board. Automation in the development environment helps us focus our efforts on thinking, writing code, and debugging. Automation helps ensure our code works after every change that we pub- lish to version control. It saves time when preparing the application for production by bundling, minifying assets, creating spritesheets, and adding other performance opti- mization techniques. It also helps with deployments by reducing risk and automating away a complicated and error-prone process. Many books discuss processes and
ABOUT THIS BOOK xxii automation when it comes to back-end languages, but it’s much harder to find mate- rial on the subject when it comes to JavaScript-driven applications. The core value of JavaScript Application Design is quality. Automation gives you a bet- ter environment in which to build your application, but that alone isn’t enough: the application itself needs to be quality conscious as well. To that end, the book covers application design guidelines, starting with a quick rundown of language-specific cave- ats, teaching you about the power of modularity, helping you untangle asynchronous code, develop client-side MVC applications, and write unit tests for your JavaScript code. This book relies on specific tools and framework versions, as books about web tech- nologies usually do, but it separates library-specific concerns from the theory at hand. This is a concession to the fact that tooling changes frequently in the fast-paced web development arena, but design and the processes behind tooling tend to have a much slower rhythm. Thanks to this separation of concerns, I hope this book stays relevant for years to come. Road map JavaScript Application Design is broken into two parts and four appendixes. The first part is dedicated to the Build First approach, what it is, and how it can aid your every- day job. This part covers process automation in detail, from everyday development to automated deployments, as well as continuous integration and continuous deploy- ments; it spans 4 chapters. ■ Chapter 1 describes the core principles that drive Build First, and the different processes and flows you can set up. It then introduces the application design guidelines that we’ll discuss throughout the book and lays the foundation for the rest of the book. ■ In chapter 2 you learn about Grunt, and how you can use it to compose build flows. Then we look at a few different build tasks that you can easily perform using Grunt. ■ Chapter 3 is all about environments and the development workflow. You’ll learn that not all environments are born the same, and how you can prioritize debugging and productivity in the development environment. ■ Chapter 4 walks you through the release flow and discusses deployments. You’ll learn about a few more build tasks that are geared toward performance optimi- zation, and discover how to perform automated deployments. You’ll also learn how to hook up continuous integration and how to monitor your application once in production. While part 1 is focused on building applications using Grunt, appendix C teaches you to choose the best build tool for the job. Once you’ve read past part 1, you’ll go into the second part of the book, which is dedicated to managing complexity in your appli- cation designs. Modules, MVC, asynchronous code flows, testing, and a well-designed API all play significant roles in modern applications and are discussed in the next chapters.
ABOUT THIS BOOK xxiii ■ Chapter 5 focuses on developing modular JavaScript. It starts by expressing what constitutes a module and how you can design applications modularly and lists the benefits of doing so. Afterward, you’ll get a crash course on lexical scoping and related quirks in the JavaScript language. Later you get a rundown of the major ways to attain modularity: RequireJS, CommonJS, and the upcom- ing ES6 module system. The chapter concludes by going over different package management solutions such as Bower and npm. ■ In chapter 6 you learn about asynchronous code flows. If you ever descend into callback hell, this may be your way out. This chapter discusses different approaches to deal with complexity in asynchronous code flows, namely call- backs, Promises, events, and ES6 generators. You’ll also learn how to do proper error handling under each of those paradigms. ■ Chapter 7 starts by describing MVC architectures, and then ties them specifically to the web. You’ll learn how you can use Backbone to develop rich client-side applications that separate concerns using MVC. Later, you’ll learn about Rendr, which can be used to render Backbone views on the server side, optimizing the performance and accessibility of your applications. ■ In chapter 8, now that your applications are modular, clean-cut, and maintain- able, you’ll take the next logical step and look into testing your applications in different ways. To this end we’ll go over an assortment of JavaScript testing tools and get hands-on experience using them to test small components. Then we’ll go back to the MVC application built in chapter 7 and add tests to it. You won’t be doing unit testing only, you’ll also learn more about continuous integration, visual testing, and measuring performance. ■ Chapter 9 is the last chapter of the book, and it’s dedicated to REST API design. This is the layer where the client side interacts with the server, and it sets the scene for everything that we do in the application. If the API is convoluted and complicated, chances are the application as a whole will be as well. REST intro- duces clear guidelines when designing an API, making sure the API is concise. Last, we’ll look at consuming these services in the client side in a conventional manner. The appendixes can be read after you’re done with the book, but you’ll probably get the most value from them by reading them if you get stuck with the areas they cover, as they contain answers to questions you might have. Throughout the book, you’ll be pointed to the appendixes where it makes sense to expand a little on one of these subjects. ■ Appendix A is a soft introduction to Node.js and its module system, CommonJS. It’ll help you troubleshoot your Node.js installation and answer a few questions on how CommonJS works. ■ Appendix B is a detailed introduction to Grunt. Whereas the chapters in part I only explain what’s absolutely necessary about Grunt, the appendix covers its inner workings in more detail, and will be handy if you’re serious about devel- oping a full-blown build process using Grunt.
ABOUT THIS BOOK xxiv ■ Appendix C makes it clear that this book is in no way married to Grunt, and lists a couple of alternatives, Gulp and npm run. The appendix discusses the pros and cons of each of the three tools, and leaves it up to you to determine which one (if any) fits your needs best. ■ Appendix D presents a JavaScript quality guide containing a myriad of best prac- tices you may choose to follow. The idea isn’t to force those specific guidelines down your throat, but rather to arm you with the idea that consistency is a good thing to enforce throughout a code base when working in a development team. Code conventions and downloads All source code is in fixed-size width font like this, and sometimes grouped under named code listings. Code annotations accompany many of the listings, high- lighting important concepts. The source code for this book is open source and pub- licly hosted on GitHub. You can download it by visiting github.com/buildfirst/ buildfirst. The online repository will always have the most up-to-date version of the accompanying source code. While source code might only be discussed at a glance in the book, it’s better documented in the repository, and I encourage you to check out the commented code there, if you run into trouble. You can also download the code from the publisher’s website at www.manning .com/JavaScriptApplicationDesign. Author Online Purchase of JavaScript Application Design includes free access to a private web forum run by Manning Publications, where you can make comments about the book, ask technical questions, and receive help from the author and from other users. To access the forum and subscribe to it, point your web browser to www.manning.com/ JavaScriptApplicationDesign. This page provides information on how to get on the forum once you are registered, what kind of help is available, and the rules of con- duct on the forum. Manning’s commitment to our readers is to provide a venue where a meaningful dialogue between individual readers and between readers and the author can take place. It is not a commitment to any specific amount of participation on the part of the author, whose contribution to the book’s forum remains voluntary (and unpaid). We suggest you try asking the author some challenging questions, lest his interest stray! The Author Online forum and the archives of previous discussions will be accessi- ble from the publisher’s website as long as the book is in print.
xxv about the author Nicolas Bevacqua is an active member of the open source JavaScript community, a freelance web developer, an occasional public speaker, and a passionate writer. He maintains many open source projects and blogs about the web, performance, progressive enhancement, and JavaScript development at ponyfoo.com. Nico currently lives in Buenos Aires, Argentina, with his beautiful girl- friend, Marian.
xxvi about the cover illustration The figure on the cover of JavaScript Application Design is captioned “Winter Habit of a Kamtchadal in 1760.” The Kamchatka Peninsula is the eastern-most part of Russia, lying between the Pacific Ocean to the east and the Sea of Okhotsk to the west. The illustration is taken from Thomas Jefferys' A Collection of the Dresses of Different Nations, Ancient and Modern, London, published between 1757 and 1772. The title page states that these are hand-colored copperplate engravings, heightened with gum arabic. Thomas Jefferys (1719–1771) was called “Geographer to King George III.” He was an English cartographer who was the leading map supplier of his day. He engraved and printed maps for government and other official bodies and produced a wide range of commercial maps and atlases, especially of North America. His work as a mapmaker sparked an interest in local dress customs of the lands he surveyed and mapped; they are brilliantly displayed in this four-volume collection. Fascination with faraway lands and travel for pleasure were relatively new phenom- ena in the eighteenth century and collections such as this one were popular, introduc- ing both the tourist as well as the armchair traveler to the inhabitants of other countries. The diversity of the drawings in Jefferys’ volumes speaks vividly of the uniqueness and individuality of the world's nations centuries ago. Dress codes have changed, and the diversity by region and country, so rich at one time, has faded away. It is now often hard to tell the inhabitant of one continent from another. Perhaps, try- ing to view it optimistically, we have traded a cultural and visual diversity for a more varied personal life—or a more varied and interesting intellectual and technical life.
ABOUT THE COVER ILLUSTRATION xxvii At a time when it is hard to tell one computer book from another, Manning cele- brates the inventiveness and initiative of the computer business with book covers based on the rich diversity of national costumes two and a half centuries ago, brought back to life by Jefferys’ pictures.
ABOUT THE COVER ILLUSTRATION xxviii
Part 1 Build processes The first part of this book is dedicated to build processes and provides a practical introduction to Grunt. You’ll learn the why, how, and what of build pro- cesses, both in theory and in practice. In chapter 1, we go over what the Build First philosophy entails: a build pro- cess and application complexity management. Then, we’ll start fiddling with our first build task, using lint to prevent syntax errors in our code. Chapter 2 is all about build tasks. You’ll learn about the various tasks that comprise a build, how to configure them, and how to create your own tasks. In each case, we’ll take a look at the theory and then walk through practical exam- ples using Grunt. In chapter 3, we’ll learn how to configure application environments while keeping sensitive information safe. We’ll go over the development environment workflow, and you’ll learn how to automate the build step itself. Chapter 4 then describes a few more tasks we need to take into account when releasing our application, such as asset optimization and managing documenta- tion. You’ll learn about keeping code quality in check with continuous integra- tion, and we’ll also go through the motions of deploying an application to a live environment.
2 CHAPTER
3 Introduction to Build First Developing an application properly can be hard. It takes planning. I’ve created applications over a weekend, but that doesn’t mean they were well-designed. Improvisation is great for throw-away prototypes and great when concept-proofing an idea; however, building a maintainable application requires a plan, the glue that holds together the features you currently have in mind and maybe even those you might add in the near future. I’ve participated in countless endeavors where the application’s front-end wasn’t all it could be. Eventually, I realized that back-end services usually have an architect devoted to their planning, design, and overview—and often it’s not one architect but an entire team of them. This is hardly the case with front-end development, where a devel- oper is expected to prototype a working sketch of the application and then asked to This chapter covers ■ Identifying problems in modern application design ■ Defining Build First ■ Building processes ■ Managing complexity within applications
4 CHAPTER 1 Introduction to Build First run with it, hoping that the prototype will survive an implementation in production. Front-end development requires as much dedication to architecture planning and design as back-end development does. Long gone are the days when we’d copy a few snippets of code off the internet, paste them in our page, and call it a day. Mashing together JavaScript code as an after- thought no longer holds up to modern standards. JavaScript is now front and center. We have many frameworks and libraries to choose from, which can help you organize your code by allowing you to write small components rather than a monolithic appli- cation. Maintainability isn’t something you can tack onto a code base whenever you’d like; it’s something you have to build into the application, and the philosophy under which the application is designed, from the beginning. Writing an application that isn’t designed to be maintainable translates into stacking feature after feature in an ever-so-slightly tilting Jenga tower. If maintainability isn’t built in, it gets to a point where you can’t add any more pieces to the tower. The code becomes convoluted and bugs become increasingly hard to track down. Refactoring means halting product development, and the busi- ness can’t afford that. The release schedule must be maintained, and letting the tower come crashing down is unacceptable, so we compromise. 1.1 When things go wrong You might want to deploy a new feature to production, so humans can try it out. How many steps do you have to take to do that? Eight? Five? Why would you risk a mistake in a routine task such as a deployment? Deploying should be no different than build- ing your application locally. One step. That’s it. Unfortunately that’s rarely the standard. Have you faced the challenging position I’ve found myself in of having to take many of these steps manually? Sure, you can compile the application in a single step, or you might use an interpreted server-side language that doesn’t need any pre-compilation. Maybe later you need to update your database to the latest version. You may have even created a script for those updates, and yet you log into your database server, upload the file, and run the schema updates yourself. Cool, you’ve updated the database; however, something’s not right and the appli- cation is throwing an error. You look at the clock. Your application has been down for more than 10 minutes. This should’ve been a straightforward update. You check the logs; you forgot to add that new variable to your configuration file. Silly! You add it promptly, mumbling something about wrestling with the code base. You forget to alter the config file before it deploys; it slipped your mind to update it before deploying to production! Sound like a familiar ritual? Fear not, this is an unfortunately common illness, spread through different applications. Consider the crisis scenarios described next.
5 When things go wrong 1.1.1 How to lose $172,222 a second for 45 minutes I bet you’d consider losing almost half a billion dollars a serious issue, and that’s exactly what happened to Knight’s Capital.1 They developed a new feature to allow stock traders to participate in something called the Retail Liquidity Program (RLP). The RLP functionality was intended to replace an unused piece of functionality called Power Peg (PP), which had been discontinued for close to nine years. The RLP code reused a flag, which was used to activate the PP code. They removed the Power Peg feature when they added RLP, so all was good. Or at least they thought it was good, until the point when they flipped the switch. Deployments had no formal process and were executed by hand by a single techni- cian. This person forgot to deploy the code changes to one of their eight servers, meaning that in the case of the eighth server, the PP code, and not the RLP feature, would be behind the activation flag. They didn’t notice anything wrong until a week later when they turned on the flag, activating RLP on all servers but one, and the nine- year-old Power Peg feature on the other. Orders routed through the eighth server triggered the PP code rather than RLP. As a result, the wrong types of orders were sent to trading centers. Attempts to amend the situation only further aggravated it, because they removed the RLP code from the serv- ers which did have it. Long story short, they lost somewhere in the vicinity of $460 mil- lion in less than an hour. When you consider that all they needed to do to avoid their downfall was have a more formal build process in place, the whole situation feels out- rageous, irresponsible, and, in retrospect, easily averted. Granted, this is an extreme case, but it boldly illustrates the point. An automated process would have increased the probability that human errors could be prevented or at least detected sooner. 1.1.2 Build First In this book, my goal is to teach you the Build First philosophy of designing for clean, well-structured, and testable applications before you write a single line of code. You’ll learn about process automation, which will mitigate the odds of human error, such as those leading to Knight’s Capital’s bankruptcy. Build First is the foundation that will empower you to design clean, well-structured, and testable applications, which are easy to maintain and refactor. Those are the two fundamental aspects of Build First: process automation and design. To teach you the Build First approach, this book will show you techniques that will improve the quality of your software as well as your web development workflow. In Part 1, we’ll begin by learning how to establish build processes appropriate for mod- ern web application development. Then, you'll walk through best practices for pro- ductive day-to-day development, such as running tasks when your code changes, deploying applications from your terminal by entering a single command, and moni- toring the state of your application once it's in production. 1 For more information about Knight’s Capital, see http://bevacqua.io/bf/knight.
6 CHAPTER 1 Introduction to Build First The second part of the book—managing complexity and design—focuses on application quality. Here I give you an introduction to writing more modular Java- Script components by comparing the different options that are currently available. Asynchronous flows in JavaScript tend to grow in complexity and length, which is why I prepared a chapter where you’ll gain insight into writing cleaner asynchronous code while learning about different tools you can use to improve that code. Using Back- bone as your gateway drug of choice, you’ll learn enough about MVC in JavaScript to get you started on the path to client-side MVC. I mentioned testable applications are important, and while modularity is a great first step in the right direction, testing mer- its a chapter of its own. The last chapter dissects a popular API design mentality denominated REST (Representational State Transfer), helping you design your own, as well as delving into application architecture on the server side, but always keeping an eye on the front end. We’ll begin our exploration of build processes after looking at one more crisis scenario Build First can avert by automating your process. 1.1.3 Rites of initiation Complicated setup procedures, such as when new team members come onboard, are also a sign you may be lacking in the automation department. Much to my torment, I’ve worked on projects where getting a development environment working for the first time took a week. A full week before you can even begin to fathom what the code does. Download approximately 60 gigabytes worth of database backups, create a data- base configuring things you’ve never heard of before, such as collation, and then run a series of schema upgrade scripts that don’t quite work. Once you’ve figured that out, you might want to patch your Windows Media Player by installing specific and extremely outdated codecs in your environment, which will feel as futile as attempts to cram a pig into a stuffed refrigerator. Last, try compiling the 130+ project monolith in a single pass while you grab a cup of coffee. Oh, but you forgot to install the external dependencies; that’ll do it. Nope, wait, you also need to compile a C++ program so codecs will work again. Compile again, and another 20 minutes go by. Still failing? Shoot. Ask around, maybe? Well, nobody truly knows. All of them went through that excruciating process when they started out, and they erased the memory from their minds. Check out the wiki? Sure, but it’s all over the place. It has bits of information here and there, but they don’t address your specific problems. The company never had a formal initiation workflow, and as things started to pile up, it became increasingly hard to put one together. They had to deal with giant back- ups, upgrades, codecs, multiple services required by the website, and compiling the project took half an hour for every semi-colon you changed. If they’d automated these steps from the beginning, like we’ll do in Build First, the process would’ve been that much smoother. Both the Knight’s Capital debacle and the overly complicated setup story have one thing in common: if they’d planned ahead and automated their build and deploy- ment processes, their issues would’ve been averted. Planning ahead and automating
7 Planning ahead with Build First the processes surrounding your applications are fundamental aspects of the Build First philosophy, as you’ll learn in the next section. 1.2 Planning ahead with Build First In the case of Knight’s Capital, where they forgot to deploy code to one of the produc- tion web servers, having a single-step deployment process that automatically deployed the code to the whole web farm would’ve been enough to save the company from bankruptcy. The deeper issue in this case was code quality, because they had unused pieces of code sitting around in their code base for almost 10 years. A complete refactor that doesn’t provide any functional gains isn’t appealing to a product manager; their goal is to improve the visible, consumer-facing product, not the underlying software. Instead, you can continuously improve the average quality of code in your project by progressively improving the code base and refactoring code as you touch it, writing tests that cover the refactored functionality, and wrapping legacy code in interfaces, so you can refactor later. Refactoring won’t do the trick on its own, though. Good design that’s ingrained into the project from its inception is much more likely to stick, rather than attempts to tack it onto a poor structure as an afterthought. Design is the other fundamental aspect of the book, along with build processes mentioned previously. Before we dive into the uncharted terrains of Build First, I want to mention this isn’t a set of principles that only apply to JavaScript. For the most part, people usually asso- ciate these principles with back-end languages, such as Java, C#, or PHP, but here I’m applying them to the development process for JavaScript applications. As I mentioned previously, client-side code often doesn’t get the love and respect it deserves. That often means broken code because we lack proper testing, or a code base that’s hard to read and maintain. The product (and developer productivity) suffers as a result. When it comes to JavaScript, given that interpreted languages don’t need a com- piler, naive developers might think that’s justification enough to ditch the build pro- cess entirely. The problem when going down that road is that they’ll be shooting in the dark: the developer won’t know whether the code works until it’s executed by a browser, and won’t know whether it does what it's expected to, either. Later on, they might find themselves manually deploying to a hosting environment and logging into it remotely to tweak a few configuration settings to make it work. 1.2.1 Core principles in Build First At its core, the Build First approach encourages establishing not only a build process but also clean application design. The following list shows at a high level what embrac- ing the Build First approach gives us: ■ Reduced error proclivity because there’s no human interaction ■ Enhanced productivity by automating repetitive tasks ■ Modular, scalable application design
8 CHAPTER 1 Introduction to Build First ■ Testability and maintainability by shrinking complexity ■ Releases that conform to performance best practices ■ Deployed code that’s always tested before a release Looking at figure 1.1, starting with the top row and moving down, you can see ■ Build process: This is where you compile and test the application in an auto- mated fashion. The build can be aimed at facilitating continuous development or tuned for maximum performance for a release. ■ Design: You’ll spend most of your time here, coding and augmenting the archi- tecture as you go. While you’re at it, you might refactor your code and update the tests to ensure components work as expected. Whenever you’re not tweak- ing the build process or getting ready for a deployment, you’ll be designing and iterating on the code base for your application. ■ Deployment and Environment: These are concerned with automating the release process and configuring the different hosted environments. The Build process Automation concerns Design Architecture concerns Code Compile Test Turns source code into different build distributions Code quality: readability, maintainability, testability Takes a single distribution and deploys to a hosting environment Environment configuration, such as a database connection string, API keys, or listen port Helps iterate on code quality and refactor Debug or release Distribution Deployment Release concerns Environment Performance concerns App server Deploy Turns source code into different build distributions Built app, feeds from environment configuration Configuration Distribution Figure 1.1 High-level view of the four areas of focus in Build First: Build process, Design, Deployment, and Environment
9 Build processes deployment process is in charge of delivering your changes to the hosted envi- ronment, while environment configuration defines the environment and the services—or databases—it interacts with, at a high level. As figure 1.1 illustrates, Build First applications have two main components: the pro- cesses surrounding the project, such as building and deploying the application, and the design and quality of the application code itself, which is iteratively improved on a daily basis as you work on new features. Both are equally important, and they depend on each other to thrive. Good processes don’t do any good if you’re lacking in your application design. Similarly, good design won’t survive crises such as the ones I described previously without the help of decent build and deployment procedures. As with the Build First approach, this book is broken into two parts. In part 1, we look at the build process (tuned for either development or release) and the deploy- ment process, as well as environments and how they can be configured. Part 2 delves into the application itself, and helps us come up with modular designs that are clear and concise. It also takes us through the practical design considerations you'll have to make when building modern applications. In the next two sections, you’ll get an overview of the concepts discussed in each part of the book. 1.3 Build processes A build process is intended to automate repetitive tasks such as installing dependen- cies, compiling code, running unit tests, and performing any other important func- tions. The ability to execute all of the required tasks in a single step, called a one-step build, is critical because of the powerful opportunities it unveils. Once you have a one- step build in place, you can execute it as many times as required, without the outcome changing. This property is called idempotence: no matter how many times you invoke the operation, the result will be the same. Figure 1.2 highlights in more detail the steps that make up the automated build and deployment processes. Pros and cons of automating your build processes Possibly the most important advantage to having an automated build process is that you can deploy as frequently as needed. Providing humans with the latest features as soon as they’re ready allows us to tighten the feedback loop through which we can gain better insights into the product we should be building. The main disadvantage to setting up an automated process is the time you’ll need to spend putting the process together before you can start seeing the real benefits, but the benefits—such as automated testing, higher code quality, a leaner develop- ment workflow, and a safer deployment flow—far outweigh the effort spent putting together that process. As a general rule, you’ll set up the process once and then replay it as much as you’d like, tweaking it a little as you go.
10 CHAPTER 1 Introduction to Build First BUILD The top of figure 1.2 zooms in on the build portion in the build process workflow (shown back in figure 1.1), detailing the concerns as you aim for either development or release. If you aim for development, you’ll want to maximize your ability to debug, and I bet you’ll like a build that knows when to execute parts of itself without you tak- ing any action. That’s called continuous development (CD), and you’ll learn about it in chapter 3. The release distribution of a build isn’t concerned with CD, but you’ll want to spend time optimizing your assets so they perform as fast as possible in production environments where humans will use your application. DEPLOYMENT The bottom of figure 1.2 zooms into the deployment process (originally shown in fig- ure 1.1), which takes either the debug or release distribution (what I call distinct pro- cess flows with a specific purpose throughout the book) and deploys it to a hosted environment. This package will work together with the environment-specific configuration (which keeps secrets, such as database connection strings and API keys, safe, and is dis- cussed in chapter 3) to serve the application. Part 1 is dedicated to the build aspect of Build First: ■ Chapter 2 explains build tasks, teaching you how to write tasks and configure them using Grunt, the task runner you’ll use as a build tool throughout part 1. Build Build concerns Code Distributions Which distribution depends on target environment and deployment needs Ready for deployment Run specific tasks again whenever a part of your source code changes No deployment required, but it has its own environment configuration Environment-specific Tasks Distribution Debug Deployment Deployment concerns Configuration Deployment Distribution Release Environments Local Production Testing Watching Compilation Optimization Release notes App server Ch 2 Ch 4 Ch 4 Ch 3 Monitoring Figure 1.2 High-level view of the processes in Build First: Build and Deployment
11 Handling application complexity and design ■ Chapter 3 covers environments, how to securely configure your application, and the development work flow. ■ Chapter 4 discusses tasks you should perform during release builds. Then you’ll learn about deployments, running tests on every push to version control, and production monitoring. BENEFITS OF A BUILD PROCESS Once you’re done with part 1, you’ll feel confident performing the following opera- tions on your own applications: ■ Automating repetitive tasks such as compilation, minification, and testing ■ Building an icon spritesheet so that HTTP requests for iconography are reduced to a single one. Such spriting techniques are discussed in chapter 2, as well as other HTTP 1.x optimization tricks, as a means to improve page speed and application delivery performance. ■ Spinning up new environments effortlessly and neglecting to differentiate between development and production ■ Restarting a web server and recompiling assets automatically whenever related files change ■ Supporting multiple environments with flexible, single-step deployments The Build First approach eliminates manual labor when it comes to tedious tasks, while also improving your productivity from the beginning. Build First acknowledges the significance of the build process for shaping a maintainable application iteratively. The application itself is also built by iteratively chipping away at its complexity. Clean application design and architecture are addressed in part 2 of this book, which covers complexity management within the application, as well as design consid- erations with a focus on raising the quality bar. Let’s go over that next. 1.4 Handling application complexity and design Modularization, managing dependencies, understanding asynchronous flow, carefully following the right patterns, and testing are all crucial if you expect your code to work at a certain scale, regardless of language. In part 2 you’ll learn different concepts, techniques, and patterns to apply to your applications, making them more modular, focused, testable, and maintainable. Figure 1.3, viewed from the top down, shows the progression we’ll follow in part 2. MODULARITY You’ll learn how to break your application into components, break those components down into modules, and then write concise functions that have a single purpose inside those modules. Modules can come from external packages, developed by third par- ties, and you can also develop them yourself. External packages should be handled by a package manager that takes care of versioning and updates on your behalf, which eliminates the need to manually download dependencies (such as jQuery) and auto- mates the process.
12 CHAPTER 1 Introduction to Build First As you’ll learn in chapter 5, modules indicate their dependencies (the modules they depend upon) in code, as opposed to grabbing them from the global namespace; this improves self-containment. A module system will take advantage of this information, being able to resolve all of these dependencies; it’ll save you from having to maintain long lists of <script> tags in the appropriate order for your application to work correctly. Modularity Improves testability and maintainability Design Architecture concerns Asynchronous code Services, events, timing External package managers Dependencies are injected into consuming modules Dependencies might be local, too (also injected) Component Shared rendering in the server and client Test individual modules in isolation, faking their dependencies Test the application as a whole, including services, dependencies, and client-side HTML/CSS/JavaScript Types of asynchronous flow control techniques Automates updates and isolates external dependencies Component Dependency A Dependency B Module A Module B Module C MVC architecture Asynchronous operations Model View Controller Services Events Callbacks Promises Events Generator Testing practices Testability concerns Unit tests Integration tests Application Dependencies Services Modules Browser DOM Module A Module B Ch 5 Ch 7 Ch 8 Ch 6 Figure 1.3 Application design and development concerns discussed in part 2
13 Handling application complexity and design DESIGN You’ll get acquainted with separation of concerns and how to design your application in a layered way by following the Model-View-Controller pattern, further tightening the modularity in your applications. I’ll tell you about shared rendering in chapter 7, the technique where you render views on the server side first, and then let the client side do view rendering for subsequent requests on the same single-page application. ASYNCHRONOUS CODE I’ll teach you about the different types of asynchronous code flow techniques, using callbacks, Promises, generators, and events and helping you tame the asynchronous beast. TESTING PRACTICES In chapter 5 we discuss everything about modularity, learn about closures and the module pattern, talk about module systems and package managers, and try to pin- point the strengths found in each solution. Chapter 6 takes a deep dive into asynchro- nous programming in JavaScript. You’ll learn how to avoid writing a callback soup that will confuse you a week from now, and then you’ll learn about the Promise pattern and the generators API coming in ES6. Chapter 7 is dedicated to patterns and practices, such as how to best develop code, whether jQuery is the right choice for you, and how to write JavaScript code you can use in both the client and the server. We’ll then look at the Backbone MVC framework. Keep in mind that Backbone is the tool I’ll use to introduce you to MVC in JavaScript, but it’s by no means the only tool you can use to this end. In chapter 8 we’ll go over testing solutions, automation, and tons of practical examples of unit testing client-side JavaScript. You’ll learn how to develop tests in JavaScript at the unit level by testing a particular component and at the integration level by testing the application as a whole. The book closes with a chapter on REST API design, and the implications of con- suming a REST API in the front end, as well as a proposed structure to take full advan- tage of REST. PRACTICAL DESIGN CONSIDERATIONS The book aims to get you thinking about practical design considerations made when building a real application, as well as deciding thoughtfully on the best possible tool for a job, all the while focusing on quality in both your processes and the application itself. When you set out to build an application, you start by determining the scope, choosing a technology stack, and composing a minimum viable build process. Then you begin building the app, maybe using an MVC architecture and sharing the view rendering engine in both the browser and the server, something we discuss in chapter 7. In chapter 9 you’ll learn the important bits on how to put an API together, and you’ll learn how to define backing services that will be used by both the server-side view controllers and the REST API. Figure 1.4 is an overview of how typical Build First applications may be organized.
14 CHAPTER 1 Introduction to Build First BUILD PROCESS Beginning at the upper left, figure 1.4 outlines how you can start by composing a build process which helps consolidate a starting point for your architecture, by decid- ing how to organize your code base. Defining a modular application architecture is Build process Organization and workflow concerns Design Architecture concerns REST API Input sanitizing, HTTP responses Services Contains domain logic Technology stack Application architecture Solid directory structure helps organize an application Consolidate architecture Ensure our code works as expected, on every push to version control Ensure our environment is fault-tolerant and provides error reporting capabilities Build + watch Testing Deployments Model View Shared rendering in server and browser Controller Organization Directory structure Battle testing Reliability concerns API queries service layer Service layer queries database Gets data HTML response Query service layer Query REST API JSON response Continuous testing Unit testing Integration testing Deployment Clusters Logging Monitoring Continuous integration Fault-tolerance Db Browser Server Figure 1.4 Pragmatic architectural considerations
15 Diving into Build First the key to a maintainable code base, as you’ll observe in chapter 5. The architecture is then consolidated by putting in place automated processes that provide you with con- tinuous development, integration, and deployment capabilities. DESIGN AND REST API Designing the application itself, including a REST API that can effectively increase main- tainability, is only possible by identifying clear cut components with clear purposes so they’re orthogonal (meaning that they don’t fight for resources on any particular con- cern). In chapter 9 we’ll explore a multi-tiered approach to application design which can help you quickly isolate the web interface from your data and your business logic by strictly defining layers and the communication paths between those layers. BATTLE TESTING Once a build process and architecture are designed, battle testing is where you’ll get drenched in reliability concerns. Here you’ll plumb together continuous integration, where tests are executed on every push to your version control system, and maybe even continuous deployments, making several deployments to production per day. Last, fault tolerance concerns such as logging, monitoring, and clustering are dis- cussed. These are glanced over in chapter 4, and help make your production environ- ment more robust, or (at worst) warn you when things go awry. All along the way, you’ll write tests, adjust the build process, and tweak the code. It will be a terrific experiment for you to battle test Build First. It’s time you get comfort- able and start learning specifics about the Build First philosophy. 1.5 Diving into Build First Quality is the cornerstone of Build First, and every measure taken by this approach works toward the simple goal of improving quality in both your code and the structure surrounding it. In this section, you’ll learn about code quality and setting up lint, a code quality tool, in your command line. Measuring code quality is a good first step toward writing well-structured applications. If you start doing it early enough, it’ll be easy to have your code base conform to a certain quality standard, and that’s why we’ll do it right off the bat. In chapter 2, once you’ve learned about lint, I’ll introduce you to Grunt, the build tool you’ll use throughout the book to compose and automate build processes. Using Grunt allows you to run the code quality checks as part of a build, meaning you won’t forget about them. Grunt: the means to an end Grunt is used intensively in part 1 and in some of part 2 to drive our build processes. I chose Grunt because it’s a popular tool that’s easy to teach and satisfies the most needs: ■ It has full support for Windows. ■ Little JavaScript knowledge is required and it takes little effort to pick up and run.
16 CHAPTER 1 Introduction to Build First Lint is a code-quality tool that’s perfect for keeping an interpreted program—such as those written in JavaScript—in check. Rather than firing up a browser to check if your code has any syntax errors, you can execute a lint program in the command line. It can tell you about potential problems in your code, such as undeclared variables, miss- ing semicolons, or syntax errors. That being said, lint isn’t a magic wand: it won’t detect logic issues in your code, it’ll only warn you about syntax and style errors. 1.5.1 Keeping code quality in check Lint is useful for determining if a given piece of code contains any syntax errors. It also enforces a set of JavaScript coding best practice rules, which we’ll cover at the begin- ning of part 2, in chapter 5, when we look at modularity and dependency management. Around 10 years ago Douglas Crockford released JSLint, a harsh tool that checks code and tells us all the little things that are wrong with it. Linting exists to help us improve the overall quality of our code. A lint program can tell you about the poten- tial issues with a snippet, or even a list of files, straight from the command line, and this has the added benefit that you don’t even have to execute the code to learn what’s wrong with it. This process is particularly useful when it comes to JavaScript code, because the lint tool will act as a compiler of sorts, making sure that to the best of its knowledge your code can be interpreted by a JavaScript engine. On another level, linters (the name given to lint programs) can be configured to warn you about code that’s too complex, such as functions that include too many lines, obscure constructs that might confuse other people (such as with blocks, new statements, or using this too aggressively, in the case of JavaScript), or similar code style checks. Take the following code snippet as an example (listed as ch01/01_lint- sample in the samples online): function compose_ticks_count (start) { start || start = 1; this.counter = start; return function (time) { ticks = +new Date; return ticks + '_' + this.counter++ } } (continued) It's important to understand that Grunt is a means to an end, a tool that enables you to easily put together the build processes described in this book. This doesn’t make Grunt the absolute best tool for the job, and in an effort to make that clear, I’ve com- piled a comparison between Grunt and two other tools: *npm, which is a package manager that can double as a lean build tool, and *Gulp, a code-driven build tool that has several conventions in common with Grunt. If you’re curious about other build tools such as Gulp or using npm run as a build system, then you should read more about the topic in appendix C, which covers picking your own build tool.
Another Random Scribd Document with Unrelated Content
General Meusnier, who had been wounded near Cassel, on the 7th, died on the 13th, and was buried the next day, within the new fortifications, all the officers of the garrison, with the members of the convention and clubs, attending. Some fire ships were now completed, which a Dutch engineer had conducted from Holland, to be employed by the besiegers in burning the bridge of boats over the Rhine. It was thought, however, that their explosion would damage the city unnecessarily, and they were rejected. In the night of the 15th, one of these floated down the river, whether by accident, or by the connivance of the inventor, is not known; the inhabitants were in the utmost terror, but it struck against the quay, and, being immediately boarded, did no damage. The trenches were opened, in the night of the 16th and 17th, but, the workmen having been ill conducted, were not covered in, at day- light, and were compelled to retire, leaving their implements behind them. Two nights afterwards, the work was renewed in good order and without loss, the King of Prussia, his sons and the Duke of Brunswick surveying them from a neighbouring height. The first balls fell in a street near one of the gates, and all that part of the town was presently deserted. The 24th was a distressful day for the inhabitants. Four days before, the King of Prussia had sent a general passport for such as chose to come out, and 1500 persons, chiefly women and children, had accepted his offer. A short time after the gate had been opened, dismay was spread through the whole city by an account, that the Prussians would suffer no more to pass and the French none to return. The bridge was covered with these unhappy fugitives, who had no food, or shelter, and who thought themselves within reach of the Hockheim batteries, that played furiously upon the city. Two children lost their senses through fright. At length, the French soldiers took compassion upon them; they carried several persons into the city under their cloaks, and, the next day, their remonstrances against the inhumanity of the German clubbists, who
had shut the gates against this defenceless crowd, obliged them to permit the return of the whole number. For several succeeding nights, the garrison made sorties, with various effect, interrupting, but not preventing the completion of the parallel. At sunset, on the 27th, the besiegers began a dreadful cannonade and bombardment. On this night, the steeple of the church of Notre Dame caught fire; and during the alarm, excited by an immense volume of flame, arising in the midst of the city, the Austrians completely carried the French posts, near Weissenau. The next night was equally terrible to the inhabitants; the flames caught several parts of the city, amongst others the cathedral; some of the magazines took fire, and eleven hundred sacks of corn were burned. The church, formerly belonging to the Jesuits, was much injured. The French, intending to retaliate their last surprise upon the Austrians, made a fruitless attack upon the Weissenau redoubt. On the 29th of June, at mid-day, the French were driven from a point of land, near the Main, called the Bleiau. In this affair, a vessel, with 78 Prussians on board, drove from her anchor, owing to the unskilfulness of the crew, and, during a fire, by which eight men were killed, made towards the city. The Prussians were taken prisoners, and exchanged the next day. At night, the bombardment was renewed; the Domprobstei, or palace of the Provost, was burned and several of the neighbouring residences; in other parts of the city, some houses were reduced to ashes. The next night, the church of the Franciscans and several other public buildings were destroyed. A dreadful fire, on the night of the 2d and 4th of June, consumed the chapel of St. Alban. Families in the southern part of the city now constantly passed the night in their cellars; in the day-time, they ventured into their usual apartments; for the batteries of the besiegers were by far the most terrible, at night, when the whole city was a sufficient mark for them, though
their works could scarcely be discerned by the garrison. In the day- time, the exactness of the French gunners frequently did great injury to the batteries, which, at night, were repaired and used with equal effect against the city. St. Alban's fort was now demolished, so that the besieged withdrew their cannon from it. Elizabeth fort was also much damaged. A strong work, which the French had raised, in prolongation of the glacis, divided the opinions of the Prussian engineers. Some thought it should be preserved, when taken, because it would command part of the town; others, that it should be demolished. The latter opinion prevailed, and, in the night of the 5th and 6th, General Manstein was ordered to make the attack with three battalions. He perfectly succeeded, as to the nearest part of the work; but the other, on account of its solid foundation, could not be entirely destroyed. In the mean time, two battalions were sent, under cover of the darkness, to attack the Zahlbach fort, a part of which they carried by storm; but the reinforcements, immediately supplied by the garrison, obliged them to retire. Two Prussian officers were killed; one wounded, and another, with one-and-thirty men, taken. The Prussians lost in all 183 men; the French had twelve killed and forty-seven wounded. On the 6th of July, the French repaired the damaged fort, the distance of it from the Prussians preventing the latter from hindering them. At night, General Kleist carried the fort, at Zahlbach, by a second attack, and demolished it; at the same time, some batteries of the second parallel were perfected. The French could not support the loss of this fort; on the 7th, they attacked the scite; carried it, after a severe contest; and rebuilt it. At night, they were driven back again and the fort entirely destroyed. In the same night they were driven from Kostheim, after a furious battle, by the Prussian General Schonfield. During this engagement, the rapid succession of flashes and explosion of bombs seemed to fill the air with flame. A Prussian
detachment having been posted on the road to Cassel, in order to prevent the garrison of that place from sending succour to Kostheim, this road was so strongly bombarded by the French, that seven bombs were frequently seen in the air at once. The loss was great, on both sides, in this engagement, after which the Council in the city resolved, to make no more attempts upon Kostheim, on account of the distance. The following night, the fire was less than usual, but a few bombs and grenades fell in the city, where the inhabitants had now learned to extinguish such as grounded, before their fusees were consumed. They also formed themselves into parties for the ready suppression of fires. The next morning, the garrison saw the works of the besiegers brought to within two hundred and fifty paces of the walls. About this time, the sickliness of the garrison became apparent, and General D'Oyré informed the Council, that, on account of this and of the fatiguing service of the works, he feared the defence could not be much longer continued. He lamented, that the troops of the line were so few, and the others so inexperienced. For several nights, the works of the besiegers were eagerly pushed, but still they were not so forward, as had been expected. Some of the besieging corps began to be sickly; the King of Prussia having resolved to employ no more labourers, it was reckoned, that the soldiers, for eight-and-forty hours of work, had only eighteen of rest. On the other hand, they were assured, that the garrison must be equally fatigued, since, in such an extensive fortification, none could be left long unemployed. The French had been, for some time, busied in forming what is called a Fleche at the head of one of their forts, and this was thought necessary to be destroyed. It was attacked in the night of the 12th and 13th by the Austrians; but so much time was passed in their operations, that the French fell upon them, in great force,
about two in the morning, and beat them away, with loss. The Austrians were as little employed as possible in services of this fort. On the 13th of July, another battery was stormed by the Prussians; but, as the officer, unlike the Austrians, advanced with too little caution, his party was much hurt by some pieces of concealed cannon, and the enterprise failed. The night of the 13th and 14th was passed in much agitation by the garrison and inhabitants. Several of the public buildings were set fire to and burned by grenades. The works of the besiegers were now greatly advanced. The garrison made five sorties in this night, and were repulsed in all, losing an hundred men, while the besiegers lost eight killed and one-and-thirty wounded. On the 14th of July, a cessation of arms took place from seven o'clock in the morning till one. In the city, the French celebrated their annual fête; General d'Oyré and the troops took the oath, and Merlin delivered an address to them. In the Austrian camp, the Prince de Condé was received with a feu de joye. During this cessation, the soldiers upon the different outposts entered into conversation with each other, and the French boasted of the difficulties they laboured under from the length of the siege. At night, an affair at the Fleche cost the allies, who succeeded in part, ninety men; the French confessed, that this work cost them in all three hundred. The inhabitants of the city were again greatly alarmed, their streets being covered with a shower of grenades. The laboratory and a part of the Benedictine abbey were burned, and two explosions took place at the former. The whole city shook with each report, and, in the nearer parts, all the windows were broken and the doors burst open. The remainder of the hay and straw was consumed in this fire; the whole stock of other forage was reduced to a sufficiency for four days; and the surgeon's stores were much damaged.
Still the Fleche prevented the besiegers from completing their second parallel. It was, therefore, again attacked, on the night of the 16th and 17th, Prince Louis Ferdinand of Prussia commanding at the assault, in which he was one of twelve officers wounded. The Fleche was then completely carried. The next night was very industriously spent by the besiegers in forming new batteries, and those of the second parallel were raised, before there were cannon enough at hand to place upon them. The French took advantage of this, and brought a part of theirs to bear, so as to enfilade the parallel, with great effect; the Prussians almost immediately losing an officer and forty men. In the city, the sick had now increased so much, that six hundred men were brought from Cassel, on the 17th, to re-inforce the garrison. On the 18th, the commandant informed the Council, that there was a want of fodder and such a loss of horses, by desertion, that there were not cavalry enough left for service. The soldiers, who knew the deficiency of medicines and other means of relief for the wounded, were unwilling to be led to sorties. Though corn had not failed, flour, it appeared, soon would, for some of the mills had been rendered unserviceable, for the present, by shot, and others were deserted by the millers. At night, after an unsuccessful attempt upon the Fleche, it was resolved, that the garrison, which had hitherto scarcely suffered a night to pass, without making some sorties, should, for the future, adhere solely to defensive measures. Some engineers proposed to abandon the whole line of forts, and others, that two of the largest should be blown up. The General and Council, at length, confessed, that they could not continue the defence, and assured the inhabitants, who had declared themselves in their favour, that a longer delay of the surrender would produce a more severe disposition of the besiegers towards them, without increasing the chance of escaping it.
A negotiation, relative to the surrender, was now begun by D'Oyré, in a letter, which partly replied to one from the Prussian commander Kalkreuth, upon the subject of the departure of aged persons and children from the city. Their correspondence continued till the 20th, and several letters were exchanged, chiefly upon the question of the removal, or detention of the inhabitants, who had attached themselves to the French; it was then broken off, upon a disagreement, as to this and some other points. The firing, on both sides, had in the mean time continued, and the besiegers carried on the trenches, though these were now such an easy mark for the garrison, that they lost an officer and five-and-twenty men, in the night of the 19th and 20th. The next night, the Dominicans' church in the city took fire, and six French soldiers were buried under its ruins. Upon a renewal of the intercourse, the fire slackened, on the 21st; but, on some delays in the negotiation, was threatened to be recommenced. At length, the conditions of the surrender were settled, and the negotiation signed, on the 22d of July, by the two Generals Kalkreuth and D'Oyré; the former having rendered the capitulation somewhat easier than was expected for the garrison, because the Duke of Brunswick had only nineteen thousand men to cover the siege, and Custine had forty thousand, which were near enough to attack him. General Kalkreuth's orders are supposed to have been to obtain possession of the place, upon any terms, that would give it him quickly. At this time, the garrison, which, at the commencement of the siege, had consisted of 22,653 men, was reduced to 17,038, having had 1959 killed, 3334 wounded, or rendered unserviceable by sickness, and having lost 322 by desertion. The loss of the besiegers is stated at about 3000 men. The consumption of ammunition, on the part of the French, was found to have been
681,850 pounds of powder, 106,152 cannon balls, 10,278 bombs, 6,592 grenades, 44,500 pounds of iron, 300,340 musquet cartridges; and, during the siege, 107 cannon either burst, or were rendered unserviceable by the besiegers' shot. Towards the conclusion, sixty cannon also became useless by the failure of balls of the proper calibre. On the 24th and 25th, the garrison marched out, Merlin leading the first column of 7500 men. The members of the Clubs, who would have gone out with the troops, were pointed out by the other inhabitants and detained; but the Elector had the magnanimity to think of no other retaliation, than their imprisonment in a tower, near the Rhine, where they have since remained. There was now leisure to examine the city, and it was found, that six churches were in ruins; that seven mansions of the nobility had been burned, and that very few houses had escaped, without some damage. The surrounding grounds were torn up by balls and batteries. The works of Cassel were surrendered entire to the conquerors, and are an important addition to the strength of Mentz, already reckoned one of the strongest and largest fortifications in Europe. Between Cassel and the ruins of Kostheim not a tree was to be seen. All the neighbouring villages were more, or less, injured, being contended for, as posts, at the commencement of the siege; and the country was so much disfigured, that the proprietors of lands had some difficulty to ascertain their boundaries.
MENTZ. Something has been already said of the present condition of this city: upon a review it appears, that from the mention of churches, palaces, burgesses, quays and streets, we might be supposed to represent it as a considerable place, either for splendour, or commerce, or for having its middle classes numerously filled. Any such opinion of Mentz will be very incorrect. After two broad and somewhat handsome streets, all the other passages in the city are narrow lanes, and into these many of the best houses open, having, for the most part, their lower windows barricadoed, like those of Cologne. The disadvantage, with which any buildings must appear in such situations, is increased by the neglected condition of these; for a German has no notion, that the outside of his house should be clean, even if the inside is so. An Englishman, who spends a few hundred pounds in a year, has his house in better condition, as to neatness, than any German nobleman's we saw; a Dutchman, with fifty pounds a year, exceeds both. The Elector's palace is a large turreted building of reddish stone, with one front towards the Rhine, which it commands in a delightful point of view; but we did not hear, that it was so much altered, by being now used as a barrack, as that its appearance can formerly have been much less suitable than at present to such a purpose. On the quay there is some appearance of traffic, but not much in the city; so that the transfer of commodities from vessels of other districts to those of the Electorate may be supposed to contribute great part of the show near the river. The commerce is not sufficient to encourage the building of warehouses over the quay. The vessels are ill rigged, and the hulls are entirely covered with pitch, without paint. About thirty of these, apparently from forty to seventy tons burthen, were lying near the quay; and the war could scarcely have diminished their usual number, so many being employed in carrying stores for the armies.
The burgesses are numerous, and have some privileges, which render their political condition enviable to the other inhabitants of the Electorate. But, though these have invited manufacturers, and somewhat encouraged commerce, there is not wealth enough in the neighbouring country, to make such a consumption, as shall render many traders prosperous. In point of wealth, activity and address, the burgesses of Mentz are much below the opinion, which must be formed, while German cities are described and estimated by their importance in their own country, rather than by a comparison of their condition with that of others. A trader, it will be allowed, is at least as likely to appear to advantage in his business as in any other state. His intelligence may surely be, in some degree, judged of by those, who deal with him; and that we might know something of those of Mentz, we passed some of the little time we were left to ourselves in endeavouring to buy trifles at their shops. The idleness and inadvertence we generally saw are difficult to be conceived; perhaps, the trouble, experienced in purchasing a book, may give an idea of them. We wanted the German pamphlet, from which most of the above-mentioned particulars of the siege are extracted; and, as it related to a topic so general within the place, we smiled, when our friends said they would assist us to procure it, during a walk. Two booksellers, to whom we applied, knew nothing of it; and one supposed, that an engraved view of the works would do quite as well. Passing another shop, a young German gentleman enquired for it of the master, who was at the door, and heard, that we might have it, upon our return, in half an hour. The door, when we came back, was shut, and no knocking could procure it to be opened; so that we were obliged to send into the dwelling-house. When the shopman came, he knew nothing of the book; but, being assured that his master had promised it, went away, and returned with a copy in sheets. We paid for this, and left it to be sewed, which was agreed to be done, in three hours. At that time, it was not finished, but might be had in another hour; and, after that hour, it was again promised, within two. Finally, it could not be had, that night, but would be ready in the morning, and, in the morning, it
was still unfinished; we then went to Franckfort without it, and it was sent after us by a friend. This was the most aggravated instance we saw of a German trader's manners; but something like it may be almost every where met with. From such symptoms and from the infrequency of wealth among the middle classes it is apparent, that Mentz could not have been important, as to commerce, even if there had been no siege, which is here mentioned as the cause of all deficiencies, and certainly is so of many. The destruction of property, occasioned by it, will not be soon remedied. The nobility have almost forsaken a place, where their palaces have been either destroyed, or ransacked; the Prince has no residence there; some of the Germans, who emigrated on account of the last siege, fled into France; the war-taxes, as well as the partial maintenance of the garrison, diminish what property remains; and all expenditure is upon a reduced footing. The contribution of the inhabitants towards a support of the garrison is made by the very irksome means of affording them lodging. At the best houses, the doors are chalked over with the names of officers, lodged in them; which the servants dare not efface, for the soldiers must know where to find their officers. In a family, whom we visited, four officers and their servants were quartered; but it must be acknowledged, that the former, so far from adding to this inconvenience by any negligent conduct, were constantly and carefully polite. We, indeed, never saw Prussian officers otherwise; and can testify, that they are as much superior to those Austrians in manners and intelligence, as they are usually said to be in military qualities. Another obstruction, which the siege has given to the prosperity of Mentz, consists in the absence of many members of the Noble Chapter; an institution, which, however useless, or injurious to the country, occasions the expenditure of considerable sums in the capital. That of Mentz is said to be one of the richest of many similar Chapters in Germany. From such foundations the younger sons of
noble families derive sometimes very ample incomes, and are but little restricted by their regulations from any enjoyment of temporal splendour. Their carriages and liveries vie with those of the other attendants at Court; they are not prohibited from wearing the ornaments of orders of knighthood; are very little enjoined to residence; are received in the environs of the Court with military honours, and allowed to reside in their separate houses. They may wear embroidery of gold, and cloths of any colours, except scarlet, or green, which, as well as silver lace, are thought too gay. Being thus permitted and enabled to become examples of luxury, their residence in any city diffuses some appearance of prosperity over it. One of the largest buildings in Mentz is the arsenal, which fronts towards the river, and attracts the attention of those, who walk upon the quay, by having armed heads placed at the windows of the first floor, which seem to frown, with Roman sternness, upon the passenger. In one of the principal rooms within, a party of figures in similar armour are placed at a council-board. We did not hear who contrived them; but the heads in the windows may be mistaken for real ones, at the distance of fifty yards. The Elector of Mentz, who is chosen by a Chapter of twenty-four Canons, and is usually one of their number, is the first ecclesiastical Prince in the empire, of which he is also the Arch-chancellor and Director of the Electoral College. In the Diet, he sits on the right hand of the Emperor, affixes the seal of the Empire to its decrees, and has afterwards the custody of them among the archives. His revenues, in a time of peace, are nearly 200,000l. annually; but, during a war, they are much less, a third part of them arising from tolls, imposed upon the navigation of the Rhine. The vineyards supply another large part; and his subjects, not interested in them, are but little taxed, except when military preparations are to be made; the taxes are then as direct as possible, that money may be immediately collected.
The fortifications of his chief city are as much a misfortune to his country as they are an advantage to the rest of the Empire. Being always one of the first objects, on this side of the Rhine, since an enemy cannot cross the river, while so considerable a fortress and so large a garrison as it may contain, might, perhaps, check their return, the Electorate has been often the scene of a tedious warfare. From the first raising of the works by Louis the Fourteenth, their strength has never been fully tried. The surrender in 1792 was partly for the want of a proper garrison, and partly by contrivance; even in 1793, when the defence was so furious and long, the garrison, it is thought, might have held out further, if their stores had been secured in bomb-proof buildings. A German garrison, supported by an army, which should occupy the opposite bank of the Rhine, might be continually reinforced and supplied, so as to be conquered by nothing but the absolute demolition of the walls. The bridge of boats over the Rhine, which, both in peace and war, is so important to the city, is now in a much better state than the French found it, being guarded, at the eastern end, by the fortifications of Cassel. Notwithstanding its great length and the rapidity of the river, it is so well constructed, as to be much less liable to injury, than might be supposed, and would probably sustain batteries, which might defeat every attempt at destroying it by fireships. It is 766 feet long, and wide enough for the passage of two carriages at once. Various repairs, and the care of a daily survey, have continued it, since 1661, when it was thrown over the river. The practice of modifying the names of towns so as to incorporate them separately with every language, is no where more remarkable than with respect to those of Germany, where a stranger, unless he is aware of them, might find the variations very inconvenient. The German name for what we call Mentz, is Maynz; the French, which is most used, Mayence; and the Italian Magontio, by descent from the Roman Magontiacum. The German synonym for Liege is Luttich; for Aix la Chapelle, Achen; for Bois le Duc, Herzogenbusch; and for
Cologne, Cöln, which is pronounced Keln. The name borne by every town in the nation to which it belongs, should surely be its name, wherever it is mentioned; for the same reason, that words, derived into one language from another, are pronounced according to the authority of their roots, because the use of the primary term is already established, and there can never be a decision between subsequent varieties, which are cotemporary among themselves, and are each produced by the same arrogance of invention. FRANCKFORT. We came hither by means of a passage boat, which we were told would shew something of the German populace, but which displayed nothing so much as the unskilfulness of the German sailors. Though they make this voyage, every day, they went aground in the even stream of the Maine, and during the calmest weather; fixing the vessel so fast by their ill-directed struggle to get off, that they were compelled to bring the towing horses to the side and tug backward with the stream. There were an hundred people in the boat; but the expedient of desiring them to remove from the part, which was aground, was never used. We heard, that they seldom make the voyage, without a similar stoppage, not against any shifting sand, but upon the permanent shelves of the river. The distance is about four-and-twenty miles, but we were nine hours in reaching Franckfort, the environs of which afford some symptoms of a commercial and opulent city, the banks of the Maine being covered for nearly the last mile with country seats, separated from each other by small pleasure grounds. There are gates and walls to Franckfort, but the magistrates do not oppress travellers by a military examination at their entrance. Having seen the worthlessness of many places, which bear
ostentatious characters either for splendour or trade, we were surprised to find in this as much of both as had been reported. The quays were well covered with goods and labourers; the streets nearest to the water are lined with shops, and those in the middle of the city with the houses of merchants, of which nearly all are spacious, and many magnificent. Some, indeed, might be called palaces, if they had nobility for their tenants; but, though the independence, which commerce spreads among the middle classes, does not entirely deter the German nobility from a residence here, the finest houses are the property of merchants. In our way to the Cigne Blanc, which is one of the best inns, we passed many of so good an appearance, that it was difficult to believe there could be better in a German city. But Franckfort, which is the pride of Germany, in this respect, has probably a greater number of large inns than any other place of equal extent in Europe. The fairs fill these, twice in a year, for three weeks, at each time; and the order, which is indispensible then, continues at other periods, to the surprise and comfort of strangers. This city has been justly described by many travellers; and Doctor Moore has treated of its inhabitants with the ease and elegant animation of his peculiar manner. We shall not assume the disadvantage of entering upon the same subject after him. The inhabitants of Franckfort are very distinct, as to manners and information, from the other Germans; but they are so far like to those of our own commercial cities, that one able account leaves scarcely any thing new to be seen, or told, concerning them. All their blessings of liberty, intelligence, and wealth are observed with the more attention, because they cannot be approached, except through countries afflicted by arbitrary power, ignorance and poverty. The existence of such a city, in such a situation, is little less than a phenomenon; the causes of which are so various and minute as to make the effect, at first sight, appear almost accidental. The jealousy of the neighbouring Princes towards each other, is the
known, and, certainly, the chief cause of its exterior protection against each; the continuance of its interior liberties is probably owing to the circumstance, which, but for that jealousy, would expose it to subjection from without,—the smallness of its territory. Where the departments of government must be very few, very difficult to be rendered expensive to the public, and very near to their inspection, the ambition of individuals can be but little tempted to contrive encroachments upon the community. So complexly are the chief causes of its exterior and interior independence connected with each other. As to the first of these, it may, perhaps, be replied, that a similar jealousy has not always been sufficient to protect similar cities; and Dantzick is the recent instance of its insufficiency. But the jealousy, as to Dantzick, though similar, was not equal to this, and the temptation to oppose it was considerably greater. What would the most capable of the neighbouring Princes gain by the seizure of Franckfort? A place of strength? No. A place capable of paying taxes? Yes; but taxes, which would be re-imposed upon commodities, consumed partly by his own subjects, whose property is his own already, and partly by those of his neighbours, to whose jealousy they would afford an additional and an unappeasable provocation. Dantzick, on the contrary, being a seaport, was, if not strong, capable of supplying strength, and might pay taxes, which should not fall entirely upon its neighbours, but upon the distant countries, that traffick with it. And even to these considerations it is unnecessary to resort, unless we can suppose, that despotism would have no effect upon commerce; a supposition which does not require to be refuted. If a severe taxation was introduced here, and, in so small a district, taxation must be severe to be productive; if such a taxation was to be introduced, and if the other advantage of conquest, that of a forcible levy of soldiers, was attempted, commerce would vanish in silence before the oppressor, and the Prince, that should seize the liberties of Franckfort, would find nothing but those liberties in his grasp.
On the other hand, what are the advantages of permitting the independence of such a city to the sovereigns, who have the power of violating it? Those of a neutral barrier are well known, but apply only to military, or political circumstances. The others are the market, which Franckfort affords, for the produce and manufactures of all the neighbouring states; its value as a banking depôt and emporium, in which Princes may place their money, without rendering it liable to the orders of each other, or from which they may derive loans, by negotiating solely and directly with the lenders; its incapacity for offensive measures; and its usefulness as a place of meeting to themselves, or their ministers, when political connections are to be discussed. That the inhabitants do enjoy this independence without and freedom within, we believe, not because they are asserted by treaties, or political forms; of which the former might not have survived the temporary interests, that concluded them, and the latter might be subdued by corruption, if there were the means of it; but because they were acknowledged to us by many temperate and discerning persons, as much aloof from faction, as they were from the affectation, or servility, that sometimes makes men boast themselves free, only because they have, or would be thought to have, a little share in oppressing others. Many such persons declared to us, that they had a substantial, practical freedom; and we thought a testimony to their actual enjoyments more valuable than any formal acknowledgments of their rights. As to these latter securities, indeed, Franckfort is no better provided than other imperial cities, which have proved their inutility. It stands in the same list with Cologne, but is as superior to it in government as in wealth. The inhabitants having had the good sense to foresee, that fortifications might render them a more desirable prize to their neighbours, at the same time that their real protection must depend upon other means, have done little more than sustain their antient walls, which are sufficient to defend them against a surprise by small parties. They maintain no troops, except a few companies of city-
guards, and make their contributions to the army of the Empire in specie. These companies are filled chiefly with middle-aged men, whose appearance bespeaks the plenty and peacefulness of the city. Their uniforms, blue and white, are of the cut of those in the prints of Marlborough's days; and their grenadiers' caps are of the same peaked sort, with tin facings, impressed with the city arms. In wars with France, the fate of Franckfort has usually depended upon that of Mentz, which is properly called the key of Germany, on the western frontier. In the campaign of 1792, Custine detached 3000 troops of the 11,000, with which he had besieged Mentz, and these reached Franckfort, early in the morning of the 22d of October. Neuwinger, their commander, sent a letter to the magistrates from Custine, demanding a contribution of two millions of florins, which, by a negotiation at Mentz, was reduced to a million and a half, for the present. Notice was accordingly given in the city, that the magistrates would receive money at four per cent. interest, and, on the 23d, at break of day, it began to flow in to the Council-house from all quarters. Part was immediately given to Neuwinger, but payment of the rest was delayed; so that Custine came himself on the 27th, and, by throwing the hostages into prison, obtained, on the 31st of October, the remainder of the first million. For the second, the magistrates gave security to Neuwinger, but it was never paid; the Convention disavowed great part of the proceedings of Custine, and the money was not again demanded. The French, during the whole of their stay, were very eager to spread exaggerated accounts of their numbers. Troops were accordingly marched out at one gate of the city, with very little parade, that they might enter with much pomp and in a longer column, at the other. The inhabitants, who were not expert at military numeration, easily believed, that the first party had joined other troops, and that the whole amounted to treble their real number. After the entry of the Prussians, this contrivance was related by prisoners.
The number of troops, left in the city by Custine, on his retirement from the neighbouring posts, in the latter end of November, was 1800 men, with two pieces of cannon. On the 28th, when the Prussian Lieutenant Pellet brought a summons to surrender, Helden, the commander, having sent to Custine for reinforcements and cannon, was answered, that no men could be spared; and that, as to cannon, he might use the city artillery. Helden endeavoured to remove this from the arsenal; but the populace, encouraged by the neighbourhood of the Prussians, rose to prevent him; and there might have been a considerable tumult, if Custine had not arrived, on the 29th, and assured the magistrates, that the garrison should retire, rather than expose the place to a siege. The city then became tranquil, and remained so till the 2d of December, when the inhabitants, being in church, first knew by the noise of cannon, that the place was attacked. General Helden would then have taken his two cannon to the gate, which was contended for, but the inhabitants, remembering Custine's promise, would permit no resistance; they cut the harness of the horses, broke the cannon wheels, and themselves opened the gates to the Prussians, or rather to the Hessians, for the advanced corps of the assailants was chiefly formed of them. About 100 fell in this attack. Of the French 41 were killed; 139 wounded; and 800 taken prisoners. The remainder of the 1800 reached Custine's army. A monument, erected without the northern gate of the city, commemorates the loss of the 100 assailants, on the spot, on which they fell. Thus Franckfort, having happily but few fortifications, was lost and regained, without a siege; while Mentz, in a period of six more months, had nearly all its best buildings destroyed, by a similar change of masters. We stayed here almost a week, which was well occupied by visits, but shewed nothing in addition to what is already known of the society of the place. Manners, customs, the topics of conversation
and even dress, differ very slightly from those of London, in similar ranks; the merchants of Franckfort have more generally the advantages of travel, than those of England, but they have not that minute knowledge of modern events and characters, which an attention to public transactions renders common in our island. Those, who have been in England, or who speak English, seem desirous to discuss the state of parliamentary transactions and interests, and to remedy the thinness of their own public topics, by introducing ours. In such discussions one error is very general from their want of experience. The faculty of making a speech is taken for the standard of intellectual power in every sort of exertion; though there is nothing better known in countries, where public speakers are numerous enough to be often observed, than that persons may be educated to oratory, so as to have a facility, elegance and force in it, distinct from the endowments of deliberative wisdom; may be taught to speak in terms remote from common use, to combine them with an unfailing dexterity of arrangement, and to invest every thought with its portion of artificial dignity, who, through the chaos of benefits and evils, which the agitation of difficult times throws up before the eye of the politician, shall be able to see no gleam of light, to describe no direct path, to discern no difference between greater and lesser evils, nor to think one wholesome truth for a confiding and an honest country. To estimate the general intellectual powers of men, tutored to oratory, from their success in the practice of it, is as absurd as to judge of corporeal strength from that of one arm, which may have been rendered unusually strong by exercise and art. Of the society at Franckfort, Messrs. Bethman, the chief bankers, seem able to collect a valuable part; and their politeness to strangers induces them to do it often. A traveller, who misses their table, loses, both as to conversation and elegant hospitality, a welcome proof of what freedom and commerce can do against the mental and physical desolation otherwise spread over the country.
The assistance, which the mutual use of languages gives to a connection between distant places, we were happy to see existing and increasing, to the advantage of England, at Franckfort. At the Messrs. Bethmans', one day, French was nearly excluded, the majority being able to converse with nine or ten English, who were there, in their own language. Of the merchants, who have not been in England, several speak English, without difficulty, and the rising generation, it is said, will be generally accomplished in it. One of the luxuries of Franckfort is a Cabinet Literaire, which is open to strangers by the introduction of members. There the best periodical publications of the Continent are received, and their titles immediately entered in a book, so that the reading is not disturbed by conversation with the librarian. It excited our shame to hear, that some contrivance had, for several months, prevented the society from receiving a very valuable English publication. After this, the Theatre may seem to require some notice. It is a modern, but not an elegant building, standing in an area, that renders it convenient of access, and nearly in the middle of the city. The interior, which has been gaudily decorated, contains a pit, three rows of boxes, that surround the audience part, and a gallery over them in the centre. It is larger than the Little Theatre in the Haymarket, and, in form, resembles that of Covent Garden, except that six or seven of the central boxes, in each tier, encroach upon the oval figure by a projection over the pit. The boxes are let by the year; the price of admission for non-subscribers, is a florin, for which they may find places in the box, engaged by their friends, or in the pit, which is in the same proportion of esteem as that at an Opera- house. The performances are plays and operas alternately; both in German; and the music of the latter chiefly by German composers. The players are very far beneath mediocrity; but the orchestra, when we heard it, accorded with the fame of German musicians, for spirit
and precision. In these qualities even the wandering parties, that play at inns, are very seldom deficient. The stage was well lighted, but the other parts of the theatre were left in duskiness, which scarcely permitted us to see the diamonds, profusely worn by several ladies. Six o'clock is the hour of beginning, and the performances conclude soon after nine. The Cabinet Literaire and the Theatre are the only permanent places of public amusement at Franckfort, which is, however, in want of no more, the inhabitants being accustomed to pass much of their time in friendly parties, at their houses. Though wealth is, of course, earnestly and universally sought for in a place purely mercantile, we were assured, that the richest persons, and there are some, who have above half a million sterling, find no more attention in these parties than others. This was acknowledged and separately boasted of by some of the very rich, and by those who were comparatively poor. We are so far able to report it for true, as that we could never discern the least traces of the officiousness, or subserviency that, in a corrupt and debased state of society, frequently point to the wealthiest individuals in every private party. These and many other circumstances would probably render Franckfort a place of residence for foreigners, if the magistrates, either dreading the increase of luxury, or the interference of strangers with their commerce, did not prevent this by prohibiting them from being lodged otherwise than at inns. It was with difficulty, that an English officer, acting as Commissary to some of the German regiments, lately raised upon our pay, could obtain an exemption from this rule, at the request of the Hanoverian Minister. Round the city, are several well-disposed walks, as pleasant as the flatness of the nearer country will permit; and, at intervals, along these, are the country houses of the merchants, who do not choose to go beyond the city territories, for a residence. Saxenhausen, a small town, on the other side of the Maine, though incorporated with
Franckfort, as to jurisdiction, and connected with it by a bridge, is chiefly inhabited by watermen and other labourers. We left Franckfort, after a stay of six days, fortified by a German passport from M. de Swartzhoff, the Hanoverian Minister, who obligingly advised us to be prepared with one in the native language of the Austrian officers. At Mentz, the ceremonies of examination were rendered much more troublesome than before, the Governor, General Kalkreuth, happening to be in the great square, who chose to make several travellers wait as if for a sort of review before him, though, after all, nothing was to be said but "Go to the Commandant, who will look at your passports." This Commandant was M. de Lucadou, a gentleman of considerate and polite manners, who, knowing our friends in Mentz, added to his confirmation of M. de Swartzhoff's passport an address to M. de Wilde, the Intendant of some salt mines in Switzerland, which he recommended to us to see. These circumstances are necessary to be mentioned here, because they soon led to a disagreeable and very contradictory event in our journey.
The next morning, we set out from Mentz, and were conducted by our voiturier over a summer road, on the left bank of the Rhine, then flowing with the melted snows of Switzerland. OPPENHEIM. This is the first town of the Palatinate, on arriving from the north; and it bears marks of the devastation, inflicted upon that country, in the last century, more flagrant than could be expected, when the length of the intervening time, and the complete recovery of other cities from similar disasters, are considered. Louis the Fourteenth's fury has converted it from a populous city into little more than a picturesque ruin. It was burned in 1668; and the walls, which remain in double, or sometimes in treble circles, are more visible, at a distance, than the streets, which have been thinly erected within them. Above all, is the Landscroon, or crown of the country, a castle erected on an eminence, which commands the Rhine, and dignifies the view from it, for several miles. The whole city, or rather ruin, stands on a brow, over this majestic river. The gates do not now open directly into streets, but into lanes of stone walls between vineyards and gardens, formed on the site of houses, never restored, since the fire. The town itself has shrunk from its antient limits into a few streets in the centre. In some of the interstices, corn grows up to the walls of the present houses. In others the ruins of former buildings remain, which the owners have not been tempted to remove, for the sake of cultivating their sites. Of the cathedral, said to have been once the finest on the Rhine, nearly all the walls and the tower still exist; but these are the only remains of grandeur in a city, which seems entirely incapable of overcoming in this century the wretchedness it inherits from the last.
Had the walls been as strong as they are extensive, this place might not improbably have endured a siege in the present age, having been several times lost and regained. It was surrendered to the French, without a contest, in the campaign of 1792. After their retreat from Worms, and during the siege of Mentz, it was occupied by the Prussians; and, in December 1793, when the allies retired from Alsace, the Duke of Brunswick established his head-quarters in it, for the purpose of covering the fortress. His army ovens remained near the northern gate, in July 1794, when we passed through it. In October of the same year it fell again into the hands of the French. No city on the banks of the Rhine is so well seated for affording a view of it as this, which, to the north, overlooks all its windings as far as Mentz, and, southward, commands them towards Worms. The river is also here of a noble breadth and force, beating so vehemently against the watermills, moored near the side, that they seem likely to be borne away with the current. A city might be built on the site of Oppenheim, which should faintly rival the castle of Goodesberg, in the richness, though not in the sublimity of its prospect. From hence the road leads through a fertile country of corn and vines, but at a greater distance from the river, to Worms, five or six miles from which it becomes broad, straight, and bordered with regularly-planted trees, that form an avenue to the city. Soon after leaving Oppenheim, we had the first symptom of an approach to the immediate theatre of the war, meeting a waggon, loaded with wounded soldiers. On this road, there was a long train of carriages, taking stores to some military depôt. The defacement of the Elector's arms, on posts near the road, shewed also, that the country had been lately occupied by the French; as the delay in cutting the ripe corn did, that there was little expectation of their return.
WORMS. The condition of Worms is an aggravated repetition of the wretchedness of Oppenheim. It suffered something in the war, which the unfortunate Elector, son-in-law of our James the First, provoked by accepting the kingdom of Bohemia. Louis the Fourteenth came upon it next, and, in 1669, burned every thing that could be consumed. Nothing was restored, but on that part, which was the centre of the antient city; and the walls include, as at Oppenheim, corn and vineyards upon the ground, which was once covered with houses, and which plainly appears to have been so, from the lanes that pass between, and doors that open into the inclosures. A much larger space is so covered, than at Oppenheim, for you are some time in driving from the northern gate of the old city to the first street of the present one. On the right of the road stands the skeleton of the Electoral palace, which the French burned in one of the late campaigns; and it is as curious as melancholy to observe how the signs of antient and modern desolation mingle with each other. On one hand is a palace, burned by the present French; on the other, the walls of a church, laid open by Louis the Fourteenth. The first and principal street of the place leads through these mingled ruins, and through rows of dirty houses, miserably tenanted, to the other end of the city. A few others branch from it, chiefly towards the Rhine, including sometimes the ruins, and sometimes the repaired parts of churches; of which streets, narrow, ill-paved and gloomy, consists the city of Worms. The French General, that lately wrote to Paris, "We entered the fair episcopal city of Worms," may be supposed to have derived his terms from a geographical dictionary, rather than from a view of his conquest. We were now in a place, occupied by part of the acting army of the allies, which, if not immediately liable to be attacked, was to be defended by the maintenance of posts, at a very short distance.
Troops passed through it daily, for the service of these posts. The noise of every cannonade was audible, and the result of every engagement was immediately known, for it might make an advance, or a retreat necessary from Worms. The wounded men arrived, soon after the intelligence, to the military hospitals of the Prussians. A city, so circumstanced, seemed to differ but little from a camp; and we were aware, for a few hours, of a departure from the security and order of civil life. The inn, which was not otherwise a mean building, was nearly destitute of furniture; so that the owner was prepared to receive any sort of guests, or masters. The only provision which we could obtain was bread, the commonest sort of wine, and one piece of cold veal; for the city was under military jurisdiction, and no guests were allowed to have more than one dish at their table. In the afternoon, we saw, for the first time, a crowd in a German city. A narrow waggon, of which nearly all but the wheels was basket-work, had arrived from the army, with a wounded officer, who lay upon the floor, supported by his servant, but occasionally rose to return the salutes of passengers. This was the Prince of Anhalt Plessis, who had been wounded, in the morning, when the French attacked all the neighbouring lines of the allies, and an indecisive engagement ensued, the noise of which had been distinctly heard, at Worms. He was hurt in the leg, and descended, with much difficulty, from the waggon; but did not, for an instant, lose the elegance of his address, and continued bowing through the passage to his apartment. No doubt was entertained of his recovery, but there seemed to be a considerable degree of sympathy, attending this young man. We had not time to look into the churches, or numerous monasteries, that yet remain, at Worms; the war appeared to have depopulated the latter, for not a monk was to be seen. The cathedral, or church of St. Mary and St. Peter, is one of the most antient sacred buildings in Germany, having been founded at least as
early as the commencement of the seventh century. One of the prebends was established in 1033, another in 1058. The Dominicans, Carmelites, Capuchins and Augustines have each a monastery, at Worms; as have the Cistercians and the Augustines a nunnery. A Protestant church was also consecrated, on the 9th of June 1744; something more than two hundred years, after the ineffectual conference held here of Protestant and Catholic divines, which Charles the Fifth interrupted, when Melancthon, on one side, and Echius, on the other, had engaged in it, ordering them to resume their arguments, in his presence, at Ratisbon. This meeting was five years previous to the celebrated diet of Worms, at which Charles, having then estimated the temporal strength of the two parties, openly shewed his animosity to the Protestants, as Maurice of Saxony did his intriguing ambition, by referring the question to the Council of Trent. The Jews, at Worms, inhabit a separate street, and have a synagogue, of great antiquity, their numbers having been once such as to endanger the peace of the city; but, in 1689, when the French turned their synagogue into a stable, they fled with the rest of the opulent inhabitants to Holland. Those of the present day can have very few articles of traffic, except money, the changing of which may have been frequent, on account of the neighbourhood of France. Worms is somewhat connected with English history, having been occupied by the troops, which James the First uselessly sent to the assistance of the proscribed Elector Palatine, when his just abhorrence of continental wars was once, though tardily, overcome by the entreaties of his daughter. Here too George the Second held his head-quarters, from the 7th to the 20th of September 1743; on the 14th of which month, Lord Carteret concluded, in his name, an offensive and defensive treaty with the Ministers of Hungary and Sardinia. This city, like Cologne, retains some affectation of the Roman form of government, to which it was rendered subject by Cæsar, with the
Welcome to Our Bookstore - The Ultimate Destination for Book Lovers Are you passionate about books and eager to explore new worlds of knowledge? At our website, we offer a vast collection of books that cater to every interest and age group. From classic literature to specialized publications, self-help books, and children’s stories, we have it all! Each book is a gateway to new adventures, helping you expand your knowledge and nourish your soul Experience Convenient and Enjoyable Book Shopping Our website is more than just an online bookstore—it’s a bridge connecting readers to the timeless values of culture and wisdom. With a sleek and user-friendly interface and a smart search system, you can find your favorite books quickly and easily. Enjoy special promotions, fast home delivery, and a seamless shopping experience that saves you time and enhances your love for reading. Let us accompany you on the journey of exploring knowledge and personal growth! ebookgate.com

More Related Content

Similar to JavaScript Application Design A Build First Approach 1st Edition Nicolas Bevacqua (20)

PDF
AOP in NET Practical Aspect Oriented Programming Matthew D. Groves
anusansuphi
 
PDF
ASP NET 4 0 in Practice Daniele Bochicchio
fofangomeal55
 
PDF
[PDF Download] Akka in Action 1st Edition Raymond Roestenburg fulll chapter
labliinagai
 
PDF
ASP NET MVC in Action 1st Edition Jeffrey Palermo
sysolkadieqj
 
PDF
iPhone in action introduction to Web and SDK development 1st Edition Christop...
lipiriuezee
 
PDF
Continuous Integration in NET Marcin Kawalerowicz
senawoalklb
 
PDF
Openstack In Action 1st Edition V K Cody Bumgardner
pompefodge3d
 
PDF
Testing Microservices With Mountebank 1st Edition Brandon Byars
moaudndingo
 
PDF
ASP NET 4 0 in Practice Daniele Bochicchio
sabenaforu
 
PDF
Eclipse In Action A Guide For Java Developers 1st Edition David Gallardo
spatzoachskq
 
PDF
ASP NET MVC in Action 1st Edition Jeffrey Palermo
psfxedtb367
 
PDF
Akka in Action 1st Edition Raymond Roestenburg download pdf
himlalnunys
 
PDF
Azure Infrastructure As Code With Arm Templates And Bicep 1st Edition Henry Been
biprolarebo
 
PDF
Rxjs In Action Covers Rxjs 5 1st Edition Paul P Daniels Luis Atencio
lyeannhoung
 
PDF
ASP.NET Core in Action (2018).pdf
Emma Burke
 
PDF
Vertx In Action Asynchronous And Reactive Java Julien Ponge
ratanaarizbe
 
PDF
Spring Microservices In Action 1st Edition John Carnell
kcjsuwx115
 
PDF
React in Action 1st Edition Mark Tielens Thomas
jyliyakainu
 
PDF
PDF DevOps with OpenShift 1st Edition Mike Hepburn download
xalanaunnuk
 
PDF
Go Web Programming 1st Edition Sau Sheong Chang
braykoofunne
 
AOP in NET Practical Aspect Oriented Programming Matthew D. Groves
anusansuphi
 
ASP NET 4 0 in Practice Daniele Bochicchio
fofangomeal55
 
[PDF Download] Akka in Action 1st Edition Raymond Roestenburg fulll chapter
labliinagai
 
ASP NET MVC in Action 1st Edition Jeffrey Palermo
sysolkadieqj
 
iPhone in action introduction to Web and SDK development 1st Edition Christop...
lipiriuezee
 
Continuous Integration in NET Marcin Kawalerowicz
senawoalklb
 
Openstack In Action 1st Edition V K Cody Bumgardner
pompefodge3d
 
Testing Microservices With Mountebank 1st Edition Brandon Byars
moaudndingo
 
ASP NET 4 0 in Practice Daniele Bochicchio
sabenaforu
 
Eclipse In Action A Guide For Java Developers 1st Edition David Gallardo
spatzoachskq
 
ASP NET MVC in Action 1st Edition Jeffrey Palermo
psfxedtb367
 
Akka in Action 1st Edition Raymond Roestenburg download pdf
himlalnunys
 
Azure Infrastructure As Code With Arm Templates And Bicep 1st Edition Henry Been
biprolarebo
 
Rxjs In Action Covers Rxjs 5 1st Edition Paul P Daniels Luis Atencio
lyeannhoung
 
ASP.NET Core in Action (2018).pdf
Emma Burke
 
Vertx In Action Asynchronous And Reactive Java Julien Ponge
ratanaarizbe
 
Spring Microservices In Action 1st Edition John Carnell
kcjsuwx115
 
React in Action 1st Edition Mark Tielens Thomas
jyliyakainu
 
PDF DevOps with OpenShift 1st Edition Mike Hepburn download
xalanaunnuk
 
Go Web Programming 1st Edition Sau Sheong Chang
braykoofunne
 

Recently uploaded (20)

PPTX
grade 5 lesson matatag ENGLISH 5_Q1_PPT_WEEK4.pptx
SireQuinn
 
PDF
People & Earth's Ecosystem -Lesson 2: People & Population
marvinnbustamante1
 
PPT
Talk on Critical Theory, Part One, Philosophy of Social Sciences
Soraj Hongladarom
 
PPTX
How to Create a PDF Report in Odoo 18 - Odoo Slides
Celine George
 
PPTX
Growth and development and milestones, factors
BHUVANESHWARI BADIGER
 
PPT
Talk on Critical Theory, Part II, Philosophy of Social Sciences
Soraj Hongladarom
 
PPTX
I AM MALALA The Girl Who Stood Up for Education and was Shot by the Taliban...
Beena E S
 
PPTX
MENINGITIS: NURSING MANAGEMENT, BACTERIAL MENINGITIS, VIRAL MENINGITIS.pptx
PRADEEP ABOTHU
 
PDF
Stokey: A Jewish Village by Rachel Kolsky
History of Stoke Newington
 
PDF
ARAL-Orientation_Morning-Session_Day-11.pdf
JoelVilloso1
 
PPTX
ASRB NET 2023 PREVIOUS YEAR QUESTION PAPER GENETICS AND PLANT BREEDING BY SAT...
Krashi Coaching
 
PDF
The Different Types of Non-Experimental Research
Thelma Villaflores
 
PPTX
HYDROCEPHALUS: NURSING MANAGEMENT .pptx
PRADEEP ABOTHU
 
PDF
Lesson 2 - WATER,pH, BUFFERS, AND ACID-BASE.pdf
marvinnbustamante1
 
PDF
CEREBRAL PALSY: NURSING MANAGEMENT .pdf
PRADEEP ABOTHU
 
PDF
Dimensions of Societal Planning in Commonism
StefanMz
 
PPTX
PATIENT ASSIGNMENTS AND NURSING CARE RESPONSIBILITIES.pptx
PRADEEP ABOTHU
 
PDF
The Constitution Review Committee (CRC) has released an updated schedule for ...
nservice241
 
PDF
CONCURSO DE POESIA “POETUFAS – PASSOS SUAVES PELO VERSO.pdf
Colégio Santa Teresinha
 
PDF
The History of Phone Numbers in Stoke Newington by Billy Thomas
History of Stoke Newington
 
grade 5 lesson matatag ENGLISH 5_Q1_PPT_WEEK4.pptx
SireQuinn
 
People & Earth's Ecosystem -Lesson 2: People & Population
marvinnbustamante1
 
Talk on Critical Theory, Part One, Philosophy of Social Sciences
Soraj Hongladarom
 
How to Create a PDF Report in Odoo 18 - Odoo Slides
Celine George
 
Growth and development and milestones, factors
BHUVANESHWARI BADIGER
 
Talk on Critical Theory, Part II, Philosophy of Social Sciences
Soraj Hongladarom
 
I AM MALALA The Girl Who Stood Up for Education and was Shot by the Taliban...
Beena E S
 
MENINGITIS: NURSING MANAGEMENT, BACTERIAL MENINGITIS, VIRAL MENINGITIS.pptx
PRADEEP ABOTHU
 
Stokey: A Jewish Village by Rachel Kolsky
History of Stoke Newington
 
ARAL-Orientation_Morning-Session_Day-11.pdf
JoelVilloso1
 
ASRB NET 2023 PREVIOUS YEAR QUESTION PAPER GENETICS AND PLANT BREEDING BY SAT...
Krashi Coaching
 
The Different Types of Non-Experimental Research
Thelma Villaflores
 
HYDROCEPHALUS: NURSING MANAGEMENT .pptx
PRADEEP ABOTHU
 
Lesson 2 - WATER,pH, BUFFERS, AND ACID-BASE.pdf
marvinnbustamante1
 
CEREBRAL PALSY: NURSING MANAGEMENT .pdf
PRADEEP ABOTHU
 
Dimensions of Societal Planning in Commonism
StefanMz
 
PATIENT ASSIGNMENTS AND NURSING CARE RESPONSIBILITIES.pptx
PRADEEP ABOTHU
 
The Constitution Review Committee (CRC) has released an updated schedule for ...
nservice241
 
CONCURSO DE POESIA “POETUFAS – PASSOS SUAVES PELO VERSO.pdf
Colégio Santa Teresinha
 
The History of Phone Numbers in Stoke Newington by Billy Thomas
History of Stoke Newington
 
Ad

JavaScript Application Design A Build First Approach 1st Edition Nicolas Bevacqua

  • 1. JavaScript Application Design A Build First Approach 1st Edition Nicolas Bevacqua download https://ebookgate.com/product/javascript-application-design-a- build-first-approach-1st-edition-nicolas-bevacqua/ Get Instant Ebook Downloads – Browse at https://ebookgate.com
  • 2. Get Your Digital Files Instantly: PDF, ePub, MOBI and More Quick Digital Downloads: PDF, ePub, MOBI and Other Formats Algorithmic Trading Systems and Strategies A New Approach Design Build and Maintain 1st Edition Viktoria Dolzhenko https://ebookgate.com/product/algorithmic-trading-systems-and- strategies-a-new-approach-design-build-and-maintain-1st-edition- viktoria-dolzhenko/ Pressure sensitive design and formulation application First Edition Benedek https://ebookgate.com/product/pressure-sensitive-design-and- formulation-application-first-edition-benedek/ Web Application Design and Implementation Apache 2 PHP5 MySQL JavaScript and Linux UNIX Quantitative Software Engineering Series 1st Edition Steven A. Gabarró https://ebookgate.com/product/web-application-design-and- implementation-apache-2-php5-mysql-javascript-and-linux-unix- quantitative-software-engineering-series-1st-edition-steven-a- gabarro/ Build an HTML5 Game A Developer s Guide with CSS and JavaScript 1st Edition Karl Bunyan https://ebookgate.com/product/build-an-html5-game-a-developer-s- guide-with-css-and-javascript-1st-edition-karl-bunyan/
  • 3. Automate with Grunt The Build Tool for JavaScript 1st Edition Brian P. Hogan https://ebookgate.com/product/automate-with-grunt-the-build-tool- for-javascript-1st-edition-brian-p-hogan/ Head First JavaScript 1st Edition Michael Morrison https://ebookgate.com/product/head-first-javascript-1st-edition- michael-morrison/ Reinforced Concrete Design A Practical Approach 1st Edition Brzev https://ebookgate.com/product/reinforced-concrete-design-a- practical-approach-1st-edition-brzev/ Head First JavaScript Programming 1st Edition Eric T. Freeman https://ebookgate.com/product/head-first-javascript- programming-1st-edition-eric-t-freeman/ The Design of Mammals A Scaling Approach 1st Edition John William Prothero https://ebookgate.com/product/the-design-of-mammals-a-scaling- approach-1st-edition-john-william-prothero/
  • 4. M A N N I N G Nicolas Bevacqua FOREWORD BY Addy Osmani A Build First Approach
  • 7. JavaScript Application Design A Build First Approach NICOLAS BEVACQUA M A N N I N G SHELTER ISLAND
  • 8. iv For online information and ordering of this and other Manning books, please visit www.manning.com. The publisher offers discounts on this book when ordered in quantity. For more information, please contact Special Sales Department Manning Publications Co. 20 Baldwin Road PO Box 761 Shelter Island, NY 11964 Email: [email protected] ©2015 by Manning Publications Co. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps. Recognizing the importance of preserving what has been written, it is Manning’s policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end. Recognizing also our responsibility to conserve the resources of our planet, Manning books are printed on paper that is at least 15 percent recycled and processed without elemental chlorine. Manning Publications Co. Development editor: Susan Conant 20 Baldwin Road Technical development editor: Douglas Duncan PO Box 761 Copyeditor: Katie Petito Shelter Island, NY 11964 Proofreader: Alyson Brener Technical proofreaders: Deepak Vohra Valentin Crettaz Typesetter: Marija Tudor Cover designer: Marija Tudor ISBN: 9781617291951 Printed in the United States of America 1 2 3 4 5 6 7 8 9 10 – EBM – 20 19 18 17 16 15
  • 9. To Marian, for withstanding the birth of this book, your unconditional love, and your endless patience. I love you! Will you marry me?
  • 10. vi
  • 11. vii brief contents PART 1 BUILD PROCESSES ........................................................ 1 1 ■ Introduction to Build First 3 2 ■ Composing build tasks and flows 23 3 ■ Mastering environments and the development workflow 50 4 ■ Release, deployment, and monitoring 71 PART 2 MANAGING COMPLEXITY ........................................... 97 5 ■ Embracing modularity and dependency management 99 6 ■ Understanding asynchronous flow control methods in JavaScript 131 7 ■ Leveraging the Model-View-Controller 166 8 ■ Testing JavaScript components 211 9 ■ REST API design and layered service architectures 251
  • 13. ix contents foreword xv preface xvii acknowledgments xix about this book xxi about the author xxv about the cover illustration xxvi PART 1 BUILD PROCESSES ............................................ 1 1 Introduction to Build First 3 1.1 When things go wrong 4 How to lose $172,222 a second for 45 minutes 5 Build First 5 ■ Rites of initiation 6 1.2 Planning ahead with Build First 7 Core principles in Build First 7 1.3 Build processes 9 1.4 Handling application complexity and design 11 1.5 Diving into Build First 15 Keeping code quality in check 16 ■ Lint in the command line 19 1.6 Summary 22
  • 14. CONTENTS x 2 Composing build tasks and flows 23 2.1 Introducing Grunt 24 Installing Grunt 26 ■ Setting up your first Grunt task 28 Using Grunt to manage the build process 29 2.2 Preprocessing and static asset optimization 31 Discussing preprocessing 31 ■ Doing LESS 34 Bundling static assets 37 ■ Static asset minification 38 Implementing image sprites 41 2.3 Setting up code integrity 43 Cleaning up your working directory 43 ■ Lint, lint, lint! 44 Automating unit testing 45 2.4 Writing your first build task 46 2.5 Case study: database tasks 47 2.6 Summary 49 3 Mastering environments and the development workflow 50 3.1 Application environments 51 Configuring build distributions 51 ■ Environment-level configuration 56 ■ What’s so special about development? 58 3.2 Configuring environments 58 Storing configuration in a waterfall 59 ■ Using encryption to harden environment configuration security 61 ■ Setting environment-level configuration at the OS level 62 Merging configuration as a waterfall in code 64 3.3 Automating tedious first-time setup tasks 65 3.4 Working in continuous development 66 Waste no time, use a watch! 66 ■ Monitoring for changes to the Node app 67 ■ A text editor that cares 69 ■ Browser refresh is so Y2K 69 3.5 Summary 70 4 Release, deployment, and monitoring 71 4.1 Releasing your application 73 Image optimization 73 ■ Static asset caching 75 Inlining critical above-the-fold CSS 77 ■ Testing before a deployment 78 4.2 Predeployment operations 79 Semantic versioning 80 ■ Using changelogs 81 ■ Bumping changelogs 81
  • 15. CONTENTS xi 4.3 Deploying to Heroku 82 Deploying builds 85 ■ Managing environments 85 4.4 Continuous integration 86 Hosted CI using Travis 86 ■ Continuous deployments 88 4.5 Monitoring and diagnostics 89 Logging and notifications 89 ■ Debugging Node applications 92 ■ Adding performance analytics 93 Uptime and process management 94 4.6 Summary 95 PART 2 MANAGING COMPLEXITY ................................ 97 5 Embracing modularity and dependency management 99 5.1 Working with code encapsulation 101 Understanding the Single Responsibility Principle 101 Information hiding and interfaces 104 ■ Scoping and this keyword 106 ■ Strict mode 109 ■ Variable hoisting 110 5.2 JavaScript modules 111 Closures and the module pattern 111 ■ Prototypal modularity 112 ■ CommonJS modules 113 5.3 Using dependency management 114 Dependency graphs 114 ■ Introducing RequireJS 117 Browserify: CJS in the browser 119 ■ The Angular way 120 5.4 Understanding package management 122 Introducing Bower 122 ■ Big libraries, small components 124 ■ Choosing the right module system 125 Learning about circular dependencies 126 5.5 Harmony: a glimpse of ECMAScript 6 127 Traceur as a Grunt task 127 ■ Modules in Harmony 128 Let there be block scope 129 5.6 Summary 129 6 Understanding asynchronous flow control methods in JavaScript 131 6.1 Using callbacks 132 Avoiding callback hell 133 ■ Untangling the callback jumble 134 ■ Requests upon requests 136 ■ Asynchronous error handling 138
  • 16. CONTENTS xii 6.2 Using the async library 141 Waterfall, series, or parallel? 141 ■ Asynchronous functional tasks 145 ■ Asynchronous task queues 147 ■ Flow composition and dynamic flows 147 6.3 Making Promises 150 Promise fundamentals 150 ■ Chaining Promises 153 Controlling the flow 155 ■ Handling rejected Promises 156 6.4 Understanding events 157 Events and the DOM 157 ■ Creating your own event emitters 158 6.5 Glimpse of the future: ES6 generators 161 Creating your first generator 161 ■ Asynchronicity and generators 163 6.6 Summary 165 7 Leveraging the Model-View-Controller 166 7.1 jQuery isn’t enough 167 7.2 Model-View-Controller in JavaScript 170 Why Backbone? 170 ■ Installing Backbone 172 Browserifying your Backbone module with Grunt 172 7.3 Introduction to Backbone 174 Backbone views 175 ■ Creating Backbone models 177 Organizing models with Backbone collections 179 ■ Adding Backbone routers 180 7.4 Case study: the shopping list 183 Starting with a static shopping list 183 ■ This time with remove buttons 185 ■ Adding items to your cart 187 ■ Using inline editing 191 ■ A service layer and view routing 197 7.5 Backbone and Rendr: server/client shared rendering 199 Diving into Rendr 199 ■ Understanding boilerplate in Rendr 201 ■ A simple Rendr application 203 7.6 Summary 210 8 Testing JavaScript components 211 8.1 JavaScript testing crash course 212 Logical units in isolation 212 ■ Using the Test Anything Protocol (TAP) 213 ■ Putting together our first unit test 214 Tape in the browser 214 ■ Arrange, Act, Assert 215 Unit testing 216 ■ Convenience over convention 217
  • 17. CONTENTS xiii Case study: unit testing an event emitter 217 ■ Testing the event emitter 218 ■ Testing for the .on method 219 Mocks, spies, and proxies 221 ■ Mocking 222 Introducing Sinon.js 223 ■ Spying on function calls 223 Proxying require calls 224 8.2 Testing in the browser 226 Faking XHR and server communication 227 ■ Case study: testing DOM interaction 229 8.3 Case study: unit testing the MVC shopping list 238 Testing the view router 238 ■ Testing validation on a view model 243 8.4 Automating Tape tests 245 Automating Tape tests for the browser 246 ■ Continuous testing 247 8.5 Integration, visual, and performance testing 247 Integration testing 247 ■ Visual testing 248 ■ Performance testing 249 8.6 Summary 250 9 REST API design and layered service architectures 251 9.1 Avoiding API design pitfalls 252 9.2 Learning REST API design 253 Endpoints, HTTP verbs, and versioning 254 ■ Requests, responses, and status codes 257 ■ Paging, caching, and throttling 260 ■ Documenting an API 263 9.3 Implementing layered service architectures 264 Routing layer 265 ■ Service layer 265 ■ Data layer 265 Routing layer 266 ■ Service layer 266 ■ Data layer 267 9.4 Consuming a REST API on the client side 267 The request handling layer 268 ■ Shooting down old requests 268 ■ Consistent AJAX error management 269 9.5 Summary 271 appendix A Modules in Node.js 273 appendix B Introduction to Grunt 276 appendix C Picking your build tool 284 appendix D JavaScript code quality guide 293 index 307
  • 19. xv foreword The process of designing a robust JavaScript web app has gone through a roaring renaissance in recent years. With the language being used to develop increasingly ambitious apps and interfaces, this is the perfect time for JavaScript Application Design. Through concise examples, lessons learned from the field, and key concepts for scal- able development, Nico Bevacqua will give you a whirlwind tour of taking the process and design of your apps to the next level. This book will also help you craft build processes that will save you time. Time is a key factor in staying productive. As web app developers, we want to make the most of ours, and a Build First philosophy can help us hit the ground running with clean, test- able apps that are well structured from the get-go. Learning process workflow and how to manage complexity are fundamental cornerstones of modern JavaScript app development. Getting them right can make a massive difference in the long run. JavaScript Application Design will walk you through automation for the front end. It covers everything from avoiding repetitive tasks and monitoring production builds to mitigating the cost of human error through a clean tooling setup. Automation is a big factor here. If you aren't using automation in your workflow today, you're working too hard. If a series of daily tasks can be accomplished with a single command, follow Nico's advice and spend the time you save improving the code quality of your apps. Modularity is the final crucial concept that can assist with building scalable, main- tainable apps. Not only does this help ensure that the pieces composing our applica- tion can be more easily tested and documented, it encourages reuse and focus on quality. In JavaScript Application Design, Nico expertly walks you through writing modu-
  • 20. FOREWORD xvi lar JavaScript components, getting asyncronous flow right, and enough client-side MVC for you to build an app of your own. Strap on your seatbelts, adjust your command line, and enjoy a ride through the process of improving your development workflow. ADDY OSMANI SENIOR ENGINEER WITH A PASSION FOR DEVELOPER TOOLING GOOGLE
  • 21. xvii preface Like most people in our field, I’ve always been fascinated with problem solving. The painful thrill of hunting for a solution, the exhilarating relief of having found a fix— there’s nothing quite like it. When I was young I really enjoyed strategy games, such as chess, which I’ve played ever since I was a kid; StarCraft, a real-time strategy game I played for 10 years straight; and Magic: The Gathering, a trading card game that can be described as the intersection between poker and chess. They presented plenty of problem-solving opportunities. At primary school I learned Pascal and rudimentary Flash programming. I was psyched. I would go on and learn Visual Basic, PHP, C, and start developing websites, reaping the benefits of a masterful handle on <marquee> and <blink> tags, paired with a modest understanding of MySQL; I was unstoppable, but my thirst for problem solving didn’t end there, and I went back to gaming. Ultima Online (UO), a massively multiplayer online role-playing game (no wonder they abbreviate that as MMORPG), wasn’t any different than other games that got me hooked for years. Eventually I found out that there was an open source1 implementa- tion of the UO server, which was named RunUO and written entirely in C#. I played on a RunUO server where the administrators had no programming experience. They slowly started trusting me to handle minor bug fixes by literally emailing source code files back and forth. I was hooked. C# was a wonderful, expressive language, and the open source software for the UO server was amicable and inviting—you didn’t even 1 You can check out the RunUO website at runuo.com, although the project isn’t maintained anymore.
  • 22. PREFACE xviii need an IDE (or even need to know what that was) because the server would compile script files dynamically for you. You’d be essentially writing a file with 10 to 15 lines in it, inheriting from the Dragon class, and adding an intimidating text bubble over their head, or overriding a method so they’d spit more fireballs. You’d learn the language and its syntax without even trying, simply by having fun! Eventually, a friend revealed that I could make a living out of writing C# code: “You know, people actually pay you to do that,” he said. That’s when I started developing websites again, except I wasn’t using only Front Page and piles of <marquee> tags or Java applets for fun anymore. It still feels like a game to me, though. A few years ago I read The Pragmatic Programmer2 , and something clicked. The book has a lot of solid advice, and I can’t recommend it highly enough. One thing that par- ticularly affected me: the authors advocate you get out of your comfort zone and try something you’ve been meaning to do but haven’t gotten around to. My comfort zone was C# and ASP.NET at that point, so I decided to try Node.js, an unmistakably UNIX-y platform for JavaScript development on the server side, certainly a break from my Microsoft-ridden development experience so far. I learned a ton from that experiment and ended up with a blog3 where I’d write about everything I learned in the process. About six months later I’d decided that I’d put my years of experience in C# design into a book about JavaScript. I contacted Manning, and they jumped at the opportunity, helping me brainstorm and turn raw ideas into something more deliberate and concise. This book is the result of many hours of hard work, dedication, and love for the web. In it, you’ll find practical advice about application design, process automation, and best practices that will improve the quality of your web projects. 2 The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas (Addison Wesley, 1999) is a timeless classic you should seriously consider reading. 3 You can read my blog, “Pony Foo,” at ponyfoo.com. I write articles about the web, performance, progressive enhancement, and JavaScript.
  • 23. xix acknowledgments You wouldn’t be holding this book in your hands if it weren’t for everyone who sup- ported and endured me throughout the writing process. I can only hope that those who deserve acknowledgment the most, my friends and family, already know that I can’t put into words how thankful I am for their love, understanding, and frequent reassurance. Many more people contributed—directly or indirectly—a great deal of wisdom and inspiration to this book. The open source JavaScript community is an endless spring of insight, encourage- ment, and selfless contributions. They have opened my eyes to a better approach to software development, where collaboration isn’t only possible, but actively encour- aged. Most of these people have contributed indirectly by evangelizing for the web, maintaining blogs, sharing their experience and resources, and otherwise educating me. Others have contributed directly by developing tools discussed in the book. Among these individuals are Addy Osmani, Chris Coyier, Guillermo Rauch, Harry Roberts, Ilya Grigorik, James Halliday, John-David Dalton, Mathias Bynens, Max Ogden, Mikeal Rogers, Paul Irish, Sindre Sorhus, and T.J. Holowaychuk. There are also many book authors and content distributors who have influenced and motivated me to become a better educator. Through their writing and sharing, these people have significantly helped shape my career. They include Adam Wiggins, Alan Cooper, Andrew Hunt, Axel Rauschmayer, Brad Frost, Christian Heilmann, David Thomas, Donald Norman, Frederic Cambus, Frederick Brooks, Jeff Atwood, Jeremy Keith, Jon Bentley, Nicholas C. Zakas, Peter Cooper, Richard Feynmann, Steve Krug, Steve McConnell, and Vitaly Friedman.
  • 24. ACKNOWLEDGMENTS xx Susan Conant, my developmental editor at Manning, deserves to be singled out. She held this book to the greatest standard of quality I could possibly create, and it’s in much better shape than it would’ve been if not for her. On top of that, she had to hand-hold me through the delicate and intimate process of writing my first book. Through her relentless, yet gentle, guidance she helped shape my lumps of ideas into a book that I’m not afraid to publish. I’ve become a better writer because of her, and I’m grateful for that. She wasn’t alone in that endeavor. All of the staff at Manning wanted this book to be the best that it could be. The publisher, Marjan Bace—along with his editorial col- lective—are to be thanked for that. Valentin Crettaz and Deepak Vohra, the technical proofreaders, were not only instrumental in ensuring the code samples were consis- tent and useful, but provided me with great feedback as well. There are also the hordes of anonymous souls that were willing to read through the manuscript, leaving their impressions and helping improve the book. Thanks to the MEAP readers who posted corrections and comments in the Author Online forum, and to the reviewers who read the chapters at various stages of development: Alberto Chiesa, Carl Mosca, Dominic Pettifer, Gavin Whyte, Hans Donner, Ilias Ioan- nou, Jonas Bandi, Joseph White, Keith Webster, Matthew Merkes, Richard Harriman, Sandeep Kumar Patel, Stephen Wakely, Torsten Dinkheller, and Trevor Saunders. Special thanks to Addy Osmani for contributing the foreword, and to everyone else who played a part. Even if they didn’t make the keystrokes themselves, they played an instrumental role in getting this book published, and one step closer to you.
  • 25. xxi about this book Web development has grown out of proportion, and today it’s hard to imagine a world without the web. The web is famously fault tolerant. While traditional programming teaches us that missing a semicolon, forgetting to add a closing tag, or declaring invalid properties will have crippling consequences, the same cannot be said about the web. The web is a place where it’s okay to make mistakes, yet there’s increasingly less room for error. This dichotomy stems from the fact that modern web applications are an order of magnitude more complex than they used to be. During the humble beginnings of the web, we would maybe modestly make a minor change in web pages using JavaScript; whereas on the modern web, entire sites are rendered in a single page, powered by JavaScript. JavaScript Application Design is your guide to a better modern web development experience, one where you can develop maintainable JavaScript applications as you would if you were using any other language. You’ll learn how to leverage automation as a replacement for tedious and repetitive error-prone processes, how to design mod- ular applications that are easy to test, and how to test them. Process automation is a critical time-saver across the board. Automation in the development environment helps us focus our efforts on thinking, writing code, and debugging. Automation helps ensure our code works after every change that we pub- lish to version control. It saves time when preparing the application for production by bundling, minifying assets, creating spritesheets, and adding other performance opti- mization techniques. It also helps with deployments by reducing risk and automating away a complicated and error-prone process. Many books discuss processes and
  • 26. ABOUT THIS BOOK xxii automation when it comes to back-end languages, but it’s much harder to find mate- rial on the subject when it comes to JavaScript-driven applications. The core value of JavaScript Application Design is quality. Automation gives you a bet- ter environment in which to build your application, but that alone isn’t enough: the application itself needs to be quality conscious as well. To that end, the book covers application design guidelines, starting with a quick rundown of language-specific cave- ats, teaching you about the power of modularity, helping you untangle asynchronous code, develop client-side MVC applications, and write unit tests for your JavaScript code. This book relies on specific tools and framework versions, as books about web tech- nologies usually do, but it separates library-specific concerns from the theory at hand. This is a concession to the fact that tooling changes frequently in the fast-paced web development arena, but design and the processes behind tooling tend to have a much slower rhythm. Thanks to this separation of concerns, I hope this book stays relevant for years to come. Road map JavaScript Application Design is broken into two parts and four appendixes. The first part is dedicated to the Build First approach, what it is, and how it can aid your every- day job. This part covers process automation in detail, from everyday development to automated deployments, as well as continuous integration and continuous deploy- ments; it spans 4 chapters. ■ Chapter 1 describes the core principles that drive Build First, and the different processes and flows you can set up. It then introduces the application design guidelines that we’ll discuss throughout the book and lays the foundation for the rest of the book. ■ In chapter 2 you learn about Grunt, and how you can use it to compose build flows. Then we look at a few different build tasks that you can easily perform using Grunt. ■ Chapter 3 is all about environments and the development workflow. You’ll learn that not all environments are born the same, and how you can prioritize debugging and productivity in the development environment. ■ Chapter 4 walks you through the release flow and discusses deployments. You’ll learn about a few more build tasks that are geared toward performance optimi- zation, and discover how to perform automated deployments. You’ll also learn how to hook up continuous integration and how to monitor your application once in production. While part 1 is focused on building applications using Grunt, appendix C teaches you to choose the best build tool for the job. Once you’ve read past part 1, you’ll go into the second part of the book, which is dedicated to managing complexity in your appli- cation designs. Modules, MVC, asynchronous code flows, testing, and a well-designed API all play significant roles in modern applications and are discussed in the next chapters.
  • 27. ABOUT THIS BOOK xxiii ■ Chapter 5 focuses on developing modular JavaScript. It starts by expressing what constitutes a module and how you can design applications modularly and lists the benefits of doing so. Afterward, you’ll get a crash course on lexical scoping and related quirks in the JavaScript language. Later you get a rundown of the major ways to attain modularity: RequireJS, CommonJS, and the upcom- ing ES6 module system. The chapter concludes by going over different package management solutions such as Bower and npm. ■ In chapter 6 you learn about asynchronous code flows. If you ever descend into callback hell, this may be your way out. This chapter discusses different approaches to deal with complexity in asynchronous code flows, namely call- backs, Promises, events, and ES6 generators. You’ll also learn how to do proper error handling under each of those paradigms. ■ Chapter 7 starts by describing MVC architectures, and then ties them specifically to the web. You’ll learn how you can use Backbone to develop rich client-side applications that separate concerns using MVC. Later, you’ll learn about Rendr, which can be used to render Backbone views on the server side, optimizing the performance and accessibility of your applications. ■ In chapter 8, now that your applications are modular, clean-cut, and maintain- able, you’ll take the next logical step and look into testing your applications in different ways. To this end we’ll go over an assortment of JavaScript testing tools and get hands-on experience using them to test small components. Then we’ll go back to the MVC application built in chapter 7 and add tests to it. You won’t be doing unit testing only, you’ll also learn more about continuous integration, visual testing, and measuring performance. ■ Chapter 9 is the last chapter of the book, and it’s dedicated to REST API design. This is the layer where the client side interacts with the server, and it sets the scene for everything that we do in the application. If the API is convoluted and complicated, chances are the application as a whole will be as well. REST intro- duces clear guidelines when designing an API, making sure the API is concise. Last, we’ll look at consuming these services in the client side in a conventional manner. The appendixes can be read after you’re done with the book, but you’ll probably get the most value from them by reading them if you get stuck with the areas they cover, as they contain answers to questions you might have. Throughout the book, you’ll be pointed to the appendixes where it makes sense to expand a little on one of these subjects. ■ Appendix A is a soft introduction to Node.js and its module system, CommonJS. It’ll help you troubleshoot your Node.js installation and answer a few questions on how CommonJS works. ■ Appendix B is a detailed introduction to Grunt. Whereas the chapters in part I only explain what’s absolutely necessary about Grunt, the appendix covers its inner workings in more detail, and will be handy if you’re serious about devel- oping a full-blown build process using Grunt.
  • 28. ABOUT THIS BOOK xxiv ■ Appendix C makes it clear that this book is in no way married to Grunt, and lists a couple of alternatives, Gulp and npm run. The appendix discusses the pros and cons of each of the three tools, and leaves it up to you to determine which one (if any) fits your needs best. ■ Appendix D presents a JavaScript quality guide containing a myriad of best prac- tices you may choose to follow. The idea isn’t to force those specific guidelines down your throat, but rather to arm you with the idea that consistency is a good thing to enforce throughout a code base when working in a development team. Code conventions and downloads All source code is in fixed-size width font like this, and sometimes grouped under named code listings. Code annotations accompany many of the listings, high- lighting important concepts. The source code for this book is open source and pub- licly hosted on GitHub. You can download it by visiting github.com/buildfirst/ buildfirst. The online repository will always have the most up-to-date version of the accompanying source code. While source code might only be discussed at a glance in the book, it’s better documented in the repository, and I encourage you to check out the commented code there, if you run into trouble. You can also download the code from the publisher’s website at www.manning .com/JavaScriptApplicationDesign. Author Online Purchase of JavaScript Application Design includes free access to a private web forum run by Manning Publications, where you can make comments about the book, ask technical questions, and receive help from the author and from other users. To access the forum and subscribe to it, point your web browser to www.manning.com/ JavaScriptApplicationDesign. This page provides information on how to get on the forum once you are registered, what kind of help is available, and the rules of con- duct on the forum. Manning’s commitment to our readers is to provide a venue where a meaningful dialogue between individual readers and between readers and the author can take place. It is not a commitment to any specific amount of participation on the part of the author, whose contribution to the book’s forum remains voluntary (and unpaid). We suggest you try asking the author some challenging questions, lest his interest stray! The Author Online forum and the archives of previous discussions will be accessi- ble from the publisher’s website as long as the book is in print.
  • 29. xxv about the author Nicolas Bevacqua is an active member of the open source JavaScript community, a freelance web developer, an occasional public speaker, and a passionate writer. He maintains many open source projects and blogs about the web, performance, progressive enhancement, and JavaScript development at ponyfoo.com. Nico currently lives in Buenos Aires, Argentina, with his beautiful girl- friend, Marian.
  • 30. xxvi about the cover illustration The figure on the cover of JavaScript Application Design is captioned “Winter Habit of a Kamtchadal in 1760.” The Kamchatka Peninsula is the eastern-most part of Russia, lying between the Pacific Ocean to the east and the Sea of Okhotsk to the west. The illustration is taken from Thomas Jefferys' A Collection of the Dresses of Different Nations, Ancient and Modern, London, published between 1757 and 1772. The title page states that these are hand-colored copperplate engravings, heightened with gum arabic. Thomas Jefferys (1719–1771) was called “Geographer to King George III.” He was an English cartographer who was the leading map supplier of his day. He engraved and printed maps for government and other official bodies and produced a wide range of commercial maps and atlases, especially of North America. His work as a mapmaker sparked an interest in local dress customs of the lands he surveyed and mapped; they are brilliantly displayed in this four-volume collection. Fascination with faraway lands and travel for pleasure were relatively new phenom- ena in the eighteenth century and collections such as this one were popular, introduc- ing both the tourist as well as the armchair traveler to the inhabitants of other countries. The diversity of the drawings in Jefferys’ volumes speaks vividly of the uniqueness and individuality of the world's nations centuries ago. Dress codes have changed, and the diversity by region and country, so rich at one time, has faded away. It is now often hard to tell the inhabitant of one continent from another. Perhaps, try- ing to view it optimistically, we have traded a cultural and visual diversity for a more varied personal life—or a more varied and interesting intellectual and technical life.
  • 31. ABOUT THE COVER ILLUSTRATION xxvii At a time when it is hard to tell one computer book from another, Manning cele- brates the inventiveness and initiative of the computer business with book covers based on the rich diversity of national costumes two and a half centuries ago, brought back to life by Jefferys’ pictures.
  • 32. ABOUT THE COVER ILLUSTRATION xxviii
  • 33. Part 1 Build processes The first part of this book is dedicated to build processes and provides a practical introduction to Grunt. You’ll learn the why, how, and what of build pro- cesses, both in theory and in practice. In chapter 1, we go over what the Build First philosophy entails: a build pro- cess and application complexity management. Then, we’ll start fiddling with our first build task, using lint to prevent syntax errors in our code. Chapter 2 is all about build tasks. You’ll learn about the various tasks that comprise a build, how to configure them, and how to create your own tasks. In each case, we’ll take a look at the theory and then walk through practical exam- ples using Grunt. In chapter 3, we’ll learn how to configure application environments while keeping sensitive information safe. We’ll go over the development environment workflow, and you’ll learn how to automate the build step itself. Chapter 4 then describes a few more tasks we need to take into account when releasing our application, such as asset optimization and managing documenta- tion. You’ll learn about keeping code quality in check with continuous integra- tion, and we’ll also go through the motions of deploying an application to a live environment.
  • 35. 3 Introduction to Build First Developing an application properly can be hard. It takes planning. I’ve created applications over a weekend, but that doesn’t mean they were well-designed. Improvisation is great for throw-away prototypes and great when concept-proofing an idea; however, building a maintainable application requires a plan, the glue that holds together the features you currently have in mind and maybe even those you might add in the near future. I’ve participated in countless endeavors where the application’s front-end wasn’t all it could be. Eventually, I realized that back-end services usually have an architect devoted to their planning, design, and overview—and often it’s not one architect but an entire team of them. This is hardly the case with front-end development, where a devel- oper is expected to prototype a working sketch of the application and then asked to This chapter covers ■ Identifying problems in modern application design ■ Defining Build First ■ Building processes ■ Managing complexity within applications
  • 36. 4 CHAPTER 1 Introduction to Build First run with it, hoping that the prototype will survive an implementation in production. Front-end development requires as much dedication to architecture planning and design as back-end development does. Long gone are the days when we’d copy a few snippets of code off the internet, paste them in our page, and call it a day. Mashing together JavaScript code as an after- thought no longer holds up to modern standards. JavaScript is now front and center. We have many frameworks and libraries to choose from, which can help you organize your code by allowing you to write small components rather than a monolithic appli- cation. Maintainability isn’t something you can tack onto a code base whenever you’d like; it’s something you have to build into the application, and the philosophy under which the application is designed, from the beginning. Writing an application that isn’t designed to be maintainable translates into stacking feature after feature in an ever-so-slightly tilting Jenga tower. If maintainability isn’t built in, it gets to a point where you can’t add any more pieces to the tower. The code becomes convoluted and bugs become increasingly hard to track down. Refactoring means halting product development, and the busi- ness can’t afford that. The release schedule must be maintained, and letting the tower come crashing down is unacceptable, so we compromise. 1.1 When things go wrong You might want to deploy a new feature to production, so humans can try it out. How many steps do you have to take to do that? Eight? Five? Why would you risk a mistake in a routine task such as a deployment? Deploying should be no different than build- ing your application locally. One step. That’s it. Unfortunately that’s rarely the standard. Have you faced the challenging position I’ve found myself in of having to take many of these steps manually? Sure, you can compile the application in a single step, or you might use an interpreted server-side language that doesn’t need any pre-compilation. Maybe later you need to update your database to the latest version. You may have even created a script for those updates, and yet you log into your database server, upload the file, and run the schema updates yourself. Cool, you’ve updated the database; however, something’s not right and the appli- cation is throwing an error. You look at the clock. Your application has been down for more than 10 minutes. This should’ve been a straightforward update. You check the logs; you forgot to add that new variable to your configuration file. Silly! You add it promptly, mumbling something about wrestling with the code base. You forget to alter the config file before it deploys; it slipped your mind to update it before deploying to production! Sound like a familiar ritual? Fear not, this is an unfortunately common illness, spread through different applications. Consider the crisis scenarios described next.
  • 37. 5 When things go wrong 1.1.1 How to lose $172,222 a second for 45 minutes I bet you’d consider losing almost half a billion dollars a serious issue, and that’s exactly what happened to Knight’s Capital.1 They developed a new feature to allow stock traders to participate in something called the Retail Liquidity Program (RLP). The RLP functionality was intended to replace an unused piece of functionality called Power Peg (PP), which had been discontinued for close to nine years. The RLP code reused a flag, which was used to activate the PP code. They removed the Power Peg feature when they added RLP, so all was good. Or at least they thought it was good, until the point when they flipped the switch. Deployments had no formal process and were executed by hand by a single techni- cian. This person forgot to deploy the code changes to one of their eight servers, meaning that in the case of the eighth server, the PP code, and not the RLP feature, would be behind the activation flag. They didn’t notice anything wrong until a week later when they turned on the flag, activating RLP on all servers but one, and the nine- year-old Power Peg feature on the other. Orders routed through the eighth server triggered the PP code rather than RLP. As a result, the wrong types of orders were sent to trading centers. Attempts to amend the situation only further aggravated it, because they removed the RLP code from the serv- ers which did have it. Long story short, they lost somewhere in the vicinity of $460 mil- lion in less than an hour. When you consider that all they needed to do to avoid their downfall was have a more formal build process in place, the whole situation feels out- rageous, irresponsible, and, in retrospect, easily averted. Granted, this is an extreme case, but it boldly illustrates the point. An automated process would have increased the probability that human errors could be prevented or at least detected sooner. 1.1.2 Build First In this book, my goal is to teach you the Build First philosophy of designing for clean, well-structured, and testable applications before you write a single line of code. You’ll learn about process automation, which will mitigate the odds of human error, such as those leading to Knight’s Capital’s bankruptcy. Build First is the foundation that will empower you to design clean, well-structured, and testable applications, which are easy to maintain and refactor. Those are the two fundamental aspects of Build First: process automation and design. To teach you the Build First approach, this book will show you techniques that will improve the quality of your software as well as your web development workflow. In Part 1, we’ll begin by learning how to establish build processes appropriate for mod- ern web application development. Then, you'll walk through best practices for pro- ductive day-to-day development, such as running tasks when your code changes, deploying applications from your terminal by entering a single command, and moni- toring the state of your application once it's in production. 1 For more information about Knight’s Capital, see http://bevacqua.io/bf/knight.
  • 38. 6 CHAPTER 1 Introduction to Build First The second part of the book—managing complexity and design—focuses on application quality. Here I give you an introduction to writing more modular Java- Script components by comparing the different options that are currently available. Asynchronous flows in JavaScript tend to grow in complexity and length, which is why I prepared a chapter where you’ll gain insight into writing cleaner asynchronous code while learning about different tools you can use to improve that code. Using Back- bone as your gateway drug of choice, you’ll learn enough about MVC in JavaScript to get you started on the path to client-side MVC. I mentioned testable applications are important, and while modularity is a great first step in the right direction, testing mer- its a chapter of its own. The last chapter dissects a popular API design mentality denominated REST (Representational State Transfer), helping you design your own, as well as delving into application architecture on the server side, but always keeping an eye on the front end. We’ll begin our exploration of build processes after looking at one more crisis scenario Build First can avert by automating your process. 1.1.3 Rites of initiation Complicated setup procedures, such as when new team members come onboard, are also a sign you may be lacking in the automation department. Much to my torment, I’ve worked on projects where getting a development environment working for the first time took a week. A full week before you can even begin to fathom what the code does. Download approximately 60 gigabytes worth of database backups, create a data- base configuring things you’ve never heard of before, such as collation, and then run a series of schema upgrade scripts that don’t quite work. Once you’ve figured that out, you might want to patch your Windows Media Player by installing specific and extremely outdated codecs in your environment, which will feel as futile as attempts to cram a pig into a stuffed refrigerator. Last, try compiling the 130+ project monolith in a single pass while you grab a cup of coffee. Oh, but you forgot to install the external dependencies; that’ll do it. Nope, wait, you also need to compile a C++ program so codecs will work again. Compile again, and another 20 minutes go by. Still failing? Shoot. Ask around, maybe? Well, nobody truly knows. All of them went through that excruciating process when they started out, and they erased the memory from their minds. Check out the wiki? Sure, but it’s all over the place. It has bits of information here and there, but they don’t address your specific problems. The company never had a formal initiation workflow, and as things started to pile up, it became increasingly hard to put one together. They had to deal with giant back- ups, upgrades, codecs, multiple services required by the website, and compiling the project took half an hour for every semi-colon you changed. If they’d automated these steps from the beginning, like we’ll do in Build First, the process would’ve been that much smoother. Both the Knight’s Capital debacle and the overly complicated setup story have one thing in common: if they’d planned ahead and automated their build and deploy- ment processes, their issues would’ve been averted. Planning ahead and automating
  • 39. 7 Planning ahead with Build First the processes surrounding your applications are fundamental aspects of the Build First philosophy, as you’ll learn in the next section. 1.2 Planning ahead with Build First In the case of Knight’s Capital, where they forgot to deploy code to one of the produc- tion web servers, having a single-step deployment process that automatically deployed the code to the whole web farm would’ve been enough to save the company from bankruptcy. The deeper issue in this case was code quality, because they had unused pieces of code sitting around in their code base for almost 10 years. A complete refactor that doesn’t provide any functional gains isn’t appealing to a product manager; their goal is to improve the visible, consumer-facing product, not the underlying software. Instead, you can continuously improve the average quality of code in your project by progressively improving the code base and refactoring code as you touch it, writing tests that cover the refactored functionality, and wrapping legacy code in interfaces, so you can refactor later. Refactoring won’t do the trick on its own, though. Good design that’s ingrained into the project from its inception is much more likely to stick, rather than attempts to tack it onto a poor structure as an afterthought. Design is the other fundamental aspect of the book, along with build processes mentioned previously. Before we dive into the uncharted terrains of Build First, I want to mention this isn’t a set of principles that only apply to JavaScript. For the most part, people usually asso- ciate these principles with back-end languages, such as Java, C#, or PHP, but here I’m applying them to the development process for JavaScript applications. As I mentioned previously, client-side code often doesn’t get the love and respect it deserves. That often means broken code because we lack proper testing, or a code base that’s hard to read and maintain. The product (and developer productivity) suffers as a result. When it comes to JavaScript, given that interpreted languages don’t need a com- piler, naive developers might think that’s justification enough to ditch the build pro- cess entirely. The problem when going down that road is that they’ll be shooting in the dark: the developer won’t know whether the code works until it’s executed by a browser, and won’t know whether it does what it's expected to, either. Later on, they might find themselves manually deploying to a hosting environment and logging into it remotely to tweak a few configuration settings to make it work. 1.2.1 Core principles in Build First At its core, the Build First approach encourages establishing not only a build process but also clean application design. The following list shows at a high level what embrac- ing the Build First approach gives us: ■ Reduced error proclivity because there’s no human interaction ■ Enhanced productivity by automating repetitive tasks ■ Modular, scalable application design
  • 40. 8 CHAPTER 1 Introduction to Build First ■ Testability and maintainability by shrinking complexity ■ Releases that conform to performance best practices ■ Deployed code that’s always tested before a release Looking at figure 1.1, starting with the top row and moving down, you can see ■ Build process: This is where you compile and test the application in an auto- mated fashion. The build can be aimed at facilitating continuous development or tuned for maximum performance for a release. ■ Design: You’ll spend most of your time here, coding and augmenting the archi- tecture as you go. While you’re at it, you might refactor your code and update the tests to ensure components work as expected. Whenever you’re not tweak- ing the build process or getting ready for a deployment, you’ll be designing and iterating on the code base for your application. ■ Deployment and Environment: These are concerned with automating the release process and configuring the different hosted environments. The Build process Automation concerns Design Architecture concerns Code Compile Test Turns source code into different build distributions Code quality: readability, maintainability, testability Takes a single distribution and deploys to a hosting environment Environment configuration, such as a database connection string, API keys, or listen port Helps iterate on code quality and refactor Debug or release Distribution Deployment Release concerns Environment Performance concerns App server Deploy Turns source code into different build distributions Built app, feeds from environment configuration Configuration Distribution Figure 1.1 High-level view of the four areas of focus in Build First: Build process, Design, Deployment, and Environment
  • 41. 9 Build processes deployment process is in charge of delivering your changes to the hosted envi- ronment, while environment configuration defines the environment and the services—or databases—it interacts with, at a high level. As figure 1.1 illustrates, Build First applications have two main components: the pro- cesses surrounding the project, such as building and deploying the application, and the design and quality of the application code itself, which is iteratively improved on a daily basis as you work on new features. Both are equally important, and they depend on each other to thrive. Good processes don’t do any good if you’re lacking in your application design. Similarly, good design won’t survive crises such as the ones I described previously without the help of decent build and deployment procedures. As with the Build First approach, this book is broken into two parts. In part 1, we look at the build process (tuned for either development or release) and the deploy- ment process, as well as environments and how they can be configured. Part 2 delves into the application itself, and helps us come up with modular designs that are clear and concise. It also takes us through the practical design considerations you'll have to make when building modern applications. In the next two sections, you’ll get an overview of the concepts discussed in each part of the book. 1.3 Build processes A build process is intended to automate repetitive tasks such as installing dependen- cies, compiling code, running unit tests, and performing any other important func- tions. The ability to execute all of the required tasks in a single step, called a one-step build, is critical because of the powerful opportunities it unveils. Once you have a one- step build in place, you can execute it as many times as required, without the outcome changing. This property is called idempotence: no matter how many times you invoke the operation, the result will be the same. Figure 1.2 highlights in more detail the steps that make up the automated build and deployment processes. Pros and cons of automating your build processes Possibly the most important advantage to having an automated build process is that you can deploy as frequently as needed. Providing humans with the latest features as soon as they’re ready allows us to tighten the feedback loop through which we can gain better insights into the product we should be building. The main disadvantage to setting up an automated process is the time you’ll need to spend putting the process together before you can start seeing the real benefits, but the benefits—such as automated testing, higher code quality, a leaner develop- ment workflow, and a safer deployment flow—far outweigh the effort spent putting together that process. As a general rule, you’ll set up the process once and then replay it as much as you’d like, tweaking it a little as you go.
  • 42. 10 CHAPTER 1 Introduction to Build First BUILD The top of figure 1.2 zooms in on the build portion in the build process workflow (shown back in figure 1.1), detailing the concerns as you aim for either development or release. If you aim for development, you’ll want to maximize your ability to debug, and I bet you’ll like a build that knows when to execute parts of itself without you tak- ing any action. That’s called continuous development (CD), and you’ll learn about it in chapter 3. The release distribution of a build isn’t concerned with CD, but you’ll want to spend time optimizing your assets so they perform as fast as possible in production environments where humans will use your application. DEPLOYMENT The bottom of figure 1.2 zooms into the deployment process (originally shown in fig- ure 1.1), which takes either the debug or release distribution (what I call distinct pro- cess flows with a specific purpose throughout the book) and deploys it to a hosted environment. This package will work together with the environment-specific configuration (which keeps secrets, such as database connection strings and API keys, safe, and is dis- cussed in chapter 3) to serve the application. Part 1 is dedicated to the build aspect of Build First: ■ Chapter 2 explains build tasks, teaching you how to write tasks and configure them using Grunt, the task runner you’ll use as a build tool throughout part 1. Build Build concerns Code Distributions Which distribution depends on target environment and deployment needs Ready for deployment Run specific tasks again whenever a part of your source code changes No deployment required, but it has its own environment configuration Environment-specific Tasks Distribution Debug Deployment Deployment concerns Configuration Deployment Distribution Release Environments Local Production Testing Watching Compilation Optimization Release notes App server Ch 2 Ch 4 Ch 4 Ch 3 Monitoring Figure 1.2 High-level view of the processes in Build First: Build and Deployment
  • 43. 11 Handling application complexity and design ■ Chapter 3 covers environments, how to securely configure your application, and the development work flow. ■ Chapter 4 discusses tasks you should perform during release builds. Then you’ll learn about deployments, running tests on every push to version control, and production monitoring. BENEFITS OF A BUILD PROCESS Once you’re done with part 1, you’ll feel confident performing the following opera- tions on your own applications: ■ Automating repetitive tasks such as compilation, minification, and testing ■ Building an icon spritesheet so that HTTP requests for iconography are reduced to a single one. Such spriting techniques are discussed in chapter 2, as well as other HTTP 1.x optimization tricks, as a means to improve page speed and application delivery performance. ■ Spinning up new environments effortlessly and neglecting to differentiate between development and production ■ Restarting a web server and recompiling assets automatically whenever related files change ■ Supporting multiple environments with flexible, single-step deployments The Build First approach eliminates manual labor when it comes to tedious tasks, while also improving your productivity from the beginning. Build First acknowledges the significance of the build process for shaping a maintainable application iteratively. The application itself is also built by iteratively chipping away at its complexity. Clean application design and architecture are addressed in part 2 of this book, which covers complexity management within the application, as well as design consid- erations with a focus on raising the quality bar. Let’s go over that next. 1.4 Handling application complexity and design Modularization, managing dependencies, understanding asynchronous flow, carefully following the right patterns, and testing are all crucial if you expect your code to work at a certain scale, regardless of language. In part 2 you’ll learn different concepts, techniques, and patterns to apply to your applications, making them more modular, focused, testable, and maintainable. Figure 1.3, viewed from the top down, shows the progression we’ll follow in part 2. MODULARITY You’ll learn how to break your application into components, break those components down into modules, and then write concise functions that have a single purpose inside those modules. Modules can come from external packages, developed by third par- ties, and you can also develop them yourself. External packages should be handled by a package manager that takes care of versioning and updates on your behalf, which eliminates the need to manually download dependencies (such as jQuery) and auto- mates the process.
  • 44. 12 CHAPTER 1 Introduction to Build First As you’ll learn in chapter 5, modules indicate their dependencies (the modules they depend upon) in code, as opposed to grabbing them from the global namespace; this improves self-containment. A module system will take advantage of this information, being able to resolve all of these dependencies; it’ll save you from having to maintain long lists of <script> tags in the appropriate order for your application to work correctly. Modularity Improves testability and maintainability Design Architecture concerns Asynchronous code Services, events, timing External package managers Dependencies are injected into consuming modules Dependencies might be local, too (also injected) Component Shared rendering in the server and client Test individual modules in isolation, faking their dependencies Test the application as a whole, including services, dependencies, and client-side HTML/CSS/JavaScript Types of asynchronous flow control techniques Automates updates and isolates external dependencies Component Dependency A Dependency B Module A Module B Module C MVC architecture Asynchronous operations Model View Controller Services Events Callbacks Promises Events Generator Testing practices Testability concerns Unit tests Integration tests Application Dependencies Services Modules Browser DOM Module A Module B Ch 5 Ch 7 Ch 8 Ch 6 Figure 1.3 Application design and development concerns discussed in part 2
  • 45. 13 Handling application complexity and design DESIGN You’ll get acquainted with separation of concerns and how to design your application in a layered way by following the Model-View-Controller pattern, further tightening the modularity in your applications. I’ll tell you about shared rendering in chapter 7, the technique where you render views on the server side first, and then let the client side do view rendering for subsequent requests on the same single-page application. ASYNCHRONOUS CODE I’ll teach you about the different types of asynchronous code flow techniques, using callbacks, Promises, generators, and events and helping you tame the asynchronous beast. TESTING PRACTICES In chapter 5 we discuss everything about modularity, learn about closures and the module pattern, talk about module systems and package managers, and try to pin- point the strengths found in each solution. Chapter 6 takes a deep dive into asynchro- nous programming in JavaScript. You’ll learn how to avoid writing a callback soup that will confuse you a week from now, and then you’ll learn about the Promise pattern and the generators API coming in ES6. Chapter 7 is dedicated to patterns and practices, such as how to best develop code, whether jQuery is the right choice for you, and how to write JavaScript code you can use in both the client and the server. We’ll then look at the Backbone MVC framework. Keep in mind that Backbone is the tool I’ll use to introduce you to MVC in JavaScript, but it’s by no means the only tool you can use to this end. In chapter 8 we’ll go over testing solutions, automation, and tons of practical examples of unit testing client-side JavaScript. You’ll learn how to develop tests in JavaScript at the unit level by testing a particular component and at the integration level by testing the application as a whole. The book closes with a chapter on REST API design, and the implications of con- suming a REST API in the front end, as well as a proposed structure to take full advan- tage of REST. PRACTICAL DESIGN CONSIDERATIONS The book aims to get you thinking about practical design considerations made when building a real application, as well as deciding thoughtfully on the best possible tool for a job, all the while focusing on quality in both your processes and the application itself. When you set out to build an application, you start by determining the scope, choosing a technology stack, and composing a minimum viable build process. Then you begin building the app, maybe using an MVC architecture and sharing the view rendering engine in both the browser and the server, something we discuss in chapter 7. In chapter 9 you’ll learn the important bits on how to put an API together, and you’ll learn how to define backing services that will be used by both the server-side view controllers and the REST API. Figure 1.4 is an overview of how typical Build First applications may be organized.
  • 46. 14 CHAPTER 1 Introduction to Build First BUILD PROCESS Beginning at the upper left, figure 1.4 outlines how you can start by composing a build process which helps consolidate a starting point for your architecture, by decid- ing how to organize your code base. Defining a modular application architecture is Build process Organization and workflow concerns Design Architecture concerns REST API Input sanitizing, HTTP responses Services Contains domain logic Technology stack Application architecture Solid directory structure helps organize an application Consolidate architecture Ensure our code works as expected, on every push to version control Ensure our environment is fault-tolerant and provides error reporting capabilities Build + watch Testing Deployments Model View Shared rendering in server and browser Controller Organization Directory structure Battle testing Reliability concerns API queries service layer Service layer queries database Gets data HTML response Query service layer Query REST API JSON response Continuous testing Unit testing Integration testing Deployment Clusters Logging Monitoring Continuous integration Fault-tolerance Db Browser Server Figure 1.4 Pragmatic architectural considerations
  • 47. 15 Diving into Build First the key to a maintainable code base, as you’ll observe in chapter 5. The architecture is then consolidated by putting in place automated processes that provide you with con- tinuous development, integration, and deployment capabilities. DESIGN AND REST API Designing the application itself, including a REST API that can effectively increase main- tainability, is only possible by identifying clear cut components with clear purposes so they’re orthogonal (meaning that they don’t fight for resources on any particular con- cern). In chapter 9 we’ll explore a multi-tiered approach to application design which can help you quickly isolate the web interface from your data and your business logic by strictly defining layers and the communication paths between those layers. BATTLE TESTING Once a build process and architecture are designed, battle testing is where you’ll get drenched in reliability concerns. Here you’ll plumb together continuous integration, where tests are executed on every push to your version control system, and maybe even continuous deployments, making several deployments to production per day. Last, fault tolerance concerns such as logging, monitoring, and clustering are dis- cussed. These are glanced over in chapter 4, and help make your production environ- ment more robust, or (at worst) warn you when things go awry. All along the way, you’ll write tests, adjust the build process, and tweak the code. It will be a terrific experiment for you to battle test Build First. It’s time you get comfort- able and start learning specifics about the Build First philosophy. 1.5 Diving into Build First Quality is the cornerstone of Build First, and every measure taken by this approach works toward the simple goal of improving quality in both your code and the structure surrounding it. In this section, you’ll learn about code quality and setting up lint, a code quality tool, in your command line. Measuring code quality is a good first step toward writing well-structured applications. If you start doing it early enough, it’ll be easy to have your code base conform to a certain quality standard, and that’s why we’ll do it right off the bat. In chapter 2, once you’ve learned about lint, I’ll introduce you to Grunt, the build tool you’ll use throughout the book to compose and automate build processes. Using Grunt allows you to run the code quality checks as part of a build, meaning you won’t forget about them. Grunt: the means to an end Grunt is used intensively in part 1 and in some of part 2 to drive our build processes. I chose Grunt because it’s a popular tool that’s easy to teach and satisfies the most needs: ■ It has full support for Windows. ■ Little JavaScript knowledge is required and it takes little effort to pick up and run.
  • 48. 16 CHAPTER 1 Introduction to Build First Lint is a code-quality tool that’s perfect for keeping an interpreted program—such as those written in JavaScript—in check. Rather than firing up a browser to check if your code has any syntax errors, you can execute a lint program in the command line. It can tell you about potential problems in your code, such as undeclared variables, miss- ing semicolons, or syntax errors. That being said, lint isn’t a magic wand: it won’t detect logic issues in your code, it’ll only warn you about syntax and style errors. 1.5.1 Keeping code quality in check Lint is useful for determining if a given piece of code contains any syntax errors. It also enforces a set of JavaScript coding best practice rules, which we’ll cover at the begin- ning of part 2, in chapter 5, when we look at modularity and dependency management. Around 10 years ago Douglas Crockford released JSLint, a harsh tool that checks code and tells us all the little things that are wrong with it. Linting exists to help us improve the overall quality of our code. A lint program can tell you about the poten- tial issues with a snippet, or even a list of files, straight from the command line, and this has the added benefit that you don’t even have to execute the code to learn what’s wrong with it. This process is particularly useful when it comes to JavaScript code, because the lint tool will act as a compiler of sorts, making sure that to the best of its knowledge your code can be interpreted by a JavaScript engine. On another level, linters (the name given to lint programs) can be configured to warn you about code that’s too complex, such as functions that include too many lines, obscure constructs that might confuse other people (such as with blocks, new statements, or using this too aggressively, in the case of JavaScript), or similar code style checks. Take the following code snippet as an example (listed as ch01/01_lint- sample in the samples online): function compose_ticks_count (start) { start || start = 1; this.counter = start; return function (time) { ticks = +new Date; return ticks + '_' + this.counter++ } } (continued) It's important to understand that Grunt is a means to an end, a tool that enables you to easily put together the build processes described in this book. This doesn’t make Grunt the absolute best tool for the job, and in an effort to make that clear, I’ve com- piled a comparison between Grunt and two other tools: *npm, which is a package manager that can double as a lean build tool, and *Gulp, a code-driven build tool that has several conventions in common with Grunt. If you’re curious about other build tools such as Gulp or using npm run as a build system, then you should read more about the topic in appendix C, which covers picking your own build tool.
  • 49. Another Random Scribd Document with Unrelated Content
  • 50. General Meusnier, who had been wounded near Cassel, on the 7th, died on the 13th, and was buried the next day, within the new fortifications, all the officers of the garrison, with the members of the convention and clubs, attending. Some fire ships were now completed, which a Dutch engineer had conducted from Holland, to be employed by the besiegers in burning the bridge of boats over the Rhine. It was thought, however, that their explosion would damage the city unnecessarily, and they were rejected. In the night of the 15th, one of these floated down the river, whether by accident, or by the connivance of the inventor, is not known; the inhabitants were in the utmost terror, but it struck against the quay, and, being immediately boarded, did no damage. The trenches were opened, in the night of the 16th and 17th, but, the workmen having been ill conducted, were not covered in, at day- light, and were compelled to retire, leaving their implements behind them. Two nights afterwards, the work was renewed in good order and without loss, the King of Prussia, his sons and the Duke of Brunswick surveying them from a neighbouring height. The first balls fell in a street near one of the gates, and all that part of the town was presently deserted. The 24th was a distressful day for the inhabitants. Four days before, the King of Prussia had sent a general passport for such as chose to come out, and 1500 persons, chiefly women and children, had accepted his offer. A short time after the gate had been opened, dismay was spread through the whole city by an account, that the Prussians would suffer no more to pass and the French none to return. The bridge was covered with these unhappy fugitives, who had no food, or shelter, and who thought themselves within reach of the Hockheim batteries, that played furiously upon the city. Two children lost their senses through fright. At length, the French soldiers took compassion upon them; they carried several persons into the city under their cloaks, and, the next day, their remonstrances against the inhumanity of the German clubbists, who
  • 51. had shut the gates against this defenceless crowd, obliged them to permit the return of the whole number. For several succeeding nights, the garrison made sorties, with various effect, interrupting, but not preventing the completion of the parallel. At sunset, on the 27th, the besiegers began a dreadful cannonade and bombardment. On this night, the steeple of the church of Notre Dame caught fire; and during the alarm, excited by an immense volume of flame, arising in the midst of the city, the Austrians completely carried the French posts, near Weissenau. The next night was equally terrible to the inhabitants; the flames caught several parts of the city, amongst others the cathedral; some of the magazines took fire, and eleven hundred sacks of corn were burned. The church, formerly belonging to the Jesuits, was much injured. The French, intending to retaliate their last surprise upon the Austrians, made a fruitless attack upon the Weissenau redoubt. On the 29th of June, at mid-day, the French were driven from a point of land, near the Main, called the Bleiau. In this affair, a vessel, with 78 Prussians on board, drove from her anchor, owing to the unskilfulness of the crew, and, during a fire, by which eight men were killed, made towards the city. The Prussians were taken prisoners, and exchanged the next day. At night, the bombardment was renewed; the Domprobstei, or palace of the Provost, was burned and several of the neighbouring residences; in other parts of the city, some houses were reduced to ashes. The next night, the church of the Franciscans and several other public buildings were destroyed. A dreadful fire, on the night of the 2d and 4th of June, consumed the chapel of St. Alban. Families in the southern part of the city now constantly passed the night in their cellars; in the day-time, they ventured into their usual apartments; for the batteries of the besiegers were by far the most terrible, at night, when the whole city was a sufficient mark for them, though
  • 52. their works could scarcely be discerned by the garrison. In the day- time, the exactness of the French gunners frequently did great injury to the batteries, which, at night, were repaired and used with equal effect against the city. St. Alban's fort was now demolished, so that the besieged withdrew their cannon from it. Elizabeth fort was also much damaged. A strong work, which the French had raised, in prolongation of the glacis, divided the opinions of the Prussian engineers. Some thought it should be preserved, when taken, because it would command part of the town; others, that it should be demolished. The latter opinion prevailed, and, in the night of the 5th and 6th, General Manstein was ordered to make the attack with three battalions. He perfectly succeeded, as to the nearest part of the work; but the other, on account of its solid foundation, could not be entirely destroyed. In the mean time, two battalions were sent, under cover of the darkness, to attack the Zahlbach fort, a part of which they carried by storm; but the reinforcements, immediately supplied by the garrison, obliged them to retire. Two Prussian officers were killed; one wounded, and another, with one-and-thirty men, taken. The Prussians lost in all 183 men; the French had twelve killed and forty-seven wounded. On the 6th of July, the French repaired the damaged fort, the distance of it from the Prussians preventing the latter from hindering them. At night, General Kleist carried the fort, at Zahlbach, by a second attack, and demolished it; at the same time, some batteries of the second parallel were perfected. The French could not support the loss of this fort; on the 7th, they attacked the scite; carried it, after a severe contest; and rebuilt it. At night, they were driven back again and the fort entirely destroyed. In the same night they were driven from Kostheim, after a furious battle, by the Prussian General Schonfield. During this engagement, the rapid succession of flashes and explosion of bombs seemed to fill the air with flame. A Prussian
  • 53. detachment having been posted on the road to Cassel, in order to prevent the garrison of that place from sending succour to Kostheim, this road was so strongly bombarded by the French, that seven bombs were frequently seen in the air at once. The loss was great, on both sides, in this engagement, after which the Council in the city resolved, to make no more attempts upon Kostheim, on account of the distance. The following night, the fire was less than usual, but a few bombs and grenades fell in the city, where the inhabitants had now learned to extinguish such as grounded, before their fusees were consumed. They also formed themselves into parties for the ready suppression of fires. The next morning, the garrison saw the works of the besiegers brought to within two hundred and fifty paces of the walls. About this time, the sickliness of the garrison became apparent, and General D'Oyré informed the Council, that, on account of this and of the fatiguing service of the works, he feared the defence could not be much longer continued. He lamented, that the troops of the line were so few, and the others so inexperienced. For several nights, the works of the besiegers were eagerly pushed, but still they were not so forward, as had been expected. Some of the besieging corps began to be sickly; the King of Prussia having resolved to employ no more labourers, it was reckoned, that the soldiers, for eight-and-forty hours of work, had only eighteen of rest. On the other hand, they were assured, that the garrison must be equally fatigued, since, in such an extensive fortification, none could be left long unemployed. The French had been, for some time, busied in forming what is called a Fleche at the head of one of their forts, and this was thought necessary to be destroyed. It was attacked in the night of the 12th and 13th by the Austrians; but so much time was passed in their operations, that the French fell upon them, in great force,
  • 54. about two in the morning, and beat them away, with loss. The Austrians were as little employed as possible in services of this fort. On the 13th of July, another battery was stormed by the Prussians; but, as the officer, unlike the Austrians, advanced with too little caution, his party was much hurt by some pieces of concealed cannon, and the enterprise failed. The night of the 13th and 14th was passed in much agitation by the garrison and inhabitants. Several of the public buildings were set fire to and burned by grenades. The works of the besiegers were now greatly advanced. The garrison made five sorties in this night, and were repulsed in all, losing an hundred men, while the besiegers lost eight killed and one-and-thirty wounded. On the 14th of July, a cessation of arms took place from seven o'clock in the morning till one. In the city, the French celebrated their annual fête; General d'Oyré and the troops took the oath, and Merlin delivered an address to them. In the Austrian camp, the Prince de Condé was received with a feu de joye. During this cessation, the soldiers upon the different outposts entered into conversation with each other, and the French boasted of the difficulties they laboured under from the length of the siege. At night, an affair at the Fleche cost the allies, who succeeded in part, ninety men; the French confessed, that this work cost them in all three hundred. The inhabitants of the city were again greatly alarmed, their streets being covered with a shower of grenades. The laboratory and a part of the Benedictine abbey were burned, and two explosions took place at the former. The whole city shook with each report, and, in the nearer parts, all the windows were broken and the doors burst open. The remainder of the hay and straw was consumed in this fire; the whole stock of other forage was reduced to a sufficiency for four days; and the surgeon's stores were much damaged.
  • 55. Still the Fleche prevented the besiegers from completing their second parallel. It was, therefore, again attacked, on the night of the 16th and 17th, Prince Louis Ferdinand of Prussia commanding at the assault, in which he was one of twelve officers wounded. The Fleche was then completely carried. The next night was very industriously spent by the besiegers in forming new batteries, and those of the second parallel were raised, before there were cannon enough at hand to place upon them. The French took advantage of this, and brought a part of theirs to bear, so as to enfilade the parallel, with great effect; the Prussians almost immediately losing an officer and forty men. In the city, the sick had now increased so much, that six hundred men were brought from Cassel, on the 17th, to re-inforce the garrison. On the 18th, the commandant informed the Council, that there was a want of fodder and such a loss of horses, by desertion, that there were not cavalry enough left for service. The soldiers, who knew the deficiency of medicines and other means of relief for the wounded, were unwilling to be led to sorties. Though corn had not failed, flour, it appeared, soon would, for some of the mills had been rendered unserviceable, for the present, by shot, and others were deserted by the millers. At night, after an unsuccessful attempt upon the Fleche, it was resolved, that the garrison, which had hitherto scarcely suffered a night to pass, without making some sorties, should, for the future, adhere solely to defensive measures. Some engineers proposed to abandon the whole line of forts, and others, that two of the largest should be blown up. The General and Council, at length, confessed, that they could not continue the defence, and assured the inhabitants, who had declared themselves in their favour, that a longer delay of the surrender would produce a more severe disposition of the besiegers towards them, without increasing the chance of escaping it.
  • 56. A negotiation, relative to the surrender, was now begun by D'Oyré, in a letter, which partly replied to one from the Prussian commander Kalkreuth, upon the subject of the departure of aged persons and children from the city. Their correspondence continued till the 20th, and several letters were exchanged, chiefly upon the question of the removal, or detention of the inhabitants, who had attached themselves to the French; it was then broken off, upon a disagreement, as to this and some other points. The firing, on both sides, had in the mean time continued, and the besiegers carried on the trenches, though these were now such an easy mark for the garrison, that they lost an officer and five-and-twenty men, in the night of the 19th and 20th. The next night, the Dominicans' church in the city took fire, and six French soldiers were buried under its ruins. Upon a renewal of the intercourse, the fire slackened, on the 21st; but, on some delays in the negotiation, was threatened to be recommenced. At length, the conditions of the surrender were settled, and the negotiation signed, on the 22d of July, by the two Generals Kalkreuth and D'Oyré; the former having rendered the capitulation somewhat easier than was expected for the garrison, because the Duke of Brunswick had only nineteen thousand men to cover the siege, and Custine had forty thousand, which were near enough to attack him. General Kalkreuth's orders are supposed to have been to obtain possession of the place, upon any terms, that would give it him quickly. At this time, the garrison, which, at the commencement of the siege, had consisted of 22,653 men, was reduced to 17,038, having had 1959 killed, 3334 wounded, or rendered unserviceable by sickness, and having lost 322 by desertion. The loss of the besiegers is stated at about 3000 men. The consumption of ammunition, on the part of the French, was found to have been
  • 57. 681,850 pounds of powder, 106,152 cannon balls, 10,278 bombs, 6,592 grenades, 44,500 pounds of iron, 300,340 musquet cartridges; and, during the siege, 107 cannon either burst, or were rendered unserviceable by the besiegers' shot. Towards the conclusion, sixty cannon also became useless by the failure of balls of the proper calibre. On the 24th and 25th, the garrison marched out, Merlin leading the first column of 7500 men. The members of the Clubs, who would have gone out with the troops, were pointed out by the other inhabitants and detained; but the Elector had the magnanimity to think of no other retaliation, than their imprisonment in a tower, near the Rhine, where they have since remained. There was now leisure to examine the city, and it was found, that six churches were in ruins; that seven mansions of the nobility had been burned, and that very few houses had escaped, without some damage. The surrounding grounds were torn up by balls and batteries. The works of Cassel were surrendered entire to the conquerors, and are an important addition to the strength of Mentz, already reckoned one of the strongest and largest fortifications in Europe. Between Cassel and the ruins of Kostheim not a tree was to be seen. All the neighbouring villages were more, or less, injured, being contended for, as posts, at the commencement of the siege; and the country was so much disfigured, that the proprietors of lands had some difficulty to ascertain their boundaries.
  • 58. MENTZ. Something has been already said of the present condition of this city: upon a review it appears, that from the mention of churches, palaces, burgesses, quays and streets, we might be supposed to represent it as a considerable place, either for splendour, or commerce, or for having its middle classes numerously filled. Any such opinion of Mentz will be very incorrect. After two broad and somewhat handsome streets, all the other passages in the city are narrow lanes, and into these many of the best houses open, having, for the most part, their lower windows barricadoed, like those of Cologne. The disadvantage, with which any buildings must appear in such situations, is increased by the neglected condition of these; for a German has no notion, that the outside of his house should be clean, even if the inside is so. An Englishman, who spends a few hundred pounds in a year, has his house in better condition, as to neatness, than any German nobleman's we saw; a Dutchman, with fifty pounds a year, exceeds both. The Elector's palace is a large turreted building of reddish stone, with one front towards the Rhine, which it commands in a delightful point of view; but we did not hear, that it was so much altered, by being now used as a barrack, as that its appearance can formerly have been much less suitable than at present to such a purpose. On the quay there is some appearance of traffic, but not much in the city; so that the transfer of commodities from vessels of other districts to those of the Electorate may be supposed to contribute great part of the show near the river. The commerce is not sufficient to encourage the building of warehouses over the quay. The vessels are ill rigged, and the hulls are entirely covered with pitch, without paint. About thirty of these, apparently from forty to seventy tons burthen, were lying near the quay; and the war could scarcely have diminished their usual number, so many being employed in carrying stores for the armies.
  • 59. The burgesses are numerous, and have some privileges, which render their political condition enviable to the other inhabitants of the Electorate. But, though these have invited manufacturers, and somewhat encouraged commerce, there is not wealth enough in the neighbouring country, to make such a consumption, as shall render many traders prosperous. In point of wealth, activity and address, the burgesses of Mentz are much below the opinion, which must be formed, while German cities are described and estimated by their importance in their own country, rather than by a comparison of their condition with that of others. A trader, it will be allowed, is at least as likely to appear to advantage in his business as in any other state. His intelligence may surely be, in some degree, judged of by those, who deal with him; and that we might know something of those of Mentz, we passed some of the little time we were left to ourselves in endeavouring to buy trifles at their shops. The idleness and inadvertence we generally saw are difficult to be conceived; perhaps, the trouble, experienced in purchasing a book, may give an idea of them. We wanted the German pamphlet, from which most of the above-mentioned particulars of the siege are extracted; and, as it related to a topic so general within the place, we smiled, when our friends said they would assist us to procure it, during a walk. Two booksellers, to whom we applied, knew nothing of it; and one supposed, that an engraved view of the works would do quite as well. Passing another shop, a young German gentleman enquired for it of the master, who was at the door, and heard, that we might have it, upon our return, in half an hour. The door, when we came back, was shut, and no knocking could procure it to be opened; so that we were obliged to send into the dwelling-house. When the shopman came, he knew nothing of the book; but, being assured that his master had promised it, went away, and returned with a copy in sheets. We paid for this, and left it to be sewed, which was agreed to be done, in three hours. At that time, it was not finished, but might be had in another hour; and, after that hour, it was again promised, within two. Finally, it could not be had, that night, but would be ready in the morning, and, in the morning, it
  • 60. was still unfinished; we then went to Franckfort without it, and it was sent after us by a friend. This was the most aggravated instance we saw of a German trader's manners; but something like it may be almost every where met with. From such symptoms and from the infrequency of wealth among the middle classes it is apparent, that Mentz could not have been important, as to commerce, even if there had been no siege, which is here mentioned as the cause of all deficiencies, and certainly is so of many. The destruction of property, occasioned by it, will not be soon remedied. The nobility have almost forsaken a place, where their palaces have been either destroyed, or ransacked; the Prince has no residence there; some of the Germans, who emigrated on account of the last siege, fled into France; the war-taxes, as well as the partial maintenance of the garrison, diminish what property remains; and all expenditure is upon a reduced footing. The contribution of the inhabitants towards a support of the garrison is made by the very irksome means of affording them lodging. At the best houses, the doors are chalked over with the names of officers, lodged in them; which the servants dare not efface, for the soldiers must know where to find their officers. In a family, whom we visited, four officers and their servants were quartered; but it must be acknowledged, that the former, so far from adding to this inconvenience by any negligent conduct, were constantly and carefully polite. We, indeed, never saw Prussian officers otherwise; and can testify, that they are as much superior to those Austrians in manners and intelligence, as they are usually said to be in military qualities. Another obstruction, which the siege has given to the prosperity of Mentz, consists in the absence of many members of the Noble Chapter; an institution, which, however useless, or injurious to the country, occasions the expenditure of considerable sums in the capital. That of Mentz is said to be one of the richest of many similar Chapters in Germany. From such foundations the younger sons of
  • 61. noble families derive sometimes very ample incomes, and are but little restricted by their regulations from any enjoyment of temporal splendour. Their carriages and liveries vie with those of the other attendants at Court; they are not prohibited from wearing the ornaments of orders of knighthood; are very little enjoined to residence; are received in the environs of the Court with military honours, and allowed to reside in their separate houses. They may wear embroidery of gold, and cloths of any colours, except scarlet, or green, which, as well as silver lace, are thought too gay. Being thus permitted and enabled to become examples of luxury, their residence in any city diffuses some appearance of prosperity over it. One of the largest buildings in Mentz is the arsenal, which fronts towards the river, and attracts the attention of those, who walk upon the quay, by having armed heads placed at the windows of the first floor, which seem to frown, with Roman sternness, upon the passenger. In one of the principal rooms within, a party of figures in similar armour are placed at a council-board. We did not hear who contrived them; but the heads in the windows may be mistaken for real ones, at the distance of fifty yards. The Elector of Mentz, who is chosen by a Chapter of twenty-four Canons, and is usually one of their number, is the first ecclesiastical Prince in the empire, of which he is also the Arch-chancellor and Director of the Electoral College. In the Diet, he sits on the right hand of the Emperor, affixes the seal of the Empire to its decrees, and has afterwards the custody of them among the archives. His revenues, in a time of peace, are nearly 200,000l. annually; but, during a war, they are much less, a third part of them arising from tolls, imposed upon the navigation of the Rhine. The vineyards supply another large part; and his subjects, not interested in them, are but little taxed, except when military preparations are to be made; the taxes are then as direct as possible, that money may be immediately collected.
  • 62. The fortifications of his chief city are as much a misfortune to his country as they are an advantage to the rest of the Empire. Being always one of the first objects, on this side of the Rhine, since an enemy cannot cross the river, while so considerable a fortress and so large a garrison as it may contain, might, perhaps, check their return, the Electorate has been often the scene of a tedious warfare. From the first raising of the works by Louis the Fourteenth, their strength has never been fully tried. The surrender in 1792 was partly for the want of a proper garrison, and partly by contrivance; even in 1793, when the defence was so furious and long, the garrison, it is thought, might have held out further, if their stores had been secured in bomb-proof buildings. A German garrison, supported by an army, which should occupy the opposite bank of the Rhine, might be continually reinforced and supplied, so as to be conquered by nothing but the absolute demolition of the walls. The bridge of boats over the Rhine, which, both in peace and war, is so important to the city, is now in a much better state than the French found it, being guarded, at the eastern end, by the fortifications of Cassel. Notwithstanding its great length and the rapidity of the river, it is so well constructed, as to be much less liable to injury, than might be supposed, and would probably sustain batteries, which might defeat every attempt at destroying it by fireships. It is 766 feet long, and wide enough for the passage of two carriages at once. Various repairs, and the care of a daily survey, have continued it, since 1661, when it was thrown over the river. The practice of modifying the names of towns so as to incorporate them separately with every language, is no where more remarkable than with respect to those of Germany, where a stranger, unless he is aware of them, might find the variations very inconvenient. The German name for what we call Mentz, is Maynz; the French, which is most used, Mayence; and the Italian Magontio, by descent from the Roman Magontiacum. The German synonym for Liege is Luttich; for Aix la Chapelle, Achen; for Bois le Duc, Herzogenbusch; and for
  • 63. Cologne, Cöln, which is pronounced Keln. The name borne by every town in the nation to which it belongs, should surely be its name, wherever it is mentioned; for the same reason, that words, derived into one language from another, are pronounced according to the authority of their roots, because the use of the primary term is already established, and there can never be a decision between subsequent varieties, which are cotemporary among themselves, and are each produced by the same arrogance of invention. FRANCKFORT. We came hither by means of a passage boat, which we were told would shew something of the German populace, but which displayed nothing so much as the unskilfulness of the German sailors. Though they make this voyage, every day, they went aground in the even stream of the Maine, and during the calmest weather; fixing the vessel so fast by their ill-directed struggle to get off, that they were compelled to bring the towing horses to the side and tug backward with the stream. There were an hundred people in the boat; but the expedient of desiring them to remove from the part, which was aground, was never used. We heard, that they seldom make the voyage, without a similar stoppage, not against any shifting sand, but upon the permanent shelves of the river. The distance is about four-and-twenty miles, but we were nine hours in reaching Franckfort, the environs of which afford some symptoms of a commercial and opulent city, the banks of the Maine being covered for nearly the last mile with country seats, separated from each other by small pleasure grounds. There are gates and walls to Franckfort, but the magistrates do not oppress travellers by a military examination at their entrance. Having seen the worthlessness of many places, which bear
  • 64. ostentatious characters either for splendour or trade, we were surprised to find in this as much of both as had been reported. The quays were well covered with goods and labourers; the streets nearest to the water are lined with shops, and those in the middle of the city with the houses of merchants, of which nearly all are spacious, and many magnificent. Some, indeed, might be called palaces, if they had nobility for their tenants; but, though the independence, which commerce spreads among the middle classes, does not entirely deter the German nobility from a residence here, the finest houses are the property of merchants. In our way to the Cigne Blanc, which is one of the best inns, we passed many of so good an appearance, that it was difficult to believe there could be better in a German city. But Franckfort, which is the pride of Germany, in this respect, has probably a greater number of large inns than any other place of equal extent in Europe. The fairs fill these, twice in a year, for three weeks, at each time; and the order, which is indispensible then, continues at other periods, to the surprise and comfort of strangers. This city has been justly described by many travellers; and Doctor Moore has treated of its inhabitants with the ease and elegant animation of his peculiar manner. We shall not assume the disadvantage of entering upon the same subject after him. The inhabitants of Franckfort are very distinct, as to manners and information, from the other Germans; but they are so far like to those of our own commercial cities, that one able account leaves scarcely any thing new to be seen, or told, concerning them. All their blessings of liberty, intelligence, and wealth are observed with the more attention, because they cannot be approached, except through countries afflicted by arbitrary power, ignorance and poverty. The existence of such a city, in such a situation, is little less than a phenomenon; the causes of which are so various and minute as to make the effect, at first sight, appear almost accidental. The jealousy of the neighbouring Princes towards each other, is the
  • 65. known, and, certainly, the chief cause of its exterior protection against each; the continuance of its interior liberties is probably owing to the circumstance, which, but for that jealousy, would expose it to subjection from without,—the smallness of its territory. Where the departments of government must be very few, very difficult to be rendered expensive to the public, and very near to their inspection, the ambition of individuals can be but little tempted to contrive encroachments upon the community. So complexly are the chief causes of its exterior and interior independence connected with each other. As to the first of these, it may, perhaps, be replied, that a similar jealousy has not always been sufficient to protect similar cities; and Dantzick is the recent instance of its insufficiency. But the jealousy, as to Dantzick, though similar, was not equal to this, and the temptation to oppose it was considerably greater. What would the most capable of the neighbouring Princes gain by the seizure of Franckfort? A place of strength? No. A place capable of paying taxes? Yes; but taxes, which would be re-imposed upon commodities, consumed partly by his own subjects, whose property is his own already, and partly by those of his neighbours, to whose jealousy they would afford an additional and an unappeasable provocation. Dantzick, on the contrary, being a seaport, was, if not strong, capable of supplying strength, and might pay taxes, which should not fall entirely upon its neighbours, but upon the distant countries, that traffick with it. And even to these considerations it is unnecessary to resort, unless we can suppose, that despotism would have no effect upon commerce; a supposition which does not require to be refuted. If a severe taxation was introduced here, and, in so small a district, taxation must be severe to be productive; if such a taxation was to be introduced, and if the other advantage of conquest, that of a forcible levy of soldiers, was attempted, commerce would vanish in silence before the oppressor, and the Prince, that should seize the liberties of Franckfort, would find nothing but those liberties in his grasp.
  • 66. On the other hand, what are the advantages of permitting the independence of such a city to the sovereigns, who have the power of violating it? Those of a neutral barrier are well known, but apply only to military, or political circumstances. The others are the market, which Franckfort affords, for the produce and manufactures of all the neighbouring states; its value as a banking depôt and emporium, in which Princes may place their money, without rendering it liable to the orders of each other, or from which they may derive loans, by negotiating solely and directly with the lenders; its incapacity for offensive measures; and its usefulness as a place of meeting to themselves, or their ministers, when political connections are to be discussed. That the inhabitants do enjoy this independence without and freedom within, we believe, not because they are asserted by treaties, or political forms; of which the former might not have survived the temporary interests, that concluded them, and the latter might be subdued by corruption, if there were the means of it; but because they were acknowledged to us by many temperate and discerning persons, as much aloof from faction, as they were from the affectation, or servility, that sometimes makes men boast themselves free, only because they have, or would be thought to have, a little share in oppressing others. Many such persons declared to us, that they had a substantial, practical freedom; and we thought a testimony to their actual enjoyments more valuable than any formal acknowledgments of their rights. As to these latter securities, indeed, Franckfort is no better provided than other imperial cities, which have proved their inutility. It stands in the same list with Cologne, but is as superior to it in government as in wealth. The inhabitants having had the good sense to foresee, that fortifications might render them a more desirable prize to their neighbours, at the same time that their real protection must depend upon other means, have done little more than sustain their antient walls, which are sufficient to defend them against a surprise by small parties. They maintain no troops, except a few companies of city-
  • 67. guards, and make their contributions to the army of the Empire in specie. These companies are filled chiefly with middle-aged men, whose appearance bespeaks the plenty and peacefulness of the city. Their uniforms, blue and white, are of the cut of those in the prints of Marlborough's days; and their grenadiers' caps are of the same peaked sort, with tin facings, impressed with the city arms. In wars with France, the fate of Franckfort has usually depended upon that of Mentz, which is properly called the key of Germany, on the western frontier. In the campaign of 1792, Custine detached 3000 troops of the 11,000, with which he had besieged Mentz, and these reached Franckfort, early in the morning of the 22d of October. Neuwinger, their commander, sent a letter to the magistrates from Custine, demanding a contribution of two millions of florins, which, by a negotiation at Mentz, was reduced to a million and a half, for the present. Notice was accordingly given in the city, that the magistrates would receive money at four per cent. interest, and, on the 23d, at break of day, it began to flow in to the Council-house from all quarters. Part was immediately given to Neuwinger, but payment of the rest was delayed; so that Custine came himself on the 27th, and, by throwing the hostages into prison, obtained, on the 31st of October, the remainder of the first million. For the second, the magistrates gave security to Neuwinger, but it was never paid; the Convention disavowed great part of the proceedings of Custine, and the money was not again demanded. The French, during the whole of their stay, were very eager to spread exaggerated accounts of their numbers. Troops were accordingly marched out at one gate of the city, with very little parade, that they might enter with much pomp and in a longer column, at the other. The inhabitants, who were not expert at military numeration, easily believed, that the first party had joined other troops, and that the whole amounted to treble their real number. After the entry of the Prussians, this contrivance was related by prisoners.
  • 68. The number of troops, left in the city by Custine, on his retirement from the neighbouring posts, in the latter end of November, was 1800 men, with two pieces of cannon. On the 28th, when the Prussian Lieutenant Pellet brought a summons to surrender, Helden, the commander, having sent to Custine for reinforcements and cannon, was answered, that no men could be spared; and that, as to cannon, he might use the city artillery. Helden endeavoured to remove this from the arsenal; but the populace, encouraged by the neighbourhood of the Prussians, rose to prevent him; and there might have been a considerable tumult, if Custine had not arrived, on the 29th, and assured the magistrates, that the garrison should retire, rather than expose the place to a siege. The city then became tranquil, and remained so till the 2d of December, when the inhabitants, being in church, first knew by the noise of cannon, that the place was attacked. General Helden would then have taken his two cannon to the gate, which was contended for, but the inhabitants, remembering Custine's promise, would permit no resistance; they cut the harness of the horses, broke the cannon wheels, and themselves opened the gates to the Prussians, or rather to the Hessians, for the advanced corps of the assailants was chiefly formed of them. About 100 fell in this attack. Of the French 41 were killed; 139 wounded; and 800 taken prisoners. The remainder of the 1800 reached Custine's army. A monument, erected without the northern gate of the city, commemorates the loss of the 100 assailants, on the spot, on which they fell. Thus Franckfort, having happily but few fortifications, was lost and regained, without a siege; while Mentz, in a period of six more months, had nearly all its best buildings destroyed, by a similar change of masters. We stayed here almost a week, which was well occupied by visits, but shewed nothing in addition to what is already known of the society of the place. Manners, customs, the topics of conversation
  • 69. and even dress, differ very slightly from those of London, in similar ranks; the merchants of Franckfort have more generally the advantages of travel, than those of England, but they have not that minute knowledge of modern events and characters, which an attention to public transactions renders common in our island. Those, who have been in England, or who speak English, seem desirous to discuss the state of parliamentary transactions and interests, and to remedy the thinness of their own public topics, by introducing ours. In such discussions one error is very general from their want of experience. The faculty of making a speech is taken for the standard of intellectual power in every sort of exertion; though there is nothing better known in countries, where public speakers are numerous enough to be often observed, than that persons may be educated to oratory, so as to have a facility, elegance and force in it, distinct from the endowments of deliberative wisdom; may be taught to speak in terms remote from common use, to combine them with an unfailing dexterity of arrangement, and to invest every thought with its portion of artificial dignity, who, through the chaos of benefits and evils, which the agitation of difficult times throws up before the eye of the politician, shall be able to see no gleam of light, to describe no direct path, to discern no difference between greater and lesser evils, nor to think one wholesome truth for a confiding and an honest country. To estimate the general intellectual powers of men, tutored to oratory, from their success in the practice of it, is as absurd as to judge of corporeal strength from that of one arm, which may have been rendered unusually strong by exercise and art. Of the society at Franckfort, Messrs. Bethman, the chief bankers, seem able to collect a valuable part; and their politeness to strangers induces them to do it often. A traveller, who misses their table, loses, both as to conversation and elegant hospitality, a welcome proof of what freedom and commerce can do against the mental and physical desolation otherwise spread over the country.
  • 70. The assistance, which the mutual use of languages gives to a connection between distant places, we were happy to see existing and increasing, to the advantage of England, at Franckfort. At the Messrs. Bethmans', one day, French was nearly excluded, the majority being able to converse with nine or ten English, who were there, in their own language. Of the merchants, who have not been in England, several speak English, without difficulty, and the rising generation, it is said, will be generally accomplished in it. One of the luxuries of Franckfort is a Cabinet Literaire, which is open to strangers by the introduction of members. There the best periodical publications of the Continent are received, and their titles immediately entered in a book, so that the reading is not disturbed by conversation with the librarian. It excited our shame to hear, that some contrivance had, for several months, prevented the society from receiving a very valuable English publication. After this, the Theatre may seem to require some notice. It is a modern, but not an elegant building, standing in an area, that renders it convenient of access, and nearly in the middle of the city. The interior, which has been gaudily decorated, contains a pit, three rows of boxes, that surround the audience part, and a gallery over them in the centre. It is larger than the Little Theatre in the Haymarket, and, in form, resembles that of Covent Garden, except that six or seven of the central boxes, in each tier, encroach upon the oval figure by a projection over the pit. The boxes are let by the year; the price of admission for non-subscribers, is a florin, for which they may find places in the box, engaged by their friends, or in the pit, which is in the same proportion of esteem as that at an Opera- house. The performances are plays and operas alternately; both in German; and the music of the latter chiefly by German composers. The players are very far beneath mediocrity; but the orchestra, when we heard it, accorded with the fame of German musicians, for spirit
  • 71. and precision. In these qualities even the wandering parties, that play at inns, are very seldom deficient. The stage was well lighted, but the other parts of the theatre were left in duskiness, which scarcely permitted us to see the diamonds, profusely worn by several ladies. Six o'clock is the hour of beginning, and the performances conclude soon after nine. The Cabinet Literaire and the Theatre are the only permanent places of public amusement at Franckfort, which is, however, in want of no more, the inhabitants being accustomed to pass much of their time in friendly parties, at their houses. Though wealth is, of course, earnestly and universally sought for in a place purely mercantile, we were assured, that the richest persons, and there are some, who have above half a million sterling, find no more attention in these parties than others. This was acknowledged and separately boasted of by some of the very rich, and by those who were comparatively poor. We are so far able to report it for true, as that we could never discern the least traces of the officiousness, or subserviency that, in a corrupt and debased state of society, frequently point to the wealthiest individuals in every private party. These and many other circumstances would probably render Franckfort a place of residence for foreigners, if the magistrates, either dreading the increase of luxury, or the interference of strangers with their commerce, did not prevent this by prohibiting them from being lodged otherwise than at inns. It was with difficulty, that an English officer, acting as Commissary to some of the German regiments, lately raised upon our pay, could obtain an exemption from this rule, at the request of the Hanoverian Minister. Round the city, are several well-disposed walks, as pleasant as the flatness of the nearer country will permit; and, at intervals, along these, are the country houses of the merchants, who do not choose to go beyond the city territories, for a residence. Saxenhausen, a small town, on the other side of the Maine, though incorporated with
  • 72. Franckfort, as to jurisdiction, and connected with it by a bridge, is chiefly inhabited by watermen and other labourers. We left Franckfort, after a stay of six days, fortified by a German passport from M. de Swartzhoff, the Hanoverian Minister, who obligingly advised us to be prepared with one in the native language of the Austrian officers. At Mentz, the ceremonies of examination were rendered much more troublesome than before, the Governor, General Kalkreuth, happening to be in the great square, who chose to make several travellers wait as if for a sort of review before him, though, after all, nothing was to be said but "Go to the Commandant, who will look at your passports." This Commandant was M. de Lucadou, a gentleman of considerate and polite manners, who, knowing our friends in Mentz, added to his confirmation of M. de Swartzhoff's passport an address to M. de Wilde, the Intendant of some salt mines in Switzerland, which he recommended to us to see. These circumstances are necessary to be mentioned here, because they soon led to a disagreeable and very contradictory event in our journey.
  • 73. The next morning, we set out from Mentz, and were conducted by our voiturier over a summer road, on the left bank of the Rhine, then flowing with the melted snows of Switzerland. OPPENHEIM. This is the first town of the Palatinate, on arriving from the north; and it bears marks of the devastation, inflicted upon that country, in the last century, more flagrant than could be expected, when the length of the intervening time, and the complete recovery of other cities from similar disasters, are considered. Louis the Fourteenth's fury has converted it from a populous city into little more than a picturesque ruin. It was burned in 1668; and the walls, which remain in double, or sometimes in treble circles, are more visible, at a distance, than the streets, which have been thinly erected within them. Above all, is the Landscroon, or crown of the country, a castle erected on an eminence, which commands the Rhine, and dignifies the view from it, for several miles. The whole city, or rather ruin, stands on a brow, over this majestic river. The gates do not now open directly into streets, but into lanes of stone walls between vineyards and gardens, formed on the site of houses, never restored, since the fire. The town itself has shrunk from its antient limits into a few streets in the centre. In some of the interstices, corn grows up to the walls of the present houses. In others the ruins of former buildings remain, which the owners have not been tempted to remove, for the sake of cultivating their sites. Of the cathedral, said to have been once the finest on the Rhine, nearly all the walls and the tower still exist; but these are the only remains of grandeur in a city, which seems entirely incapable of overcoming in this century the wretchedness it inherits from the last.
  • 74. Had the walls been as strong as they are extensive, this place might not improbably have endured a siege in the present age, having been several times lost and regained. It was surrendered to the French, without a contest, in the campaign of 1792. After their retreat from Worms, and during the siege of Mentz, it was occupied by the Prussians; and, in December 1793, when the allies retired from Alsace, the Duke of Brunswick established his head-quarters in it, for the purpose of covering the fortress. His army ovens remained near the northern gate, in July 1794, when we passed through it. In October of the same year it fell again into the hands of the French. No city on the banks of the Rhine is so well seated for affording a view of it as this, which, to the north, overlooks all its windings as far as Mentz, and, southward, commands them towards Worms. The river is also here of a noble breadth and force, beating so vehemently against the watermills, moored near the side, that they seem likely to be borne away with the current. A city might be built on the site of Oppenheim, which should faintly rival the castle of Goodesberg, in the richness, though not in the sublimity of its prospect. From hence the road leads through a fertile country of corn and vines, but at a greater distance from the river, to Worms, five or six miles from which it becomes broad, straight, and bordered with regularly-planted trees, that form an avenue to the city. Soon after leaving Oppenheim, we had the first symptom of an approach to the immediate theatre of the war, meeting a waggon, loaded with wounded soldiers. On this road, there was a long train of carriages, taking stores to some military depôt. The defacement of the Elector's arms, on posts near the road, shewed also, that the country had been lately occupied by the French; as the delay in cutting the ripe corn did, that there was little expectation of their return.
  • 75. WORMS. The condition of Worms is an aggravated repetition of the wretchedness of Oppenheim. It suffered something in the war, which the unfortunate Elector, son-in-law of our James the First, provoked by accepting the kingdom of Bohemia. Louis the Fourteenth came upon it next, and, in 1669, burned every thing that could be consumed. Nothing was restored, but on that part, which was the centre of the antient city; and the walls include, as at Oppenheim, corn and vineyards upon the ground, which was once covered with houses, and which plainly appears to have been so, from the lanes that pass between, and doors that open into the inclosures. A much larger space is so covered, than at Oppenheim, for you are some time in driving from the northern gate of the old city to the first street of the present one. On the right of the road stands the skeleton of the Electoral palace, which the French burned in one of the late campaigns; and it is as curious as melancholy to observe how the signs of antient and modern desolation mingle with each other. On one hand is a palace, burned by the present French; on the other, the walls of a church, laid open by Louis the Fourteenth. The first and principal street of the place leads through these mingled ruins, and through rows of dirty houses, miserably tenanted, to the other end of the city. A few others branch from it, chiefly towards the Rhine, including sometimes the ruins, and sometimes the repaired parts of churches; of which streets, narrow, ill-paved and gloomy, consists the city of Worms. The French General, that lately wrote to Paris, "We entered the fair episcopal city of Worms," may be supposed to have derived his terms from a geographical dictionary, rather than from a view of his conquest. We were now in a place, occupied by part of the acting army of the allies, which, if not immediately liable to be attacked, was to be defended by the maintenance of posts, at a very short distance.
  • 76. Troops passed through it daily, for the service of these posts. The noise of every cannonade was audible, and the result of every engagement was immediately known, for it might make an advance, or a retreat necessary from Worms. The wounded men arrived, soon after the intelligence, to the military hospitals of the Prussians. A city, so circumstanced, seemed to differ but little from a camp; and we were aware, for a few hours, of a departure from the security and order of civil life. The inn, which was not otherwise a mean building, was nearly destitute of furniture; so that the owner was prepared to receive any sort of guests, or masters. The only provision which we could obtain was bread, the commonest sort of wine, and one piece of cold veal; for the city was under military jurisdiction, and no guests were allowed to have more than one dish at their table. In the afternoon, we saw, for the first time, a crowd in a German city. A narrow waggon, of which nearly all but the wheels was basket-work, had arrived from the army, with a wounded officer, who lay upon the floor, supported by his servant, but occasionally rose to return the salutes of passengers. This was the Prince of Anhalt Plessis, who had been wounded, in the morning, when the French attacked all the neighbouring lines of the allies, and an indecisive engagement ensued, the noise of which had been distinctly heard, at Worms. He was hurt in the leg, and descended, with much difficulty, from the waggon; but did not, for an instant, lose the elegance of his address, and continued bowing through the passage to his apartment. No doubt was entertained of his recovery, but there seemed to be a considerable degree of sympathy, attending this young man. We had not time to look into the churches, or numerous monasteries, that yet remain, at Worms; the war appeared to have depopulated the latter, for not a monk was to be seen. The cathedral, or church of St. Mary and St. Peter, is one of the most antient sacred buildings in Germany, having been founded at least as
  • 77. early as the commencement of the seventh century. One of the prebends was established in 1033, another in 1058. The Dominicans, Carmelites, Capuchins and Augustines have each a monastery, at Worms; as have the Cistercians and the Augustines a nunnery. A Protestant church was also consecrated, on the 9th of June 1744; something more than two hundred years, after the ineffectual conference held here of Protestant and Catholic divines, which Charles the Fifth interrupted, when Melancthon, on one side, and Echius, on the other, had engaged in it, ordering them to resume their arguments, in his presence, at Ratisbon. This meeting was five years previous to the celebrated diet of Worms, at which Charles, having then estimated the temporal strength of the two parties, openly shewed his animosity to the Protestants, as Maurice of Saxony did his intriguing ambition, by referring the question to the Council of Trent. The Jews, at Worms, inhabit a separate street, and have a synagogue, of great antiquity, their numbers having been once such as to endanger the peace of the city; but, in 1689, when the French turned their synagogue into a stable, they fled with the rest of the opulent inhabitants to Holland. Those of the present day can have very few articles of traffic, except money, the changing of which may have been frequent, on account of the neighbourhood of France. Worms is somewhat connected with English history, having been occupied by the troops, which James the First uselessly sent to the assistance of the proscribed Elector Palatine, when his just abhorrence of continental wars was once, though tardily, overcome by the entreaties of his daughter. Here too George the Second held his head-quarters, from the 7th to the 20th of September 1743; on the 14th of which month, Lord Carteret concluded, in his name, an offensive and defensive treaty with the Ministers of Hungary and Sardinia. This city, like Cologne, retains some affectation of the Roman form of government, to which it was rendered subject by Cæsar, with the
  • 78. Welcome to Our Bookstore - The Ultimate Destination for Book Lovers Are you passionate about books and eager to explore new worlds of knowledge? At our website, we offer a vast collection of books that cater to every interest and age group. From classic literature to specialized publications, self-help books, and children’s stories, we have it all! Each book is a gateway to new adventures, helping you expand your knowledge and nourish your soul Experience Convenient and Enjoyable Book Shopping Our website is more than just an online bookstore—it’s a bridge connecting readers to the timeless values of culture and wisdom. With a sleek and user-friendly interface and a smart search system, you can find your favorite books quickly and easily. Enjoy special promotions, fast home delivery, and a seamless shopping experience that saves you time and enhances your love for reading. Let us accompany you on the journey of exploring knowledge and personal growth! ebookgate.com