From dbd6adca5c8a7be9b450f9b7fb4809e837f7771a Mon Sep 17 00:00:00 2001 From: Bill Talcott Date: Wed, 15 Mar 2023 12:32:12 -0400 Subject: [PATCH] edits, frontend and backend consistency --- book/CH00_Introduction.adoc | 2 +- book/CH02_ComponentsOfAHypermediaSystem.adoc | 2 +- book/CH05_ExtendingHTMLAsHypermedia.adoc | 2 +- book/CH07_MorehtmxPatterns.adoc | 4 ++-- book/CH10_ScriptingInAHypermediaApplication.adoc | 2 +- book/CH11_JSONDataAPIs.adoc | 4 ++-- 6 files changed, 8 insertions(+), 8 deletions(-) diff --git a/book/CH00_Introduction.adoc b/book/CH00_Introduction.adoc index d2a7445..1f721e8 100644 --- a/book/CH00_Introduction.adoc +++ b/book/CH00_Introduction.adoc @@ -31,7 +31,7 @@ This JavaScript runtime is so powerful, in fact, that today many developers igno browser, in favor of building their web applications entirely in JavaScript. Applications built in this manner have come to be called Single Page Applications (SPAs). Rather than navigating between pages, these web applications use JavaScript for updating the user interface directly. When they communicate with a server, these applications -typically use JSON API calls via AJAX. And they often update the user interface using a "`reactive`" style front-end +typically use JSON API calls via AJAX. And they often update the user interface using a "`reactive`" style frontend JavaScript library. In these applications HTML becomes a (somewhat awkward) graphical interface description language that is used diff --git a/book/CH02_ComponentsOfAHypermediaSystem.adoc b/book/CH02_ComponentsOfAHypermediaSystem.adoc index d1f4806..dd6d264 100644 --- a/book/CH02_ComponentsOfAHypermediaSystem.adoc +++ b/book/CH02_ComponentsOfAHypermediaSystem.adoc @@ -306,7 +306,7 @@ this means that nearly any programming language can be used to build a hypermedi libraries available for building HTTP-based hypermedia servers in nearly every programming language imaginable. This is one of the best aspects of adopting hypermedia as your primary technology for building a web application: it removes -the pressure of adopting JavaScript as a back-end technology. In contrast, if you decide to adopt a JavaScript-heavy +the pressure of adopting JavaScript as a backend technology. In contrast, if you decide to adopt a JavaScript-heavy Single Page Application-based front end, and you use JSON Data APIs, you will feel significant pressure to adopt JavaScript on the back end. diff --git a/book/CH05_ExtendingHTMLAsHypermedia.adoc b/book/CH05_ExtendingHTMLAsHypermedia.adoc index 0c98423..f292501 100644 --- a/book/CH05_ExtendingHTMLAsHypermedia.adoc +++ b/book/CH05_ExtendingHTMLAsHypermedia.adoc @@ -888,6 +888,6 @@ would need to use a 3rd party library or roll your own modal implementation and to use modals within an htmx-based application. By staying closer to the original model of the web, htmx aims to strike a balance between simplicity and functionality, -deferring to other libraries for more elaborate front-end extensions on top of the existing web platform. The good news +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. diff --git a/book/CH07_MorehtmxPatterns.adoc b/book/CH07_MorehtmxPatterns.adoc index b0d1cff..4468f7b 100644 --- a/book/CH07_MorehtmxPatterns.adoc +++ b/book/CH07_MorehtmxPatterns.adoc @@ -22,7 +22,7 @@ when Google adopted it for search results, and many applications now implement i To implement Active Search, we are going to use techniques closely related to the way we did email validation in the previous chapter. If you think about it, the two features are similar in many ways: in both cases we want to issue a request as the user types into an input and then update some other element with a response. The server-side implementations -will, of course, be very different, but the front-end code will look fairly similar due to htmx's general approach of "`issue +will, of course, be very different, but the frontend code will look fairly similar due to htmx's general approach of "`issue a request on an event and replace something on the screen.`" === Our Current Search UI @@ -165,7 +165,7 @@ bit_ of HTML, rather than a full document. Currently, we are letting the server and then, on the client side, we filter the HTML down to the bits that we want. This is easy to do, and, in fact, might be necessary if we don't control the server side or can't easily modify responses. -In our application, however, since we are doing "`Full Stack`" development (that is: we control both front-end _and_ back-end +In our application, however, since we are doing "`Full Stack`" development (that is: we control both frontend _and_ backend code, and can easily modify either) we have another option: we can modify our server responses to return only the content necessary, and remove the need to do client-side filtering. diff --git a/book/CH10_ScriptingInAHypermediaApplication.adoc b/book/CH10_ScriptingInAHypermediaApplication.adoc index a19be51..033d75a 100644 --- a/book/CH10_ScriptingInAHypermediaApplication.adoc +++ b/book/CH10_ScriptingInAHypermediaApplication.adoc @@ -1127,7 +1127,7 @@ or rate limiting events. +_hyperscript+ also provides declarative mechanisms fo and across multiple elements. Again we wish to stress that, in this example, we are not stepping outside the lines of a Hypermedia-Driven -Application: we are only adding front-end, client-side functionality with our scripting. We are not creating and +Application: we are only adding frontend, client-side functionality with our scripting. We are not creating and managing a large amount of state outside of the DOM itself, or communicating with the server in a non-hypermedia exchange. diff --git a/book/CH11_JSONDataAPIs.adoc b/book/CH11_JSONDataAPIs.adoc index f4b858d..38172e0 100644 --- a/book/CH11_JSONDataAPIs.adoc +++ b/book/CH11_JSONDataAPIs.adoc @@ -491,8 +491,8 @@ should be "`thin`", with the model containing the majority of the logic in the s .The Model View Controller Pattern **** The Model View Controller design pattern is a classic architectural pattern in software development, and was a major -influence in early web development. It is no longer emphasized as heavily, as web development has split into front-end -and back-end camps, but most web developers are still familiar with the idea. +influence in early web development. It is no longer emphasized as heavily, as web development has split into frontend +and backend camps, but most web developers are still familiar with the idea. Traditionally, the MVC pattern mapped into web development like so: