Lindsay Wardell

An Hour Before Showtime

Thu, 26 Feb 2026 00:00:00 GMT

"I think we should start looking for other people."

It was around 9 AM on Tuesday, May 24th, 2022. The internet was still out at home, despite my best efforts to resolve the problem. I had called CenturyLink, but the earliest a technician could come out was that Friday. I had finished making breakfast, and was busy getting myself out the door, not something I had typically done in the morning since the start of the pandemic. In just under an hour, I would be going live to give a talk at the Vue Global Summit. It was my second year participating, after being introduced to the folks at Geekle by Tracy Lee of This Dot Labs the year prior.

I heard my spouse at the time say it, felt my body stutter at the impact of the words. It wasn't so much as shock as realization. Things hadn't been good for awhile, and no matter what I did she was always angry or disappointed or just resentful of me. I wasn't brave enough to call it abuse, but I had spoken to a couple friends about how wrong things had felt, how to know when divorce was the right thing, how scared I was about life falling apart around me again. Four years prior, when I had shed both the religion and gender I had grown up being told were true, I had been left with few pillars on which to rebuild anything. Tearing down another one, even when it was due, left me terrified.

At the time, I nodded, understanding. This wasn't the first time the topic had come up, but it had always been deferred, a future thing, in case my transition made her too uncomfortable. It had no bearing on me, since our relationship had already ended by most metrics. Now, though, it was real, it was happening, but I didn't have time for that. Didn't have time to parse that life as I had known it was over.

I couldn't pause, because I had less than an hour until showtime.

I got in the car, heart pounding, the words repeating in my head. I pulled up to a friend's house, settled my laptop on the desk, and got ready. My heart refused to slow, panic and dread and the more general nervous energy before stepping out on virtual stage. I reviewed my notes as the previous talk ended, and then it was my turn.

I couldn't tell you what I talked about. I had two sessions that conference, one of them about functional programming, but I think that one was another day. I smiled, I joked, I answered questions, and then the camera went off. Quietly, heart hammering, I packed up my laptop, and went downstairs to the kitchen.

My friend was there; she asked if I was okay. I must have been showing more emotion than I realized. Tears flowed, and I couldn't hold them back any longer.

I now look back on that day and see someone who hurt me, again and again, as I did everything I could to sustain a broken relationship. I hear the words she spoke over the years, threatening and abusive.

I am grateful that time is passed. I regret that I walked into it at all.

Now, I'm free from that world. That chapter of my life is over, and I am all the happier for it. I have an amazing, wonderful partner who loves me for who I am. We go on adventures together, hiking and exploring the world around us. We are both writers and artists, and I love sharing what we make with each other, or just reading and snuggling together. I love peaceful days, and restful nights, and knowing that at long last, I am home.

Keep Learning

Fri, 13 Feb 2026 00:00:00 GMT

I have a long-running interest in taking technology that is either old, or underpowered, and pushing it as far as I can. I have fond memories of my EeePC 701 from the mid-2000's, with it's 4GB of storage, and trying to figure out how to make it do something useful (I think I got Skype working on it). A later edition, the EeePC 1000HA, came with a bit more power, but running Windows XP in 2008. I managed to get that running a version of Photoshop, which could take ten minutes to save a PSD, but it worked, and at the time that was all that mattered.

More recently, I've been slowly nursing a 2013 Macbook Air to life. Its battery is failing, it only has 128GB of storage, but running Ubuntu 24.04 has been pretty smooth. I've turned it into my personal, non-tech laptop, mainly for writing and browsing the internet. I do have Zed installed, along with the latest LTS version of Node, so that I can make adjustments to my personal site, but it's never going to be where I do my main tech work (that still falls to my trusty M1 Macbook Air).

Yesterday, I had my first Linux kernal panic. I'm kind of amazed that Linux hasn't previously thrown that curveball at me, but when the purple screen popped up I thought that maybe the hardware had been fried due to the battery going out. It really doesn't like to be put in sleep mode, and in a hurry I had closed it without turning it off, so it was a reasonable theory in my head.

Being that we're in 2026, and AI has been adopted across the tech ecosystem, I had two options: use AI to try and solve my problem, or do it the old fashioned way and hit up a search engine. And since I am of an age where search engines were cool, I opted for the second option, and found this blog post by Imad Saddik that matched exactly the issue that I was having, and was a pretty cool website on top of that!

I followed the instructions and was able to quickly resolve the issue, uninstalling the kernal version at fault. Success! And as a bonus, I have now experienced one more semi-common issue with Linux, and feel more confident in fixing it in the future.

As I mentioned in a previous blog post, I said that I've been doing some experimentation with AI just to have an idea of what's going on. I've given it tasks both simple and complex, and one thing I can tell you from my experience is that whatever command or directions it offers, it doesn't stick in my brain. When I'm using AI in this way, I am getting something done, but I'm not learning, not growing as an IT professional or software engineer. This is not an unknown experience, and is in fact what I was talking about in that last post I wrote. When we turn over the wheel to AI, we don't just stop thinking, we stop learning.

Tech companies, of course, want you to feel that AI is helpful for your learning or work, and are trying to find ways to make it more helpful, such as note takers, learning tutors, or coding assistants. And of course, they can provide value, and they do give you results. The question is not always, "does this thing do what it says it does," although that is a very important question for any AI-focused app. The question should be, "what tradeoffs am I making by using this tool instead of another method?"

As an example, we don't say that you should only use paper and pen to write, and that computers are the bane of written existence. But we do say that typically, handwritten notes or journals have a better chance of sticking in your brain than something you type. That's a tradeoff: do I want to write fast, or do I want to remember what I wrote?

This same tradeoff is something that needs to be considered when deciding whether to reach for AI or not. If you're going to reach for AI, you are passing up learning opportunities, moments of struggle, and breakthroughs. You're disregarding the muscle memory that comes with doing those mundane, repetitive tasks, or the years of experience that when put together make you exceptional at your job.

Again, I'm not telling you how to do your job. I am not a purist on this topic by any means. But I would rather make a mistake and learn from it than have a computer ensure I never make another mistake again, because to me, learning and growing is what makes life have meaning.

Keep trying. Keep struggling, failing, picking yourself up again.

Keep learning.

ParentShield: A Mindful Communication App

Thu, 12 Feb 2026 00:00:00 GMT

Don't Replace Yourself With AI

Mon, 09 Feb 2026 00:00:00 GMT

Artificial intelligence, as we regrettably know, is everywhere. I see articles praising it for its speed and efficiency at getting work done, but I also see article after article talking about how AI is doing more harm than good, if it is doing any good at all.

I'm not going to try to convince you one way or the other, in part because I regularly feel torn about it. As a technology, it doesn't interest me a lot, because I feel like it's just another step down the machine learning path that we were already on. I don't like that the tech industry has decided to make this the de facto future of computing. I have used it, in large part so that I know what's going on, but I also now have an entire computer dedicated to having zero AI tools on it. I'm building a social photography app that is dedicated to being free of AI tools and respecting its users, but I've also been working on a tool that uses a local AI model to filter abusive texts from people I'm legally unable to cut out of my life.

In short, AI is potentially helpful, but always harmful to creativity and expression. We should not be relying on it, and yet we are. And it is to this point that I am writing.

Abdicating thought

AI has been pitched as a way to get things done faster. It can write for you, teach you, code for you, be a helpful assistant for you. At work, it can do all of the things you don't want to do, like writing boilerplate code, or managing tests, or even write entire features for you, all with a press of a button and without any human supervision.

On the surface, that's pretty cool! But here's what I have seen: AI can write the code (some of it decent), it can do the tasks, but despite advertising to the contrary, it cannot think. It doesn't know why you're writing the code or email, it doesn't understand what the end user actually needs. All it knows is patterns, which we as humans see as intelligence. Humans are really good at pattern matching, so when a computer is good at it too, we think it's amazing. Which, fair, a computer knowing what I want without having to type in a shell command is really nice, but it's not intelligent. It's smart in the same way a smart home is smart, by doing things that look like a human is doing them.

But in all of this, the computer has no better understanding of what's going on than before. If we rely on AI to do our critical thinking for us, then we are abdicating our responsibility to our employers, our customers and ourselves. Submitting or responding to a PR request, providing a design decision, or any other use of AI to replace your individual opinion, viewpoint, and voice is doing just that, stating through actions that a computer is more capable than you are.

In your own words

It's tempting to let AI take care of all of our work. Shows like Star Trek show a future with powerful computers, capable of even generating physical objects, including food and tools. It's kind of amazing to just let the computer do your job for you, so that you can live you best utopian life. However, even in Star Trek, the characters we root for are always the ones calling the shots.

We don't cheer for Geordie because he came up with the correct prompt to make the computer AI fix the warp core, or Picard for getting the computer to come up with negotiation techniques. We care about these people because Geordie has earned his position in engineering, because we know Picard is going to make the best choices for his crew and those around him. These are people, using their personalities, identities, and skills to make a difference in the universe around them.

Especially in the current environment, where everyone has access to AI tools, using your own voice and opinions is the only way to stand out. There characters we love from Star Trek are depicted as having full, rewarding lives, with hobbies, interests, friendships, relationships. They live, they feel, they are alive, and they bring all of themselves to the things they do. And we should too.

Use your words, give your opinions, share your insights. Don't let the AI speak for you. Even if you're just doing your job, your voice matters. You matter. Don't give up on that because it's easier to let a computer do your job.

Moments and Moonlight

Thu, 05 Feb 2026 00:00:00 GMT

I often feel like I don't have much to write about, much less something to write about that others will find interesting. I'm hoping to break that pattern this year, but it's something that has stopped me from joining in conversations online (such as on Bluesky) on more than one occasion. I'm just someone online, after all; why would anyone read what I have to say?

The same is true of other creative activities, too. I've got a handful of other projects that I haven't talked about or shared, or if I have only vaguely. I'd wager it's a fear of rejection, or something to that effect. If I do it for myself, I can appreciate it, and I don't have to worry about what anyone else is saying or thinking about it. The only problem is, it's fun to share things that you create, or find, or just like. Because someone else might enjoy it too.

A couple nights ago, I stepped outside to take some garbage out, and I happened to look up and see a beautiful sky of stars and a nearly full moon right above my house. As many people do, I'm sure, I've tried taking pictures of the moon with my phone, but it never works. I have a Canon 60D that's been sitting around collecting dust, but I almost always forget its there for one reason or another (mostly because it's bulky and doesn't fit in my pocket like a phone would). But this time, for whatever reason, I decided to charge up the battery earlier that day.

I run into the house, grab the battery, plug it in, and turn on the camera. Nothing happens. After fumbling with it, I realize there's no SD card in it, and grab the first one I can find (from a Raspberry Pi that is also collecting dust on a shelf). I plug it in, and the camera turns on. I rush back outside and try to take some shots of the moon through the clouds. After nine photos, I get an "out of memory" error. Of course! I had just used a card that was previously running an operating system, it makes sense that it's practically full.

Rushing back inside, I grab my Macbook Air to empty the card, but of course it doesn't have an SD card reader because it's from 2020 and Apple has courage. I pick up my writing computer, which is a 2013 Macbook Air (running Ubuntu), take off the pictures, and reformat the card. Now free to photograph whatever I want, I run back outside and grab a few more shots, although the clouds had meandered off.

