docs(concepts): simplify the introduction (#1673)

Make the `index` page more beginner friendly with less technical
lingo and complex details.

Resolves #1416

src/content/concepts/index.md

@@ -1,47 +1,53 @@
 ---
-title: Core Concepts
+title: Concepts
 sort: 1
 contributors:
   - TheLarkInn
   - jhnns
   - grgur
   - johnstew
   - jimrfenner
+  - TheDutchCoder
 ---
 
-*webpack* is a _module bundler_ for modern JavaScript applications. When webpack processes your application, it recursively builds a _dependency graph_ that includes every module your application needs, then packages all of those modules into a small number of _bundles_ - often only one - to be loaded by the browser.
+At its core, *webpack* is a _module bundler_ for modern JavaScript applications. When webpack processes your application, it recursively builds a _dependency graph_ that includes every module your application needs, then packages all of those modules into one or more _bundles_.
 
-It is [incredibly configurable](/configuration), but to get started you only need to understand **Four Core Concepts**: entry, output, loaders, and plugins.
+It is [incredibly configurable](/configuration), but to get started you only need to understand four **Core Concepts**:
+
+- Entry
+- Output
+- Loaders
+- Plugins
 
 This document is intended to give a **high-level** overview of these concepts, while providing links to detailed concept specific use cases.
 
 
 ## Entry
 
-webpack creates a graph of all of your application's dependencies. The starting point of this graph is known as an _entry point_. The _entry point_ tells webpack _where to start_ and follows the graph of dependencies to know _what to bundle_. You can think of your application's _entry point_ as the **contextual root** or **the first file to kick off your app**.
+An **entry point** indicates which module webpack should use to begin building out its internal *dependency graph*. After entering the entry point, webpack will figure out which other modules and libraries that entry point depends on (directly and indirectly).
 
-In webpack we define _entry points_ using the `entry` property in our [webpack configuration object](/configuration).
+Every dependency is then processed and outputted into files called *bundles*, which we'll discuss more in the next section.
 
-The simplest example is seen below:
+You can specify an entry point (or multiple entry points) by configuring the `entry` property in the [webpack configuration](/configuration).
 
-**webpack.config.js**
+Here's the simplest example of an `entry` configuration:
 
-```javascript
+__webpack.config.js__
+
+``` js
 module.exports = {
   entry: './path/to/my/entry/file.js'
 };
 ```
 
-There are multiple ways to declare your `entry` property that are specific to your application's needs.
-
-[Learn more!](/concepts/entry-points)
+T> You can configure the `entry` property in various ways depending the needs of your application. Learn more in the [entry points](/concepts/entry-points) section.
 
 
 ## Output
 
-Once you've bundled all of your assets together, you still need to tell webpack **where** to bundle your application. The webpack `output` property tells webpack **how to treat bundled code**.
+The **output** property tells webpack where to emit the *bundles* it creates and how to name these files. You can configure this part of the process by specifying an `output` field in your configuration:
 
-**webpack.config.js**
+__webpack.config.js__
 
 ```javascript
 const path = require('path');
@@ -59,20 +65,18 @@ In the example above, we use the `output.filename` and the `output.path` propert
 
 T> You may see the term **emitted** or **emit** used throughout our documentation and [plugin API](/api/plugins). This is a fancy term for 'produced' or 'discharged'.
 
-The `output` property has [many more configurable features](/configuration/output), but let's spend some time understanding some of the most common use cases for the `output` property.
-
-[Learn more!](/concepts/output)
+T> The `output` property has [many more configurable features](/configuration/output) and if you like to know more about the concepts behind the `output` property, you can [read more in the concepts section](/concepts/output).
 
 
 ## Loaders
 
-The goal is to have all of the assets in your project be **webpack's** concern and not the browser's (though, to be clear, this doesn't mean that they all have to be bundled together). webpack treats [every file (.css, .html, .scss, .jpg, etc.) as a module](/concepts/modules). However, webpack itself **only understands JavaScript**.
+*Loaders* enable webpack to process more than just JavaScript files (webpack itself only understands JavaScript). They give you the ability to leverage webpack's bundling capabilities for all kinds of files by converting them to valid [modules](/concepts/modules) that webpack can process.
 
-**Loaders in webpack _transform these files into modules_ as they are added to your dependency graph.**
+Essentially, webpack loaders transform all types of files into modules that can be included in your application's dependency graph.
 
 At a high level, **loaders** have two purposes in your webpack config. They work to:
 
-1. Identify which file or files should be transformed by a certain Loader. (`test` property)
+1. Identify which file or files should be transformed by a certain loader (with the `test` property).
 2. Transform those files so that they can be added to your dependency graph (and eventually your bundle). (`use` property)
 
 **webpack.config.js**
@@ -102,16 +106,16 @@ The configuration above has defined a `rules` property for a single module with
 
 W> It is important to remember that **when defining rules in your webpack config, you are defining them under `module.rules` and not `rules`**. For your benefit, webpack will 'yell at you' if this is done incorrectly.
 
-There are other, more specific properties to define on Loaders that we haven't yet covered.
+There are other, more specific properties to define on loaders that we haven't yet covered.
 
 [Learn more!](/concepts/loaders)
 
 
 ## Plugins
 
-While Loaders only execute transforms on a per-file basis, `plugins` are most commonly used to perform actions and custom functionality on "compilations" or "chunks" of your bundled modules [(and so much more!)](/concepts/plugins). The webpack Plugin system is [extremely powerful and customizable](/api/plugins).
+While loaders are used to transform certain types of modules, plugins can be leveraged to perform a wider range of tasks. Plugins range from bundle optimization and minification all the way to defining environment-like variables. The [plugin interface](/api/plugins) is extremely powerful and can be used to tackle a wide variety of tasks.
 
-In order to use a plugin, you just need to `require()` it and add it to the `plugins` array. Most plugins are customizable via options. Since you can use a plugin multiple times in a config for different purposes, you need to create an instance of it by calling it with `new`.
+In order to use a plugin, you need to `require()` it and add it to the `plugins` array. Most plugins are customizable through options. Since you can use a plugin multiple times in a config for different purposes, you need to create an instance of it by calling it with the `new` operator.
 
 **webpack.config.js**