soften language

book/CH00_Introduction.adoc

@@ -42,7 +42,7 @@ system of the web.
 
 To explain what a hypermedia-driven application looks like, and to contrast it with the popular SPA approach of today,
 we need to first explore the entire _hypermedia system_ of the web, beyond just discussing HTML.  We need to look at the
-_network architecture_ of the original web, including how a web server delivers a hypermedia API, and how to effectively
+_network architecture_ of the web, including how a web server delivers a hypermedia API, and how to effectively
 use the hypermedia features available in the hypermedia _client_ (e.g., the browser).
 
 Each of these are important aspects of building an effective hypermedia-driven application, and it is the entire
@@ -105,7 +105,7 @@ The book is broken into three parts:
 * Next we will look at how we can use https://htmx.org[htmx], a hypermedia-oriented JavaScript library created by the
   authors of this book, to improve Contact.app.  By using htmx, we will be able to achieve a level of interactivity in our
   application that many developers would expect to require a large, sophisticated front end library, such as React.
-  Thanks to htmx, we will be able to do this _without_ abandoning hypermedia as a system architecture.
+  Thanks to htmx, we will be able to do this using hypermedia as our system architecture.
 
 * Finally, we will look at a completely different hypermedia system, Hyperview.  Hyperview is a _mobile_ hypermedia system, related to, but distinct from the web and created by one of the authors of this book -- Adam Stepinski.  It supports _mobile specific_ features by providing not only a mobile specific hypermedia, but also a mobile hypermedia client, a network protocol and so on.  It provides a full _mobile hypermedia system_ for you to build your mobile application with, and, in doing so, makes it possible to build mobile Hypermedia-Driven Applications.
 

book/CH01_HypermediaAReintroduction.adoc

@@ -376,23 +376,24 @@ are updated via JavaScript code and the framework then "`reacts`" to these chang
 When the user interface is updated by a user these changes also flow _into_ the model objects, establishing a "`two-way`"
 binding mechanism: the model can update the UI, and the UI can update the model.
 
-This is all very sophisticated and, today, very popular.  However, web developers that adopt this approach to building
-their web applications are abandoning the web's underlying hypermedia system.
+This is a much more sophisticated approach to a web client than hypermedia, and it typically does away almost entirely
+with the underlying hypermedia infrastructure available in the browser.
 
 HTML is still used to build user interfaces, but the _hypermedia_ aspect of the two major hypermedia controls,
-anchors and forms, are ignored.  Neither tag interacts with a server via their native _hypermedia_ mechanism.  Rather,
-they become mere user interface elements that drive local interactions with the in-memory domain model via JavaScript,
+anchors and forms, are unused.  Neither tag interacts with a server via their native _hypermedia_ mechanism.  Rather,
+they become user interface elements that drive local interactions with the in-memory domain model via JavaScript,
 which is then synchronized with the server using plain data JSON APIs.
 
-So, as with our simple button above, the Single Page Application approach is _not_ built on top of a hypermedia architecture.
-It does not take advantage of the existing RESTful architecture of the web, nor does it utilize the built-in functionality
-found in HTML's native hypermedia controls.
+So, as with our simple button above, the Single Page Application approach foregoes the hypermedia architecture.
+It leaves aside the advantages of the existing RESTful architecture of the web and the built-in functionality
+found in HTML's native hypermedia controls in favor of JavaScript driven behaviors.
 
 SPAs are more much like _thick client applications_, that is, like the client-server applications of the
 1980s -- an architecture popular _before_ the web came along and that the web was, in many ways, a reaction to.
 
-This approach _isn't necessarily wrong_, but it is worth thinking about _why_ web developers so frequently take it and
-if there are reasons _not_ to go down this path.
+This approach isn't necessarily wrong, of course: there are times when a thick client approach is the appropriate choice
+for an application.  But it is worth thinking about _why_ web developers so frequently make this choice without
+considering other alternatives, and if there are reasons _not_ to go down this path.
 
 == Why Use Hypermedia?
 
@@ -409,15 +410,15 @@ marketing sites and blogs.
 ____
 
 The JavaScript-based Single Page Application approach has taken the web development world by storm, and if there was one
-major for its wild success it was this: The Single Page Application offers a far more interactive and immersive experience
+single for its wild success it was this: The Single Page Application offers a far more interactive and immersive experience
 than the old, gronky, Web 1.0 hypermedia-based applications could.  SPAs had the ability to smoothly update elements inline on
 a page without a dramatic reload of the entire document, they had the ability to use CSS transitions to create nice visual effects,
 and the ability to hook into arbitrary events like mouse movements.
 