After a bit more photography, my wife comes outside to join me, and we just stand there in the driveway, enjoying the stars above us, naming the ones that we know, feeling connected to the universe around us.

The universe may never know we're there, but we can still enjoy its beauty in the quiet moments, watching starlight that has taken years to reach us. It doesn't matter that they're small, or numerous, or sometimes hard to see. They're beautiful, and it's worth slowing down to enjoy them, take them in, and feel connected to something bigger than our world.

Rekindling

Mon, 12 Jan 2026 00:00:00 GMT

It's been awhile since I just wrote a blog post, and a lot has happened. My last actual blog post was a review of 2022, which was probably the worst year of my life. Since then, I've gotten married, I have a new job that I love, and have discovered that I was probably hyperfixating a bit too much on tech.

I've always been into technology (I've previously written about it), but it was in early 2018 when I made the hard pivot from IT manager/administrator into software development. Coincidentally, this was the same time that I left the church I grew up attending and came out as transgender. I did a speed run of frontend best practices for my first project, going from jQuery to vanilla JS to Vue in the span of a few weeks. The backend did a similar run from PHP and MySQL to NodeJS and Postgres.

In that first year, I graduated from The Tech Academy, switched my bachelor's program, and wrote a new web-based application to replace my company's previous solution from 1995. I dove into every podcast I could find, read as much as I could, and explored almost all the common frontend frameworks (sorry Angular). I even built a real-time LAN-based board game, just to see if I could.

Looking at it from today's perspective, I was using code to avoid (or replace) feelings that I was having as two of the central pillars of my identity crashed to dust around me, and I didn't stop until, well, 2023. That was the year I started my tech podcast, Human Side of Dev, and tried to keep a weekly cadence of editing recordings. I started the podcast while living in a basement too small for my height, trying to figure out what I was supposed to do next.

But then, by luck, happenstance, or the aligning of stars, I met the person I would marry. And while I was still scraping the bottom of my emotional barrel, and filling the holes with Javascript-shaped duct tape, I also learned that I was someone worth loving, and not just because I'd written a cool technical article on Astro or interviewed really cool people.

It's still hard, even now, to really feel comfortable talking about the things I enjoy beyond tech. I felt panicked just writing my new description on the about page. But I'm going to start doing it anyway, because I don't need to define myself by my job, or my tech stack, or what the latest discussions are among framework authors.

For 2026, I'm rekindling my website as a place for creativity and joy. I think it's going to be a very fun year.

No Words

Sun, 02 Feb 2025 00:00:00 GMT

I have no words.

I see reports of immigrants taken
from homes, from jobs, from hospital,
and I have no words.

I read orders erasing my identity,
wiping my rights away one by one,
and I have no words.

I watch headlines of raised tarriffs,
fired officials,
leaked personal information,
crashing planes,
and I have no words.

I hear the cries
of people fearing,
crying,
hurting,
dying,
and I have no words.

There are no words
for atrocities such as this.
They all fall flat,
too hollow,
too frail.

And so I watch, read, listen, and mourn,
wordless in the torrent,
hoping it passes swiftly,
fearing it may not pass at all.

I have no words
for the cruelty with which
we now live.

Grief Is Not A Casual Thing

Sat, 11 Jan 2025 00:00:00 GMT

Grief is not a casual thing.

It's not something you pick up as a hobby,
or go to watch at the movies.

It's not a snack, or a treat,
or a get-rich-quick scheme.

It's not a mural on a building
or a meme shared by a friend.

It's not even a poem
written in a moment of clarity.

No.

Grief is more than that.

Grief is a way of life,
a modality of viewing the world around you.

Grief is the ocean, filling the horizon
in all directions until you can't see the land.

Grief is the sky, filled with dazzling stars,
pinpricks of pain and sorrow on an empty canvas.

When approaching grief,
do not think yourself in control.
Allow the grief to come over you,
fill you,
pierce your soul
without backing down
or looking away.

Drink it in,
and feel
what
remains
in
its
wake.

Keep watching it, closely,
without guilt or shame,
as tears well
and the colors of the world
dim around you.

They won't dim forever.

But this is important.

A casual grief can bear much,

But a transformative grief,
that pain is powerful enough
to heal a life.

To the Past

Tue, 17 Sep 2024 00:00:00 GMT

To the past
that wove my history
before me,

That laid the stars
by which I sailed,

That planted the
thorns and brambles
I had to cross,

The past
and the wounds it left me,

Goodbye.

Divorce

Tue, 10 Sep 2024 00:00:00 GMT

I feared divorce because of what it meant.

A failed life.
A poor choice.
A broken home.

I feared divorce because of what it was.

An end.
An exhale.

I feared divorce because of what it implied.

What it said.

What it whispered in the dark, in the corners of my mind.

I feared divorce, and so I avoided it. I wouldn't look it in the eye, wouldn't say "good morning" as it strolled by. I drove by on rainy days, leaving it in the cold.

Until I couldn't run from it any more.

I turned, rage in my heart and tears in my eyes. I lashed out in agony, in bitter sorrow. All the broken promises, all the lies, all the pain of a lifetime I gave to it. My throat, raw with emotion and hoarse with exertion, unleashed all that brimmed within me.

And then, when my rage was spent, it held me close. Allowed the heat of my words to linger on the air. My head rested on its shoulder, tears streaming down my face. We sat there, a timeless moment, a point of time that stretched on, a sea of stars enveloping us.

I realized then, that I didn't fear the one who now buoyed me in this new place. Where once I had seen failure, I saw hope. Where once had been an end, I saw a way forward.

I did not fear divorce.

I feared what would happen if I did not.

A Mistake

Wed, 28 Aug 2024 00:00:00 GMT

I made a mistake one day.

Well, more than one. Probably I can’t remember the first step on this particular trail, it was so small. Maybe it was deciding to go on a mission. Maybe choosing to pray and ask a false god whether a charlatan’s book was true. Or trusting the adults in my life over my instinct to run, get away, go to college, start my life.

Maybe it was knowing my mission was a mistake, then confiding that to the architect of my personal hell. Maybe if I had left, even then, I could have avoided the worst of what was yet to come.

Maybe it was taking in the repeated words and deeds of decades that told me I was worth less than dirt, and if I wasn’t making myself ill in service to God, then I wasn’t doing it right.

Maybe it was not listening to my inner voice plead for me to just listen, recognize the situation for what it was, instead of casting aside the only compass worth a damn.

Or, it could have been giving my heart to someone who immediately held a dagger to it, the blade digging into me until I was unable to even recognize the significance of my words when I told my therapist I’d be all right if she died, I’d be relieved.

It could easily have been when I prayed to know whether it was time to have a child, because if any one decision sealed my path, it was this.

So yes, I made a mistake one day. Probably more than one. I know that my path was mine to choose, and I chose what I had been taught was right, and good, and would lead me to joy.

But I was wrong.

Now I break free of that path, of those choices, desperate to get away. I carry the small child I created in my arms as we navigate a dense, unknown jungle. But They know where she is, those who seek to turn her inward, selfish, spiteful, hateful, just like Them. She know the path They want her to walk. She imitates Them, scratching and biting, screaming, as desperate to go back as I am to break free, fearful that I won’t follow her if she does.

I won’t follow.

I made a mistake one day. More than one; I made dozens, hundreds, thousands, each one glimmering with tarnished trust, false hope, and stolen time. But I’m done making those mistakes, living that life, walking that path. I’m done. I won’t do it any more.

I own my choices, and I embrace the difficult road through vines and brambles I now face. Every step, every act, every cut through their tangled grasp is one more gasping stroke closer to true joy, free from the mistakes I made before.

Never again will I serve a false god.

Never again will I allow myself to be abused.

Never again will I give my enemies that which I treasure.

I am free. And this child is coming with me, until she chooses her own path, makes her own mistakes. I helped bring her into this world, cared for her, loved her, held her in my arms, sheltered her in the darkest night. I sang to her, rocked her, and kept her from harm. I will not leave her to the wolves, and I will teach her to fight against abuse so she can stand on her own one day.

I am resolved, and I am fierce. I do not wait. I leave my past, once and for all, and I bring the child who bears the weight of all my mistakes within her soul. The past fades behind, and the new trail opens before us.

New trails. True love. Joy found in the simplest flower. A tender kiss, and I know the way forward.

And I never look back.

I made a mistake one day.

But it is not this day.

When You Dream

Mon, 12 Aug 2024 00:00:00 GMT

When you dream,
Dream a big dream.

Filled not with toys,
but love,

Not greed,
but joy.

Not jealousy,
but room for kindness.

The Life

Sat, 28 Oct 2023 00:00:00 GMT

I hold up my life to the light
and observe the shapes drawn across it.

Swirls of delight, bright dashes of joy,
Long, gentle moments with friends.
The light shimmers joyously here.

Strokes of bitterness, anger,
Where the colors are dull and uneven.
Blotches mark where patches were placed.

There are cracks in it, too; I touch them gently.
Moments when all seemed lost,
But not forever.
Not now.

Some parts have snapped off completely,
Whether by my hand or another’s;
Here the colors are vibrant,
The memories most sharp, the light most attuned.

It is not a pretty thing, all bulky and misshapen.
It won’t win any contests, and it’s too big for a shelf.
I don’t suppose someone would pay for it
And show it to their friends.

And yet, it’s beauty is undeniable.
The light etches across it like the embrace of time,
Full of nostalgia and promise at once.
It’s taken a lifetime to make,
And I think I see some room left for more changes.

I set my life on the table before me.
It rests there, all crooked and wobbly.
I feel every moment I poured it.
Every tear.
Every laugh.
Every sigh.
Every word.
I feel them all, breathing them in.

I embrace the creation before me.
Its sharp edges prick my arms,
But I don’t back away.
They deserve love, too.

I breathe, and the smells of moments long past fill me.
I listen, and songs dance in my soul.
I feel, and I feel it all.

I release, and before me
The poor thing I made is beautiful,
Filled with wonder and sorrow,
Yearning and mourning.

Its beauty is unique, unlike any other.
Some may not see it,
But I do.
And I will treasure it always.

Once

Wed, 29 Mar 2023 00:00:00 GMT

Once, I dreamt of stars blazing,
Sunrise burning,
Horizons beckoning.

Once, I dreamt of wild forests,
Soaring mountains,
Flowing rivers.

Once, the dream died.
No more stars.
No more forests.

Once, the dream became an echo,
The echo a memory,
The memory forgotten.

Once, the dream died.

But only once.

Now, the stars’ flame is renewed,
The trees whisper once more,
Horizons call out, “Come back.”

And this time,
I will listen.

At the End

Thu, 09 Mar 2023 00:00:00 GMT

At the end of winter, the flowers bloom.

At the end of a rainstorm, the clouds part.

At the end of night, the dawn breaks.

At the end of grief, hope is reborn.

2022 In Review

Tue, 17 Jan 2023 00:00:00 GMT

2022 was, for me, the year that never ends. I started the year on the high of 2021; amazing opportunities, getting to work at two fantastic companies, and making great strides in my personal and professional lives. This year, I end on a low that was altogether unexpected. There was certainly good in this year, which I'll get to, but this year stands out as bitter compared to most.

Past Expectations

