Using Astro for Display

Creating a Custom Blogging Platform

Thinking about creating a custom blogging platform.

Part 1: I Am Never Satisfied With This Site
Part 2: Talkin’ It Through – Supabase or Appwrite
Part 3: Blogging with Rich Text
Part 4: Using Astro for Display

When thinking about a custom blog platform, I decided that my first hurdle was going to concern how to deal with the rich text aspect necessary for creating posts which included formatting, links, and inline images. That was only the first part of the battle, though because once I could get the editor down, I’d need a front-end design capable of using whatever the rich text editor produced. I talked about how I had settled on Lexical and the Markdown plugin which would let me maybe avoid having to deal with a toolbar, but that comes with some inherent problems — like how Lexical-to-Markdown is a one-way street, turning Markdown sigils into HTML, but not vice-versa.

Astro, a front-end platform designed for displaying content, seems to like native Markdown, especially as physical files. This framework is a bit weird like that; rather than behave like Markdown or HTML, it combines the two. It uses frontmatter, a delineated “safe space” at the top of a .astro file in which we can write actionable code in JavaScript or TypeScript, while the content outside of the frontmatter is the HTML display markup.

---
import Header from '../components/Header.astro';
import Footer from '../components/Footer.astro';
import '../styles/global.css';
const pageTitle = "Home Page";
---
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <link rel="icon" type="image/svg+xml" href="/favicon.svg" />
    <meta name="viewport" content="width=device-width" />
    <meta name="generator" content={Astro.generator} />
    <title>{pageTitle}</title>
  </head>
  <body>
    <Header />
    <h1>{pageTitle}</h1>
    <Footer />
    <script>
      import "../scripts/menu.js";
    </script>
  </body>
</html>

This is a quick example from Astro’s intro tutorial on — wait for it — building a blog. The frontmatter is doing some imports of other files for processing and display as well as the CSS. It also sets a variable for the page title. These elements are used either directly in the HTML as tags (such as <Header/> and <Footer/>) or via inline-code reference the way we do it with modern ECMAScript (such as {pageTitle} to display the value of the variable). On the surface Astro doesn’t seem overly complicated; it focuses on components which, with the inclusion of the frontmatter paradigm, allows for bits of code and display to be created and reused throughout the site, which is how React and other frameworks urge developers to do. Later, though, things can get more complicated, but I haven’t gotten that far in the documentation. Astro’s big “claim to fame” is that it’s big on server side rendering (SSR) which means that it will compile the front end down to just HTML and send that to the browser, only “hydrating” JavaScript at the destination when it determines it can’t be avoided. This makes delivering content faster, less complicated, and less prone to Bad Actors examining your site’s code to figure out how it works.

I might entertain the idea of combining Astro with Lexical, and having Lexical pump out actual Markdown files in place of or in addition to keeping the data in a database for categorization purposes. I feel that this is potentially overcomplicating things, but since Lexical doesn’t officially speak Markdown, and while Astro can probably handle the translated Markdown, maybe keeping things native where they need to be is a worthwhile goal.

Of course, I had to actually look up “what is frontmatter” so I could explain it correctly, and then I ran into this plugin for Visual Studio Code called — wait for it again — Front Matter. The blurb from the homepage goes a little something like this:

Designed for developers and content creators, Front Matter gives you the power and control of a full-blown CMS, without the hassle of dealing with servers, websites, or APIs. With Front Matter, you can create and manage your content directly in Visual Studio Code, using your favorite tools and workflows.

I already use a plugin that shows me markup when working with .md files in VSC, so why not use VSC as a blog-post editor? I don’t blog on the run, and have VSC installed on every system I work with. Writing a file directly to the directory which Astro reads from, and then setting up a means whereby Astro examines file structure and files on disk to create navigation seems like an incredibly low-rent way of writing this platform. It does away with the need to manage a database and set up systems for managing users and content; I would be the only user, and all the content would drop into folders on disk. So I now need to examine this Front Matter plugin to see what it offers that maybe straight Markdown files in VSC do not, finish reading up on Astro, and then figuring out if there’s a way to incorporate everything that goes into a blog post into this framework mashup.

Series Navigation<< Blogging with Rich Text