More updates to frontend documentation (#5724)

* Updated styles documentation.

* Added some docs about dynamic import usage.

* Updated architecture overview doc.

* Changed some wording

* Changed some wording

docs/frontend/dynamic-imports.md

@@ -0,0 +1,34 @@
+---
+title: Dynamic Imports
+---
+
+# Dynamic Imports
+
+[Dynamic imports](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import/#Dynamic_Imports)
+are supported in all major browsers except for Edge
+([EdgeHTML](https://en.wikipedia.org/wiki/EdgeHTML) version) and Internet
+Explorer which are both unsupported browsers for DEV. They allow you to import
+JavaScript dynamically instead of statically. Why is this important?
+Performance.
+
+Should you use them everywhere? No. They are a great tool when you need to load a
+JavaScript module on the fly for functionality that is not needed immediately
+for the page to be usable.
+
+Here are a couple of examples of dynamic import usage on DEV:
+
+- The
+  [Onboarding flow](https://github.com/thepracticaldev/dev.to/blob/master/app/javascript/packs/Onboarding.jsx#L28).
+- In
+  [connect](https://github.com/thepracticaldev/dev.to/blob/master/app/javascript/chat/codeEditor.jsx#L11)
+  (chat)
+
+DEV uses [webpacker](frontend/webpacker) (webpack), so what webpack will do is
+create separate bundles for code that is dynamically imported. So not only do we
+end up loading code only when we need it, we also end up with smaller bundle
+sizes in the frontend.
+
+For a great deep dive into dynamic imports, there is a great article from
+community member [@goenning](https://dev.to/goenning) about dynamic import
+usage,
+[How we reduced our initial JS/CSS size by 67%](https://dev.to/goenning/how-we-reduced-our-initial-jscss-size-by-67-3ac0).

docs/frontend/readme.md

@@ -5,6 +5,7 @@ items:
   - webpacker.md
   - preact.md
   - instant-click.md
+  - dynamic-imports.md
   - styles.md
   - linting-formatting.md
   - liquid-tags.md

docs/frontend/styles.md

@@ -6,7 +6,9 @@ title: Styles
 
 The majority of the CSS in the application is written in
 [SASS](https://sass-lang.com/). There are a few places in the code base that
-have style blocks in ERB templates, but this is not the norm.
+have style blocks in ERB templates, for inlining critical CSS (good). There are
+also some styles that live in ERB templates that are not critical CSS (bad).
+That is a bit of refactoring that needs to be done. PRs welcome!
 
 Important files when working with SASS in the project:
 

docs/technical-overview/architecture.md

@@ -32,8 +32,9 @@ rule, you should avoid relying on JavaScript for layout when working on DEV.
 
 ## We attempt to reduce our bundle size
 
-We use [PreactJS][preact], a lightweight alternative to ReactJS, and we try to
-reduce our bundle size with [dynamic imports][dynamic_imports].
+We use [PreactJS](/frontend/preact), a lightweight alternative to ReactJS, and
+we try to reduce our bundle size with
+[dynamic imports](frontend/dynamic-imports).
 
 ## Service workers and shell architecture
 
@@ -77,7 +78,8 @@ shared among all users.
 
 ## Inter-page navigation
 
-DEV uses a variation of "instant click," which swaps out page content instead of
+DEV uses a variation of "instant click", via
+[InstantClick](/frontend/instant-click), which swaps out page content instead of
 making full-page requests. This approach is similar to the one used by the Rails
 gem `Turbolinks`, but our approach is more lightweight. The library is modified
 to work specifically with this Rails app and does not swap out reused elements
@@ -183,7 +185,4 @@ This is far from a complete view of the app, but it covers a few core concepts.
 
 [fastly]: https://www.fastly.com/
 [rails_caching]: https://guides.rubyonrails.org/caching_with_rails.html
-[preact]: https://preactjs.com/
-[dynamic_imports]:
-  https://dev.to/goenning/how-we-reduced-our-initial-jscss-size-by-67-3ac0
 [fastly_rails]: https://github.com/fastly/fastly-rails