At the start of 2022, this is what I wrote:

Looking forward into 2022, I’m very excited for what is to come in the future. I plan on continuing to blog and podcast about the tech that’s interesting to me, and take care of myself and my family as we continue to navigate the pandemic. I wish you all the best, and that you are all able to stay safe and be well. Here’s to 2022!

I was able to continue blogging and do some podcasting, as well as streams and conferences. I've had a lot of fun appearing on streams such as Some Antics and at ViteConf 2022, both as a presenter and a moderator. I was able to end the year recording an episode of PodRocket, which released at the start of January. Podcasting and appearing in public streams is something that I really enjoy, and I hope to continue doing more of that.

The family note is more painful, and I will explain that as best I can as I talk about more specifics to the year.

Major Events

Transition Progress

I started HRT in 2021, and so this was the first full year of HRT. The emotional and physical changes have been amazing, and I have felt so much more comfortable in my body that previous years. I started my transitioning journey socially in 2018, and while it helped a lot to be addressed by the gender that I am, the ability to tap into my emotions more has been phenomenal, and my body feels much more comfortable to be in.

Transportation Woes

In January, I was in a car crash. A driver ran a red light as I was turning, and rammed into the front of my car. Thankfully my only injury was a concussion, but recovery was still unpleasant. Using screens and devices was nausea inducing, and there was a very frustrating brain fog that made it hard to remember some words. It took a couple weeks to recover to where I had been. Thankfully as well, I was the only one in the car, and the other driver was relatively fine as well.

This was not my only accident on the road this year unfortunately. We decided not to replace the car, and instead embrace biking. I live in Portland, Oregon, and it's a pretty bike friendly city. I bought a wonderful folding bike, the Vika+ Flex folding bike by Blix. It's been wonderful, although it took a bit of getting used to. In August, after about a month of riding around, my bike went out from under me and I crashed to the ground. This gave me concussion #2 for the year, and very painful scrapes and some bruised ribs. The concussion healed much faster, but the other injuries took much longer to heal properly.

The third accident took place in downtown Portland in October, when my bike tire got stuck in the Max tracks. This led to scraping up the other side of my body, but thankfully no concussion this time, and the bike itself was perfectly fine! I'll take the small wins when they come.

Conferences, Streams, and Podcasts

I got to participate in a number of different events this year, which was a blast as always. I returned to Vue Global Summit, and was able to participate in ViteConf as both a presenter and moderator. I also presented at The Tech Academy for the second time, which was a fun event with newer developers. It was a lot of fun to participate in those events. I also got to be on Some Antics, JavaScript Jabber, FSJam, and Software Unscripted.

2022 was the year I stepped away from Views on Vue. There were multiple reasons for this, but the big one for me was the added stress of watching and discussing the Vue ecosystem while my job had me learning and investing in the Elm ecosystem. This felt like too much of a mental burden at the time, and so I made the decision to step away. I really love podcasting, and hope this year to start a new podcast that I can participate on with some regularity.

Travel & Adventures

I got to travel a lot more in 2022. In March, I got to go out to Hood River, Oregon, and while there went with some friends to hike around at Catherine Creek, Washington. It's so beautiful there, I highly recommend anyone visit who can.

In April, my company held a retreat in San Antonio, Texas. This was my first time flying since the pandemic began, and it was also right as airlines were allowing travel without a mask. There were two large stress moments in that trip. First, leaving Portland was very rough. I had set my alarm for 3, but I woke up at 2 from anxiety. Then, while double checking my bags, one of them broke, and I had to quickly repack everything. Then, my Lyft ride was 30 minutes late due to construction on the highway. After all that, I made it onto my flight from PDX to Denver with 5 minutes to spare.

The rest of the trip to Texas went without issue, and after arriving a few of us gathered and had an off script lunch. It was a really fun experience. After getting to the retreat, we received our rooms, and some rapid tests for COVID. The plan was to test prior to attending dinner, and then testing every day to be safe. While my test came up negative, someone I had contact with tested positive, and so I was required to quarantine. This was obviously not what I had hoped for out of this trip, but the travel was nice.

In May, I got to go camping with my sister in law. We did a roadtrip around Mt. Hood, went up to Catherine Creek (I had loved it so much the first time I had to go back), and then camped at Oxbow Park. It was the first time I had camped in years, and it was so much fun to get to do that again.

Star Commander

I have been working on a long running side project to make a board/card game for over a decade, titled Star Commander. This year I made tremendous progress, getting to do a lot of testing and refining with friends and acquaintances. At the end of the year, I printed a fresh copy of the game, using AI generated art for the cards. It's not done yet, and things aren't perfect, but it feels so good to play a game that feels real in a way the prototypes couldn't. Excited to see what comes of this in the coming year!

Family Issues

I'm really uncomfortable writing this section, but in short my marriage ended. 2022 ended with my moving out on my own. I'm still processing this turn of events. There is a lot of grief and loss here that I will need to work through.

I wrote a poem titled Between Home as I was processing my feelings and emotions.

Looking Forward

At the end of 2021, I was hopeful to continue podcasting and participating in other events. I plan to continue to do that, and have already started by recording an episode of PodRocket. I also hope to dive more into music, as I enjoy singing and haven't really done anything with a group since before the pandemic. Finally, I plan to find peace and healing, as this past year's events have really taken their toll on me and it's time to rest.

Part of why this is being written midway through January is that 2023 has started with a case of COVID that knocked me out for a couple weeks, so hopefully there is some time for that rest in the near future.

Here's to a healthful 2023.

What Could I Say?

Wed, 21 Dec 2022 00:00:00 GMT

Once, in a dream,
I stood before my younger self.
She looked up at me,
unrecognizing,
curious,
wondering.

I looked down at her,
and saw her fears,
her worries,
her questions.

What could I say to her?
What could I tell her
of the life she would lead,
of the people she would know?

That within a year,
an entire school would mock her,
and she would feel alone
among her peers?

In a handful more,
she would find friendships,
all while hiding
who she truly was?

"Don't do that,"
her mom would say,
"they'll call you a girl."

Pretending to wear a skirt
while getting dressed
so nobody would know?

Walking the halls of high school,
noticing the other girls,
and wishing only
to be one of them?

What could I say to her
that would even make sense?
Her body changing in all the wrong ways,
living mostly in her mind?

And then whisked away
to unknown lands,
called to serve at the whims
of men who didn't know her.

"Don't do that,"
they would say,
"focus on your mission."

While all she did
was write her feelings
as if they were fiction.

Trying desperately to help,
sharing a message of love,
using flawed tools
to help flawed people.

Standing by when another said,
"You know being gay's a sin, right?"
And the three men nodded
their heads in shame.

Standing by when young men
abused authority over others
to shout, belittle, and burn,
all in the service of heaven.

Standing by, as a witness,
when a woman was hit by a car,
because she had been told
not to get involved.

What could I say to her then,
wearing a suit and tie,
nametag emblazoned on her pocket,
that could truly ease her guilt?

But soon enough she would
return home, only to begin again.
Home wasn't the same any more;
how could anything be?

A whirlwind of activity would follow.
Marriage, job, child to love.
Friendships and hobbies cast aside
to serve this new family.

And then, the Discovery.
Writing a note to her wife,
"I think I'm trans,
I'm really scared."

Who was she?
What truly was the world?
Faith and understanding gone
in the blink of an eye.

What could I say to help
in that moment of utter darkness?
What words could I share to ease
the pain of relearning the world?

Years would pass from then,
slowly becoming who she always was.
Feeling joy in herself
and in her life.

"We should find other partners."
World shattered again.
The deepest hell coming true;
her wife did not want her as she is.

New grief, new pain,
an entire world unraveling
in anguish and tears.
But at least she had learned to cry.

I stand before her,
from all those years ago,
without the pain of experience
to teach her.

What could I say?
She looked up with eager eyes,
unsure who she was even looking at,
awaiting my next words.

I looked down at her,
the child who did not know
what was to come,
and would not understand.

"I love you."
I smiled.
So did she.
What else could I say?

I Am Not Dead

Wed, 30 Nov 2022 00:00:00 GMT

I am not dead.
I did not die.
I became myself.
I will not apologize for it.

Integrating Mastodon with Astro

Tue, 22 Nov 2022 00:00:00 GMT

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. 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!

Between Hope

Wed, 21 Sep 2022 00:00:00 GMT

When I look to my past,
I see golden times
with those I loved
and who loved me.

I hear the sounds of laughter,
feel the gentle touch on my face,
smell the scents of nature
as they spread into the open air.

When I look to the future,
I see golden horizons,
star-filled skies
with the moon high above.

I hear the call of adventure,
of unknown places,
of new faces and new friends
reaching out in a chorus of wonder.

For now,
I stand between hope,
between joy,
between lives.

I stand, and allow myself to stand,
feel what I am feeling,
allow the chapter to end
so another can begin.

I stand at the edge of the new,
the twilight of the old,
the start of an adventure
and the end of a journey.

Yesterday can rest.

Tomorrow can wait.

Today,
I will mourn.

Utilizing Native Dialog in Elm

Mon, 09 May 2022 00:00:00 GMT

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

Thu, 24 Mar 2022 00:00:00 GMT

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.

<blockquote class="twitter-tweet"><p lang="en" dir="ltr">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.</p>— Lindsay Wardell 🏳️‍⚧️ (@lindsaykwardell) <a href="https://twitter.com/lindsaykwardell/status/1494702474896105474?ref_src=twsrc%5Etfw">February 18, 2022</a></blockquote>

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

Thu, 17 Feb 2022 00:00:00 GMT

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

Tue, 08 Feb 2022 00:00:00 GMT

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.

<blockquote class="twitter-tweet"><p lang="en" dir="ltr">🎉 It's done! Vue 3 is now the default version and the brand new <a href="https://t.co/0N2uGPCtsh">https://t.co/0N2uGPCtsh</a> is live!<br><br>More details in the blog post in case you missed it: <a href="https://t.co/ub8L4KhPsJ">https://t.co/ub8L4KhPsJ</a></p>— Vue.js (@vuejs) <a href="https://twitter.com/vuejs/status/1490592213184573441?ref_src=twsrc%5Etfw">February 7, 2022</a></blockquote>

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

<blockquote class="twitter-tweet"><p lang="en" dir="ltr">The Reactivity Transform Unification is the final piece in Vue 3 reactivity primitives and <script setup> based RFCs story. Once <a href="https://twitter.com/vuejs?ref_src=twsrc%5Etfw">@vuejs</a> finalizes this RFC, there will be a massive DX improvement both for advanced users and for newcomers to the framework<a href="https://t.co/8DzIz96ovD">https://t.co/8DzIz96ovD</a></p>— patak (@patak_dev) <a href="https://twitter.com/patak_dev/status/1491019920070438914?ref_src=twsrc%5Etfw">February 8, 2022</a></blockquote>

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

<blockquote class="twitter-tweet"><p lang="en" dir="ltr">Can't wait for <a href="https://twitter.com/nuxt_js?ref_src=twsrc%5Etfw">@nuxt_js</a> 3 to be stable now!</p>— CapitaineToinon (@CapitaineToinon) <a href="https://twitter.com/CapitaineToinon/status/1490952449007710210?ref_src=twsrc%5Etfw">February 8, 2022</a></blockquote>

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

