A while back I wrote about migrating this site 

. I liked Forestry a lot more than Netlify CMS, except for one annoying bit which was I wanted to use 

 as the media manager, but it didn’t quite support it.

After a few months of using it the team behind Forestry announced they were rolling support off of it in favor of their new project, 

. I tried some of the early betas of that project but couldn’t (easily) get real time updates working and found the overall config cumbersome, so I didn’t follow through on setting it up.

They hit their 1.0 release a few months back and I saw references to it more often around the web, so I figured why not try it again. I’m writing this post with it. Config was easier, although their docs aren’t as straightforward as they could be, and had some errors in them, but I have real time editing updates working and media pulling from my Digital Ocean Space, which is all I ever wanted!

Testing out Tina CMS, yet another Git-backed Markdown CMS for this site.

Tina CMS Test

At some point when building out this blog I made the clever (but not smart) decision to match Next‘s page folder structure with my content. So when generating all the routes for this site, I’d get all the content from the blog folder, the parse out the year and month from the path of the item, and that’s the url of the post.

content/blog-posts/2023/01/mistakes-of-the-past

. Which is ok, but over time I found these issues with it:

Am I starting to wish I kept some of this in a database? No… nope. Not yet. Nope.

How not to organize content for a Next JS based blog.

Mistakes of the Past

, an enjoyable write-up of a confusing part of JavaScript, although I’m not entirely sure I’d ever use them short of a library that hides all of the implementation details.

, that’s where most of my knowledge of them comes from. After implementing it once (look at me, very smart!) I took over another project that used it and immediately ripped it out which, based on the replies, I’m not the only one:

I had to rescue a saga based project that went badly off the rails and it was some of the hardest code I’ve ever had to debug in any language. Code flow was very difficult to reason about and forget about trying to use stack traces. 

JavaScript Generators

 days. I still prefer it over other front-end frameworks because it’s 

 a framework, it’s just a library. That said — these days I prefer to use it 

 a framework. When I first started using React it was as part of an MVC app (usually) or a truly single-page application. Once we moved to handling routing client-side, and handling all data fetching and state management client side, and handling authentication client side… it’s a lot. There’s a lot of cases where you would have been better of using AngularJS or Vue or an MVC whatever backend and some web components than trying to glue together React + React Router (no wait, Reach?) + Redux (no everyone uses MobX now, wait, now it’s just React Hooks WAIT, no, now we’re using state machines) + the CSS-in-JS library of the day.

You see the problem. Still, I think the React combination of JSX and parent/child rendering updates, and prioritizing functional JavaScript without a lot of magic is great. Do I care about most of the updates in React 18? Not really. I’m glad Next, or Remix, or some other great framework is going to do magic with them.

React 18 [is now available on npm](https://reactjs.org/blog/2022/03/29/react-v18.html).

React 18

. Lots of nice updates to performance and quality of life for the Canvas API. I have a soft spot for the 

 tag — when I was (re)learning web development I spent a lot of time at my non-development related job spinning up little web projects that required no libraries or compilation steps to run in the browser pre-installed on my laptop. The canvas element was the most readily available but also 

  web API that runs locally, so I built all kinds of interfaces and animations in it while learning.

 has shifted a lot in the last decade. The Verge wrote about how  

  on how files and folders work - or they have a very good understanding of the norms of storing information in the cloud, but not on their local computers. The web contains all sorts of things that we never think of or use as files: is your email an  

  that are the native format of Apple Photos? Or consider any rich text on the internet, like a Notion page - does it have a defined file type and an option to download? And think of the mobile web. You can download a file from mobile Safari, but do you?

Worth noting, I suppose, that I’m writing this in an application which does not use files. But I generally prefer the workflow of “don’t make me think about this as a file, but give me the file if I ask for it”, so it’s nice to see this API coming together.

And I enjoyed this bit from that article:

Working with the web platform is dealing with history, with the accumulated matter of  

  and good-enough standards. In exchange for the ability to deliver instantly-updating software directly to customers with no middlemen and no installation, you have to absorb a great deal of nearly-useless information that’s entirely about dodging meaningless traps.

Web links worth reading on Canvas2D and the File System Access API.

Two articles on web APIs

Really nothing I love more than figuring out why a random config option got added 2 years ago by a dev, with no comments, and removing or changing it causes thousands of seemingly unrelated errors.

My favorite part of TypeScript is debugging the config

I like articles about accessibility in this format, how-tos of practical examples you see on almost every website. Heydon Pickering’s 

 was the first place I saw this, but the site had only a few examples and ended up being short-lived.

I went to implement two of the 5 “quick wins” above that were relevant to this site:

5 Accessibility Quick Wins (and two for this site)

I’ve had an idea floating around for a while: 

 is great, but I hate all of the steps around configuring / building React components with it. If I’m writing Markdown, HTML is valid in Markdown, and Web Components are valid HTML, so why not just stick Web Components in Markdown and call it a day?

That was the idea, anyway, I just never got around to trying it. I still don’t quite grok the actual 

, and figured with some free time today I’d give it a shot. This is the result: 

. It works! Of course it does. Probably the biggest difference between it and MDX (besides, React, obviously), is that Web Components in HTML can only accept string values, so in this example rather than passing an array of image sources, I passed a comma separated list, e.g:

One other nice thing here is you can stick fallback HTML into the 

 part, and you get fallback content. If the JS loads, yay, a gallery. If not, whatever. I made an example of that here:

I’ve had an idea floating around for a while: MDX is great, but I hate all of the steps around configuring / building React components with it. If I’m writing Markdown, HTML is valid in Markdown, and Web Components are valid HTML, so why not just stick Web Components in Markdown and call it a day?

Stencil, Markdown, and web components in Markdown

I don't write any PHP these days, but the sentiment of a single file that combines HTML, JavaScript, and database queries to quickly knock out simple projects resonates - that's the exact setup I have for the 

 powered files that generate this site. There's no 

s any more though, it's GraphQL queries and JSX that covers both the JS and the HTML.

I can't see ever going back to PHP - I'd prefer Python and I know more C# than it at this point - but I'll never complain about it being a quick and (sometimes) dirty language.

HTML, code, and databases

2019 marks twenty years since I first pushed a website to the internet, yet today I was trying to set up a project and I got caught on something very... silly. I was testing a webpack configuration for a React library so it would run in Internet Explorer 11, but I couldn't get the application code to execute when running the development server. I dug through the code and searched for anything I could think of to narrow down if it was the fault of webpack, the dev server, my application code, or the polyfills I had added for IE11 support. After a (too long) search, it came down to this:

This is not the first time I've made this mistake, and in case it's not immediately clear to you, dear reader, 

. Every time this has tripped me up it's been a particularly baffling error because a self-closing script tag will appear to load - the script will show up in the network tab of the dev tools, and all the code will be there, it just won't execute anything.

Since first learning web development, I've done the very basic task of adding a script tag a lot of different ways:

On top of that, my mental context for when or when not to close tags comes from a mix of knowing HTML, XHTML, and currently working with React - there's some conflicting ideas of what must, should, and should not be self-closing going on in my head.

The project works now - and supports IE11! - and however many years from now, when I forget that a script tag can't be self-closing, I'll at least have this blog post to look back on. Or, all of the browsers will have started supporting a self-closing script tag, or I'll have moved on to yet another abstraction around loading the script tag that removes the brackets and I'll have forgotten how HTML works entirely.

built with coffee

Posts tagged: web dev