-All of these gave JavaScript-based applications a huge advantage in building sophisticated user experiences.
+All of these abilities give JavaScript-based applications a huge advantage in building sophisticated user experiences.
 
-So, given this success, why on earth would you set aside this popular and modern approach to consider an older and
-less popular approach like hypermedia?
+Given the popularity, power and success of this modern approach to building web applications, why on earth would you
+consider an older, clunkier and less popular approach like hypermedia?
 
 === JavaScript Fatigue
 
@@ -446,7 +447,7 @@ jump through to get anything done in modern-day web applications.
 We believe that a hypermedia architecture can help cure JavaScript Fatigue for many developers and teams.
 
 But if hypermedia is so great, and if it addresses so many of the problems that beset the web
-development industry, why was it abandoned in the first place?  After all, hypermedia was there first.  Why didn't web
+development industry, why was it set aside in the first place?  After all, hypermedia was there first.  Why didn't web
 developers just stick with it?
 
 There are two major reasons hypermedia hasn't made a comeback in web development.
@@ -469,17 +470,17 @@ Single Page Application approach. The shift was not driven by any inherent super
 architecture.
 
 It didn't have to be this way.  There is nothing _intrinsic_ to the idea of hypermedia that prevents it from having a
-richer, more expressive interactivity model than vanilla HTML.  Rather than abandoning
-the hypermedia architecture, the industry could have demanded more interactivity from HTML.
+richer, more expressive interactivity model than vanilla HTML.  Rather than moving away from a hypermedia-based
+approach, the industry could have demanded more interactivity from HTML.
 
-But the industry didn't.  Instead, it reverted to making thick-client style applications within web browsers, in an
+Instead, building thick-client style applications within web browsers became the standard, in an
 understandable move to a more familiar model for building rich applications.
 
-Not everyone abandoned hypermedia, of course. There have been heroic efforts to continue to advance hypermedia outside of
+Not everyone set aside hypermedia, of course. There have been heroic efforts to continue to advance hypermedia outside of
 HTML, efforts like HyTime, VoiceXML, and HAL.
 
-But HTML, the most widely used hypermedia in the world, mostly stopped making progress as a hypermedia. The web development
-world moved on, solving the interactivity problems with HTML by adopting JavaScript-based SPAs and, inadvertently,
+But HTML, the most widely used hypermedia in the world, stopped making progress as a hypermedia. The web development
+world moved on, solving the interactivity problems with HTML by adopting JavaScript-based SPAs and, mostly inadvertently,
 a completely different system architecture.
 
 == A Hypermedia Resurgence?
@@ -487,7 +488,7 @@ a completely different system architecture.
 It is interesting to think about how HTML _could_ have advanced.  Instead of stalling as a hypermedia, how could HTML
 have continued to develop? Could it have kept adding new hypermedia controls and increasing the expressiveness of
 existing ones?  Would it have been possible to build modern web applications within this original, hypermedia-oriented
-and RESTful model that made the early web so powerful, so flexible, so... fun?
+and RESTful model that made the early web so powerful, so flexible, so much fun?
 
 This might seem like idle speculation, but we have some good news on this score: in the last decade a few
 idiosyncratic, alternative front end libraries have arisen that attempt to get HTML moving again.  Ironically, these
@@ -610,7 +611,7 @@ An HTTP response to this htmx-driven request might look something like this:
 This small bit of HTML would be placed into the element in the DOM with the id `contact-ui`.
 
 Thus, this htmx-powered button is exchanging _hypermedia_ with the server, just like an anchor tag or form
-might, and thus the interaction is still within the original hypermedia model of the web.  Htmx _is_ adding functionality
+might, and thus the interaction is still using the basic hypermedia model of the web.  Htmx _is_ adding functionality
 to this button (via JavaScript), but that functionality is _augmenting_ HTML as a hypermedia. Htmx extends the hypermedia
 system of the web, rather than _replacing_ that hypermedia system with a totally different architecture.
 
@@ -713,8 +714,4 @@ of this book we will reintroduce you to the core, practical concepts of hypermed
 you can take advantage of this system architecture in your own software.
 
 In the coming chapters you will develop a firm understanding of all the benefits and techniques enabled by this approach.
-We hope that, in addition, you will also become as passionate about it as we are.
-
-This book is, in part, a plea that we "`let the web be the web`", that we take the original architecture of the web
-seriously, and that we consider the entire _hypermedia system_ it makes available to us when we build applications
-with it.
+We hope that, in addition, you will also become as passionate about it as we are.