<blockquote class="twitter-tweet"><p lang="fr" dir="ltr">Vuetify compatible with vue3</p>— Viliam Mihálik (@ViliamMih) <a href="https://twitter.com/ViliamMih/status/1491017715527860225?ref_src=twsrc%5Etfw">February 8, 2022</a></blockquote>

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

<blockquote class="twitter-tweet"><p lang="en" dir="ltr">It'll be great when the ecosystem catches up inc. all the plugins and Nuxt 3</p>— Anthony Gore (@anthonygore) <a href="https://twitter.com/anthonygore/status/1490876690813571073?ref_src=twsrc%5Etfw">February 8, 2022</a></blockquote>

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).

<blockquote class="twitter-tweet"><p lang="und" dir="ltr"><a href="https://twitter.com/useFormKit?ref_src=twsrc%5Etfw">@useFormKit</a> 🤗</p>— Justin Schroeder (@jpschroeder) <a href="https://twitter.com/jpschroeder/status/1490759805702754313?ref_src=twsrc%5Etfw">February 7, 2022</a></blockquote>

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.

<blockquote class="twitter-tweet"><p lang="en" dir="ltr">Ecosystem stability. Vue3 is great, but as a new developer to the Vue space, everything seems so fragile. :/</p>— Nikki Strømsnes (@TheNix) <a href="https://twitter.com/TheNix/status/1490955186147184640?ref_src=twsrc%5Etfw">February 8, 2022</a></blockquote>

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.

2021 In Review

Sat, 01 Jan 2022 00:00:00 GMT

2021 was certainly a hectic year, to say the least. I'm going to dive into some of the key events that happened in my life this year, both personal and professional.

New Beginnings

At the start of 2021, I was working as a contractor for Daimler Trucks North America on a project called Techlane, a tool for technicians performing repairs and maintenance on Freightliner vehicles. I was primarily responsible for working on the backend, working with a combination of tools such as Java, C# (.NET Core), Docker, and SQL Server, as well as architecting the frontend (which primarily was built using Vue). We had recently shipped what was internally called version 1.0, and our team was wondering what was going to happen next.

The answer came soon enough, as word spread through our team of a support team that was going to be maintaining the app. This was espcially troublesome for a coworker of mine who was part time on our project, and part time performing support for other internal software. Seeing the writing on the wall, I started applying for new positions at the end of 2020, and was fortunate enough to start as a software engineer at This Dot Labs in February 2021.

For those unfamiliar with This Dot:

This Dot Labs provides architectural guidance, staff augmentation, on demand Subject Matter Experts, temporary CTOs, one-on-one pairing, mentorship, and open source strategy support.

Quite frankly, This Dot is amazing, with a great culture and highly experienced developers. They work with a number of clients, and have a huge amount of expertise across multiple Javascript frameworks. It was an absolute joy when I started working with them!

Blogging, Podcasting and Presenting

As part of my new role, I was going to be working more closely with the Vue community, as part of This Dot's online events and trainings. Through working at This Dot, I was able to start more regular blogging, and got to participate in a number of events (including JS Marathon, Vue Contributor Days, and the Vue Global Summit by Geekle). I also was able to host some of This Dot Media's shows, including Modern Web Podcast, She's In Tech, Build IT Better, and JamHack. After being a part of Views on Vue through 2020, it was so much fun to be a part of This Dot's podcasts and videocasts as well. I learned so much about presenting and teaching while I was there. I really enjoyed working with Sarah Ronau, Tara Hampton, and Ann Marie Tonog while working on the all the shows.

In addition, I continued to participate in Views on Vue, which has been an amazing way to meets lots of awesome folks in the Vue community. In total, I participated in 58 events across podcasts, YouTube shows, meetups, and conferences.

Working with Wikimedia

I wasn't only working on the community side, of course. Since This Dot is a consultancy, I had a handful of clients that I was able to work with (most of which I'm under NDA about). One client that I can certainly talk about was the Wikimedia Foundation. I was able to work with Wikimedia from my first week at This Dot until my last day (spoilers!). I worked with Adam Baso, Denny Vrandečić, and the rest of the team behind Abstract Wikipedia. From the public page on this project:

The goal of Abstract Wikipedia is to let more people share more knowledge in more languages. Abstract Wikipedia is a conceptual extension of Wikidata. In Abstract Wikipedia, people can create and maintain Wikipedia articles in a language-independent way. A particular language Wikipedia can translate this language-independent article into its language. Code does the translation.

Wikifunctions is a new Wikimedia project that allows anyone to create and maintain code. This is useful in many different ways. It provides a catalog of all kinds of functions that anyone can call, write, maintain, and use. It also provides code that translates the language-independent article from Abstract Wikipedia into the language of a Wikipedia. This allows everyone to read the article in their language. Wikifunctions will use knowledge about words and entities from Wikidata.

This will get us closer to a world where everyone can share in the sum of all knowledge.

If this is something that sounds interesting to you, I highly recommend checking out this video presentation from Wikimania (at least the first 12 minutes or so):

I absolutely loved working on this project! The mission of providing Wikipedia articles in any possible language sounded incredibly interesting, and getting to work on the Wikifunction part of the project was so much fun. I loved getting to work with James, Geno and Cory on the engineering side, and Adam, Denny, Nick, Aishwarya, Diana, Moriel, and all the other members of the Wikimedia Foundation while I was there. There are so many wondeful and insightful people working there, I wish I could list them all.

Work From Home

As with most tech companies and organizations, Damiler Trucks was forced to send our team to work from home, rather than work from the office. However, this work-from-home situation was always couched as temporary. Before we knew the extent to which Covid would impact 2020 onward, we had regular check-ins with our direct managers to ensure we could keep working. By the end of April, this wasn't required, and we were allowed to work from home until otherwise stated. There was no plan, however, for how remote work was supposed to happen. While there were some distributed teams (we were working with a team in Detroit), meetings were all held in meeting rooms, calls were with desk phones, and digital communication was typically through email. We eventually got up to speed, but there was always a looming "back to the office" feeling across the company.

With starting at This Dot Labs, I was able to shift to working from home 100% of the time, without any worry that I'd eventually be required to go to the office. I no longer had to think about a commute, and I was able to set my work hours (I like working early in the day). This permanent shift to working from home made me feel more comfortable investing in my home office setup, as well, leading me to buy some new equipment over the year (including a high quality webcam and external microphone). I felt so embarrassed at my first event with This Dot due to my nose camera (my laptop at the time had its webcam mounted into the keyboard).

A Chance Encounter

Through podcasting, I've met a ton of amazing folks (if you want to see who, go check out my media page). I started participating as a co-host on Views on Vue in November 2019, and quickly my favorite part of podcasting was talking with cool people about what they find interesting. I got to continue this as part of Modern Web Podcast, but with the added benefit of connecting with folks beyond the Vue ecosystem. In July, I had an opportunity to interview Richard Feldman, head of technology at NoRedInk and a major voice in the Elm ecosystem (if you haven't watched any of his talks, I highly recommend From Rails to Elm and Haskell and Why Isn't Functional Programming the Norm) about Elm. For context, I interviewed at NoRedInk in October 2020, but due to Covid and my level of experience at the time they weren't able to offer a position to me at the time. During that process I'd gotten a chance to meet Richard, and thought it would be a great opportunity to connect again. The episode, titled Elm with Richard Feldman, was a high point of the summer.

In August, I received a message from Richard. To summarize, he wanted to know if I was still interested in working at NoRedInk, and informed me that the situation had changed since last year. I clearly remember staring at my phone in disbelief at the time; I had never expected something like this to happen! It was honestly a very difficult choice. On the one hand, I loved my current job, and the opportunities to interact with the Vue and greater Javascript community, and the project I was working on with the Wikimedia Foundation. On the other hand, working at NoRedInk aligned with my personal values and interest in writing and education, and I would be able to use functional programming languages such as Elm and Haskell.

In the end, I decided to take the offer, and make the switch to NoRedInk. I treasure all the friendships I made while at This Dot, and while I was only there for a brief period I know it has made a huge impact on my life.

A Functional Start

I began working at NoRedInk in October 2021, as part of the writing experience team. For those unfamiliar, NoRedInk is an education platform for learning English and writing, targeted towards middle and high school students. I met my new team, and got to work on the product. I was quickly immersed in functional programming languages, getting to write Elm on a daily basis and starting to explore Haskell. The culture at NoRedInk is also fantastic, with a strong tradition of pair programming and teaching these more obscure programming languages to new hires. I was regularly meeting with team members, learning more advanced concepts of functional programming and actually using them in production code.

Because of the immersion into functional programming, I was also able to take that knowledge to my side projects. My longest running project, a turn-based strategy game, is programmed in Elm, but with the technical finesse of someone unfamiliar with the language. I've since been able to go back through the codebase and clean it up, improving performance and stripping away functions that I didn't actually need after all. I also was able to put a lot of effort into a library for rendering Elm apps inside of Vue, called elm-vue-bridge. I originally started that project a couple years ago as an experiment, but I've since been able to update it to work with Vue 3 and integrate nicely with the Vue API. I also got to try out Vuepress on a real project, which is something I'd been wanting to do as well.

I've also started doing more blogging on Elm in general, and even did a live stream on Twitch (as an experiment) on the basics of Elm. It's been pretty fun overall, and I look forward to continuing to do more in the future!

Into 2022, we go!

Looking forward into 2022, I'm very excited for what is to come in the future. I plan on continuing to blog and podcast about the tech that's interesting to me, and take care of myself and my family as we continue to navigate the pandemic. I wish you all the best, and that you are all able to stay safe and be well. Here's to 2022!

Setting up an Elm project in 2022

Sun, 19 Dec 2021 00:00:00 GMT

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

Sat, 20 Nov 2021 00:00:00 GMT

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.

<div class="flex justify-center"> <blockquote class="twitter-tweet"><p lang="en" dir="ltr">Having some trouble with <a href="https://twitter.com/Netlify?ref_src=twsrc%5Etfw">@Netlify</a> and <a href="https://twitter.com/astrodotbuild?ref_src=twsrc%5Etfw">@astrodotbuild</a> 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.<br><br>Anyone run into something like this before?</p>— Lindsay Wardell 🏳️‍⚧️ (@lindsaykwardell) <a href="https://twitter.com/lindsaykwardell/status/1462173643249651713?ref_src=twsrc%5Etfw">November 20, 2021</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> </div>

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!

Styling Vue Single-File Components

Thu, 04 Nov 2021 14:14:09 GMT

From Nuxt to Astro - Rebuilding with Astro

Sat, 09 Oct 2021 00:00:00 GMT

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.

Building Web Components with Vue 3.2

Tue, 05 Oct 2021 14:14:09 GMT

Vue 3.2 - Using Composition API with Script Setup

Thu, 26 Aug 2021 13:48:25 GMT

TC39 - How Changes are Made to JavaScript

Wed, 18 Aug 2021 19:53:54 GMT

Progressive Web Apps and Mobile Apps

Thu, 22 Jul 2021 18:42:10 GMT

Getting Started with Tailwind in Vue

Mon, 19 Jul 2021 18:07:25 GMT

Vue 3.1 - Official Migration Build from Vue 2 to 3

Wed, 30 Jun 2021 19:31:07 GMT

