davidbgk
/
larlet-fr-david-cache

title: The tangled webs we weave
url: https://daverupert.com/2020/09/tangled-webs/
hash_url: fc3558fb276cdc30844d1abfe095631d

<p class="tldr">Another reflection on modern web development</p> 
<p class="meta">September 11, 2020</p>
<p>Last month I worked on a prototype of three simple pieces of technology: <code>Eleventy</code> + <code>Tailwind</code> + <code>Netlify CMS</code>. I love a good mashup. Those are fairly distinct technologies with well defined roles, so I didn’t anticipate too many hiccups. I was more on the lookout for limitations or deal breakers. The first week was filled with excellent velocity and momentum, but I hit a wall during the second week. The preview portion of <code>Netlify CMS</code> started falling apart. So I started investigating…</p>
<p>Here’s a breakdown of the technologies I used to build the prototype:</p>
<ul>
<li>Use <code>Eleventy</code> CLI to compile <code>Markdown</code> and <code>Nunjucks</code></li>
<li>Use <code>Tailwind</code> to make those look nice</li>
<li>Use <code>TailwindUI</code> for some nice prefab styled components</li>
<li>Use <code>PurgeCSS</code> to make <code>Tailwind</code> smaller</li>
<li>Use <code>PostCSS</code> to run the <code>Tailwind</code>, <code>Purge</code>, and <code>Autoprefixer</code></li>
<li>Use <code>AlpineJS</code> to make <code>Tailwind</code> interactive</li>
</ul>
<p>This was functioning as intended with a few <code>npm scripts</code> working in tandem. But the next step got a little slippery.</p>
<ul>
<li>Use <code>NetlifyCMS</code> to make updating markdown easier for content authors</li>
<li>Use <code>netlify-cms-proxy-server</code> CLI so that I can test the CMS locally</li>
<li>Use <code>nunjucks-precompile</code> CLI so that  <code>Netlify CMS</code>’s Preview can use my <code>Nunjucks</code> templates</li>
<li>Use <code>rollup</code> to bundle content filters so <code>Netlify CMS</code> can fully render the <code>Markdown</code> content (stolen from Hylia)</li>
<li>Use <code>React</code> to create <code>&lt;Preview/&gt;</code> render components in <code>NetlifyCMS</code></li>
<li>Use <code>Babel</code> standalone to transpile the <code>JSX</code> components.</li>
</ul>
<p>This is where things started to break down. <code>Alpine</code> wasn’t working within the <code>React</code> preview component of <code>Netlify CMS</code>. So all my menus were exploded and none of the interactive bits worked. I tried a few avenues for a quick fix like rewriting my <code>&lt;Preview/&gt;</code> component <code>class</code> with <code>componentDidMount</code> as a <code>function</code> with <code>useEffect</code>. This produced more errors as <code>JSX</code> got very mad because it doesn’t like the custom directives that <code>Alpine</code> uses, but those were all red herrings, however. It smelled like the problem was between <code>Alpine</code> and the <code>React</code> portion of <code>Netlify CMS</code> because the <code>&lt;Preview/&gt;</code> frame had no knowledge of <code>Alpine</code>.</p>
<p>I decided the next best thing I could do is isolate the problem. I took <code>Markdown,</code> <code>Nunjucks</code>, <code>rollup</code>, and <code>Netlify CMS</code> out of the equation entirely by writing <a href="https://codepen.io/davatron5000/pen/YzqyOKz">a reduced test case in <code>CodePen</code></a> to prove that I could get <code>React</code> and <code>Alpine</code> working together. Seeing it worked in <code>CodePen</code> validated the hypothesis that the problem was on the <code>Netlify CMS</code> side of things (or however it was rendering previews). I ported my simple <code>CodePen</code> over to <code>Netlify CMS</code> with a bit of modification to inject <code>Alpine</code> and then I finally saw my problem.</p>
<p>I didn’t see it before because I had too much template code in the <code>iframe</code>, but reducing the amount of code helped me finally pinpoint the issue. <code>Alpine</code> was being injected, but it was on the parent <code>window</code> context, not the <code>document</code> context of the <code>iframe</code>. Now I had to figure out how to get <code>Alpine</code> inside the preview <code>iframe</code>. Curiously, the <code>iframe</code> didn’t have a <code>src</code> or <code>srcdoc</code> attribute, so it must be some quirky <code>DocumentFragment</code> thing I’ve never really used before. Pinpointing this might be tough. So I started digging into the <code>Netlify CMS</code> source code (this pretty far down the rabbit hole for a prototype, btw).  In <a href="https://github.com/netlify/netlify-cms/blob/master/packages/netlify-cms-core/src/components/Editor/EditorPreviewPane/EditorPreviewPane.js#L188-L233">EditorPreviewPane.js#L188-L233</a> you can see where the <code>iframe</code> is generated with <code>&lt;FrameContextConsumer&gt;</code> from <code>react-frame-component</code>. I know nothing about that, but you can see a way to pass preview styles into the <code>&lt;FrameContextConsumer&gt;</code>, I wondered if you could pass scripts that way as well.</p>
<p>Before I embarked on a patch to <code>Netlify CMS</code>, <a href="https://github.com/netlify/netlify-cms/issues/4142">I filed a feature request</a> with a mock solution. Thankfully, Erez Rokah (maintainer) figured out a way to get access to the <code>document</code> from <code>react-frame-component</code>, with a much smaller fix than I was proposing. A patch landed in a few days. That’s an amazing turnaround and an open source success. 🎉 Thanks, Netlify!</p>
<h2>LEGO, plumbing, and cattle herding</h2>
<p>So my little mashup, which was supposed to be just 3 technologies ended up exposing me to ~20 different technologies and had me digging into nth-level dependency source code after midnight. If there’s an allegory for what I don’t like about modern day web development, this is it. You want to use three tools, but you have to know how to use twenty tools instead. If modules and components are like LEGO, then this is dumping out the entire bin on the floor  just to find one tiny piece you need.</p>
<p>This experience was flavored with a recent post by Jessica Joy Kerr “<a href="https://jessitron.com/2020/08/04/back-when-software-was-a-craft/">Back when software was craft</a>” (and <a href="https://twitter.com/searls/status/1293933781171286016">a thread by Justin Searls</a>) talking about the industrialization of our industry. Over the years we’ve made the software industry <em>even more</em> of a knowledge-based industry. We’ve moved away from a bespoke “craft”-like industry with custom hewn boards and we now have a process that resembles a system of standardized parts.</p>
<blockquote>
<p>Software feels more like assembly than craft.<br/>
— Jessica Joy Kerr, <a href="https://jessitron.com/2020/08/04/back-when-software-was-a-craft/">Back when software was craft</a></p>
</blockquote>
<p>I definitely have felt this shift in my own life but have been unable to express it so simply. It feels like the job of programming has shifted from “Can you make this?” to “Do you have the knowledge to staple these two technologies together?” Kerr is more accepting of this reality than I am. The plumbing and glue code are not my favorite parts of the job. And often, you don’t truly know the limitations of any given dependency until you’re five thousand lines of code into a project. Massive sunk costs and the promise of rapid application development can come screeching to a halt when you run out of short cuts.</p>
<p>It reminds me of a parable I once heard:</p>
<blockquote>
<p>One day a farmer, tired of plowing his field by hand, decided to build a barn and buy a bunch of cows to help tend the field. The field plowing did get easier, but eventually cows gave birth to more cows, and that farmer spent the rest of their life cutting hay to feed the cattle and shoveling their shit.</p>
</blockquote>
<p>Tradeoffs, man.</p>