diff --git a/tex/part-practical.tex b/tex/part-practical.tex
index a9b8641..7d07389 100644
--- a/tex/part-practical.tex
+++ b/tex/part-practical.tex
@@ -420,10 +420,11 @@ empirically allows for a rather quick UI prototyping. Tailwind was chosen
 partially also because it \emph{looked} nice, had a reasonably detailed
 documentation and offered built-in support for dark/light mode. The templates
 containing the CSS classes need to be parsed by Tailwind in order to construct
-its final stylesheet. Upstream provides the original CLI tool for that action
-called \texttt{tailwindcss}. Overall, simple and accessible layouts had
-preference over convoluted ones and data-backed effort was made to create
-contrasting pages.
+the final stylesheet. Upstream provides the original CLI tool called
+\texttt{tailwindcss},which can be used exactly for that action. Overall, simple
+and accessible layouts were preferred, a single page was rather split into
+multiple when becoming convoluted, and data-backed efforts were made to create
+reasonably contrasting pages.
 
 \n{3}{Frontend experiments}
 
@@ -432,7 +433,7 @@ project, but has ultimately scrapped the functionality in favour of the
 entirely server-side rendered one. It is possible that it would get revisited
 if the client-side dynamic functionality was necessary and performance
 mattered. Even from the short experiments it was obvious how much faster
-WebAssembly was compared to JavaScript.
+WebAssembly was when compared to JavaScript.
 
 
 \newpage