book/CH03_BuildingASimpleWebApplication.adoc

@@ -861,7 +861,7 @@ It turns out that we can improve the user experience of this application while r
 architecture.
 
 In the next few chapters we will look at https://htmx.org[htmx], a hypermedia-oriented library
-that will let us improve our contact application _without_ abandoning the hypermedia approach we have used so far.
+that will let us improve our contact application while retaining the hypermedia-based approach we have used so far.
 
 [.design-note]
 .HTML Notes: Semantic HTML

book/CH04_ExtendingHTMLAsHypermedia.adoc

@@ -194,7 +194,7 @@ a Single Page Application, where only part of the DOM is updated by a given user
 == Extending HTML as a Hypermedia with Htmx
 
 These four opportunities present us a way to extend HTML well beyond its current abilities, but
-in a way that is _entirely within_ the original hypermedia model of the web. The fundamentals of HTML, HTTP, the browser,
+in a way that is _entirely within_ the hypermedia model of the web. The fundamentals of HTML, HTTP, the browser,
 and so on, won't be changed dramatically.  Rather, these generalizations of _existing functionality_ already found within
 HTML would simply let us accomplish _more_ using HTML.
 
@@ -824,7 +824,7 @@ If you have ever used a Single Page Application and accidentally clicked the bac
 application state and have to start over, you have seen this problem in action.
 
 In htmx, as with Single Page Application frameworks, you will often need to explicitly work with the history API.
-Fortunately, since htmx sticks so close to the original model of the web and since it is declarative, getting web history
+Fortunately, since htmx sticks so close to the native model of the web and since it is declarative, getting web history
 right is typically much easier to do in an htmx-based application.
 
 Consider the button we have been looking at to load contacts:
@@ -882,7 +882,7 @@ conceptually coherent with the underlying markup language.  Like any technical c
 trade-offs: by staying so close to HTML, htmx does not give developers a lot of infrastructure that many might feel 
 should be there "`by default`".
 
-By staying closer to the original model of the web, htmx aims to strike a balance between simplicity and functionality,
+By staying closer to the native model of the web, htmx aims to strike a balance between simplicity and functionality,
 deferring to other libraries for more elaborate frontend extensions on top of the existing web platform.  The good news
 is that htmx plays well with others, so when these needs arise it is often easy enough to bring in another library to handle
 them.

book/CH05_htmxPatterns.adoc

@@ -9,7 +9,7 @@ we will have a more _powerful hypermedia_ to work with, allowing us to accomplis
 
 This will allow us to address user experience issues, such as long feedback cycles or painful page refreshes, without
 needing to write much, if any, JavaScript, and without creating a JSON API.  Everything will be implemented in hypermedia,
-using the core concepts of the original web.
+using the core hypermedia concepts of the early web.
 
 == Installing Htmx
 
@@ -1032,7 +1032,7 @@ a span and then add the `revealed` event trigger.
 The fact that switching to infinite scroll was so easy shows how well htmx generalizes HTML: just a few attributes allow
 us to dramatically expand what we can achieve in the hypermedia.
 
-And, again, we are doing all this within the original, RESTful model of the web. Despite all this new
+And, again, we are doing all this within the native, RESTful model of the web. Despite all this new
 behavior, we are still exchanging hypermedia with the server, with no JSON API response to be seen.
 
 As the web was designed.

book/CH10_JSONDataAPIs.adoc

@@ -7,7 +7,7 @@
 == JSON Data APIs
 
 So far we have been focusing on using hypermedia to build Hypermedia-Driven Applications.  In doing so we are
-following the original networking architecture of the web, and building a RESTful system, in the original sense
+following the native network architecture of the web, and building a RESTful system, in the original sense
 of that term.
 
 However, today, we should acknowledge that many web applications are often _not_ built using this approach.  Instead, they use a

book/_old/ARCHIVED_gross_history_of_web.adoc

@@ -160,7 +160,7 @@ Martin Fowler's writing.  Note that the data here is "plain": we don't see any a
 properties and their values.
 
 This approach was disdainfully referred to as "The Swamp of POX", or Plain Old XML.  Fowler made the point that,
-in adopting this technique for exchanging information with a remote system, engineers were abandoning the hypermedia
+in adopting this technique for exchanging information with a remote system, engineers were leaving the hypermedia
 model entirely and were really using HTTP to implement their own Remote Procedure Call (RPC) mechanism.
 
 ===== Level 1: Resources