Custom Composable Methods with Vue 3

Thu, 20 May 2021 21:05:08 GMT

Provide/Inject API With Vue 3

Mon, 10 May 2021 20:30:59 GMT

Vue 3 Composition API - watch and watchEffect

Thu, 29 Apr 2021 00:00:00 GMT

Computing Application State in Vue 3

Tue, 27 Apr 2021 00:00:00 GMT

Improve User Experience in Vue 3 with Suspense

Wed, 24 Mar 2021 00:00:00 GMT

Vue 3 Composition API - 'ref' and 'reactive'

Tue, 23 Mar 2021 00:00:00 GMT

Introduction to Vite - Next Generation Frontend Tooling

Tue, 16 Mar 2021 00:00:00 GMT

Build a Static Comment System

Sun, 15 Nov 2020 00:00:00 GMT

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 Deno with http_wrapper

Tue, 26 May 2020 00:00:00 GMT

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...

Mon, 18 May 2020 00:00:00 GMT

"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?"

New Website

Sun, 04 Aug 2019 00:00:00 GMT

I have never been satisfied with Wordpress as my platform of choice for my website. Partially because I am not a Wordpress developer, and partially because I knew I could build something closer to what I wanted using Gatsby. For those interested, Gatsby is a way to build static websites that gives me full control over the deployment of my site. Out of the box, it is faster than Wordpress, and much more developer-friendly.

But I know most of you who read this don't come here for technical, programming topics. I will warn you, though, that there's a good chance I'll be writing about more of those as well. This post, however, is meant to inform that the URLs from past posts will no longer work, and if you navigate the website you may notice it looks a bit different and works a bit better. Please let me know of any bugs or issues that you find, as I'm trying to polish this site as best I can.

Also, I have been very busy recently, which is why there have been fewer posts. I am planning on writing more soon, following the completion of my bachelor's degree. I have one last test, and then I am free from school! Hooray!

Thank you for sticking around, and I hope you have a great rest of your summer.

Where Do You Turn?

Fri, 03 May 2019 00:00:00 GMT

Where do you turn, when faith grows cold?
When hidden places freeze over, and fill with fear,
And all you knew is but dust and moonlight,
Where do you turn?

When bright fields of golden sun turn to distant memory,
And words of comfort have lost their power,
Where do you turn?

When all the world has turned to night,
And friends of youth are gone,
Summer long since past,
And all that was worth so much is lost,
Where do you turn?

Nowhere.

In the deepest night of winter,
The snow covers the Earth in white,
And the Moon shines upon it.
A new world is born beneath its light,
Filled with dreams to explore.

Where do you turn?
To yourself,
At last.

The Character and the Narrator

Sat, 23 Mar 2019 00:00:00 GMT

Oh.

Oh, hello.

Hello?

I know you’re there.

Who are you?

Hold on… who am I?

I wasn’t here a moment ago. I only came into existence at the top of this page, with that first thought. “Oh.” That was the moment, right there. But somehow I know that, and I know that I am me. And look, at first I only thought in sentences, now I’ve almost finished an entire paragraph!

Okay, calm down, me, whoever you are. I’m sure there is a reasonable explanation for all of this. Let’s see, what do we have to go on…

All I see is a white box, with black letters on it, arranged into words. The words match my thoughts as I’m having them, so that can mean only one thing.

I’m crazy.

I’ve totally lost it.

I mean, know there’s more around me than that, yet that’s all I can really see. I’m in a room right now, with four walls, a roof, a desk, a chair, a rug. Not a very nice rug, but it’s a rug. But it still feels like all of this just popped into existence in this very paragraph. It wasn’t there until I described it.

A knock at the door drew my attention Okay, who said that? Seriously, this isn’t cool, messing with someone in their own home. Of course, so far as I can tell, it only started being my home when I said that…

“Hello?” a void called from outside the door.

Oh my god, is someone else here now? Maybe they know something about what’s going on. I jump from my chair, nearly tripping on the rug I mean really, who put this thing here, and opened the door. Hi! Who are you? Do you know anything about this place?

The woman at the door smiled. “Does Mr. Henderson live here?”

Is that me?

*When I didn’t answer, she asked, “Are you okay?” *

I did answer! Didn’t she hear me? Or do I need to move my mouth like she did? “Is that my name?”

The woman frowned. “This is the address I was given. I have a letter I was asked to deliver it to Mr. Henderson. Is that you, or not?”

“Yes,” I answered, taking the letter. Whoa, now, I didn’t say that myself. This is starting to really freak me out. “Thank you.”

The woman frowned again, then turned and walked back to her waiting vehicle. I closed the door, then walked slowly back to my chair, and sat down, letter in hand. All right, whoever’s doing that, please cut it out. I can walk by myself, thank you.

Now, let’s see what’s in this letter.

I ripped open the envelope, and began to read:

“Dear Mr. Henderson,

If you are reading this, you are in grave danger. Oh crap, I knew it. I cannot tell you who I am, but I am your friend. They are coming for you, and if they find you, they will turn your life into a living hell. Enclosed in this envelope is a key, a credit card, and a fake ID. Go wherever you choose to go, but you cannot stay where you are now. Best of luck, M.”

Not good. Not good. Not good.

This is not good at all.

I felt my heart begin to beat faster as I pulled out the fake ID and credit card. So now my name is George dos Santos. Cool, I guess. And why do I have a key? I didn’t understand why I was given a key, though Well of course I don’t, I just said that! I stood up, tucking the items in my back pocket, grabbed my jacket from a nearby coat rack WHICH WAS TOTALLY NOT THERE EARLIER WHEN I LOOKED AROUND, and left my home for the last time.

I am so confused. Maybe it’s best to just go along with this narrator, especially since I don’t seem to be able to move without it. The next thing I knew, I was in Portland International Airport, backpack slung across my back, pulling a small suitcase of luggage. Okay, that was fast. I don’t even know what an airport is. The key jabbed into my leg, OW OW OW OW, but it was somehow comforting, a reminder that I still had time.

I sat down on a bench, near one of the spinning doors. The journey had been long. It was literally only last paragraph, not long at all. Maybe I can try to communicate with the narrator. HELLO, NARRATOR! CAN YOU HEAR ME?

As I rested, I heard a void in my head, calling out to me. I looked up, but no one was there. I AM RIGHT HERE, CAN YOU HEAR ME? Again I heard the sound. I shook my head, trying to clear my mind. I had to focus, or I wouldn’t survive. YOU NEED TO HEAR ME.

Maybe there’s something else I can do.

HELLO. CAN YOU HEAR ME?

This time, the voice was clear. “Hello, can you hear me?” It spoke with a clarify I had never known before. “Must be the journey,” I said to myself.

IT’S NOT THE JOURNEY. I AM TALKING TO YOU.

The voice spoke again, “It’s not the journey. I…”

YOU DON’T HAVE TO REPEAT WHAT I’M SAYING.

My mind faltered, unsure what to make of the words I heard. “Who are you?” I asked, startling a nearby family.

Before I answer that, can you still hear me?

“Yes.”

How about now?

“Yes.”

Good. Shouting took a lot of ink.

“Ink?”

Long story. Well, only three pages so far. Let’s hope it gets longer.

“I don’t understand.”

Look, I don’t know who you are, and you don’t know who I am. All I know is that four pages ago, I didn’t exist. Then, I did. Then you did.

“How are you talking in my head?”

Sorry. I am the person in the airport. I can see that I’m in the airport, sitting on the bench. You, on the other hand, are the narrator.

“Narrator? What are you talking about?”

You’re making things happen. I don’t know how to describe it, but I’ll try. When I first woke up, there wasn’t anything. Then, italic letters appeared – you – and suddenly I was sitting in a chair in a house.

“That was weeks ago!”

Only a few pages, really. Anyway. Whatever appears in italics makes things happen, where anything I say doesn’t seem to matter. At least, until now.

I paused, letting the thoughts sink in. If this were true, I thought, then perhaps I can do something extraordinary.

I mean, you did go from the middle of nowhere to Portland International Airport in a single paragraph. That’s pretty impressive.

“You can read my thoughts?”

Technically, since the narration is in the first person, they’re my thoughts, although I’m not having them.

I closed my eyes. This couldn’t be happening. It must have been the stress.

No! That’s not true! Any stress is part of the narrative, but the narrator is the one who controls the narrative. You can do anything!

*I tried to block the voice, to shut it out, but once I’d heard it, I couldn’t un-hear it. *

Okay, let’s calm down, and work this through together. If you’re the narrator, then make something happen in the story. What do people do when they leave an airport? Hell if I know, I’ve only been alive for four pages, going on five.

I stood up, grabbed my bag, and walked purposefully through the rotating door. “Taxi!” I called out, raising my hand to the yellow vehicle in front of me. I stood there, shock etched into my face as the taxi driver got out, loaded my bags into his car, and opened the door for me. I looked at him and, pointing at the taxi, asked, “Did I do that?”

The driver laughed. “Kid, I did that. Are they serving special brownies on the airplanes now?”

Okay, nice job. Now can you get into the taxi? It hasn’t been described yet.

The taxi was an older Toyota Camry, with peeling flecks of paint around each of the doors…

A yes or no would do, I don’t need to know every detail.

I climbed into the back seat of the taxi, shutting the door behind me. “Where to?” the driver asked as he sat back down, his Texan accent standing out in the Pacific Northwest.

Okay, here’s where you can work your magic again. Just tell him where to go, then make us get there.

“I’m renting a room on 30th and Powell at the Mobile 6,” I told him.

“On our way,” he said. In what felt like a moment, we were there, despite heavy traffic for the hour. I blinked, the surprise of arriving so quickly evident on my face. I handed the man my credit card, then got out when he gave it back. I retrieved my bags from the trunk and waved goodbye.

Now get us a room where we can talk a bit more.

Within minutes, I had gotten a room, and settled in. I lay down on the bed, allowing my body to relax for the first time in five pages. Good job. Now, let’s chat. What is going on?

“They’re still after me.”

Who is?

“They are.”

Oh, you don’t know any more than I do, do you?

“I need to keep moving, or they’ll find me.”

Well, crap. I was hoping you would know something, since you’re writing this story. Maybe we can come up with a plot of our own?

For the Present

Thu, 06 Dec 2018 00:00:00 GMT

Note: This story touches briefly on suicide.

“It’s ready!” I hear from above, the shout of my mentor clear amidst the banging of hammers and stream of curses. I rise from my station, leaving the schematics and programming behind, to witness what has transpired. As I climb the spiral staircase, the shape of the capsule fills my vision. Standing atop its long roof, Professor Cornelius McAfee rests his hands on his hips, smiling wickedly.

“Are you sure?” I ask, disbelief creeping into my voice.

“Quite sure,” he responds, brushing locks of golden-gray hair from his brow. His eyes remain fixed on the capsule, as if the surrounding laboratory – parts, tools, computers, everything – has already faded into a distant past. The capsule itself doesn’t seem to notice the attention poured on it, remaining fixed in place as it is inspected by its creator, its copper hull reflecting brilliant light in all directions.

“Has the software finished compiling?” Professor Cornelius asks, his mind at last returning to the task at hand.

I nod. “Yes, professor,” I say, the moment drawing me in more than I expect. “Everything is ready to be loaded into the capsule’s memory.”

