Remove all uses of just, simple, simply, and straighforward in the do…

…cs (#936)

bridgetown-website/src/_docs/automations.md

@@ -14,7 +14,7 @@ They're uniquely powerful when combined with [plugins](/docs/plugins), as an
 automation can install and configure one or more plugins from a single script.
 
 You could also write an automation to run multiple additional automations, and
-apply that to a brand-new site to set everything up just how you want it in a
+apply that to a brand-new site to set everything up exactly how you want it in a
 repeatable and automatic fashion.
 
 Automations can be loaded from a local path, or they can be loaded from remote
@@ -67,7 +67,7 @@ actions provided by Thor](https://github.com/erikhuda/thor/wiki/Actions), such
 as `run` to run a CLI executable, or `ask` to prompt the user for details, or
 `say_status` to provide helpful messages in the terminal.
 
-Here's an example of a simple automation which creates a new file in a
+Here's an example of an automation which creates a new file in a
 site repo:
 
 ```ruby
@@ -157,5 +157,5 @@ end
 
 In summary, automations are a fantastic method of saving repeatable setup
 steps for you to reuse later in new projects, or you can share scripts with
-the world at large. Use them for plugins, themes, or just quick one-off
+the world at large. Use them for plugins, themes, or quick one-off
 scripts.

bridgetown-website/src/_docs/bundled-configurations.md

@@ -42,7 +42,7 @@ Bundled configurations can also be run while creating a new Bridgetown project u
 {%@ Note type: :warning do %}
   #### Looking for Tailwind?
 
-  The bundled configuration for TailwindCSS has been [relocated to a separate community-maintained repo](https://github.com/bridgetownrb/tailwindcss-automation). The installation process remains just as simple. However, the Bridgetown core team recommends looking into options such as Open Props, Shoelace, and otherwise "vanilla" CSS (perhaps with a bit of help from PostCSS or Sass) as a best practice for "Use the Platform", future-compatible frontend development.
+  The bundled configuration for TailwindCSS has been [relocated to a separate community-maintained repo](https://github.com/bridgetownrb/tailwindcss-automation). However, the Bridgetown core team recommends looking into options such as Open Props, Shoelace, and otherwise "vanilla" CSS (perhaps with a bit of help from PostCSS or Sass) as a best practice for "Use the Platform", future-compatible frontend development.
 {% end %}
 
 ## Configuration Setup Details
@@ -113,7 +113,7 @@ bin/bridgetown configure open-props
 
 🔴 Installs [Ruby2JS](https://www.ruby2js.com), an extensible Ruby to modern JavaScript transpiler you can use in production today. It produces JavaScript that looks hand-crafted, rather than machine generated. You can convert Ruby-like syntax and semantics as cleanly and “natively” as possible. This means that (most of the time) you’ll get a line-by-line, 1:1 correlation between your source code and the JS output.
 
-Simply write your files in `frontend/javascript` or in `src/_components` with a `.js.rb` extension and they'll be supported the same way as `.js` file by Bridgetown's frontend bundling pipeline.
+Write your files in `frontend/javascript` or in `src/_components` with a `.js.rb` extension and they'll be supported the same way as `.js` file by Bridgetown's frontend bundling pipeline.
 
 🛠 **Configure using:**
 

bridgetown-website/src/_docs/collections.md

@@ -111,7 +111,7 @@ There are special [permalink variables for collections](/docs/content/permalinks
 
 ## Custom Metadata
 
-It's also possible to add custom metadata to a collection. You simply add
+It's also possible to add custom metadata to a collection. You add
 additional keys to the collection config and they'll be made available in templates. For example, if you specify this:
 
 ```yaml

bridgetown-website/src/_docs/command-line-usage.md

@@ -78,7 +78,7 @@ task :linthtml do # this is custom for the website project
 end
 ```
 
-As is shown in comments for the default Rakefile, you can add your own [automations](/docs/automations) directly inside of Rake tasks. In the provided example, you can see that a `site` object is available, and within an `automation` block you can call Thor actions just like in standard automation scripts:
+As is shown in comments for the default Rakefile, you can add your own [automations](/docs/automations) directly inside of Rake tasks. In the provided example, you can see that a `site` object is available, and within an `automation` block you can call Thor actions like standard automation scripts:
 
 ```ruby
 task :my_task => :environment do
@@ -99,7 +99,7 @@ Running `bin/bridgetown my_task` would result in printing out the root path of t
 
 When you run `bin/bridgetown console` or `c`, you have access to an instantiated `site` object which you can use to investigate its content and configuration. You can also call `collections` directly as a shorthand for `site.collections`, and you can run `reload!` anytime you want to reset/reload site content and plugins.
 
-Besides those built-in console methods, you can add your own! Just define your own `ConsoleMethods` module and include that in Bridgetown's standard module.
+Besides those built-in console methods, you can add your own! Define your own `ConsoleMethods` module and include that in Bridgetown's standard module.
 
 ```ruby
 module ConsoleMethods

bridgetown-website/src/_docs/commands/plugins.md

@@ -7,7 +7,7 @@ category: command-line-usage
 
 The `plugins` command allows you to display all custom or gem-based plugins you have loaded in the site along with other related infrastructure such as source manifests, generators, and builders.
 
-Simply run `bridgetown plugins list` and you'll get a printout in your terminal that looks something like this:
+Run `bridgetown plugins list` and you'll get a printout in your terminal that looks something like this:
 
 
 ```
@@ -52,9 +52,9 @@ bridgetown plugins cd <origin>/<dir>
 
 where `<origin>` is one of the source manifest origins (like the `SamplePlugin` example above), and `<dir>` is one of the folder names (like `Content` or `Layouts`).
 
-The command drops you in a new temporary shell where you can access the files, and when you're done simply type `exit` to return to your site. In addition, you're given the `BRIDGETOWN_SITE` environment variable as a way to reference your site from the temporary shell.
+The command drops you in a new temporary shell where you can access the files, and when you're done, type `exit` to return to your site. In addition, you're given the `BRIDGETOWN_SITE` environment variable as a way to reference your site from the temporary shell.
 
-So for example if you wanted to copy all the layouts from a gem-based plugin into your own site layouts folder, it's as simple as running:
+For example, if you wanted to copy all the layouts from a gem-based plugin into your own site layouts folder, run:
 
 ```sh
 bridgetown plugins cd AwesomePlugin/Layouts

bridgetown-website/src/_docs/components.md

@@ -15,7 +15,7 @@ Just as a web page can be thought of as the interconnected product of the three
 
 ### [Liquid](/docs/components/liquid)
 
-Use the [Liquid template engine](/docs/template-engines/liquid) to write simple components without a lot of custom logic or for maximum compatibility with all template engines. Liquid components are not recommended when complexity is required for frontend logic.
+Use the [Liquid template engine](/docs/template-engines/liquid) to write basic components without a lot of custom logic or for maximum compatibility with all template engines. Liquid components are not recommended when complexity is required for frontend logic.
 
 ### [Ruby](/docs/components/ruby)
 
@@ -33,7 +33,7 @@ An emerging technology which has the potential to change how we approach develop
 
 ## The Subtle Interplay of HTML, CSS, & JavaScript
 
-As previously mentioned, a component will often encompass not just the output HTML coming from the component's logic/template, but styling via CSS, and client-side interactivity via JavaScript.
+As previously mentioned, a component will often encompass styling via CSS and client-side interactivity via JavaScript, alongside the output HTML coming from the component's logic/template.
 
 In those cases, where you place your CSS and JS code will vary depending on the environment. For Liquid and Ruby components, you will write what are called "sidecar" files which live alongside your component classes/templates. In contrast, Lit components fall under the category of Single-File Components. The logic, template, and styling is all part of the same unit of code. Lit components can be written in either vanilla JavaScript or Ruby2JS (a Ruby-like syntax and set of idioms which then transpiles to JavaScript). However, with a smidge of extra configuration, you do have the option of splitting the CSS of a Lit component out to its own sidecar file if you so choose.
 

bridgetown-website/src/_docs/components/liquid.md

@@ -15,7 +15,7 @@ Liquid components can be combined with front-end component strategies using **we
 
 ## Usage
 
-Including a component within a content document or design template is done via a `render` tag or `rendercontent` tag. Here is a simple example:
+Including a component within a content document or design template is done via a `render` tag or `rendercontent` tag. Here's an example:
 
 {% raw %}
 ```liquid

bridgetown-website/src/_docs/components/lit.md

@@ -15,7 +15,7 @@ Through the use of Bridgetown's [Lit Renderer](https://www.github.com/bridgetown
 
 ## Installing Lit Renderer
 
-Simply run the Bundled Configuration automation:
+Run the Bundled Configuration automation:
 
 ```sh
 bin/bridgetown configure lit
@@ -157,7 +157,7 @@ In order to separate the "globally-accessible" stylesheets you may have in `src/
 * For global stylesheets, use the standard `.css` suffix.
 * For Lit component stylesheets, use a `.lit.css` suffix.
 
-Bridgetown's bundled Lit configuration provides the building blocks for this setup. You'll need to edit a few lines in your `frontend/javascript/index.js` and `esbuild.config.js` files to opt into this (just look at the comments in the files). Once completed, you'll be able to write components such as this:
+Bridgetown's bundled Lit configuration provides the building blocks for this setup. You'll need to edit a few lines in your `frontend/javascript/index.js` and `esbuild.config.js` files to opt into this (look at the comments in the files). Once completed, you'll be able to write components such as this:
 
 ```js
 // _src/components/my-nifty-tag.lit.js

bridgetown-website/src/_docs/components/ruby.md

@@ -32,7 +32,7 @@ end
   output: Hello from MyComponent!
 ```
 
-To pass variables along to a component, simply write an `initialize` method. You can also use Ruby's "squiggly heredoc" syntax as a kind of template language:
+To pass variables along to a component, write an `initialize` method. You can also use Ruby's "squiggly heredoc" syntax as a kind of template language:
 
 ```ruby
 class FieldComponent
@@ -150,7 +150,7 @@ The `slotted` helper can also provide default content should the slot not alread
 
 Multiple captures using the same slot name will be cumulative. The above `image` slot could be appended to by calling `slot :image` multiple times. If you wish to change this behavior, you can pass `replace: true` as a keyword argument to `slot` to clear any previous slot content. _Use with extreme caution!_
 
-For more control over slot content, you can use the `pre_render` hook. Builders can register hooks to transform slots in specific ways based on their name or context. This is perhaps not all that useful when you're writing both the content and the components, but for easy customization of third-party components it could come in handy.
+For more control over slot content, you can use the `pre_render` hook. Builders can register hooks to transform slots in specific ways based on their name or context. This is perhaps not all that useful when you're writing both the content and the components, but for customization of third-party components it could come in handy.
 
 ```rb
 class Builders::FigureItOut < SiteBuilder
@@ -178,7 +178,7 @@ end
 
 ### Helpers
 
-As expected, helpers are available as well just like in standard templates:
+As expected, helpers are available as well exactly like in standard templates:
 
 ```erb
 <!-- src/_components/posts/excerpt.erb -->
@@ -207,7 +207,7 @@ end
 
 ### Lifecycle
 
-In addition to simply rendering a template for you, `Bridgetown::Component` provides a couple lifecycle hooks:
+In addition to rendering a template for you, `Bridgetown::Component` provides a couple lifecycle hooks:
 
 * `render?` – if you define this method and return `false`, the component will not get rendered at all.
 * `before_render` – called right before the component is rendered when the view_context is known and all helpers available.

bridgetown-website/src/_docs/configuration/initializers.md

@@ -110,7 +110,7 @@ init :stripe do
 end
 ```
 
-Inside of the block, you can use the DSL just like in the main `configure` block. You can also reference keys that were previously set:
+Inside of the block, you can use the same DSL as the main `configure` block. You can also reference keys that were previously set:
 
 ```rb
 init :some_initializer do
@@ -119,7 +119,7 @@ init :some_initializer do
 end
 ```
 
-These configuration values will get passed directly to the initializer. But what if the plugin requires you to set values on the main config instead (as many legacy Bridgetown plugins will)? No problem! While it's not strictly necessary, you can still use the init block and just reference the main config object from enclosing scope for a clear visual grouping:
+These configuration values will get passed directly to the initializer. But what if the plugin requires you to set values on the main config instead (as many legacy Bridgetown plugins will)? No problem! While it's not strictly necessary, you can still use the init block and reference the main config object from enclosing scope for a clear visual grouping:
 
 ```rb
 init :legacy_plugin do
@@ -210,7 +210,7 @@ end
 While it's not strictly required that you place a Roda block inside of an `only :server do` block, it's probably a good idea that you do since Roda blocks aren't used in any other configuration context.
 
 {%@ Note do %}
-  As mentioned above, you can still add and configure plugins directly in your Roda class file (`server/roda_app.rb`) just like any standard Roda application, but using a Roda configuration block alongside your other initialization steps is a handy way to keep everything consolidated. Bear in mind that the Roda blocks are all executed prior to anything defined within the class-level code of `server/roda_app.rb`, so if you write any code in a Roda block that relies on state having already been defined in the app class directly, it will fail. Best to keep Roda block code self-contained, or reliant only on other settings in the Bridgetown initializers file.
+  As mentioned above, you can still add and configure plugins directly in your Roda class file (`server/roda_app.rb`) like any standard Roda application, but using a Roda configuration block alongside your other initialization steps is a handy way to keep everything consolidated. Bear in mind that the Roda blocks are all executed prior to anything defined within the class-level code of `server/roda_app.rb`, so if you write any code in a Roda block that relies on state having already been defined in the app class directly, it will fail. Best to keep Roda block code self-contained, or reliant only on other settings in the Bridgetown initializers file.
 {% end %}
 
 ### SSR & Dynamic Routes
@@ -266,11 +266,11 @@ require_relative "../ruby_code_file.rb"
 
 ## Built-in Initializers
 
-Bridgetown ships with several initializers you can add to your configuration. In future versions of Bridgetown, we expect to make our overall architecture a little more modular so you can use the initializer system to specify just those key features you need (and by omission which ones you don't!).
+Bridgetown ships with several initializers you can add to your configuration. In future versions of Bridgetown, we expect to make our overall architecture a little more modular so you can use the initializer system to specify only those key features you need (and by omission which ones you don't!).
 
 ### Dotenv
 
-The Dotenv gem provides a simple way to manage environment variables with your Bridgetown project. Simply add the gem to your Gemfile (`bundle add dotenv`), and then add the initializer to your configuration:
+The Dotenv gem allows you to manage environment variables with your Bridgetown project. Add the gem to your Gemfile (`bundle add dotenv`), and then add the initializer to your configuration:
 
 ```rb
 init :dotenv