A foundation for other sites, but probably not for this one.

So, for the past couple of weeks, we've been intermittently working on porting this site to Eleventy - with the impending death of Cohost as of writing, we wanted to get a collection of 88x31 buttons up, and it didn't make sense to do that once with Jekyll's syntax and once with Eleventy's - particularly with wanting to use the Eleventy Image plugin to cache friends' buttons without hitting their web server every time.

(You're reading this on the Eleventy version right now, hopefully the only things that should be noticeable are those 88x31 buttons, the now page, and the top menu being a little more responsive from finally getting rid of tables for layout)

As part of that work, one of those things we wanted to look into WebC.

web, see?

WebC is a framework for creating reusable web components (lowercase) [1] - little bundles of self contained HTML, with optional CSS and/or JS included, that can be reused throughout your project.

If implemented correctly, this can lower cognitive load by making it so there's only one place to check when anything related to one of those components needs checking. It can make it easier to copy the component between two websites because everything is self contained and modular, no need to surgically extract the CSS from website A's SCSS and place it in website B in a completely different location. [2]

every article needs a good disclaimer

I need to stress this: we are not web developers. Not modern web developers, at least.

The progress we make is through a lot of trial and error; we've learned a lot, but it's filtered through sometimes wanting to do things the way they would have been done in the FrontPage era. [3]

We very much dislike overuse of client side JavaScript. In turn, that means our knowledge of JavaScript in general is limited; I do not even want the temptation to turn a website into an AJAX hellhole, we copy and paste the bare minimum into config files for the site to be built as we'd like.

small data, big inconvenience

Part of the reason we like working with Eleventy is the ease of using data.

And that's why WebC just isn't a great fit for us right now; it seems designed for a completely different workflow.

For example, the 88x31 buttons - the approach we wanted was to create a JSON file, and then use a for loop within a LiquidJS Markdown template - calling a custom component for each button.

And I tried but I couldn't figure out how to pass the data through - and ended up just giving up and doing the entire thing in Nunjucks.


<div class="flexy external_buttons">
	{%- for button in eightyeightbythirtyone -%}
		<a href="{{ button.link_url }}" title="{{ button.name }}" class="e_button">
			{% image-button button.button_url,button.name %}
		</a>	
	{%- endfor -%}
</div>

Looking at the official site's Github repo for guidance, it seems like some things that might expected to be data are instead just all included in the one file, which feels.... messy. I have to assume it's doable and I'm just missing something for how to preprocess in Nunjucks or LiquidJS and using the output data in WebC, but the documentation is also a bit messy.

And again, it would all probably be easier with the fundamentals of JavaScript under our belts - but when the options are to spend 10 mins implementing something in LiquidJS or Nunjucks, or spend an hour trying to get the WebC working, the quicker option is a lot closer to the "Cult of Done" idea.

So yeah, for now, (mostly) back to LiquidJS and Nunjucks, the dream of being able to remove a few things from SCSS will have to wait.

footnotes

  1. Not to be confused with Web Components (titlecase), which are a similar idea but reliant on JavaScript throughout. ↩︎

  2. (Of course, depending on how modular it is, may still need to go through other parts of A for why an inherited value is acting strangely) ↩︎

  3. This approach does mean a fair bit of spaghetti, and that's one reason I'm hesitant to throw stuff up on Github or another host. ↩︎