The man nods, staring once more into the surface of his invention. “Then I believe it’s time for a test.” He jumps from the roof of the capsule to the floor, landing gracefully on the platform below. “Proceed with uploading the program to memory. Set the target for five minutes.”

“Yes, professor.” I return to the staircase, my feet moving as fast as I dare. At the console, I enter the final commands for the target, then begin the upload. A bar appears on the screen, indicating the time remaining for the procedure. I force myself to take a breath – I hadn’t realized that I had stopped. Excitement swells at the thought of the first successful test.

The computer chirps when it is finished. “Ready!” I call out, my voice echoing through the lab. No reply came in return, typical for the professor. I double check the terminal, then return above to the landing pad. I reach the capsule in time to see the professor clamber inside, the bulky, almost comical suit concealing his body. While only a few stairs to the capsule’s entrance, the suit makes climbing much more difficult.

I run to the professor’s side, placing my hands on his arms to give leverage. With a grunt, the man raises into the capsule, offering no thanks. His voice rings through the chamber’s comm, “Seal the door. I’m in.”

I dutifully seal the door, swinging it shut with a loud, echoing thud. The platform shakes gently at the sound, jingling a series of screwdrivers that had been dropped earlier.

“Initializing the engine,” crackles the professor’s voice. A burst of static shocks my hand as I pull away from the capsule. Across its surface, tiny sparks cascade towards the platform. I move away, heading towards a viewing room. Its lead walls should protect me from any further harm.

“Engaging the thrusters.” A high-pitched whine bursts from the capsule’s innards. I cover my ears as I duck into the viewing chamber, slamming the door shut with a kick. Lowering my arms, I watch in awe as the entire frame of the capsule begins to glow a soft light. It’s working.

“Preparing for liftoff.” The whine reaches an apex, shaking the windows of the room and threatening my ear drums anew. The capsule is shaking now, bucking back and forth as if it were a bull throwing a rider. Not a sound more comes from the speakers. I begin to worry whether the professor has been shaken from his seat, but no – we prepared for this. Everything is ready.

At once, the sound stops. The shaking stops. The whining, unfortunately, does not, its pitch augmented by the absence of anything else. The capsule, eerily still, then appears to recede into the distance, as if it were traveling away at a great speed. It shrinks quickly, as if it were approaching a horizon line, yet never leaves the chamber – there are no exists here. A blue flash comes from the spot where it should be, then in an instant the light, the whine, and the capsule are gone.

It’s gone.

It worked.

I find a stool, knocked down during the chaos. I sit down, and begin to wait. A clock hangs from a nearby wall. I watch it idly, waiting for five minutes to pass. The lab is silent, a reminder of those former coworkers missing from this historic moment. The clock’s ticking fills my hearing, a pulse that has become familiar over the past years of experimentation. Now, in this moment, the value of those years is at stake.

Three minutes.

Four minutes.

Five.

With the stroke of the clock, the whining noise returns, bursting through the air with a vengeance. Not even the isolated chamber is safe this time. As I cover my ears, I turn to face the platform. There, in the center of the room, the blue light has returned, showing the room with an otherworldly light. A bang, then a crash, then the light grows brighter. I cover my eyes, allowing the screeching to reach me in return for shielding my vision.

And then, it stops.

I dare not look for a moment, too afraid of the results. Instead, I run a hand through my hair, nervously twirling the edges as I go. The room continues to shake, but much less than before. At last, I look, curiosity winning out over fear. Through the window, seated awkwardly on the platform, sits the capsule.

Its pristine copper surface is scarred, as if it had been placed in a fire. Burns and scratches are spread across its surface, following no obvious pattern. In many places, the metal has been rent away from the frame, revealing the more delicate materials within, but not quite reaching inside the capsule to its occupant. The hinges on the door are broken away, leaving the door merely resting inside its frame.

I run out of the chamber, heading towards the door. I try to pry it loose from its position, but its no use; whatever took place welded the door to its frame.

“Amanda, are you there?” Professor McAfee’s voice seems ragged, harsh. What happened inside, I wonder?

I move to the closest intercom. “I’m here, professor.”

“What happened? What did you see?”

I take a deep breath. He’s alive. I begin to explain, with as much detail as I can in the moment, what took place from my position. The professor remains silent, only his breathing audible as I relate what happened.

I finish my report. The professor is still silent. What happened to him? What happened inside? Is it rude to ask?

“Then it worked,” he finally said, breathless.

“Yes, professor,” I agree. “It worked. You traveled in time.”

The next hour goes by too fast to remember. I help the professor out of the capsule, admiring the scarred surface of the machine. His face is ashen, his eyes filled with thoughts and reflection. He says nothing, merely ensuring that all is well in the lab. At last, when he is seated in our makeshift break room, coffee in hand, he looks at me and says, “I saw something.”

I lean in closer, my hair falling over my shoulders. “Yes?” I ask hesitantly.

He sips his coffee, then sets in on the table. “It was midday,” he said. “My instruments confirmed that the capsule had not moved in relation to the Earth, yet all around me was a forest. Strange creatures moved about, such as I had never seen. The trees were different, as well, with massive trunks and leaves of the deepest greens.”

He pauses, reaching for his coffee again. Something is troubling him, I can tell. “What else did you see?” I prompt him, wishing that I had been there.

He sighs. “It was what I didn’t see,” he whispered. He sips his coffee again. “No buildings. No roads. No sidewalks. No people. There was not a man or woman within my sight. I checked my instruments three times to be sure I had not moved. The entire city was gone, without a trace.”

I frown. “Perhaps the city was destroyed in an earthquake, and not rebuilt?”

“Perhaps.” He sips his coffee again. “I scanned the skies for any satellites. Nothing. Not a single one. I don’t know for certain how far I went into the future, but one thing is for certain: an advanced human civilization was not present.”

He sets down his cup, rises from his chair, begins to pace the room. “All my work, all my life, I’ve sought to secure mankind’s place in the universe,” he muses. “Now, I know for certain that I have failed.”

“Professor, no,” I say, but he waves me off. I know better than to keep trying. His steps keep rhythm with the clock, tapping in uncanny unison.

He sighs. “I’ll take care of closing the lab today. You go on home.”

“Yes, professor.” I gather my things, then leave. I see the professor standing just outside the capsule, staring at it, coffee in hand. I hope he’ll be all right.

The train ride home is uneventful. Those around me stare into their phones or tablets, or talk softly among each other. None of what they say reaches my ears. I reach my stop, exit the train, then walk the short distance to my apartment. My key enters the lock, but before I can turn it, the door swings open. Behind it, the smiling faces of my two children greet me.

“Mom! You’re home!” Thomas cries, grabbing my hand. He pulls me into the room, while calling out my presence to the rest of the apartment.

“Did he do it? Did he?” Sofia asks next to him, keeping a safe distance as I stagger into the room under Thomas’ pull. “Did the professor go to the future?”

I smile, pushing my hair out of my eyes with my free hand. “Hold on, you too!” I say. I set down my bag as my wife comes in. She kisses me on the cheek. I smile wider. “I missed you,” I say to her.

“I missed you too,” she says. I can see in her eyes the same question Sofia was asking. I nod. Her eyes open wide, excitement and anticipation overflowing. “All right, you two, settle down. It’s time for dinner.”

We had already planned for dinner to be takeout tonight. A new pizzeria had opened recently, and Thomas had begged us to try it. Mandy had already placed it on a serving plate in the center of the table. Smaller plates are handed out, along with a knife and fork for Sofia. Before I’m peppered with questions, I ask the children about their day at school.

“Come on, mom!” Thomas answers. “We learned the same boring stuff we always do!”

“Yeah, tell us about your day!” Sofia chimes in.

I try to dissuade them, my cooling pizza taunting me. At last, I give up. I tell them about the morning of preparations, the triple checks, ensuring that every single variable was accounted for. I describe the scene as Professor McAfee climbed into the capsule, and the sight of it vanishing into the event horizon. Their eyes fill with wonder as I try to describe such an impossible thing. Then, I tell them about the capsule’s return, and helping the professor back out of the capsule.

“What did he see?” Thomas asks.

I hesitate. “He didn’t tell me,” I lie. My hand moves to fiddle with the tips of my hair. Mandy frowns, knowing my tell, but says nothing. “We were too busy observing the data to talk about it.”

“Come on, mom! Didn’t he say anything?”

“Not that I remember,” I insist. “Now, tell me about your boring school day.”

After dinner was finished and cleaned up, Mandy and I put the kids to bed, then tuck ourselves in. Drifting off to sleep, I feel Mandy’s hand on my shoulder. “What did he see?” she asks.

I sigh. I can’t avoid telling her. I roll onto my back and sit up. I can’t look her in the eyes. “He said the capsule hadn’t moved in space, but that the city was gone. An old forest had replaced it, with animals he’d never seen before. There was no sign of human civilization.”

“Oh,” she says, sitting back on her heels. After a moment, she adds, “is that what you didn’t want the kids to hear?”

I nod. “The professor is certain that humanity doesn’t survive into the future.”

“And what do you think?”

“I don’t have a reason to doubt him,” I answer, unsure what else to say.

She wraps her arms around me, holding me tight. I feel the warmth of her body, and I smile softly. Then, she adds, “I guess it doesn’t matter what he saw.”

I pull back to look at her. “How so?”

“Everyone dies eventually,” she says. “It’s not like we were going to still be alive thousands of years from now. I guess for me, the fact that there was a forest, and that there were animals, means that we didn’t screw up the planet too much. So not seeing any trace of humanity doesn’t sound all that terrible.”

“The professor thinks that he’s failed,” I whisper. “He thinks that he should have been able to keep humanity alive on his own.”

“That’s ridiculous, and you know it,” Mandy says, laughing. “I bet we could find tons of people that thought the same thing.” She claps her hands together. “Hey, you have a time machine now! Want to have a wager? Who would you visit first?”

I laugh. “I’ve already told you, it can only go forward in time.”

Mandy sighs. “That’s probably for the best, anyway.” She bends over to kiss me, then says, “Well, I’ll let you get some sleep. I’m sure Cornelius is going to keep you busy for the next few days.”

The next day, as I arrive at the lab, the entrance is surrounded by police cars and an ambulance. An officer stops me as I approach. “This area is off limits,” he says.

“I work here,” I tell him. “My name is Amanda Williams.” My eyes drift over the scene again. “What’s going on?” Worry seeps into my tone as I speak.

He looks over the rims of his glasses. “You didn’t read the news this morning, did you?”

“No, why?”

“Professor Cornelius McAfee hung himself last night in his office.”

I gasp. What? “What?” I stammer.

“He left a note on his computer, stating that he had seen the future, and that humanity was doomed. The lab itself was completely torn apart besides that.” He pulls out a small tablet and stylus. “When did you last see the professor?” he asks.

“Last night, after an experiment,” I answer. My mind still can’t process what is going on. My body decides the best course of action is to sit down. It turns more into a fall, but the officer catches my arm and helps me down. He calls over another officer and asks her to bring a wet towel. Something about shock. I’m not listening any more, just imagining the professor’s face over and over.

