edits

scripts/build.py

@@ -69,6 +69,9 @@ def compile_posts():
         trim_start = post.find("</header>") + len("</header>")
         trim_end = post.find("</body")
         post = post[trim_start:trim_end]
+        # Wrap the main article inside a div.
+        nav_end = post.find("</nav>") + len("</nav>")
+        post = post[:nav_end] + '<div id="POST">' + post[nav_end:] + "</div>"
 
         # Wrap the post with a Jinja template.
         postmeta = meta[f.stem]

src/assets/css/post.css

@@ -4,8 +4,7 @@
 }
 
 .pandoc #TOC {
-  padding-top: 1rem;
-  padding-bottom: 1rem;
+  padding: 1rem;
   margin-bottom: 1.5rem;
   background: var(--color-bg-nested);
   border: 2px solid var(--color-border);
@@ -15,7 +14,10 @@
   list-style-type: none;
 }
 .pandoc #TOC ul {
-  margin-left: -1rem;
+  padding-left: 0;
+}
+.pandoc #TOC li > ul {
+  padding-left: 1.25rem;
 }
 .pandoc #TOC a {
   color: var(--color-fg-primary);

src/posts/frontend-build-systems.tex

@@ -16,8 +16,8 @@
 \begin{enumerate}
   \item \textbf{Unsupported Language Features:} Because JavaScript runs in the browser, and there
     are many browsers out there of a variety of versions, each language feature you use reduces the
-    number of clients that can execute your JavaScript. Furthermore, frameworks such as JSX, being
-    language extensions, are not valid JavaScript and will not run in any browser.
+    number of clients that can execute your JavaScript. Furthermore, language extensions like JSX
+    are not valid JavaScript and will not run in any browser.
 
   \item \textbf{Performance:} The browser must request each JavaScript file individually. In a large
     codebase, this can result in thousands of HTTP requests in order to render a single page. In the
@@ -93,8 +93,8 @@ \subsection{Transpilation}
 All bundlers are also inherently transpilers, as they parse multiple JavaScript source files and
 emit a new bundled JavaScript file. When doing so, they can pick which language features to use in
 their emitted JavaScript file. Some bundlers are additionally capable of parsing TypeScript and JSX
-source files. If your application has straightforward transpilation needs, the bundler alone may
-suffice.
+source files. If your application has straightforward transpilation needs, you may not need a
+separate transpiler.
 
 \subsection{Bundling}
 
@@ -200,8 +200,8 @@ \subsubsection{Static Assets}
 Webpack ``loaders'' allowed the importing of static assets from JavaScript, unifying both code and
 static assets into a single dependency graph. During bundling, Webpack replaces the static asset
 import with its final path inside the distributable. This feature enabled static assets to be
-organized with its associated components in the source code, and added new possibilities for static
-analysis, such as detecting non-existent assets.
+organized with its associated components in the source code, and created new possibilities for
+static analysis, such as detecting non-existent assets.
 
 It is important to recognize that the importing of static assets
 (non-JavaScript-or-transpiles-to-JavaScript files) is not part of the JavaScript language. It
@@ -218,7 +218,7 @@ \subsection{Minification}
 
 Several JavaScript minifiers in common use today are Terser, esbuild, and SWC.
 \href{https://terser.org/}{\textbf{Terser}} was forked from the unmaintained uglify-es. It is
-written in JavaScript and is somewhat slow. \textbf{Esbuild} and \tb{SWC}, mentioned previously,
+written in JavaScript and is somewhat slow. \textbf{Esbuild} and \textbf{SWC}, mentioned previously,
 implement minifiers in addition to their other capabilities and are faster than Terser.
 
 Several CSS minifiers in common use today are cssnano, csso, and Lightning CSS.
@@ -287,10 +287,10 @@ \subsection{Hot Reload}
 Replacement can become very slow due to the growing rebundling cost.
 
 The no-bundle paradigm, currently championed by Vite, counters this by choosing to not bundle the
-development server, instead serving ESM modules, corresponding to the source files, directly to the
-browser. In this paradigm, each code change triggers a single module replacement in the frontend.
-This results in a near-constant refresh time complexity relative to application side. However, if
-you have a many modules, the initial page load may take longer.
+development server. Instead, Vite serves ESM modules, each corresponding to a source file, directly
+to the browser. In this paradigm, each code change triggers a single module replacement in the
+frontend. This results in a near-constant refresh time complexity relative to application side.
+However, if you have many modules, the initial page load may take longer.
 
 \subsection{Monorepos}