Forem: Lindsay Wardell

Integrating Mastodon with Astro

Lindsay Wardell — Tue, 22 Nov 2022 19:47:18 +0000

In case you have missed it, Twitter is going through a series of upheavals. This has led to a large number of folks leaving the platform for alternatives. I've been interested in Mastodon as a potential alternative to Twitter for some time, especially since it's open source, but I was never able to make the jump. Now that it feels everyone is trying out alternative platforms, the number of folks I know on Mastodon has grown significantly, and I've been able to replicate a lot of what I was doing on Twitter.

Before I dive in too far, let's talk about microblogging and federation as Mastodon describes it. For microblogging, the Mastodon docs say:

Similar to how blogging is the act of publishing updates to a website, microblogging is the act of publishing small updates to a stream of updates on your profile. You can publish text posts and optionally attach media such as pictures, audio, video, or polls. Mastodon lets you follow friends and discover new ones.

For me, a microblog is a way to share what's going on or what I'm interested in with people in a less formal, more conversational way. I can talk about life, current events, things my kid says, or just share things that I found that interest me. Twitter has been my microblogging platform for the past few years, while I write my more longform blog posts here on my site.

How does Mastodon define federation?

Federation is a form of decentralization. Instead of a single central service that all people use, there are multiple services, that any number of people can use.

Twitter is very centralized; there's only one "instance", and you can't communicate from Twitter to other platforms. Federated platforms, on the other hand, allow for multiple providers to communicate together in a standardized way. The easiest comparison is email, which is another federated system. Different email providers establish rules and filter content as they want, and allow you to interact with other email providers beyond what they host. Mastodon is similar, in that each instance has its own moderators and rules, and allows for interoperation between other Mastodon instances.

Note before we keep going: This post is not intended as a pitch for switching to Mastodon. I know it's not for everyone. But I'm really liking it.

One of the really neat things about Mastodon is that you can host your own instance, and have it federate with the rest of Mastodon. This allows you to control your own data, and host on your own site. This sounds really cool! It'd be neat to host my own social media account under a URL that I own, it seems like an easy way to verify myself. However, I switched to using a static site (specifically using Astro) specifically because I didn't want to pay monthly for a server. It didn't make sense to start paying just to have an account on social media, so I set the idea aside.

Integrating to the Fediverse

Later, I read an article by Maarten Balliauw titled "Mastodon on your own domain without a server", in which he described using the WebFinger spec to inform Mastodon of your account. I highly recommend reading the whole article, but in short, Mastodon is looking for a resource at /.well-known/webfinger that returns JSON in a specific structure. Mastodon is passing a query parameter to specify the account, but if you're hosting your own site, you can ignore the parameter and just return a JSON structure for your account. This sounded interesting, and I wanted to give it a shot!

My site is built on Astro, and is hosted with Netlify. To meet the requirement for the endpoint, I created an endpoint at /.well-known/webfinger.json, which just includes the following code:

export async function get() {
  return {
    body: JSON.stringify({
      subject: 'acct:lindsaykwardell@mastodon.social',
      aliases: [
        'https://mastodon.social/@lindsaykwardell',
        'https://mastodon.social/users/lindsaykwardell',
      ],
      links: [
        {
          rel: 'http://webfinger.net/rel/profile-page',
          type: 'text/html',
          href: 'https://mastodon.social/@lindsaykwardell',
        },
        {
          rel: 'self',
          type: 'application/activity+json',
          href: 'https://mastodon.social/users/lindsaykwardell',
        },
        {
          rel: 'http://ostatus.org/schema/1.0/subscribe',
          template: 'https://mastodon.social/authorize_interaction?uri={uri}',
        },
      ],
    }),
  }
}

Then, in my Netlify config (netlify.toml), I added a redirect:

[[redirects]]
  from = "/.well-known/webfinger"
  to = "/.well-known/webfinger.json"

With that, searching for @lindsay@lindsaykwardell.com properly returns my account on mastodon.social!

Awesome! Now people can look me up by my own URL, and I don't have to host a Mastodon instance to do it! However, this communication is only one way; I can tell the Fediverse who I am, but I don't have a page on my site with any content. How can we fix that?

Bringing the Fediverse Home

Because Mastodon is built to interoperate with other systems, it has a powerful, public API that can be used to fetch data about users and their posts. In addition, it offers multiple ways to subscribe to any user's posts, including an RSS feed. You can subscribe to anyone on Mastodon via RSS by appending .rss to their username (feel free to follow me at https://mastodon.social/@lindsaykwardell.rss).

I have a custom username that can be found on Mastodon, but what I was missing was a page to actually see my content on my site. On Mastodon, the username @lindsaykwardell@mastodon.social can be found at mastodon.social/@lindsaykwardell. However, lindsaykwardell.com/@lindsay didn't exist, so I decided to fix that!

Again, using Astro, I created a page (/@lindsay.astro) that would fetch the content of my RSS feed and then render it. I created a separate template for my site that would also fetch my Mastodon profile and banner images, description, follower counts, and other details, and then rendered it out using static HTML.

---
import MicroblogPost from "../layouts/MicroblogPost.astro";
import MicroPost from "../components/MicroPost.astro";
import Parser from 'rss-parser';

const feedUrl = "https://mastodon.social/@lindsaykwardell.rss"
const parser = new Parser({
  customFields: {
    item: [ ['media:content', 'attachments', { keepArray: true} ]]
  }
})

const feed = await parser.parseURL(feedUrl);

const content = {
  title: feed.title,
  snippet: "Public posts from @lindsay@lindsaykwardell.com",
  slug: "/@lindsay"
}
---
<MicroblogPost content={content}>
  {feed.items.map(item => (
    <MicroPost 
      avatar={feed.image.url}
      displayName={feed.title}
      content={item.content}
      createdAt={item.pubDate}
      url={item.link}
      attachments={item.attachments?.map(attachment => attachment['$'])}
    />
  ))}
</MicroblogPost>

In this file, I'm importing the layout (MicroblogPost) and a component (MicroPost), as well as rss-parser. I then created a parser, and added the custom field for media content (such as images). I then fetch the feed content, parse it, and pass it into the site template and components. With that, I can now see my Mastodon content within my own site!