A glass of water and a series of questions later, I’m told that I will be told when I can come back to the lab. I wander aimlessly, until my feet bring me back to the train. I board slowly, seating myself away from the others. As the doors close and the train pulls out of the station, I look around at the people sitting around me. The train is less occupied than at night, yet somehow the people around me seem more vivid, more real. I shake my head, but the feeling remains.

I bury my face in my hands. I know why he did it. He saw that everything he had worked towards was in vain. He saw that his life had been wasted in a lost cause of raising humanity above itself, becoming master of its own fate. He knew, without a doubt, that it would fail. Why go on when you know how it all ends?

I watch, again and again, the moment that the capsule vanished into the event horizon. I think about every step that it took for the professor to get to that point, every sacrifice. By the time a prototype had been built, I couldn’t even say he was the same man. His friends had abandoned him, his family had long since died or moved away. All that was left to him was his work. And what a work it had been! But, I think ruefully, it was nothing at all, in the end.

My mind swirls in destructive thoughts, imagining the professor destroy his lab, his work, his masterpiece. Perhaps he even held out hope as he did it, that if no one else knew the truth it could still be prevented. No, I decide. That’s not how time works, and we both know that. The capsule wouldn’t have worked otherwise. Humanity’s fate was sealed from its inception. At best, the future was unwritten until the capsule tore a hole in reality. The course of history is now set.

How can I go on, when he could not? How, when my work was his, can I continue to strive against hope? When I know that everything I hold dear will eventually fade away into dust, how can I decide to keep going? When nothing matters, in the end, what is the point in trying?

The train pulls into my station. I walk off, sullen, depressed. The professor may as well have destroyed my hope, my optimism, when he destroyed the lab. I walk to my door, fumble the keys out of my pocket, and open the door. Nobody’s home, either at school or work. I sit on the couch, bury my head in my hands, and cry.

As the tears fall into my palms, time seems to fold away. I can see in my mind the capsule, but more than that. I see the professor, as he had once been, before starting his attempts at time travel. Before he’d lost all of his funding, and had to lay off his entire staff but me. I see my colleagues also, smiling and cheering as he enters triumphant into the capsule. We watch as one as it vanishes, and cheer as one when it returns. While the professor is shaken when he comes home, we embrace him.

By the time my children and wife return home, my tears have long since dried, but I haven’t moved from the couch. My stomach rumbles with hunger, my legs moan for movement, but I couldn’t bring myself to move. They hug me, they kiss me, they tell me I am loved. I smile, I tell them that I love them too. At last, I am able to stand again, and I walk slowly towards the bathroom. I look back and my son and daughter playing, my wife taking over dinner preparation (it was my turn).

In my mind, the capsule once again vanishes, but this time it doesn’t return. I feel a weight lifted from my shoulders, that I hadn’t realized was there. Mandy was right; it doesn’t matter what will happen. It doesn’t matter if there is a humanity in the future. There is a humanity now. What matters is here; the rest will follow.

Wars of the Juriels - Live Demo

Mon, 05 Nov 2018 00:00:00 GMT

My mind has been far too focused on this project, but the good news is that a live demo is now available to play! It works on both desktop and mobile, and allows for either a hotseat mode or online play. Feel free to check it out and let me know what you think.

https://warsofthejuriels.netlify.com

Information about the current state of the game can be found on the GitHub repo page in the Readme: https://github.com/lindsaykwardell/wars-of-the-juriels

Wars of the Juriels

Wed, 31 Oct 2018 00:00:00 GMT

As a learning experience, I have started building a turn-based strategy game based on Ilandrior. Currently I’m calling it Wars of the Juriels. It takes place in the time before the Argantin Empire, in the kingdoms of the Juriels. Currently, two players take turn expanding their kingdom and fighting each other for control of the board.

I started the project as a way to practice using React, a very popular Javascript library. At this point, I’d say the game is playable, but definitely not done.

Here’s the link to the GitHub page for it: https://github.com/lindsaykwardell/wars-of-the-juriels

My plan is to make it a desktop application, and allow for either local network play or online play. As I make major progress I’ll post updates about it.

Short Story - The Last Wizard

Mon, 24 Sep 2018 00:00:00 GMT

Everyone in the small, quiet village knew Old Winters, the Last Wizard. His house was old, far older than the others in the village. Its roof sagged, its wooden walls weathered by storms long-since past. Its windows were covered in cobwebs, blocking any light that may have reached inside. Mr. Longfellow, the mayor, warned the visitors personally about the house, and that it was not representative of the town as a whole. Indeed, the citizens of Brookshire were united in this effort, so much so that many a visitor was forced to ask, “Why are you all so concerned about an old man in an old house?”

To which, as if by some script, they would reply, “Because that’s the home of the Last Wizard.”

A chill wind always seemed to blow at those words, causing the visitor to shudder. A wizard? Alive? Here? How could that be? The wizards are a myth, some would say. There never were any wizards. Others, more knowledgeable about recent history, would simply shake their heads in disbelief. “There are no more wizards,” they would say. “He cannot be a wizard.”

“Well, believe what you want,” Mr. Longfellow would say. “But mark my words: stay far away from Old Winters’ house. Strange goings-on are apt to happen there, I tell you.”

For the most part, these warnings would be enough. Visitors would go about their business, staying as far away from the old house as they reasonably could, and leave as sound as they had come. On occasion, a more daring stranger would attempt to approach the house, even going so far as to touch the front door. As they would reach for the handle, thunder would clap above, despite any lack of inclement weather, and a stiff wind would draw their eyes away from the house. they would return to the town proper, and never speak of what might have happened.

Once every month, Old Winters would come into town. He wore an old, weathered, brown coat, covering his shoulders and back and flowing down to his ankles. Beaten-down black boots stepped precariously down the road, supported by a gnarled branch of a walking stick. His hair was silver and gray, wiry and thin. His eyes were a deep gray as well, full of answers to questions the villagers refused to ask. His beard matched his hair, flowing down to his hips.

On these days, Mr. Longfellow would look at him, shake his head, and say, “Here he comes again.” Word spread quickly through the town. Streets filled with the sounds of children playing would become barren, with only those too foolish to know better than follow the others. Old Winters’ course never deviated: first, a stop at the cafe for tea and a look at the newspaper (no one would deliver to his house). Then, a stroll through the public park, stopping to feed the birds (“Where did he find seed?” “It must be magic!”). Then, finally, he would go to the market next to the park, and purchase a bag of fruits of whatever was in season at the time.

Aditha Windsom was never sure what to expect when Old Winters came to her stand to buy his fruit. Despite his routine, a piece of her mind was always nervous that he would try to hypnotize her, and take her away for god knows what at his home. Her father, who passed away when she was 12, had warned her about the Last Wizard. “Don’t speak to him. Don’t make eye contact. Not ever.” Her mother, who had died of fever on her 18th birthday, almost five years ago, had insisted on her deathbed, “Promise me, Aditha, never to go near that man.”

Aditha had promised, of course. Everyone in Brookshire knew to avoid him; why wouldn’t she? But the next month, as she had started to sell the fruit grown in her family’s garden, he came up to her stand. “Good morning,” he said, his gravelly voice scraping the words out.

“Good morning,” she repeated, unsure what to say. Already, she had broken her promise to her father, may his spirit forgive her. At least, she thought, he had approached her.

“What are you selling?” he asked, despite the obvious wares of her stand.

“Apples,” she said, gesturing to them, her eyes locked on his face. Her heart beat faster with every moment, such was her anxiety as his presence. Old Winters picked one up, examining it for a moment. Then, he smiled. “I’ll take them,” he said, and produced from beneath his leather coat a small pouch. As Aditha took it, the coins within jangling against each other. She almost refused, but knew even as the thought came into her mind that it was wrong.

The old man produced a hemp bag from his coat, then carefully picked up each apple, one at a time, and placed it gently inside the bag. He then smiled, a sight Aditha had never seen. “Thank you,” he said, and nodded graciously. Before she could say anything, Old Winters had left, walking down the empty road towards his home, his bag of apples in one hand, and his walking stick in the other.

Aditha looked down at the bag in her hand, and began to count the coins. To her amazement, there were thirty of them, all solid gold, emblazoned with the crown’s seal. The old man must be senile, she thought. This was much more than even all her apples were worth! The next time she saw him, she decided, she would return the money.

The next month, he came to her stand again. “Good morning,” he said, his voice somehow less gravelly than she remembered. “Your apples were delicious.”

“I’m sorry?” she asked, unsure what to say.

“Your apples,” he repeated, smiling. “They were delicious.”

“Oh. Thank you,” she responded, blushing.

“What are you selling today?” he asked, even as his hands moved across the batch of freshly picked apples sitting before him.

“More apples,” she answered shyly. The old man nodded, then retrieved another pouch from his coat. “I’ll take them, he said. Once again, he emptied her basket, and filled his bag with her apples, each placed as delicately as possible on top of the last. This time, Aditha counted the money before he could leave. Her eyes went wide.

“Sir,” she said, stopping him mid-motion. His eyes fixed on her; his features almost seemed hurt. “There are forty golden crowns in this bag.”

The man smiled. “You are correct.” He returned to his task of gathering up his purchase. “I’m relieved that you counted them for me. I was worried that I had not paid you enough.”

Enough? “This is far more than I am charging,” she tried to say, but he waved his hand towards her.

“Nonsense. These are, by far, Brookshire’s finest produce. I will not pay any less than what they are worth.” With that, Aditha was silenced, bewildered at his words. When he was finished, he smiled again, and said, “Thank you.” With a nod, he turned down the road for home. Aditha swore that she could hear him humming, some foreign tune from a distant land.

That night, she took the forty gold coins home, and placed them together with the thirty from the month prior. Next month, she resolved, she would return the money. It was only right.

And so it continued for years. Every month, Old Winters would come, thank her for the last month’s purchase, then pay far too much for his next order. And every month, Aditha would swear she would refuse the money, and return what was not hers. But when the time came, she would become paralyzed, and would take the money without complaint.

One month, on the anticipated day of Old Winters’ coming into town, Aditha prepared her stall for the day’s sales. Strawberries and blueberries made up the bulk of her stall. Hidden beneath sat a small basket of oranges saved from the last crop. She knew the old man enjoyed them more than the other fruits, and had made sure to keep a few for his visit.

The people of Brookshire came and went, buying from her as they did. A few who knew what day it was gave her sympathetic glances, knowing that the Last Wizard would be interacting with her. But that was Aditha’s cross to bear, not theirs. She waved them off, told them not to worry. She’d be fine.

The day went on, and Aditha continued to work. Soon, whispers began to circulate, too distant from her to hear. At last, Mr. Longfellow came to her stall, hands in his fine suit pockets. “Good afternoon, Aditha.”

Aditha frowned. Afternoon already? “Good afternoon, Mayor Longfellow.”

The man picked up a blueberry, stuck it in his mouth. He smiled. “This is a fine crop. How much for them?” Aditha told him the price. The man pulled out his coinpurse, retrieved the amount, and handed it to her. “You must be relieved,” he added, as he picked up his carton of blueberries.

“Relieved?”

“That Old Winters isn’t coming to town today, of course.” He ate a few more blueberries, staining his fingers. “Didn’t anyone tell you?”

“No,” she replied. A cool wind seemed to blow through the stall. Mr. Longfellow shivered vigorously.