I then took it a step further, and created an individual page for each post. On sites like Twitter and Mastodon, you can link directly to a post (such as https://twitter.com/lindsaykwardell/status/1583481321330200577 or https://mastodon.social/@lindsaykwardell/109248202243508025). It made sense that if I was trying to recreate the interface of a microblog on my own site, I would want to do the same.

This required using Astro's dynamic routing and enabling SSR mode, but the result is that any of my Mastodon posts can be viwed on my personal site! Here's the code:

---
import MicroblogPost from "../../layouts/MicroblogPost.astro";
import MicroPost from "../../components/MicroPost.astro";

const { id } = Astro.params;

const data = await fetch(`https://mastodon.social/api/v1/statuses/${id}`).then(res => res.json())

const name = data.account.display_name
const post = data.content.replace(/<[^>]*>?/gm, '');
let snippet = post.substring(0,30);

if (snippet.length === 30) {
  snippet += "..."
}

const card = data.card;

const content = {
  title: name + ": " + snippet,
  snippet: post,
  image: data.media_attachments[0]?.url,
  slug: `/@lindsay/${id}`,
}
---
<MicroblogPost content={content}>
  <MicroPost
    avatar={data.account.avatar}
    url={data.url}
    username={data.account.username}
    userPage={data.account.url}
    createdAt={data.created_at}
    displayName={data.account.display_name}
    content={data.content}
    attachments={data.media_attachments}
    card={card}
    postStats={{
      repliesCount: data.replies_count,
      reblogsCount: data.reblogs_count,
      favouritesCount: data.favourites_count,
    }}
  />
</MicroblogPost>

Rather than fetching from the RSS feed, I use Mastodon's public API to fetch via ID. I then pass the data for the post into the MicroPost component, including a bit more metadata than the RSS feed gives us. With that, we can now load individual Mastodon posts directly into the site! Go to this post about my ViteConf talk to see!

One thing to note about using the API in this way, because we are just fetching data by ID we could load a post that I didn't write. I'm not too worried about it, as the correct user's name and profile image will be displayed in the post contents, but it is a consideration to keep in mind.

Conclusion

I'm sure there is more that can be done to integrate my site with the Fediverse, but this already feels really nice. Future changes could lead to better integrations with Mastodon, such as following or favoriting things from my site rather than having to go to Mastodon, but it's not a huge issue at the moment.

While Twitter may be going through some major struggles, this feels like a good way to keep up interaction with the dev community and integrate it more with my own site in a way that Twitter never allowed. And that, at least, is worth it.

If you're interested in how this turned out, check out lindsaykwardell.com/@lindsay!

Utilizing Native Dialog in Elm

Lindsay Wardell — Mon, 09 May 2022 23:30:54 +0000

A common design pattern when building client-side applications is the need to display a modal or dialog on top of the main page content. It may be a login form, a "What's New" style notification, a feedback input, or any number of other possible designs. Modals are incredibly tricky to program by hand in a way that provides a friendly and accessible experience. The W3C provides a list of reccomendations and guidelines for creating dialog interfaces, which includes a series of recommendations and guidelines on how to implement a dialog.

From the above documentation, here's the definition of a dialog:

A dialog is a window overlaid on either the primary window or another dialog window. Windows under a modal dialog are inert. That is, users cannot interact with content outside an active dialog window. Inert content outside an active dialog is typically visually obscured or dimmed so it is difficult to discern, and in some implementations, attempts to interact with the inert content cause the dialog to close.

Like non-modal dialogs, modal dialogs contain their tab sequence. That is, Tab and Shift + Tab do not move focus outside the dialog. However, unlike most non-modal dialogs, modal dialogs do not provide means for moving keyboard focus outside the dialog window without closing the dialog.

It's fairly simple to create the basic outline of a dialog interface: render a box or card in the center of the screen, provide a fade-out overlay for the background content (ideally one that can be clicked to close the box), and prevent global scrolling. However, in order to meet the requirements as outlined by the W3C, we also need to prevent tabbing in the background application, set focus on a button that can close the dialog, and restore focus to the element that triggered the dialog after it closes. Suddenly things feel a lot more complicated!

Thankfully, there is a browser native way to implement dialogs that covers (most of) the cases above, and provides straightforward ways to handle the rest: the <dialog> element!

What is `<dialog>`?

From the MDN docs:

The <dialog> HTML element represents a dialog box or other interactive component, such as a dismissible alert, inspector, or subwindow.

<dialog> is a browser-based way to create dialog interfaces. It's a newer HTML element, which only recently got support from all major browsers (Safari 15.4 was the last one, released in March 2022). According to caniuse, it's now supported across the board (except in IE11, which is expected):

In short, a dialog element is just like any other HTML element, and can be written like this (try it out!):

<html>
  <head>
    <title>Dialog example</title>
  </head>
  <body>
    <h1>Dialogs are awesome!</h1>
    <button id="open-dialog">Open dialog</button>
    <dialog>
      <h2>My dialog</h2>
      <button>Close</button>
    </dialog>
    <script src="script.js"></script>
  </body>
</html>

document.getElementById('open-dialog').addEventListener('click', () => {
  document.querySelector('dialog').showModal();
});

document.querySelector('dialog > button').addEventListener('click', () => {
  document.querySelector('dialog').close();
});

Some cool things to note here:

You get a basic style for the dialog box and the background (which are all targetable by CSS and can be tweaked as desired).
Opening the dialog sets focus to the close button.
Closing the dialog sets focus back to the open button.
Tabbing is diabled outside of the dialog when it's open.
You can also press the escape key to close the dialog.
If you're using a screen reader, such as VoiceOver, it should announce that focus has shifted between the open and close buttons.

That's a lot of free benefits for using the built-in element! Of course, some of the functionality here is reliant on Javascript. In this case, we set two event listeners, one for clicking the open button and another for clicking the close button. In order to properly toggle the dialog, we need to call a method on the dialog element itself. To open the dialog, we call showModal, and to close it we call close.

The `open` Attribute

But wait! The MDN docs list a different way to display the dialog as open: the open attribute!

Indicates that the dialog is active and can be interacted with. When the open attribute is not set, the dialog shouldn't be shown to the user. It is recommended to use the .show() or .showModal() methods to render dialogs, rather than the open attribute.

As Elm developers, it might be tempting to go down this path and set the attribute. However, doing this does not provide the additional benefits of updating focus, blocking the background from input, etc. To get the full benefit of the dialog element, we need to call showModal. Note that show is also an option, but it does basically the same thing as open, and is not recommended.

We can, however, check whether the dialog is visible at the moment by looking at open. When we call showModal, open is set to true, which means that rather than have distinct calls to open and the close the dialog, we could choose to have a simple toggle function, which internally checks whether the dialog is open.

Implementing `<dialog>` in Elm

Now that we understand what the dialog element provides us, and what is required to make it useful, let's start working with it in Elm. Elm provides a number of HTML elements in its Html module, but since the dialog element is newer, we first need to define it ourselves.

Rendering the dialog

In order to define a custom element, we need to import Html, then we can use Html.node to generate a custom element. As with any HTML element in Elm, it takes two arguments (a list of attributes and a list of HTML), but it also takes a string to use as the custom element's tag. Here's a basic example:

dialog : List (Html.Attribute msg) -> List (Html msg) -> Html msg
dialog attr content =
    Html.node "dialog" attr content

This provides a basic interface for a dialog element. However, we're going to need to trigger it's showModal and close methods, so it's probably helpful to require an ID. Let's just add the ID as part of the function signature:

dialog : String -> List (Html.Attribute msg) -> List (Html msg) -> Html msg
dialog elementId attr content =
    Html.node "dialog" ((id elementId) :: attr) content

Great! Now the ID will be set by the first argument, and the rest of the HTML element signature is the same that other elements use. At this point, you can start rendering the dialog on the page, but it won't appear (unless you set the open attribute). We need a way to trigger the methods provided in Javascript.

Triggering the dialog

Elm provides ports as the go-to solution for interacting between Javascript and Elm. We need to utilize a port to call out to Javascript in order to trigger the dialog to appear. Let's define our port below:

port toggleDialog : String -> Cmd msg

When our Elm application is compiled, toggleDialog will be available to subscribe to from Javascript. In this case, it provides a string (the dialog's ID) that we can use to select our element and perform the required action on it. Here's an example of our Javascript code:

app.ports.toggleDialog.subscribe(id => {
  const dialog = document.querySelector(`#${id}`)

  if (dialog.open) {
      dialog.close.();
  } else {
      dialog.showModal.();
  }
});

This is a pretty simple snippet of Javascript. We take the provided ID, find the element, and check whether it's open. If it is, then we close it, otherwise we open it. If you want, you could add an additional port for Javascript to inform Elm of the current status of the dialog, but it's not required.

Here's an example repository showcasing the dialog element, and here's a live demo of that repository. Check it out!

Conclusion

The dialog element provides a lot of benefits for developers needing to utilize this UI pattern. However, it's important to note that just because it provides a large number of benefits and accessibility support built-in, it still requires planning and testing to properly implement a dialog that is usable by all the visitors to your site. Make sure that you and your team are performing regular a11y testing, so you aren't leaving any of your users out of the loop with what your site is showing them!

Also, keep in mind that it is a fairly new element, and you may have users that are not supported yet. If you still have a large number of users that don't have access to the dialog element, consider using an existing alternative or providing an alternative userflow.

That said, it's very exciting to see what the future of HTML looks like, and I'm looking forward to more elements like this that are built-in and provide a lot of value to both users and developers. Try it out, and see if it works for you today!

Shipping Side Projects

Lindsay Wardell — Fri, 25 Mar 2022 04:09:27 +0000

It's late at night. Everyone else has gone to bed, but you're up just a bit later. Your fingers are flying across the keys, your brain fighting against exhaustion but flowing with great ideas. In front of you, your laptop's fans hum gently as your side project's local environment runs in the terminal. Constantly switching between your IDE and the browser, you watch as your ideas come to life before you. It's truly a magical moment. Just one more feature, and it'll be ready to ship...

A week or two later, your app is still half finished, but the drive you felt that night has faded. New ideas have started to form in your mind, unrelated to what you were working on previously. You spun up a new Git repo, and you're almost ready to buy a new domain name. It'll fit nicely next to dozen or so others you've already purchased. One day, you'll ship all of them. At least, that's the plan.

Side projects get a lot of attention from developers. It's common to visit someone's website or Github page and find multiple projects on display, all in various stages of completion or function. On Twitter, I regularly see developers talking about their side projects, often lamenting the fact that they have so many and feeling guilting that they aren't being released or finished. It's especially common to joke about the number of domains that we all have purchased but never used. At some point, I think we as developers get depressed and frustrated because of all the things we started with the best of intentions, but haven't completed.

Rather than stress ourselves out about the amount of work waiting for us when we get off work, I think it's useful to put side projects into context: what they are, what they are for, and who benefits from them.

The Purpose of Side Projects

There are lots of reasons for starting a new side project. A new framework could have been released that has some new ideas, or you want to try a new language or library. You could be trying out some new techniques, or just want to explore an idea or two that you created. Before you start a side project, it's important to understand why you're doing it. What do you want to get out of doing this project?

When I was starting to learn React, I needed a project that I felt was interesting. Rather than build a todo list or something else, I came up with a basic turn-based strategy game. It was a lot of fun, and let me explore a lot of advanced concepts in React. After many weeks of exploring this idea, the game was in a working state, but had a long way to go to be "complete".

Rather than continuing to work on it, however, I set it aside. Why? Because my goal (learing React) was complete, and I was ready to move on to learning somethign else. While it would have been cool to add all the features I had thought up, continuing to work on one project wasn't worth it. I've since come back to this concept multiple times in different frameworks and languages, the latest version being in Elm. You can play it here!

You Are the Stakeholder

When working on a professional project, either freelancing or as an employee, there are a number of stakeholders that are invested in the work you're doing and the end result of that work. This can lead to working on things that you aren't interested in, or are outright opposed to building.

For side projects, you are the stakeholder! And often, you're also the only stakeholder, which means that you get to decide what to build, how to build it, and, most importantly, when to work on it. Too often, we push ourselves to work on projects just because we started them, or out of feelings of guilt that we can't complete something. It is definitely useful to have completed, polished examples of your work for a portfolio, but not all side projects belong in that category.

At work, stakeholders help establish which projects have priority. As the stakeholder for your side projects, don't feel guilty about moving onto something else, or deprioritizing certain projects. There's no need to feel bad about side projects, they're fun!

When I feel like I'm not interested in a side project any more, rather than say I've abandoned it, I ship it. It may not be "feature-complete" to everything that I planned, but neither is any production application.

Friendly reminder, nobody is forcing you to work on side projects. If you don't want to work on it any more, then congrats! It just reached MVP. Go do something you enjoy.
— Lindsay Wardell 🏳️‍⚧️ (@lindsaykwardell) February 18, 2022

Scoping Side Projects

One of the big draws to technology is this thought that we can build a startup as a side project, and turn it into our main job. While there are a number of successes with this approach, this doesn't apply to every side project! Not every todo app needs to become Todoist. Not every budgeting app needs to turn into You Need A Budget. Just like at work, it's important to scope our side projects, so that we understand exactly what a given project should and should not become.

When I'm working on a side project, I try to put them into one of three categories - learning, maintained, and "slow cooker".

Learning Projects

Learning projects are experiments, with a goal of exploring an idea or learning a new language/framework/library/etc. These may be created to follow along with a tutorial, or just to see if something works in the way that I expect. One of the hallmarks of these projects is that I don't expect it to last longer than a week or two, and will then be abandoned.

Besides learning and exploration, these projects allow you to plant seeds of knowledge. Sometimes I will experiment with something, abandon it, then later realize that I need to do the same thing I was experimenting with. Rather than start everything from scratch, I can often copy/paste from one of these learning projects, allowing me to move faster and build on my previous learning.

Examples of learning projects include todo apps, using a public API such as the Pokemon API or the Star Wars GraphQL API, or spinning up and toying with a new framework.

Maintained Projects

Maintained projects are created with the goal of becoming a long-running project. Ideally these projects are clean and maintained, and typically small (but not always). When I want to do something to improve or change them, it doesn't take much to spin up a local environment, even if it's been awhile. I may point at these projects as examples of things I have done, such as in a portfolio.

The key identifier for a maintained project is that I expect to be coming back to it repeatedly over a long period of time, but is small enough to be finished in a reasonable amount of time.

Examples of maintained projects include my blog, small open source projects, and finished sites/applications that are used by folks on a day-to-day basis.

Slow Cooker Projects

Slow cooker projects are similar to maintained projects, except they may not have a polished, final product in the near future. These projects are the playgrounds of ambition, where the drive to build something new and make a difference somehow. This is where startup-level projects live. It takes time to build something like this, and it's important to recognize that. Just like using a slow cooker takes hours to make a meal, building a large application, framework, or whatever your idea is will take time. Don't beat yourself up when something like this doesn't result in a full-on startup after a few months, or even longer.

For me, slow cooker projects are incredibly exciting, but also incredibly draining. There's so much going on in life already, and there's only so much room for large-scale projects like this. When I'm working on a project like this, I don't limit my imagination or scope, but I allow myself to come and go from the project as inspiration strikes. If I'm not excited about working on a side project, then I set it aside, and wait for inspiration to come back. My goal with slow cooker projects is to enjoy the process, and hopefully have a finished product that I can be proud of.

Conclusion

Side projects are the first drafts of writing, the tuning session of music, and the experimentation phase of science. They provide us a fast feedback loop, and give us the opportunity to try out new ideas and concepts. They serve a crucial role in becoming a developer, and building up or maintaining our skills.

The value of side projects is in how much value they give to us, the developers. Next time you're feeling burdened with all the side projects you've never completed, remind yourself that they all served their purpose. The only person you owe to work on side projects is yourself. Don't feel like working on it? You just reached version 1.0. Congratulations!

Enjoy your next side project!

Utilizing Elm in a Web Worker

Lindsay Wardell — Fri, 18 Feb 2022 01:17:59 +0000

The Elm programming language is a great way to model and write a modern web application. By utilizing functional programming and a strong type system, Elm encourages developers to build applications that are more reliable and more easily maintained. But as a compile-to-Javascript language, there is only so much that Elm can offer by default. Any tasks that require large computations in Javascript will, unfortunately, require the same computations in Elm. Such large tasks can block the main thread in browsers, causing visual issues and a non-responsive UI. Obviously this is not what we want for our users, so what can we do?

Enter Web Workers. From MDN:

Web Workers makes it possible to run a script operation in a background thread separate from the main execution thread of a web application. The advantage of this is that laborious processing can be performed in a separate thread, allowing the main (usually the UI) thread to run without being blocked/slowed down.

Web Workers are a way that browser-based applications can move certain tasks out of the main thread, into their own environment. Web Workers have a number of restrictions to them, such as not being able to access the DOM, but they do have the ability to make HTTP requests via fetch as well as run standard Javascript code. Since Elm is a compile-to-JS language, that means that we can mount an Elm app within the Web Worker as well!

Let's explore what it would look like to use Elm inside of a Web Worker. We'll look at two ways to do it:

Using vanilla JS, no bundlers or frameworks beyond what Elm provides.
Incorporating these techniques into Vite, which provides a helpful wrapper around the Web Worker API.

Writing our Elm Modules

To start, let's set up a basic setup to work with. In a new folder, run elm init, which generates our base elm.json and a src folder. Within src, create two files: Main.elm and Worker.elm. We'll fill these in shortly. Let's also create an index.html at the root of our working direction (we'll come back to it later).

First, let's set up a very basic Main.elm file. While Web Workers are primarily useful for large tasks, for this example we're going to keep things simple for our examples. In our main file, we'll implement a basic counter example:

port module Main exposing (main)

import Browser
import Html exposing (Html, button, div, text)
import Html.Events exposing (onClick)


init : (Int, Cmd msg)
init =
    ( 0, Cmd.none )


type Msg
    = Increment
    | Decrement
    | Set Int


update : Msg -> Int -> ( Int, Cmd Msg )
update msg model =
    case msg of
        Increment ->
            ( model, increment model )

        Decrement ->
            ( model, decrement model )

        Set value ->
            ( value, Cmd.none )


view : Int -> Html Msg
view model =
    div []
        [ button [ onClick Decrement ] [ text "-" ]
        , div [] [ text (String.fromInt model) ]
        , button [ onClick Increment ] [ text "+" ]
        ]


subscriptions : Int -> Sub Msg
subscriptions _ =
    receiveCount Set


main : Program () Int Msg
main =
    Browser.element { init = \_ -> init, update = update, view = view, subscriptions = subscriptions }


port increment : Int -> Cmd msg


port decrement : Int -> Cmd msg


port receiveCount : (Int -> msg) -> Sub msg

This is a fairly straightforward Elm app, but with one key difference: rather than update the state here, we are returning a command to relay the current state to a port. We also have a port to receive a number, which then updates our local state.

Since we are going to handle this very complex computation in a Web Worker, let's now write a basic Elm module to run from within the Worker.

port module Worker exposing (main)

import Platform


type Msg
    = Increment Int
    | Decrement Int


init : () -> ( (), Cmd msg )
init _ =
    ( (), Cmd.none )


update : Msg -> () -> ( (), Cmd msg )
update msg _ =
    case msg of
        Increment int ->
            ( (), sendCount (int + 1) )

        Decrement int ->
            ( (), sendCount (int - 1) )


subscriptions : () -> Sub Msg
subscriptions _ =
    Sub.batch
        [ increment Increment
        , decrement Decrement
        ]


main : Program () () Msg
main =
    Platform.worker { init = init, update = update, subscriptions = subscriptions }


port increment : (Int -> msg) -> Sub msg


port decrement : (Int -> msg) -> Sub msg


port sendCount : Int -> Cmd msg

What's going on here? First, we import Platform, which provides us with the function Platform.worker. Most of the time, when writing an Elm app, we're leaning on elm/Browser to create apps that bind to the DOM. But in this case, we don't have a DOM to bind to, so we utilize Platform to create a basic app that doesn't do that. worker takes three inputs: init, update, and subscriptions (it's basically the same as Browser.element, from our Main.elm example).

We also create two ports for incrementing and decrementing the input (an incredibly taxing computation for even modern Javascript), and connect those to equivalent Msg values. Within the update function, we then send the results to sendCount, which outputs from Elm into the wild west of Javascript for us.

Conceptually, it looks like this:

Main receives a message (Increment)
In Main's update function, we send the current count to a matching port (increment 0)
This value is sent (via Javascript) from Main to Worker, and connected to the matching port (also increment 0)
The Worker sends out the result of its intense calculation (sendCount 1)
Main receives the updated value, and updates its model accordingly (receiveCount 1)

If you're familiar with The Elm Architecture, this is basically the same thing but with more steps. It's also important to note that because we are relying on ports to communicate between the Main and Worker apps, this calculation is inherently asynchronous. This is really only ideal for certain workloads, and should probably not be used 100% of the time (especially for small tasks like addition/subtraction).

Scaffold index.html

Now that we've had a look at the Elm code, let's look at Javascript. Since we are using vanilla JS and not a bundler, we first need to bundle our Elm code. Run the following command:

elm make src/Main.elm --output main.js
elm make src/Worker.elm --output elm-worker.js

This will output our main.js and worker.js files, which we can import into our HTML. Speaking of which let's do that! Here's a basic HTML file to start with. All it does is mount our Main app, we'll get to the Worker in a moment.

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Elm Web Workers</title>
  </head>
  <body>
    <div id="app">
      <div></div>
    </div>
    <script src="main.js"></script>
    <script>
      const app = Elm.Main.init({
        node: document.getElementById('app')
      });
    </script>
  </body>
</html>

If you open the HTML file in a browser right now, it should properly render the Main app, but the buttons don't appear to do anything. That's because rather than updating our model, they are instead sending it to ports. Currently, we aren't doing anything with our ports, but before we hook them up, let's add our Web Worker.

Adding the Web Worker

For this section, I will be referring to MDN's excellent guide to using Web Workers.

In order to create a web worker, we need to have an external JS file that can be imported and executed as a web worker. The most basic implementation of a worker can be a simple console.log. Let's do that first.

Create a worker.js file and put in console.log("Hello, worker!"). Then, in our HTML file, add this code to the top of your script block:

const worker = new Worker('worker.js')

const app = Elm.Main.init({
    node: document.getElementById('app')
});

This instructs the browser to create a worker using the Javascript file that is found at the named location (in our case, worker.js). If you open your devtools, you should see "Hello, worker!" appear there, generated from worker.js:1. Great!

Now let's add some communication between the worker and main JS files.

Sending a message

In your HTML file, let's add another line of code that will enable sending a message to the worker. To send a message from main to the worker, we use worker.postMessage().

const worker = new Worker('worker.js')

const app = Elm.Main.init({
    node: document.getElementById('app')
});

worker.postMessage(1)

To receive a message in the worker, we set onmessage (not a variable) to be a function that receives a function. Delete the contents of your worker.js file and add the following:

onmessage = function ({ data }) {
  console.log(data);
}

As with all Javascript events, there are a number of other values sent to the onmessage function. For the sake of this blog post, we only care about the data key. If you run this script, you should see a 1 logged out into the console. Congratulations, we are now able to pass data to the worker! But what about passing it into Elm?

Web Workers provide a special API for importing scripts into them:

Worker threads have access to a global function, importScripts(), which lets them import scripts. It accepts zero or more URIs as parameters to resources to import.

By using importScripts(), we can import our Elm worker module, initialize it, and begin to use its ports. Let's update our worker.js as follows:

importScripts("elm-worker.js")

const app = Elm.Worker.init();

onmessage = function ({ data }) {
  app.ports.increment.send(data);
};

app.ports.sendCount.subscribe(function(int) {
  console.log(int);
})

For those less familiar with Elm, we are initializing our Elm worker without a DOM node (because there are no DOM nodes in the worker). Then, using its ports, when we receive a message from the main thread, we send it to the increment port. Elm then does its incredibly complicated calculations, and returns (via the sendCount port) the updated integer (which we log for now). Excellent!

Before we go too much further, let's update the main and worker to properly target either the increment or decrement ports. In index.html, update your script block to the following:

const worker = new Worker('worker.js');
const app = Elm.Main.init({
    node: document.getElementById('app')
});

app.ports.increment.subscribe(int => worker.postMessage({
    type: 'increment',
    value: int
}))

app.ports.decrement.subscribe(int => worker.postMessage({
    type: 'decrement',
    value: int
}))

Then, in our worker, update to the following:

importScripts("elm-worker.js");

const app = Elm.Worker.init();

onmessage = function ({ data }) {
  const { type, value } = data;

  if (type === "increment") {
    app.ports.increment.send(value);
  }

  if (type === "decrement") {
    app.ports.decrement.send(value);
  }
};

app.ports.sendCount.subscribe(function (int) {
  console.log(int);
});

If you refresh the page, you can now start clicking the buttons and seeing the results log in the console. Of course, it's only going to show 1 or -1, so let's pass data back to the main thread.

Web Workers have a global postMessage function that allows us to pass back data. Let's wrap up this code and send the calculated result to the main thread (and our Main Elm app):

In worker.js, do the following:

importScripts("elm-worker.js");

const app = Elm.Worker.init();

onmessage = function ({ data }) {
  const { type, value } = data;

  if (type === "increment") {
    app.ports.increment.send(value);
  }

  if (type === "decrement") {
    app.ports.decrement.send(value);
  }
};

app.ports.sendCount.subscribe(function (int) {
  console.log(int);
  postMessage(int);
});

In index.html, update the script block:

const worker = new Worker('worker.js');
const app = Elm.Main.init({
    node: document.getElementById('app')
});

app.ports.increment.subscribe(int => worker.postMessage({
    type: 'increment',
    value: int
}))

app.ports.decrement.subscribe(int => worker.postMessage({
    type: 'decrement',
    value: int
}))

worker.onmessage = function( { data }) {
    app.ports.receiveCount.send(data);
}

And with that, we are now passing data! Congratulations! If you need to pass any complex data between the main and worker threads, you will probably need to turn to JSON encoding/decoding. You can also pass an object with a custom message if needed, rather than using multiple ports and relying on Javascript to act as the controller.

Here's a repository with the code we've been looking at.

Web Workers in Vite

Using vanilla HTML and JS is nice, but most of the time at work or in larger projects we're using some sort of build tooling to have a more streamlined experience. I'm personally a big fan of Vite, the frontend tooling solution by the creator of Vue. I maintain a Vite template for building Elm applications, which utilized the excellent Elm plugin for Vite to achieve hot module reload and directly importing our .elm files into our Javascript.

As an added benefit for our use case, Vite provides some abstraction over the Web Worker API that we explored above. In Vite, when we import a script that we want to use as a web worker, we can append a query parameter that signals to Vite what it is, and then Vite will wrap it in a function that generates the correct worker command.

Let's migrate our above code into Vite and see how this works. I'll be using my template to scaffold a basic app. To do that yourself, run the following command:

npx degit lindsaykwardell/vite-elm-template vite-elm-web-worker
cd vite-elm-web-worker
npm install

That will clone the template locally (with no Git history) into the vite-elm-web-worker folder, enter it, and install the required dependencies. Feel free to rename it to whatever you prefer. Then, delete the contents of the src folder and replace them with our Main.elm and Worker.elm files. At this point, you should have a setup that looks like this:

Next, let's bring over our worker.js and other Javascript. Let's start by creating a worker.js file (we'll come back to it in a moment), and then update our main.js file to include our worker and port logic:

import "./style.css";
import { Elm } from "./src/Main.elm";
import ElmWorker from "./worker?worker";

const root = document.querySelector("#app div");

const worker = new ElmWorker();
const app = Elm.Main.init({ node: root });

app.ports.increment.subscribe((int) =>
  worker.postMessage({
    type: "increment",
    value: int,
  })
);

app.ports.decrement.subscribe((int) =>
  worker.postMessage({
    type: "decrement",
    value: int,
  })
);

worker.onmessage = function ({ data }) {
  app.ports.receiveCount.send(data);
};

This should look very familiar to what we were doing, but with some additional import syntax at the top. This is because we're using Vite, and Vite supports ES Modules by default during development. Rather than including multiple script tags (which is still an option), we can import a single ES module (main.js), and import our other files within it.

For the worker, most of the code we wrote previously will work, but Vite provides some additional sugar on top of the API here:

The worker script can also use import statements instead of importScripts() - note during dev this relies on browser native support and currently only works in Chrome, but for the production build it is compiled away.

So rather than using importScripts(), Vite requires that we use the standard ES Module import syntax. However, there's an issue here: Elm doesn't compile by default into a format that works well with ES Modules. In addition, the Vite plugin for Elm assumes that you are building a browser-based app (a reasonable assumption), and injects some DOM-powered troubleshooting helpers, which do not work in the worker because the worker doesn't have access to the DOM.

For example, let's assume we update our worker to use ES import syntax, like this:

import { Elm } from './src/Worker.elm'

const app = Elm.Worker.init();

onmessage = function ({ data }) {
  const { type, value } = data;

  if (type === "increment") {
    app.ports.increment.send(value);
  }

  if (type === "decrement") {
    app.ports.decrement.send(value);
  }
};

app.ports.sendCount.subscribe(function (int) {
  console.log(int);
  postMessage(int);
});

If you start your development environment now (using npm run dev), you will immediately see an error in the browser console:

Uncaught ReferenceError: HTMLElement is not defined

This error is being thrown by overlay.ts. This file adds an error overlay when Elm isn't able to properly compile. So if you're working in the Main.elm file, and make a change that doesn't compile, you'll see something like this:

Pretty helpful during app development, but very frustrating when trying to load Elm in a web worker. There is a setting that can be set in the Vite config (server.hmr.overlay: false) to disable the overlay, but unfortuantely it doesn't actually prevent HTMLElement from being referenced within the Worker.

A second approach could be to precompile our Worker.elm file, and import it directly into the worker.js file (as we did in our vanilla JS example). This, however, throws a silent error; the app will load without any obvious failures, but the worker isn't actually initialized. Go ahead and try it! Run elm make src/Worker.elm --output elm-worker.js, then update the worker.js to the following:

import { Elm } from './elm-worker.js'

console.log("I'm here!")

const app = Elm.Worker.init();

onmessage = function ({ data }) {
  const { type, value } = data;

  if (type === "increment") {
    app.ports.increment.send(value);
  }

  if (type === "decrement") {
    app.ports.decrement.send(value);
  }
};

app.ports.sendCount.subscribe(function (int) {
  console.log(int);
  postMessage(int);
});

If you spin up the app again, you'll notice that our console.log doesn't even run. That's because the web worker was never initialized, which is very unhelpful for our complex computations.

So what's the solution? At the moment, the best solution I've found is to create a separate entrypoint for Vite, import Worker.elm there, and compile it with Vite. That will perform the transformation we need on Elm to allow an import into the worker.

Within our src folder, create an elm-worker.js file, and put the following into it:

import { Elm } from "./Worker.elm";

const app = Elm.Worker.init();

export default app;

This is a very basic file, all it does is import our Worker.elm file, initialize the app, and export it. Now we need to compile this file with Vite. At the root level of our app, create a file called worker.config.js. This will be a special Vite configuration file that we will only use to compile elm-worker.js. Here's a good configuration to start with:

import { defineConfig } from "vite";
import elmPlugin from "vite-plugin-elm";
const path = require("path");

export default defineConfig({
  publicDir: false,
  plugins: [elmPlugin()],
  build: {
    outDir: "./elm-worker",
    sourcemap: false,
    lib: {
      entry: path.resolve(__dirname, "./src/elm-worker.js"),
      name: "elm-worker",
      fileName: (format) => `elm-worker.${format}.js`,
    },
  },
});

This configuration specifies that we only care about elm-worker.js, not importing any other files (such as the public folder), and to build those files in an elm-worker folder. By default, Vite compiles both ESM and UMD formats; this is probably not useful for our case, but it's not a big issue.

With our config in place, run the following command:

npx vite build --config worker.config.js

This instructs Vite to run its build command, using our new config file instead of the default one. Once it finishes, you should see a new elm-worker folder, with two files inside: elm-worker.es.js and elm-worker.umd.js.

With our newly compiled ES-compatible file in hand, we can now, at last, import our Elm worker into our web worker file, and everything will work as expected. Update our worker.js file (at the root of our app) to the following:

import app from './elm-worker/elm-worker.es.js'

onmessage = function ({ data }) {
  const { type, value } = data;

  if (type === "increment") {
    app.ports.increment.send(value);
  }

  if (type === "decrement") {
    app.ports.decrement.send(value);
  }
};

app.ports.sendCount.subscribe(function (int) {
  console.log(int);
  postMessage(int);
});

If you run npm run dev now, and start clicking on the plus and minus buttons, you should see the value displayed on the screen changing. Congratulations! We now have a web worker running Elm within Vite!

This is by no means not a straightforward solution, but it does at least work, and it allows us to utilize the other benefits of using a frontend development tool like Vite. To make things easier going forward, you can add a custom script to package.json (something like build:worker) to run our worker build command, and you can even add it to our dev script to ensure it runs every time, keeping our web worker closer in sync with the rest of our app.

Here's a repo with our working Vite code.

Conclusion

Obviously basic addition and subtraction isn't worth the extra overhead of using web workers. Tasks that require large computations (either complex calculations, or just parsing a lot of data) are ideal for this situation. One side project where I've used a web worker required potentially processing more than 2 megabytes of data, which, when done in the main thread, caused the entire app to freeze. Moving the same calculation to a web worker didn't speed up the calculation, but it did allow the UI (and the CSS) to continue running at full speed. Here's the web worker from the side project if you're interested!

Also, in case you're concerned, Web Workers have been supported in all modern browsers since IE10, so feel free to use them in your new projects!

I look forward to seeing what you make with Web Components!

Coming Into Vue: What's Next in Vue 3

Lindsay Wardell — Tue, 08 Feb 2022 19:51:08 +0000

It was a moment of celebration across the Vueniverse. At last, after more than a year of Vue 3 being available on the next branch of all the core repositories (and many of the related frameworks and libraries), Vue 3 has been officially released to the world as the recommended way to write Vue applications. The moment was noted on the official Vue blog as well as on Twitter.

🎉 It's done! Vue 3 is now the default version and the brand new https://t.co/0N2uGPCtsh is live!

More details in the blog post in case you missed it: https://t.co/ub8L4KhPsJ
— Vue.js (@vuejs) February 7, 2022

Considering that the initial release of Vue 3 (named "One Piece") was originally released on September 18, 2020, the fact that we're only now reaching the official recommendation has shaped the Vue ecosystem. For applications, most of the actual migration between Vue 2 to Vue 3 is straightforward, with Vue minimizing breaking changes while adding new features such as the Composition API as well as the latest new feature to land in Vue, <script setup>, which provides a way to build Vue apps without so much boilerplate code (I presented a demo of using Composition API and <script setup> alongside Ben Hong at VueJS Athens, check it out!).

However, the Vue ecosystem has seen its share of churn in the meantime. Core APIs that frameworks like Vuetify rely on were altered, to the point that even the Migration Build doesn't cover the differences between Vue 2 and 3. Frameworks such as Nuxt and Quasar have been working to support Vue 3 (with Quasar releasing it's stable support back in 2021). Meanwhile, work has been going into Vite, which is now the official recommendation for building Vue apps as well (replacing the Vue CLI).

Now that we've reached an official recommendation to use Vue 3, what does the future look like for the Vue ecosystem? I asked Twitter what they were looking forward to in the future of Vue, and these are some of the answers that I got.

Reactivity Transform

The Reactivity Transform Unification is the final piece in Vue 3 reactivity primitives and <script setup> based RFCs story. Once @vuejs finalizes this RFC, there will be a massive DX improvement both for advanced users and for newcomers to the frameworkhttps://t.co/8DzIz96ovD
— patak (@patak_dev) February 8, 2022

The next new feature coming to Vue 3 is being referred to as the "Reactivity Transform Unification". The main issue being resolved here is that the introduction of Ref can be complex, especially moving from Vue 2 to 3. For context, in Vue 3 today, you can create and access a ref value like this:

<script setup>
import { ref } from 'vue';

const count = ref(0)        // Set the value with a `ref` call
console.log(count.value)    // Access the value with `.value` in JS
</script>

<template>
  <!-- Access the value with just the ref name -->
  <button @click="count++">
    {{count}}
  </button>
</template>

The change would be to provide a utility function, $ref, that would unwrap the ref into a reactive variable, and then let you work with it directly, rather than accessing the .value key.

<script setup>
const count = $ref(0)   // Set the value with a `$ref` call
console.log(count)      // Access the value directly!
</script>

<template>
  <!-- No changes, still access the value directly -->
  <button @click="count++">
    {{count}}
  </button>
</template>

This feels a lot more comfortable to work with, especially for non-Vue developers! There have been a number of proposals trying to resolve the cumbersome nature of refs, and I think this is a comfortable middle ground. There are a number of other functions proposed in the RFC, go check it out and provide your feedback!

Nuxt 3

Can't wait for @nuxt_js 3 to be stable now!
— CapitaineToinon (@CapitaineToinon) February 8, 2022

The next big call-out I saw from the ecosystem is Nuxt 3 reaching a stable build. Nuxt 3 is an exciting new major version for Vue's primary SSR framework, with new features such as its Nitro backend (that allows it to be deployed to a number of environments beyond a standard Node server) and Vite integration. On the Nuxt site, there is a chart comparing the different versions of Nuxt as they exist today, and their recommendations. I'll copy it below to keep a snapshot of the status as I write this post, but the latest comparison can be found on the Nuxt 3 site.

Feature / Version	Nuxt 2	Nuxt Bridge	Nuxt 3
Vue	2	2	3
Stability	😊 Stable	😌 Semi-stable	😬 Unstable
Performance	🏎 Fast	✈️ Faster	🚀 Fastest
Nitro Engine	❌	✅	✅
ESM support	🌙 Partial	👍 Better	✅
TypeScript	☑️ Opt-in	🚧 Partial	✅
Composition API	❌	🚧 Partial	✅
Options API	✅	✅	✅
Components Auto Import	✅	✅	✅
`<script setup>` syntax	❌	🚧 Partial	✅
Auto Imports	❌	✅	✅
Webpack	4	4	5
Vite	⚠️ Partial	🚧 Partial	🚧 Experimental
Nuxi CLI	❌ Old	✅ nuxi	✅ nuxi
Static sites	✅	✅	🚧

There are a couple key features that are still being worked out before Nuxt 3 is stable, based on this chart. Since Nuxt 2 was based on Webpack, Vite integration is still experimental and under development. I've done some playing around with it, and found it to work fairly well, but I'm not working on production code with Nuxt and Vite so there's probably some edge cases still to work out. If you want to try Nuxt 3 and Vite, just add this to your Nuxt config:

// nuxt.config.ts

import { defineNuxtConfig } from "nuxt3";

// https://v3.nuxtjs.org/docs/directory-structure/nuxt.config
export default defineNuxtConfig({
  // Add the `vite` key to your config, and you'll opt into Vite mode
  vite: {},
});

The other missing feature is static site generation. While Nuxt is primarily a server-side generator, it can be used to build static sites as well. If you're wanting to use Nuxt 3 features, but really need static sites, you'll need to use the Nuxt Bridge. From the docs:

Bridge is a forward-compatibility layer that allows you to experience many of the new Nuxt 3 features by simply installing and enabling a Nuxt module.

Using Nuxt Bridge, you can make sure your project is (almost) ready for Nuxt 3 and have the best developer experience without needing a major rewrite or risk breaking changes.

If you're looking to try out Nuxt 3 with an existing app, I'd suggest checking out the Bridge build. Otherwise, spin up a new app with Nuxt 3, and be aware that static generation is currently under development and does not work. Also, remember that because it's under development, it's best to consider the Nuxt APIs as unstable and prone to change. While it feels solid, Nuxt 3 is not yet ready for production use.

Vuetify

Vuetify compatible with vue3
— Viliam Mihálik (@ViliamMih) February 8, 2022

Vuetify, one of the most well-known material frameworks for building Vue apps, is still working on support for Vue 3. Part of this is due to an overhaul under the hood that will lead to improved performance and a better experience. According to the Vuetify official roadmap, Vuetify 3 is planned for release in May 2022, with a public beta in February.

Target Release: May 2022
Alpha: Live
Beta: February 2022
Overview:
- Rebuilt for Vue 3 using the new composition api
- Global properties that allow you to make large overarching changes to your app
- Improved SASS variable customization and extensibility with Built-In Modules
- New Vue CLI presets for generating pre-built starting projects
- First party Vite support for lightning fast development
- Greatly improved TypeScript support
- Better framework coverage with E2E testing using Cypress

Check out the links on the Vuetify page to access their Github page and Discord channel.

Ecosystem Support and Stability

It'll be great when the ecosystem catches up inc. all the plugins and Nuxt 3
— Anthony Gore (@anthonygore) February 8, 2022

There are a number of other prominent Vue libraries that are still working on their stable Vue 3 support. Vue Apollo, Vuelidate, and Bootstrap Vue have some work done, but are in different stages of either "not available" or "public alpha". Some other projects, such as NativeScript Vue, are having to undergo more substantial rewrites in order to be compatible. All of this takes time, and in the meantime the projects that are reliant on these libraries will have to remain on Vue 2, or switch to alternatives that already support Vue 3.

In that sense, libraries/frameworks that already support Vue 3 have a clear advantage at the moment, and should definitely be considered if you're using a Vue 2-only option. UI frameworks like Quasar are a good alternative to Vuetify or Bootstrap if you're able to make the switch, for example.

There are also some libraries that have already been updated, such as Vue Draggable, as well as others that will not be getting Vue 3 support, such as Vue Formulate (if you're using it, check out the public beta for its replacement, FormKit).

@useFormKit 🤗
— Justin Schroeder (@jpschroeder) February 7, 2022

Conclusion

As a wrap-up to this topic, what I think is most wanted out of the Vue ecosystem in the near future is some peace and quiet.

Ecosystem stability. Vue3 is great, but as a new developer to the Vue space, everything seems so fragile. :/
— Nikki Strømsnes (@TheNix) February 8, 2022

Upheavals in how things are done are never easy. The Vue team saw that changes were required in order for Vue applications to continue scaling and solving the problems developers were facing, and made some difficult choices. That, on top of a pandemic interrupting the normal flow of life, has led to a very delicate place for the Vue ecosystem. I feel like in general, we're heading in the right direction, and the more libraries that are able to support Vue 3 moving forward, the faster we'll get there.

Vue 3 is a fantastic JS framework to pick up and use today. If you are new to Vue, I highly encourage checking out the new official documentation for Vue 3, it's a fantastic resource that will get you up to speed on the essentials and current recommended practices. If you're into podcasts, I'd also recommend checking out both Views on Vue and Enjoy the Vue. And most important, make sure to enjoy the journey along the way.

Setting up an Elm project in 2022

Lindsay Wardell — Mon, 20 Dec 2021 00:49:47 +0000

If you haven't used Elm before, it can be a bit intimidating to get started. A pure functional programming language for building web applications, Elm provides a number of tools for writing Elm apps, including elm reactor for fast recompiling of specific modules and elm make for building JS assets. But this workflow can feel a bit lacking if you're coming from a Javascript ecosystem, where hot module reload (HMR), automatic bundling, and integration with CSS and other frontend technologies is common.

Luckily, there are a number of options for setting up a successful Elm application today. Let's explore what's available for building an Elm application in 2022, including ways to get a better development environment, as well as the tooling surrounding Elm that makes working with the language as delightful as possible.

Elm (the language)

You can install the Elm language (and its bundled tooling) from npm. Installing Elm globally gives you access to a handful of useful tools:

`elm repl`

This is the command line repl for Elm. You can use it to execute commands in Elm and see what the result would be.

`elm init`

This is the command to initialize Elm in a folder. Because Elm has its own ecoystem of tooling and libraries separate from Javascript, it also does not use npm for its package management, and as such does not rely on package.json. If you want to add Elm to a project (or start a new project), you'll need to run this command. When you do, you'll see a message like this:

$ elm init
Hello! Elm projects always start with an elm.json file. I can create them!

Now you may be wondering, what will be in this file? How do I add Elm files to
my project? How do I see it in the browser? How will my code grow? Do I need
more directories? What about tests? Etc.

Check out <https://elm-lang.org/0.19.1/init> for all the answers!

Knowing all that, would you like me to create an elm.json file now? [Y/n]

This is an example of how Elm provides helpful information at every opportunity, as well! The link it provides takes you to documentation on how to structure and scaffold an Elm application.

`elm reactor`

Running elm reactor opens an interactive page for navigating your Elm code and previewing it in the browser. Note that is does not render external Javascript, or any values set in your HTML files; it is only displaying what the output is for a given Elm file. Also, it does not support auto refresh, so you will have to manually refresh your browser.

`elm install`

As you may expect, this command installs an Elm dependency in your application. Sometimes you will need to install a dependency that is already a sub dependency, in which case Elm will inform you that it's going to move the dependency up in the chain so that you can import its modules directly.

`elm make`

This command lets you build the output Javascript from your Elm code, so that you can import and initialize it in your application. If you are utilizing a tool like Webpack, Parcel, Rollup, or Vite, this is typically not something you'll need to do (more on bundlers later).

There are other commands available as well. Feel free to run elm --help to see all the available commands and options.

Editor

There are a handful of plugins and extension for different editors, the majority of which can be found on an officially updated list within the Elm organization on Github. My editor of choice is VS Code, and the VS Code extension for Elm is an excellent tool for writing in Elm. It provides details on errors when saving, references to where a particular function or value is utilized, and access to function documentation on hover

Code Formatting

Unlike Javascript, Elm has an official Style Guide for how Elm code should be structured. In addition, some formatting is built into the language itself, such as requiring indents of four spaces. This removes a major point of contention within teams. In addition, the community has put together a wonderful tool called elm-format. Similar to Prettier, this utility can be used to ensure that all Elm code matches the official style guide. Unlike Prettier, there is no custom configuration, meaning once again that your team can focus on writing code instead of what kind of quotes to use.

Linting

The Elm community has an unofficial linter (called elm-review), which can be used to check your code for potential bugs or mistakes, or highlight a better way to write Elm. Unlike elm-format (and more similar to tools like ESLint), elm-review does not come with any default rules to follow:

All the rules describing problematic code are written in Elm, and elm-review does not come with any built-in rules; instead users are encouraged to write rules themselves and publish them as Elm packages, for everyone to benefit. Search the package registry to find what's out there!

Testing

The de-facto standard for testing an Elm application is elm-test. However, as noted in the README:

When people say “elm-test” they usually refer to either:

This Elm package for writing tests.

rtfeldman/node-test-runner – a CLI tool (called elm-test) for running tests defined using this package in the terminal.

The Elm package (available on the Elm package repository) contains the functions required to write tests, query HTML, and perform assertions. The syntax should be familiar if you've written unit or fuzz tests in other languages, with describe blocks and individual test functions being called.

To actually run the tests, however, there are currently two options. The first, as noted above, is node-test-runner, which is available from npm at elm-test. This utility will run the tests as defined in your Elm code, and return the results. There is a second option, elm-test-rs, which is written in Rust instead of Node. It has a handful of features that node-test-runner does not have, as well as some downsides (see the Github README for details), but in general both tools work very well for testing Elm code.

Development Environment

Now's the fun part - writing our app! Using only the above tools, you would be set to build an Elm application that is properly formatted, tested, and compiled to JS. However, that doesn't help you get it onto the page; you'l still have to create an HTML file, import your Elm code along with any other dependencies you may have, and test it in your "live" environment. Found an error? Time to recompile!

Needless to say, this can get pretty tedious, not to mention that most Javascript developers today are used to more advanced tooling (such as auto refresh or hot module reload). What can we do in order to set up a better development environment for ourselves?

elm-live

First on our list is elm-live. From their README, elm-live provides:

Hot reloading

Local SSL

No reload mode

No server mode

and more!

It's a pretty great tool for working with an Elm application, removing the tedious step of constantly rebuilding our application. However, there's still a couple drawbacks with using elm-live. First, it exists as a development environment for Elm, which means that changing our HTML, CSS, or Javascript assets will not trigger anything. Second, if you need any dependencies from npm, elm-live will not compile these for you. You'll still need some sort of bundler for the rest of your assets. elm-live is excellent for projects written primarily in Elm, or if you don't mind running two development environments side by side.

Webpack/Rollup/etc

If you're a Javascript developer, you may have gotten accustomed with importing arbitrary files into your Javascript code. Want to bring in a .vue file? Go for it! .svelte? Sure, why not! Our favorite frameworks typically provide some sort of integration with bundlers so that we can import them directly, without having to compile them first to standard Javascript. Can we do that with Elm?

It turns out, we can! Elm has pretty good support across compilers/bundlers, so that you can import an Elm file directly into your core JS application - no compile step required! Keep in mind that you will still need to initialize the Elm application in order for that code to do anything, but otherwise you are able to treat it like any other compile-to-JS asset.

Here's a list of common compiler options:

If you like using Parcel, then you're in luck! Parcel provides built-in support for Elm by default, no plugins required. There had been some issues in Parcel 2 and Elm, but at this point they appear to be worked out, making Parcel an amazing choice if you're expecting interop with Javascript and want a great experience.

`elm-tooling`

Great! Now we're able to import our Elm code directly into our existing applications, making the integration that much easier. However, there's still one last thing we can do to improve our environment. One problem we may run into is that the tooling described above needs to be installed locally in order to utilize it, which can lead to more work onboarding developers or getting started with a project.

There is a tool called elm-tooling which does all the hard work for us. Rather than having to install the Elm language, elm-format, and elm-test (or elm-test-rs) individually, we can run npx elm-tooling install, and all of the core tooling can be installed at once, significantly faster than if they were installed individually. This can even be added as a postinstall command in your package.json, ensuring that Elm and its related tools are available with a single install command. This is extremely useful when setting up your local environment, or during CI build steps.

Frameworks and Templates

All this tooling is great, and an excellent way to get writing Elm code and integrating it into your application. But sometimes it's nice to start from a higher level abstraction, much like React developers often start with Create React App, or Vue developers use the Vue CLI. While there are no official templates or frameworks beyond what we've already talked about, there are a few interesting projects that are worth taking a look at.

elm-spa

elm-spa is a great way to start working on a single-page Elm application. Browser navigation and handling multiple pages is something that is a bit more difficult in Elm than in pure Javascript, and as such requires more boilerplate code in order to make it work. elm-spa handles all of the complexities of building an SPA for you, while providing a number of great features for building a modern web application.

elm-pages

Where elm-spa is targeting single-page applications, elm-pages is built for generating static sites. Utilizing Elm's type system, elm-pages's goal is to make handling external data for a static site easy. Conceptually, it's similar to what Gatsby or Gridsome do (provide a typesafe interface to access multiple types of data), but utilizing Elm's strengths rather than adding an additional type system such as GraphQL.

ElmBook

ElmBook's goal is to provide a solid documentation site for library or package code. It includes a search function, as well as the ability to break down your docs into chapters and books. It also allows rendering Elm code within your docs, via a shared model, so that you can demonstrate functionality in the UI. It's built on top of elm-live, so working with ElmBook should feel familiar if you've used it before.

If you're coming from Vue, the focus of ElmBook is similar to Vuepress, but rather than focusing on markdown files, ElmBook is written within Elm itself. Markdown is supported for writing the documentation itself, but all of your work will be handled within the Elm code, making your documentation perfectly typesafe as well as useful.

Every application, tool or team has their own history worth telling.

ElmBook tries to help them by making it easy to create rich documents that showcase their libraries documentations, UI components, design tokens, or anything else their creativity comes up with.

`vite-elm-template`

This was a template I created to scratch my own itch. As a Vue developer, I love working with Vite, and really wanted a base template for Vite that I could use to build Elm applications. vite-elm-template is a basic Vite template intended to get you started writing in Elm without having to spend time configuring everything yourself. Unlike elm-pages or elm-spa, it's not a framework of any sort. If you want to bring in single-page application features, or other functionalities, you will have to build those in yourself. That said, it's perfect for getting started with a basic environment.

As of this writing it includes:

Hot Module Reload of all code in the app (including Elm)
Tooling installation via elm-tooling
- Includes Elm, elm-format, elm-json, and elm-test-rs
Basic unit test examples
Github Actions CI for running tests
Recommends the Elm VS Code extension

If Vite is something you enjoy working with, I hope you'll check it out! There is also a link in the README to set up a workspace using Gitpod if you want to try things out in a sandbox environment first.

Conclusion

I hope that helps you get started building an Elm application! Elm is an amazing language to learn and work with, and the tooling that exists to support it today makes working with it as delightful an experience as the language itself provides. Above all, I hope you enjoy learning and working with Elm in 2022!

If you're new to Elm, and would like to learn more about it, check out the official Elm Guide.

Astro 0.21 - Upgrade Experience

Lindsay Wardell — Sat, 20 Nov 2021 23:39:45 +0000

The day has finally arrived! Astro has released 0.21 publicly, and it's a big change. Most important of all, they've migrated the development environment from Snowpack to Vite, which opens up a whole slew of new features and plugins to the Astro ecosystem. There are also a number of other changes, which are listed in the annoucement and migration guide. If you're looking to upgrade your site, I highly encourage you to check out those resources first!

Rather than guide you through the upgrade process (their migration doc is pretty good for that), I want to document my experience. I ran into a number of interesting bumps along the way, and I think it would be beneficial to share my experience with anyone else interested in performing their upgrade.

For context on my site, I am mostly using Astro componets (with the .astro file extension), with a couple small Vue components. Most of the issues I ran into were related to Astro components, and the changed API. I did not have to do anything related to file imports, React, or TSX/JSX.

Also, if you're interested, here's the PR I used to track my changes as I performed the upgrade.

With that out of the way, let's upggrade to Astro 0.21!

Update Dependencies

The first thing I did was update my package.json to use the new dependencies. This was a straightforward change using npm outdated and manually updating/removing unused packages. Besides updating Astro and the Vue renderer to the latest version, I removed @snowpack/plugin-dotenv because Astro now supports .env files by default!

Also, as Astro is no longer using Snowpack for its build tool, I had to update my environment variables as well, removing SNOWPACK from the variable name.

However, when I ran npm run dev, I was presented with an error!

Error: Build failed with 12 errors:
node_modules/fetch-blob/from.js:1:59: error: Could not resolve "node:fs" (mark it as external to exclude it from the bundle)
node_modules/fetch-blob/from.js:2:25: error: Could not resolve "node:path" (mark it as external to exclude it from the bundle)
node_modules/fetch-blob/from.js:3:31: error: Could not resolve "node:worker_threads" (mark it as external to exclude it from the bundle)
node_modules/node-fetch/src/body.js:8:34: error: Could not resolve "node:stream" (mark it as external to exclude it from the bundle)
node_modules/node-fetch/src/body.js:9:31: error: Could not resolve "node:util" (mark it as external to exclude it from the bundle)

This error was thrown because I was importing node-fetch in a couple JS files. In Astro 0.21, fetch is now globally available, both inside and outside of .astro components. Removing the import of node-fetch solved the problem.

However, I was presented with a different error!

panic: Export statements must be placed at the top of .astro files!
panic: Export statements must be placed at the top of .astro files!
2:14:52 PM [vite] Error when evaluating SSR module /src/layouts/BlogPost.astro:
    at /src/layouts/BaseLayout.astro
2:14:52 PM [vite] Error when evaluating SSR module /src/pages/blog/a-song-unsung.md:
    at /src/layouts/BaseLayout.astro
2:14:52 PM [vite] Error when evaluating SSR module /src/pages/index.astro:
    at /src/layouts/BaseLayout.astro
02:14 PM [astro] 500 /                                        1753ms

Astro now requires all exports (such as the Props interface) to be at the top of the file. This was a simple change, but not one documented in the migration guide. By either removing or moving the exported Props interface, the dev environment was able to load. However, something was missing...

The content!

Missing Body

When localhost:3000 came up, I was presented with a perfectly blank screen. I noticed that the head tag was filling in properly, but not the body. In Chrome devtools, nothing appeared between the <body> tag.

<!DOCTYPE html>
<html>
  <head>
    <!-- meta tags, script, etc -->
  </head>
  <body></body>
</html>

What's going on here? I'm honestly still not sure. If I updated my index.astro file to have some extra text before calling <BaseLayout>, the text would load, and the meta tags would be replicated inside the <body> tag. The solution was to eliminate the BaseHead component (which was only utilized by BaseLayout), which placed the actual HTML tags in the layout component.

However, I took a bit of a detour before coming to this solution, and realized that my Tailwind configuration was no longer working. This was thankfully a straightforward fix, although the documentation seemed to be spread across a couple pages.

First, I had to manually install PostCSS and autoprefixer. Then, I updated my postcss.config.cjs file to include postcss-nested, Tailwind, and autoprefixer (previously I had only needed to import postcss-nested). This reenabled Tailwind for my site, which I was able to validate after I fixed the missing body problem.

However, something didn't look quite right

Missing Styles

While the site loaded (and Tailwind properly initialized), a number of custom styles were missing.

Crucially (for me), dark mode was completely nonfunctional. Some elements would switch style, but a majority (including the root background and any text) were not changing. Consulting the Chrome devtools revealed that my styles (using PostCSS) were not being properly processed before passing into the DOM. For example, this is what Astro was putting into the site (formatting added by me):

.blog-item.astro-EDZCIZOF {@apply shadow-md rounded-lg relative overflow-hidden flex justify-center;animation:0.3s ease-out 0s 1 shift;.}.blog-image-wrapper.astro-EDZCIZOF{height:300px;width:100%;overflow:hidden;}@keyframes shift{0%{transform:translateY(30%);opacity:0;}100%{transform:translateY(0);opacity:1;}}

Clearly, Astro was not properly applying PostCSS here. Tailwind's @apply rule was being ignored and sent straight to the compiled CSS. The solution here was to export these global styles into the global.css file, instead of inline on my BaseLayout.astro component. That's fine, it's probably better this way anyway.

Navigating around the site, I kept noticing that other styles were also failing:

The solution, as before, was to pull out the inline CSS into external files. I wasn't a huge fan of this solution, but it worked. Styles looked as they were supposed to, and life was good.

Except the site still wouldn't build.

Bad CSS!

Everything looks as it should, so I tried to deploy to Netlify. However, an error was still popping up:

Unknown word? That doesn't make se... oh. OH. There's an extra period after a semicolon. That's weird, I didn't write anything like that. And besides, that's coming from about.css, which isn't a file I created. What's going on?

Doing a bit of searching, I found another style block that I had missed in my previous cleanup, but this one was scoped to a component. I'd much rather not extract it from the Astro component, considering that's the whole point of scoped CSS in a component (as a Vue fan, I'm a proponent of this approach).

I reached out on the Astro Discord channel (which I highly recommend if you are using Astro), and reported the issue.

We quickly discovered that the cause of the problem was that I had set the language for the style block to postcss, which was causing issues with the Astro compiler. Switching to pcss solved the problem, and I was able to find and update the remaining scoped CSS blocks to correctly use Postcss. (If you're interested, here's the link to the Discord thread). I also moved back a number of styles to their components, leaving just the actual global styles in global.css.

Success?

With that, I was able to deploy an updated version of the site, now powered by Astro 0.21. My tests were passing, visuals looked correct, and the build ran locally without errors. Let's send it up to Netlify for deployment!

7:58:22 AM: > astro build
7:58:23 AM: 03:58 PM [config] Set "buildOptions.site" to generate correct canonical URLs and sitemap
7:58:26 AM: warn - You have enabled the JIT engine which is currently in preview.
7:58:26 AM: warn - Preview features are not covered by semver, may introduce breaking changes, and can change at any time.
7:58:31 AM: [object Object]
7:58:31 AM: Error: [object Object]
7:58:31 AM: npm ERR! code ELIFECYCLE
7:58:31 AM: npm ERR! errno 1
7:58:31 AM: npm ERR! lindsaykwardell@4.0.0 generate: `astro build`
7:58:31 AM: npm ERR! Exit status 1

What a lovely error! Thankfully, this was my fault, not Astro or Netlify. I had forgotten to update my environment variables on Netlify, causing the build to fail (that object is probably a JS fetch error). Easy fix, and it was good to go. The build went up, deployment was successful, and... my JS wasn't loading.

Having some trouble with @Netlify and @astrodotbuild 0.21. For some reason, I'm unable to fetch my JS files for partial hydration because they're blocked by CORS. It looks like files are being stored on Cloudfront instead of my domain.

Anyone run into something like this before?
— Lindsay Wardell 🏳️‍⚧️ (@lindsaykwardell) November 20, 2021

This was slightly more complex, but had an easy solution. The build was working as expected locally, I could see the JS files were present (and clearly being cached by Netlify on Cloudfront). I didn't have any build plugins enabled that modified the JS, and (most confusing) everything worked as expected on Astro 0.20.

After doing some googling, I found the problem in a Netlify support thread.

Yup - that is saying that cloudfront doesn’t have your custom header which is true! I think you’re using asset optimization on the site, and that will clash with custom headers - we can’t set them on those resources. So, you could turn off that feature in your build and deploy settings and that would remove the problem.

I'm not certain what custom header is being set by Astro/Netlify/wherever, but between 0.20 and 0.21 a custom header was being applied, which broke the JS fetch when going across domains. I went into my settings, and disabled the JS minification and bundling offered by Netlify. At last, everything actually, truly worked.

Conclusion

As upgrades go, this was honestly pretty straightforward. I started working on it late Friday night, and was able to finish Saturday morning. No major rewrites were required, just some updated syntax and moving some CSS around. And best of all, Astro is now powered by Vite, so I can start trying out the plugins I'm more familiar with on my site (rather than looking deeper into the Snowpack ecosystem).

If you're looking to migrate your own site, I strongly encourage checking out the Migration Guide, and the blog post explaining the Astro team's reasoning for making the shift from Snowpack to Astro.

If you haven't tried Astro out yet, I wrote about my experience migrating from Nuxt static site to Astro, and the performance benefits I immediately saw by migrating. I definitely recommend checking out Astro if you're interested in static site generation.

Until next time!

From Nuxt to Astro - Rebuilding with Astro

Lindsay Wardell — Sun, 10 Oct 2021 03:45:21 +0000

I don't remember exactly when I started hearing about Astro, one of the latest static site generators to help tackle the problem of building sites with less Javascript. The problem is one we're all familiar with - how can I build a static site (in my case, my personal site) using the languages and tools I know best, while performing at its best? After migrating from Wordpress, I first tried Gatsby, then Gridsome, and most recently Nuxt. All of these are excellent tools, and I highly recommend them. But one thing that is the same across all of them is that they are tied to their specific framework (React or Vue).

Astro does away with that, and it's one of the things that really drew me to the framework. From their site:

It’s time to accept that the framework wars won’t have a winner — that’s why Astro lets you use any framework you want (or none at all). And if most sites only have islands of interactivity, shouldn’t our tools optimize for that? We’re not the first to ask the question, but we might be the first with an answer for every framework.

This caught my interest. The idea of "framework wars" having a winner never made sense to me. None of these tools - React, Vue, Svelte, Angular - need to be the overall winner to make developers productive. Having a winner at all would mean that innovation is stalled, at best. The fact that Astro allows you to utilize whichever framework is most comfortable means that it can adjust to whatever change comes in the future, and focus more on what it does best: building static assets.

And so, as one does, I decided to rewrite my personal site from Nuxt to Astro.

Performance Woes

I should say, before going too much further, that I love Nuxt as a framework. I think it's an amazing tool, and I realize that, as I write this, we are days away from the release of Nuxt 3's public beta.

That said, I've been running a number of sites with Nuxt in static site mode, and each of them has some odd quirks that I've never been able to fully work out. One site, a single page in the truest sense with only a bit of reactivity, was constantly reporting Typescript errors in VS Code. This was because the VS Code plugins (either Vetur or Volar) did not recognize that Nuxt's asyncData method returned state to the Vue object. This is not Nuxt's fault, but it made things annoying.

A second site (which is purely static assets, almost no JS interaction in the browser) had an issue that when code was updated, any content fetched with Nuxt's Content module would be missing after the hot module reload finished. I found a workaround, and it's not a huge deal, but it's annoying.

My personal site uses data from multiple sources, including Github and a few podcasts RSS feeds. Using Nuxt, I was doing more data fetching on render than I wanted. This hadn't been an issue with either Gatsby or Gridsome, and I expect that if I had explored buildModules more closely I could have found a solution. As it was, some pages had to fetch content on the client, and when that content is split between multiple endpoints, it made things slow.

All of these sites, from the smallest to the largest, had one unifying issue: Lighthouse performance scores were never great. Below are my Lighthouse scores for this site before migrating from Nuxt:

This was done on my home page, on a fresh instance of Chrome with no plugins installed, in order to get the closest to a clean reading. The home page is loading a handful of images (language icons, my profile image), my latest blog post, and a few SVGs for social icons courtesy of Font Awesome. Data was also being fetched from Github's GraphQL API to get my profile's description, pinned repositories, and a few other details.

Here's the breakdown of the performance score:

Of these scores, the Largest Contentful Paint and Time to Interactive stood out to me the most. This is a mostly static page, with a number of links and one button (to toggle dark mode). Why was Nuxt taking so long to be interactive?

Looking at my Network requests, it looks to me like Nuxt is mostly fetching Javascript, and then spending its time executing it. I made a few notes to see what I was looking at. On a typical page load, I had:

37 unique requests
6.7MB of resources loaded (including images)
Load time: 2.5s

What could I do to cut down on all of this data fetching and Javascript execution?

Time for Less Javascript

This is where Astro caught my attention. On their home page, they say:

For a technology built on top of three different languages, the modern web seems to focus an awful lot on JavaScript. We don’t think it has to—and that’s certainly not a revolutionary concept.

We’ll eagerly jump at the chance to sing JavaScript’s praises, but HTML and CSS are pretty great too. There aren’t enough modern tools which reflect that, which is why we're building Astro.

Astro is a framework that is focused primarily on fetching your data from whichever source or sources you use, injecting it into an HTML template, and building static assets from it. While Astro is built on Javascript, it doesn't focus on sending Javascript to the client. Any functionality you want can still be brought in, whether that's vanilla JS, React, Vue, or something else.

This way of building a static site feels very comfortable and familiar to me. I started web development in HTML, CSS, and PHP, and avoided Javascript at all costs for many years (both before and after jQuery came onto the scene). Rendering HTML and CSS to the client is what I did, with some logic involved to perform simple tasks like displaying a list of elements or fetching data from a database. Using Astro, it's basically the same thing, just using Javascript instead of PHP.

Here's an example of my main blog page, which renders a list of blog posts. Astro uses a unique syntax that combines the look and feel of Markdown, JSX, and standard HTML. All build time Javascript is handled in a 'frontmatter'-like block at the top of the file, and the static template is built below that.

---
// Import components
import BaseLayout from '../layouts/BaseLayout.astro'
import BlogPostPreview from '../components/BlogPostPreview.astro';

// Fetch posts
const allPosts = Astro.fetchContent('./blog/*.md')
    .filter(post => 
        new Date(post.date) <= new Date()
    )
    .sort((a, b) => 
        new Date(b.date).valueOf() - new Date(a.date).valueOf()
    );

// Render to HTML
---
<BaseLayout>
  <div class="flex flex-col lg:flex-row flex-wrap">
    {allPosts.map(post => (
      <div class="w-full lg:w-1/2 xl:w-1/3 p-4">
        <BlogPostPreview item={post} />
      </div>
    ))}
  </div>
</BaseLayout>

This may look familiar to someone who has used React before, with just a few oddities (no key on the mapped JSX? Extra dashes between the head and the return?), but it's important to remember that the result of this is pure HTML. No Javascript will ever be parsed on the client from this snippet. These components are all written with Astro's unique syntax, but the same is true when using React, Vue, or anything else: only static HTML and CSS would result from rendering this page.

But what if you want to load some Javascript? What if you need some client side interaction?

Partial Hydration

Astro promotes the concept of Partial Hydration. From Astro's documentation:

Astro generates every website with zero client-side JavaScript, by default. Use any frontend UI component that you’d like (React, Svelte, Vue, etc.) and Astro will automatically render it to HTML at build-time and strip away all JavaScript. This keeps every site fast by default.

But sometimes, client-side JavaScript is required. This guide shows how interactive components work in Astro using a technique called partial hydration.

Most sites do not need to be fully controlled by Javascript. This concept of partial hydration leans into that. Using my personal site as an example, the only dynamic portion of the site is toggling dark mode. In the Nuxt version of the site, I was reliant on the Nuxt runtime to toggle light and dark mode. To be frank, that's overkill for a static site. I shouldn't have to render an entire SPA just to toggle dark mode, right?

On their page about partial hydration, the Astro docs reference Jason Miller's blog post on the idea of an Islands Architecture:

In an “islands” model, server rendering is not a bolt-on optimization aimed at improving SEO or UX. Instead, it is a fundamental part of how pages are delivered to the browser. The HTML returned in response to navigation contains a meaningful and immediately renderable representation of the content the user requested.

Rather than load an entire SPA to handle a small portion of functionality, Vue can target a much smaller section of the DOM, and render only the portion of the application that I need (in this case, a button and some JS to toggle dark mode). Vue supports this usage by default, but in the world of frameworks we tend to forget this. A number of recent episodes of Views on Vue have explored this concept, including using Vue without an SPA and building micro frontends. The Wikimedia Foundation also uses Vue this way, rendering client-side functionality on top of an existing PHP monolith (listen to my discussion with Eric Gardner to learn more).

When viewed in this way, performance is almost a byproduct of following best practices with Astro. For my personal site, I only needed a simple button to toggle dark mode. While I know this could be handled just as easily with vanilla JS, I wanted to try using Vue to build an island of functionality. Here's my Vue component:

<template>
  <button
    class="dark-mode-button"
    @click="toggleDarkMode"
  >
    {{ isDark ? "🌙" : "☀️" }}
  </button>
</template>

<script lang="ts">
export default {
  data() {
    return {
      isDark: localStorage.getItem("darkMode") === "true",
    };
  },
  methods: {
    toggleDarkMode() {
      this.isDark = !this.isDark;
    },
  },
  watch: {
    isDark() {
      localStorage.setItem("darkMode", this.isDark);
      const html = document.querySelector("html");

      if (this.isDark) {
        html.classList.add("dark");
      } else {
        html.classList.remove("dark");
      }
    },
  }
};
</script>

And here's an example of how I'm using the component:

---
// Import the Vue component into an Astro component
import DarkModeButton from '../components/DarkModeButton.vue'
---
<html lang="en">
  <body>
    ... <!-- the rest of my template -->
    <!-- Display the Vue component -->
    <DarkModeButton client:only />
  </body>
</html>

Here, I'm using Astro's client:only directive. This tells Astro that it should be hydrated on the client, so that the Javascript will be executed. In this case, because the component is accessing the window element, I want to make sure it doesn't get executed during buildtime. The best part is that, within the Astro component, it just asks like a normal component that can accept props.

Astro has a number of renderers, and at the recent Vue Contributor Days, Fred Schott said that first-class Vue support is very important to the Astro team, and that it comes out of the box when working with Astro. You do need to add the renderer to your Astro configuration, but that's all that is required to enable Vue components.

The Results

Rewriting my personal site took about a week. Most of my templating was migrated from Vue to Astro components (although, as noted above, this wasn't a requirement to make the switch), with a couple Vue components for interactivity. The migration itself went very smoothly, especially since Astro support PostCSS (and therefore Tailwind) via a plugin for Snowpack. The benefits of prefetching the data and generating static HTML were obvious very early on, and the ability to mix basic HTML and CSS with Vue components was very straightforward.

After I finished and deployed, I ran Lighthouse on the finished migration. Here are the results:

And here's the performance results:

Much better! Because everything is being loaded as HTML and CSS, rather than utilizing a JavaScript framework to render the page, everything is much faster.

Conclusion

Astro is a relatively new tool for building static sites, but it's already gaining a lot of traction. Astro recently won the Ecosystem Innovation Award as part of Jamstack Conf 2021. From the linked page:

This year’s ecosystem innovation award goes to Astro, an innovative Jamstack platform that lets you build faster websites with less client-side JavaScript. They make it possible for developers to build fully functional sites with any framework of their choice or none at all. Astro offers the best of both worlds when it comes to lightweight static sites generators like 11ty and bundle-heavy alternatives like Next and Svelte Kit.

I'm really excited to see where Astro goes in the future. One item on their roadmap is to include server-side rendering, which I'm very excited for personally. I look forward to seeing what else comes out of this very interesting project.

Feel free to look at the repository for this site to view the code, and compare it against the Nuxt equivalent (in the Git history). If you want to learn more about Astro, check out their site at astro.build.

Build a Static Comment System

Lindsay Wardell — Sun, 15 Nov 2020 14:50:12 +0000

From Wordpress to Jamstack

Back when I first started my own blog, I did what many still do today and deployed a Wordpress site. Honestly, Wordpress is great. If you're looking into setting up your own site, it's a fine option! The main problem I had with it, however, was relying on another service to host my posts, my images, everything. What if my hosting provider were to shut down? How could I migrate from their MySQL database to another easily? What would I do with all of my content?

This actually happened to me, when I needed to migrate from one provider to another. The solution - abandon everything, and start from scratch. A migration wasn't possible to my new host, so I copied everything into a text file and started over on the site.

Then I learned about Gatsby, and that I could have a static site where my blog posts are all stored in text files. That sounds like a win! I could control my posts, my site, my content, and host it anywhere. This sounded exactly like what I wanted to do. I looked at headless Wordpress, but decided I wanted full control of the site. I built out a first version of the site with Gatsby, deployed it to Netlify, and life was good.

Except...

What about comments?

Static Comments??

I've never had a super popular blog, but having a comment system felt important to build a complete blog. The options that are out there are... okay, but most of them didn't actually match what I was going for. I settled on Disqus, but the fact that I couldn't host it, plus the tie-in to another service meant that it felt antithetical to hosting a static site.

After doing some research, I found Staticman. Quoting from their homepage, "Staticman handles user-generated content for you and transforms it into data files that sit in your GitHub repository, along with the rest of your content." This concept spoke to me. I did some research into using this approach, but at the time, it looked like the service had grown too fast, and comments were processing too slowly, if at all. Hopefully they've fixed it by now, but again, it's another service to rely on.

All of this research, however, led me to a decision. I'm a developer; I can build this myself!

Jamstack to the Rescue!

My goals for this project:

Accept input from a user
Process that into a text file
Commit that text file into a Github repository.

I'm already hosted on Netlify, so accepting user input is straightforward. Netlify offers form submission (read more here). In short, by adding some basic attributes to a form, you can enable a POST request to your site that Netlify will capture and process. I'm using Vue, so I turned to Vue Formulate to build the form, and Vuetensils for an alert on success/failure. Unfortunately this doesn't work nicely with Netlify, so I had to add the form in a standard way in order for Netlify to pick it up and build the POST endpoint. A simple compromise.

Below is the code for Netlify to pick up the form. Feel free to just use a basic form element if you want, I decided to go with Vue Formulate for the added validation and submission features.

<form
  data-netlify="true"
  data-netlify-honeypot="bot-field"
  name="new-comment"
  class="hidden"
>
  <input type="hidden" name="form-name" />
  <input type="hidden" name="postTitle" />
  <input type="hidden" name="postPath" />
  <input type="hidden" name="author" />
  <input type="hidden" name="email" />
  <input type="hidden" name="message" />
</form>

Great, I've got my form, and it's submitting to Netlify. But how can I access that data to submit to Github?

Luckily, Netlify has another great feature: Serverless Functions! In short, they allow you to create AWS Lambda functions that they will host, and you don't need to create an AWS account to do anything.

Here's a basic example:

exports.handler = async ( event , context ) => { 
  return { 
    statusCode: 200, 
    body: "Success!" 
  }; 
}

In addition to writing arbitrary serverless functions, Netlify provides a number of hooks to catch events that would go to their APIs, such as Identity or Forms. You can read more about them here. In this case, we want to create a function called submission-created.js, which will receive an object called payload in the event body. This payload will contain all of our form information. We can then use that to generate a markdown file for the comment.

const axios = require('axios')
const uuid = require('uuid').v4
const dayjs = require('dayjs')
const crypto = require('crypto')
const utc = require('dayjs/plugin/utc')

dayjs.extend(utc)

exports.handler = (event, context, callback) => {
  const payload = JSON.parse(event.body).payload
  const { postTitle, postPath, author, email, message } = payload.data

  const filePath = `content/comments/${uuid()}.md`
  const content = `---
postPath: "${postPath}"
date: ${dayjs().utc().format('YYYY-MM-DD HH:mm:ss')}
author: "${author}"
authorId: "${crypto.createHash('md5').update(email).digest('hex')}"
---
${message}`
}

As a quick aside - you can always just use a generic serverless function for this step. I went with Netlify Forms and handling the event because Netlify by default applies spam filtering to the form input. You can also add a bot field (see the above HTML snippet where it says data-netlify-honeypot) to get additional checks on form submission. Rather than build in a call to something like Akismet, or import my own spam filter, I felt this was the simplest way forward. It felt a bit like a compromise on my 'I own everything' take, but if I have to move platforms I can rebuild it fairly easily.

All right, we now have our form hooked up and a serverless function to capture the data. Where do we save this? Well, anywhere we want, really! In my case, I wanted to store this data in Github. For this use case, Github offers a RESTful API where a developer can interact with a given repository. In this case, it allows me to commit a new file into a branch of my blog.

For this example, I will use Axios, but feel free to use isomorphic-fetch or your preferred fetch library.

  const url =
    'https://api.github.com/repos/lindsaykwardell/lindsaykwardell/contents/' +
    filePath

  axios
    .put(
      url,
      {
        message: `New comment on ${postTitle}`,
        branch: 'new-comments',
        author: {
          name: 'Lindsay Wardell',
          email: process.env.COMMIT_EMAIL,
        },
        committer: {
          name: 'Lindsay Wardell',
          email: process.env.COMMIT_EMAIL,
        },
        content: Buffer.from(content).toString('base64'),
      },
      {
        headers: {
          Authorization: `token ${process.env.GITHUB_API_TOKEN}`,
        },
      }
    )
    .then((res) =>
      callback(null, {
        statusCode: 200,
        body: JSON.stringify({ msg: 'Your comment has been submitted!' }),
      })
    )
    .catch((err) =>
      callback(null, {
        statusCode: 500,
        body: JSON.stringify({ msg: 'An error occurred!', err }),
      })
    )

Now, any form submission from our site will go to Netlify, pass to this function, and get committed to our Github repository. For my case, I created a separate branch for new comments, just in case any spam filtering still needs to be done.

Conclusion

Congratulations! You now have complete control over your comments on a static site. This should work with any static site generator. My goal was to have complete control over the contents of my site, so I can take it with me wherever I want. While I do feel a bit tied into Netlify, I feel that it's a worthy compromise, considering all of the data is mine at the end of the day.

Here's a link to my site's Github repository in case you want to look at the full source code.

Stay safe!

Introduction to http_wrapper for Deno

Lindsay Wardell — Tue, 26 May 2020 00:00:00 +0000

I'm a big fan of Deno, the new Javascript runtime by the creator of Node. I love that it is built with Typescript in mind, reducing the amount of configuration required to get work done. I like that packages (or modules, as they are referred to) can be imported via URL, and don't require a package manager. I also love how fast it is to start a Deno project for development.

For the uninitiated:

Deno is a simple, modern and secure runtime for JavaScript and TypeScript that uses V8 and is built in Rust.

Secure by default. No file, network, or environment access, unless explicitly enabled.

Supports TypeScript out of the box.

Ships only a single executable file.

Has built-in utilities like a dependency inspector (deno info) and a code formatter (deno fmt).

Has a set of reviewed (audited) standard modules that are guaranteed to work with Deno: deno.land/std

As a web developer, my first question was, "Okay, how do I start an HTTP server?"

It turns out, the built-in methods to handle this aren't too difficult to figure out:

import { serve } from "https://deno.land/std@0.53.0/http/server.ts";

const s = serve({ port: 8000 });

for await (const req of s) {
  req.respond({ body: "Hello World\n" });
}

Want to respond differently for different endpoints? No big deal!


import { listenAndServe } from "https://deno.land/std@0.53.0/http/server.ts";

const s = listenAndServe({ port: 8000 }, (req: ServerRequest) => {
  if (req.url === "/example") {
    req.respond({ body: "You found the example endpoint!" })
  } else {
    req.respond({
      status: 404
    })
  }
});

Pretty straightforward. However, this method of writing an API could get pretty verbose: multiple if-statements, no simple solution to break out different endpoints into their own scope or module, and no clear way to scale your application as your routes grow. A large application could become unwieldy pretty fast using this format to write your API.

There are already a lot of libraries out there for managing routes (Oak and Drash come to mind). From what I can tell, though, these libraries wrap the default ServerRequest object in their own formats, making them incompatible with other built-in methods (like web sockets). I really love how simple it is to get started, there must be a way to just wrap the default listenAndServe and ServerRequest objects in a router-based solution.

And so I wrote http_wrapper, a simple wrapper around the above code. Let's implement the above example using http_wrapper:

import { Server, Router } from "https://deno.land/x/http_wrapper@v0.3.0/mod.ts";

const app = new Server();

const router = new Router();

router.get("/example", (req: ServerRequest) => {
  req.respond({ body: "You found the example endpoint!" });
});

app.use(router.routes);

app.start({ port: 8000 });

Save the above in a file (say index.ts), and run it as follows:

deno run --allow-net --allow-read index.ts

Note: Deno has a secure runtime, so whenever you want to reach out of its sandbox you need to explicitly allow it to.

http_wrapper adds two new classes:

Server

The Server class handles calling listenAndServe(), and correctly determining which endpoint was called. When the server is started (with app.start()), internally the class calls listenAndServe() and begins checking each request against its list of routes and endpoints. The config object that is passed into app.start() is Deno.ListenOptions, the same as for listenAndServe().

Router

Router is where the fun begins. This class is meant to handle all of your API needs. It takes a constructor of a string, which is the base route for that router:

// Creating the /example route
const router = new Router("/example");

Endpoints can then be added to routes for different HTTP methods:

GET
POST
PUT
DELETE
OPTIONS
PATCH
HEAD

const router = new Router("/example");

// Add a GET request
router.get("/", req => {
  req.response({body: "You found me!" });
})

// Add a POST request
router.post("/", req => {
  req.response({
    status: 204,
    headers: new Headers({
      'content-type': 'application/json'
    }),
    body: JSON.stringify({
      msg: "Saved!"
    })
  });
});

export const router;

Note: Currently, there is no support for path parameters

Putting it together

Once you have defined your routes, you can bring them into the Server by using app.use(). Also, if you have static files you would like to deploy with your app, you can define the static file folder and endpoint with app.static().

import { route1 } from "./Router1.ts";

const app = new Server();

app.use(route1.routes); // Router.routes is a getter, so no function calls are required
app.static("static", "/");

app.start({ port: 8000 });

Congratulations, you are now hosting an app with two endpoints:

http://localhost:8000/example (various string/JSON responses)
http://localhost:8000/ (static files)

The best part? For development, it takes about a second to start up!

deno run --allow-net --allow-read index.ts

You can check out http_wrapper here: Deno.land. The project is MIT licensed, so feel free to use it and report any issues you find.

Next time, I'll talk about how to incorporate http_wrapper with a Vue 3 SPA to create a chat room, while keeping the ~1 second startup for development.

Take care!

When I Grow Up...

Lindsay Wardell — Mon, 18 May 2020 00:00:00 +0000

"What do you want to be when you grow up?"

This age-old question, asked of children before they can know what 'grow up' even means exactly, often results in answers both cute and curious. Some of the answers I remember giving include:

Astronaut
Mathematician (due to a TV show we watched in 1st grade)
Teacher
Office Max employee (well, I got to do that one!)
Author

One theme popped out from an early age, though: whatever I was going to do, it was going to revolve around computers.

Software development has always been something I was interested in. I remember being awed by an early version of Excel at a science fair, and how you could program it to do whatever you wanted. A friend and I explored making fan games with GUI game designers like The Games Factory or Multimedia Fusion. We spent countless hours trying to put together fan games for Sonic the Hedgehog and other characters, or trying to make our own. I went to Cybercamps, a computer camp which offered weeklong courses on game development, programming, graphic design (Photoshop), and web design.

In 2002, we realized that we could look at the source code for a website, change it, save it, and open it in our browsers. It wasn't long after that that I got some books on HTML4 and CSS2, and started writing my own code. We made websites hosted on Freewebs, and I was able to use the HTML sections they offered to do some things myself.

From there, I started setting up websites for gaming clans I was a part of. I would download an HTML template, put it on the server my family rented, and bam! Website for the clan. It felt great. At the time, I wrote for a school assignment, "What I want for a career is to be a website designer."

In 2005, my friend started a new fan game based on Shadow the Hedgehog. As a "company" making the game, he came up with the title, "Blackarms Studios" (a reference to the race of aliens in the Shadow the Hedgehog game, the Black Arms). And so, I made a website. We hosted it on Yagaboosh.com, which was derived from a random word/sound that I made as a child one day. We set up a community forum using ProBoards, and others from the fan game community made their way in. Later, my friend shifted to focus on making videos for YouTube. At one point, our channel was regularly reaching YouTube's top 100. Bear in mind, this was back in the day when YouTube videos couldn't be longer than 10 minutes.

Other members of the community wanted websites, so I started working with them to create and host something based on the template I had made for BAS. I then billed myself as running "The Yagaboosh Network" (everything was a URL based off of my original website, Yagaboosh.com) It was a blast. I dove straight into using CSS for styling the website, while ensuring the structure functioned without a stylesheet. I used CSS hover effects to generate dropdown menus. I avoided Javascript at the time, because it seemed intimidating and there were general concerns about compatibility across browsers.

Sadly, I don't have the original sites any more, but the Wayback Machine managed to archive some of my efforts. Looks like a large portion of the styling was misssed, though.

The community was amazing. It was probably my favorite part of the site. But I was never happy was using ProBoards, because it didn't integrate with the main site and I couldn't style it nearly as well. So in 2007, we migrated from ProBoards to a self-hosted solution with PHPBB. Over the following months, I tweaked the PHPBB theme to treat the global announcements as a blog, and finally my dream of merging the two was complete. This was my first real experience with "back-end web development" - I was writing my own PHP code, as well as the special PHPBB syntax, in order to make my own product.

The community slowly faded away, as things do. Our peak was in 2008, according to the stat counter I placed on the site (still accessible, thanks again to the Wayback Machine). Considering we were a small community site, I'm fairly proud of these numbers.

Activity on the site dropped off after 2009. The YouTube channel had been repeatedly banned for violating DMCA regulations (this was before video game companies realized that fan content was a good thing). Part of this decline was because of my focus on the web technologies, rather than supporting the community, but also because we had been around for 4-5 years. The old members moved on, while no new members were joining.

We kept talking about what to do for the website until 2011, when I left for Brazil for two years as a missionary. During the mission, I was appointed financial secretary, which meant I worked from 10 to 5 in the mission office. Within my first month, my web development came up in conversation, and I gave an example of how easy it was to get started making a website. I kept playing with it when I had a spare moment, and was able to arrange a public release of the website.

The site was written as a custom CMS, because I didn't have access to tool like Wordpress or PHPBB. It was my first attempt at a PHP application. The banner at the top was randomly selected from between 5 options. A blog was included to display the mission's monthly message. Other features included fading between images using Javascript (I believe I used jQuery) and a scroll on the left with "Scriptures of Power". The scroll in the screenshot below is sadly broken, but it involved some complicated PHP code that allowed the scroll to animate downward to display all of the text. This was complicated because to achieve the animation, I was counting the number of characters in the quote, and then generating the CSS within PHP.

Thanks again to the Wayback Machine for the archived version of the site.

It was my first custom project, and I was very excited about it. But as with many side projects, I was unsatisfied with some of the initial decisions I had made. These constraints made it difficult to expand on the site, and I felt there had to be a better way. So I started over, updating the site as needed while I worked in the office, but truly focusing on the new project - Yagaboosh.

Yagaboosh was going to be a completely flexible CMS, built around a plugin system. Everything was going to be plugins, including the blog functionality, so that features could be updated separately or ignored if not wanted. This concept had formed in my head from the years of working on Wordpress and PHPBB - wouldn't it be great if I could just pick and choose which tools I used, and put them together in a cohesive way?

I feel like the project had a lot of potential, but eventually I was transferred away from the office. I took the source code with me, but when I got home in October 2013 I didn't feel like working on it all that much. I did some minor adjustments in 2014, but then I got married, and life priorities had to be shifted around. I later did some further updates, mostly to the theme (I switched to using Bootstrap instead of a custom theme), and pushed it to deployment.

Between 2014 and 2017, I didn't do much in the way of programming. I worked as a tech specialist at Office Depot while studying for my Associate's Degree without really knowing what I wanted to do. In 2015, our daughter was born, I started working on my Bachelor's degree, and I switched jobs to be an IT Manager at Lindsey Forwarders.

Most of my time there was working there was spent on day-to-day operations, and for a time I filled the role of Operations Manager rather than focusing on IT. But I did get to deploy a PHP-based time tracking system, and did some work on an existing internal application made using Magic from around 1995. I also got to make an Excel spreadsheet for tracking rates.

In 2017, the business was sold to a son-in-law, and I began to prepare to leave the company. A friend recommended attending the Tech Academy, a programming boot camp in Portland, OR. I made an arrangement to work part time while attending the boot camp, and in return I would start developing a new application to replace the existing one from 1995. I attended the Tech Academy from November 2017 to February 2018, learning the more professional side of development I had never had due to my self-taught method up until then.

At the Tech Academy, I learned about Git, Javascript/jQuery, and how to build server-side applications that weren't just based on PHP scripts - specifically, ASP.NET and C# MVC. I also got to experiment with Knockout.js, and saw the power of a single-page application. These methods and technologies would prove essential to my career.

For the rest of 2018, I switched between helping the new owner adjust to the company he had bought and working on new development projects. The two main projects were a new Wordpress site for the company, and the Online Portal that was intended to replace the old desktop app. The Wordpress site used an existing theme, but I was able to use my skills from the Tech Academy and past experience to style it how I wanted. I also got to make a new logo for the company, using Photoshop.

The Online Portal was much more exciting. I started a prototype in 2017 while still attending the Tech Academy. The prototype was built using PHP and jQuery, and applied as close to MVC functionality as I could manage. There were dynamic Javascript imports depending on the page, REST endpoints for performing actions, and dynamic page rerenders as tasks were done. But as with the mission blog, it wasn't scalable. On top of that, there was a severe performance hit when querying the database via PHP that I couldn't figure out. Looking back, I think I was using an older version of PHP which caused it, but I'm still not certain.

After I completed the Tech Academy, I started trying to learn React, but was quickly overwhelmed by the number of new concepts I was trying to wrap my head around. Instead of continuing with React, I switched to Vue, and found a Javascript framework that was much more comfortable to get started with. I also started learning Node.js, and I realized how powerful it was to use one language for the entire application. The shift between PHP and Javascript during the prototyping phase had been annoying, especially since both are dynamic languages.

In May/June 2018, I built a new prototype using Vue and Node.js. I just replicated one page, the one where the database query was too slow. The result - a 4x performance increase, at minimum; often it was even more than that. I made the case to my boss to allow the shift from PHP/jQuery to Node/Vue, and he agreed. By this point, we had been in a closed pilot with a few customers, so we made the decision to support the old version while working on the new one. It was only a short time later that we were ready to switch. I was very impressed with the speed of development on the Vue/Node application compared to PHP/jQuery.

I continued working on the new application through the year, and into the start of 2019. However, in February 2019, I was contacted by a recruiter to see if I was interested in a position with Daimler Trucks North America, building a new project using Vue and Node. The interview was great, and they offered me the job. I immediately accepted. I started at DTNA in March, 2019.

Working in a large corporation as a developer was a major shift from anything I had done before. I worked under my project manager (the same with whom I interviewed), along with a BSA assigned to my project. My contact information was intentionally kept from the app owner, so that all communication was routed through the BSA. We had regular meeting with architecture and CI/CD teams. I had to coordinate between other teams to call APIs needed to make our application work. All things I had either done myself, or had documentation to follow.

I worked on that first project from March to June, 2019. It was an internal tool, so it wouldn't have a large user base. Also, once I had the position, I learned that I would need to write the application using Java, not Node. I had never written a single line of Java. I asked for the time to learn sufficient to write the application, which I received, and was able to complete the project a month ahead of time.

This turned out to be a good thing, because I was transferred to a new project where a developer was being transferred. This project was no small internal app - I'm actually not going to talk about it much because I'm not sure what I can say officially. I will say that, in many ways, it is the culmination of everything I have learned up until this point - database design, application development, working with teams, using version control and branches, and more. When the application goes live, and is used by its intended audience, it will be my code, along with that of my fellow developers, that is making magic happen.

There is more to the story - side projects, frustration, growing pains, and more. The path I have taken to get here was never straightforward. But in the end, I am doing what I love.

In 2002, I dreamed of being a website designer. Today, I know that I made that happen.

So now, I'll ask you:

"What do you want to be when you grow up?"

Forem: Lindsay Wardell

Integrating Mastodon with Astro

Integrating to the Fediverse

Bringing the Fediverse Home

Conclusion

Utilizing Native Dialog in Elm

What is <dialog>?

The open Attribute

Implementing <dialog> in Elm

Rendering the dialog

Triggering the dialog

Conclusion

Shipping Side Projects

The Purpose of Side Projects

You Are the Stakeholder

Scoping Side Projects

Learning Projects

Maintained Projects

Slow Cooker Projects

Conclusion

Utilizing Elm in a Web Worker

Writing our Elm Modules

Scaffold index.html

Adding the Web Worker

Sending a message

Web Workers in Vite

Conclusion

Coming Into Vue: What's Next in Vue 3

Reactivity Transform

Nuxt 3

Vuetify

Ecosystem Support and Stability

Conclusion

Setting up an Elm project in 2022

Elm (the language)

elm repl

elm init

elm reactor

elm install

elm make

Editor

Code Formatting

Linting

Testing

Development Environment

elm-live

Webpack/Rollup/etc

elm-tooling

Frameworks and Templates

elm-spa

elm-pages

ElmBook

vite-elm-template

Conclusion

Astro 0.21 - Upgrade Experience

Update Dependencies

Missing Body

Missing Styles

Bad CSS!

Success?

Conclusion

From Nuxt to Astro - Rebuilding with Astro

Performance Woes

Time for Less Javascript

Partial Hydration

The Results

Conclusion

Build a Static Comment System

From Wordpress to Jamstack

Static Comments??

Jamstack to the Rescue!

Conclusion

Introduction to http_wrapper for Deno

Server

Router

Putting it together

When I Grow Up...

What is `<dialog>`?

The `open` Attribute

Implementing `<dialog>` in Elm

`elm repl`

`elm init`

`elm reactor`

`elm install`

`elm make`

`elm-tooling`

`vite-elm-template`