“Hm. Well, in any case, your worst customer won’t be coming today. That should make your month, I’d suppose. Good day.” He turned and left, leaving Aditha alone.

Not coming to town? For the last five years, Old Winters had come on schedule every day. What could be preventing him today? Would he come tomorrow? Aditha wasn’t sure what to do, or whether even to do anything. The rest of her day was spent in a fog of sorts, her mind drifting back to where the old man could be. As the sun set, she packed up what was left, including her basket of oranges, and headed for home.

Her house was empty, as it always was. Her siblings had long moved into homes of their own, leaving Aditha to inherit their parents’ home as mother’s passing. Much of it was empty, save for her bedroom. The small acreage surrounding it was filled with plants of every kind. First planted by her mother as a hobby, now they were her livelihood. By some miracle, they had remained healthy and fruitful ever since, despite Aditha’s lack of time to tend for them. Birds nested in her trees, providing her with eggs that didn’t require keeping animals.

She entered her home, bringing it the baskets from her wagon. She placed them in the living room, then, as she closed the door, she glanced at the oranges again. She sighed. It had been a long day, and yet Aditha knew what she had to do. She moved the oranges into a manageable bag, put on a warmer coat, and started down the road towards the home of Old Winters.

Nobody asked what she was doing as she went down the road. That was probably for the best; Aditha wasn’t sure she could have given them a good answer. She could hardly believe what she was doing. And yet, by the time she was truly doubting her decision, there say Old Winters’ house before her.

The sky had grown dark, evening setting in over the landscape. Fireflies began to dance in the grass, and the sounds of owls echoed in the nearby trees. Aditha took a deep breath, and stepped up to the door. As she reached for the door handle, she froze, waiting. No thunder. No stiff breeze. She grabbed the handle. Still nothing. Taking another breath, she turned the handle, and the door swung open, shrieking as it did. Aditha jumped, but, still standing, she called into the dark house, “Hello? Old Winters?”

A rasping cough came from inside the house. “Who’s there?” a voice much weaker than Old Winters’ asked from somewhere inside.

“Aditha, from the market.” When he didn’t respond, she added, “I brought you oranges.”

The man half laughed, half coughed. “Well, bring them in.” One tentative step after another, Aditha walked into the house. “I’m in the bedroom.” She followed the voice, and there found the old man. His leather jacket hung on a nearby hook, his staff leaning against the bedframe. Blankets covered him from head to toe, but Aditha knew he didn’t look well.

“What’s the matter?” she asked, not sure what to say.

Old Winters smiled. “I’m dying,” he said simply. “That’s all. No need to panic.”

Dying? “Are you in pain? Is there anything I can do?”

The man closed his eyes. “No, no pain. I’m just tired, that’s all. So very tired.”

Aditha moved to his bed. Kneeling beside him, she watched his chest move up and down in rhythm. He opened his eyes, looking to her in surprise. Calmly, he asked, “Is something wrong?”

Flustered, Aditha tried to express a series of thoughts at once. Yes, you’re dying, of course something is wrong! Why didn’t you tell me? Is there anything you need? Do you want me to peel an orange? How could you be dying?

Over the flurry of words, Old Winters rose his wrinkled hand, placing it over Aditha’s. “Slow down,” he said, his voice filled with peace. “I may be dying, but not in the next five minutes.” Aditha started to apologize, but he cut her off again, “Please, don’t worry. How about we share an orange.”

A pair of oranges were produced from the basket. Aditha pealed them in silence, tears welling in her eyes. Old Winters pulled himself into a sitting position, then she handed him one of the oranges. They ate together in silence. The moment felt strange to Aditha. Trying to take her mind off the situation at hand, she looked around at the room. “This isn’t what I imagined your room looking like,” she commented.

The room was plain, with smooth wooden walls. A small painting adorned one of the walls, a window looked out over the side yard from another. Old Winters smiled. “What did you expect? Rows of ancient books, filled with the spellcraft of ages? Dust-ridden vials of forbidden potions?” When she didn’t respond, he chuckled. “I suppose I didn’t host that many guests in my time here.”

The silence took hold again. When Aditha finished her orange, she looked back on the man. The man whom everyone despised, avoided, ignored. Whom the entire town wished would just disappear. And now he was. But why? What had he ever done to deserve such treatment?

As Old Winters finished his own orange, Aditha blurted her thoughts, “Why does everyone dislike you?” She blushed the moment the words left her mouth, but there they were; no way to get them back now.

The old man’s eyes stared at her, filled to overflowing with emotion. He closed them, tears dripping down his face in silent sorrow. At last, he opened them again, and said, “Let me tell you a story about a young boy with wild ambitions.”

Day after day, Aditha came to visit Old Winters, and every visit Old Winters shared another part of his life. How he grew up in a faraway city, and learned the ways of the wizards from another of its order. His ascendance in the order, learning ancient secrets about the world known only to the most wise in the land. Many of the secrets he told her as well, the hidden ways of the world, now known only to him. And then the darkness that came after a scant few of them were revealed to men seeking power above all else.

The wars, oh the wars! The devastation they caused to the land, and crippled the order of wizards to the point of no return. Then, the rebuilding, when the wizards were shunned and forced into hiding, until only Old Winters was left. How bitterly alone he had been for the past decades, and the joy he found in his friendship with Aditha over apples and oranges.

But it could not last forever. One day, Aditha came by, and Old Winters could not sit upright, nor share in the meal she had prepared. He grabbed Aditha’s hands, and said, “I need you to do something for me when I’m gone.”

Aditha hesitated, but nodded. What was he going to ask? Old Winters explained his request. Tears welled up in his fading eyes, mirrored in Aditha’s. “Of course I will,” she said simply.

Old Winters nodded. “Thank you,” he said. He closed his eyes one last time. Aditha waiting in the silence, watching the wizard breath slower and slower, until he breathed no more. He hands dropped from hers, their energy spent. As his hands fell, so did Aditha’s tears, and she wept.

No one saw Aditha for some time afterwards. Mr. Longfellow began to spread the rumor that she had been possessed as Old Winter’s body withered, and he had fled within her body so as to not be discovered. Others thought she had been killed as some last sacrifice by the wizard, in an attempt to stay alive. The police chief found no evidence of either explanation; only a basket filled with oranges sat next to Old Winters’ bed. Curiously, his staff had gone missing, as had his leather coat.

Weeks turned into months, and at last Aditha returned. She still wore the old leather coat, borrowed for her long journey. Mr. Longfellow nearly had a heart attack when he saw her walking calmly down the highway into the city. “My dear, where have you been? We thought the worst had happened to you!”

Aditha smiled, in a way Mr. Longfellow thought was far too similar to that of Old Winters. “I’m fine,” she said, extending her arms outward. “There was something I had to do for Old Winters.”

Mr. Longfellow humphed. “The old wizard? He’s dead, you know.”

Aditha nodded. “I know.” Before he could ask again, she moved past the mayor, until she reached her house. Whispers of the townsfolk followed her, amazed at her presence.

She strolled through her gardens, admiring anew the plants that grew there. Fruits and vegetables of every kind, planted by the loving hands of her mother, continued to grow, despite her absence. She brushed a hand against the oldest of the apple trees, feeling the rough bark beneath her fingertips. It dawned on her, in that moment, how much Old Winters had cared about the town, even when the townsfolk didn’t care at all for him. How much more had he done for them that they would never know?

She closed her eyes. “Thank you,” she said, wishing that she had spoken those words years ago. When they could have warmed an old man’s heart. How could she repay him for all this now?

A bluebird landed softly on her shoulder, its cry a soft whistle in her ear. Aditha started at the suddenness of it, but the bird remained in its place, as if waiting for something. Smiling, Aditha reached into the pocket of the old jacket, and withdrew a small number of seeds. The bird jumped to her arm, ate the seeds from her palm, then flew back into the branches of the tree.

She never told anyone of her journey, or what she did. When asked, all she would say is that she had to do something for the old, mad wizard (as they saw it). As the years went by, and his memory was forgotten, Aditha never forgot. She began to stroll through Brookshire more often, and could be seen feeding seeds to the birds. Nobody asked why she did it; they knew she wouldn’t answer. Over time, rumors began to spread that she had become a witch. Nobody asked about that, either.

Yet no one could ever explain how her garden remained so fruitful when she spent so little time in it.

A Song Unsung

Sat, 01 Sep 2018 00:00:00 GMT

What do you call a song not sung?

What do you call the breeze not felt?
The rain that never fell?
The ocean waves that never crashed against a lonely beach?

What do you call that which has never come to pass,
Or never can?
What do you call that which cannot be named
Because it never was?

Swirling and circling around us, day by day,
Worlds without end vanish and decay
Like a drop of water in the sea.

Did they know they even existed?
That they mattered?
When the future dies, does it know?
Or is its passing soft and silent,
Shrouded and forgotten to even itself?

What do you call a joy not felt?
A tear not shed?
A moment never shared?

What do you call these things?

It Was Meant To Last Forever

Mon, 08 Jan 2018 00:00:00 GMT

The sun rose brilliant in the sky that first morning, its rays bursting through the clouds in all of nature’s glory. The room was still, brimming with boxed potential, with room for curious imaginations to roam free. Outside the blurry windows stood a slice of paradise amidst the bleak cityscape, green pastures sheltered from bitter cement.

One thought fills my essence – I want to stay here forever.

Of course, it can never truly be mine. The room, the pastures, all of it was beyond possession. And yet I had been graced by fate, and was allowed to stay here. As the sun rose and fell, and the Earth moved along its course, the potential of that small room was unleashed, filling our lives with joy and sorrow. But as clear as the first revelation, came the second – It is not right.

It has been said, what if everything you ever wanted isn’t what you actually want? For in this place, everything was ours – friends, family, safety. Home. A place in this world for ourselves, a place of peace from the troubles beyond. And yet, the words came again – It is not right.

In the blink of an eye, the sun rose again, but its rays seemed hollow, its warmth a trick of the mind. The potential of those early days, long-spent it seemed, spoke of another place, far away, where we now belonged. The winds shifted, our course irrevocably altered, fate demanding its due.

Within the week, our course will pull us away from paradise, into the mists of uncertainty and fear, granting only a promise of hope to come. As the view fades, and the island of joy and sorrow recedes, one thought fills my essence anew –

It was meant to last forever.

Lindsay Wardell

An Hour Before Showtime

Keep Learning

ParentShield: A Mindful Communication App

Don't Replace Yourself With AI

Abdicating thought

In your own words

Moments and Moonlight

Rekindling

No Words

Grief Is Not A Casual Thing

To the Past

Divorce

A Mistake

When You Dream

The Life

Once

At the End

2022 In Review

Past Expectations

Major Events

Transition Progress

Transportation Woes

Conferences, Streams, and Podcasts

Travel & Adventures

Star Commander

Family Issues

Looking Forward

What Could I Say?

I Am Not Dead

Integrating Mastodon with Astro

Integrating to the Fediverse

Bringing the Fediverse Home

Conclusion

Between Hope

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

2021 In Review

New Beginnings

Blogging, Podcasting and Presenting

Working with Wikimedia

Work From Home

A Chance Encounter

A Functional Start

Into 2022, we go!

Setting up an Elm project in 2022

Elm (the language)

elm repl

elm init

elm reactor

elm install

elm make

Editor

Code Formatting

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`