DEV Community: Ethan Hawksley

The Shipwrecked Hackathon by Hack Club

Ethan Hawksley — Tue, 23 Jun 2026 08:59:59 +0000

Last April, I was minding my own business when I received a curious email in my inbox.

Hack Club is renting an island.

We are hosting a hackathon.

Anyone who ships 4 projects gets to come. Flight stipends available!

Dates are August 8th - 11th. Boston, USA.

I'd signed up for Hack Club mailing lists in the past since they run a variety of coding activities. However, this email particularly stood out to me. I've always wanted to visit America, and it seemed like they would be offering me a free flight!

Following the link led me to a sign-up page where I entered my details to register my interest. I spread the word about this event to the other coders I knew, and soon it reached the 5,000-signup threshold to be given the green light.

Hack Club is a non-profit organisation that has received some generous donations in the past, but they still can't afford to give away such a great trip for free. To earn my place at the event, I needed to pass The Bay.

The Bay

The Bay was an online platform designed by Hack Club specifically for this event. You tracked your time spent coding projects with their WakaTime server Hackatime and submitted any completed projects for review by the Shipwrecked moderators.

Approved projects granted you a number of "shells" relative to how many hours were spent creating the project. These shells could be spent on many different items from their shop, from Flipper Zeros to 3D printers. However, the grand prize was a ticket for the Shipwrecked hackathon in Boston. This cost the small sum of 60 hours total. Travel stipends were also available, at a conversion rate of 1 hour coding → $10 grant towards a flight.

After checking Skyscanner to see return flights would charge an entire £400 (~$550), I checked the clauses for Shipwrecked and saw that if I programmed for 100 hours total, they would fully cover my flight regardless of how expensive.

Now I had the 100-hour goal in mind, it was time to start programming.

Some Notable Projects

Gravify

I had found an interesting library called html-to-image that could convert DOM elements into images I could manipulate with JavaScript. While that library was sitting in the back of my mind, I stumbled across the Matter.js physics simulation library. The library supported custom PNGs as input to the physics simulation, so I decided to combine these two libraries and recreate something very similar to Google Gravity.

Going through the MDN Web Docs to learn how to build a browser extension was far smoother than I had expected. I was comfortable writing JavaScript, and not much boilerplate was required to hook into the Browser APIs. After not too long, Gravify was created.

Turing Machine Simulator

After visits to Bletchley Park and diving into more theoretical computer science, I knew I wanted to build a Turing machine.

Turing machines are a model for computing first devised by Alan Turing in 1936. They consist of an infinite roll of tape marked out into squares, a "head" that points to a single square at a time, and a set of states and instructions. Each cycle, the Turing machine reads the value of the tape underneath itself, compares it to the corresponding instruction, writes a new symbol onto the tape, and finally either moves left or right along the tape.

Despite their limited nature, they can provably carry out any calculation and are often used for proving new theorems in computer science. I did some research and couldn't find a simulator online that I was content with using, so I built my own.

I was still studying a React course at the time, so I wasn't fully confident building UI with JSX components. This led to a lot of repetitive code.

const rightOption = document.createElement('option');
rightOption.value = 'Right';
rightOption.textContent = 'Right';
// ...

Looking back at it, it is quite brittle and challenging to debug, but I can thank my understanding of JavaScript fundamentals for framework-less code like this.

Reaching America

As soon as I got the official go-ahead from the organisers, I booked a flight ready to set off for Boston.

Coming alongside me were two friends who also qualified for the event. They had put in the hours to earn tickets, and we all came over together.

The flight took a long eight hours, but after not too long we finally reached America.

Once we arrived at the airport, we set off to EDIC Pier where we laid our picnic blankets and bought some local food. I got to know the other contestants who were there. Many were American, but surprising numbers were from all across the globe, with one even as far as Vietnam!

It didn't take long until we began to set off towards Cathleen Stone Island. The ride was short but a great opportunity to chat with the other people there and take some photos. By the time we finally reached the island, we had already decided on the structure of our teams.

Everyone scrambled to claim their beds, but as one of my projects had gone viral, I was given first pick and stayed in the executive suite with the other viral programmers. It was here that I met Daniel, another participant who managed to go viral, and formed a team with him and Oliver.

By the end of the day, we were all invited down to the pavilion to learn about the first project we would be assigned. This hackathon had three projects that we would make in total, each themed around a certain idea. The first project was to design a method of communication that wouldn't involve letters or numbers.

SymbolNotes

In my team, we decided to create an online peer-to-peer messaging app. Since I had prior experience with the PeerJS library, I suggested that we use that.

As per hackathon tradition, the code we made was hacky, and the graphics were rough, but we managed to create a working solution. We released the source code for SymbolNotes onto GitHub so others could examine and learn from it. We made it together over the course of a morning and submitted it onto The Bay.

Exploring The Island

With our project complete, we spent the rest of the day exploring the island as a team. The executive suite and pavilion were both very close to the docks, but there was the entire rest of the island still to investigate.

Alongside us were some Americans who knew the area much better than we did and told plenty of stories about what it was like living in America. As somebody who'd only set foot outside Europe once before, it was very refreshing to hear such different perspectives.

Before long, however, it was back to the next challenge.

Connect Infinity

Our next challenge was to design a creative game that could be played online. We decided to put a spin on the classic game Connect 4 and make it real-time. To prevent it from ending extremely quickly, the game only ends once the entire board is full. Every 4-in-a-row gives a point, most points win.

Now the team had got used to PeerJS, we decided to use it once again here as it seemed perfectly suited for the task. As a challenge, we designed the code so that lobbies of unlimited size were supported, instead of just groups of two.

This took more time than the previous project due to its larger scope, but we worked as a team much more efficiently. After a few tireless hours, Connect Infinity was created just in time to present.

We took laptops down to the pavilion and set them up running the game by the shore. The other participants all tried out the game, and it was surprisingly well received! We managed to win a limited-edition Shipwrecked shirt, which I still have and wear to this day.

Perlin Colours

Our final task was to create a project that heavily featured a variety of colours. One of our team had the idea to create a Perlin noise generator that could create plenty of colourful gradients. We decided to name it Perlin Colours.

After some research on the formulas involved and a fair bit of trial and error, we ended up with a functioning noise generator implemented with HTML Canvas. I had dabbled with Canvas before, but this was the first time I had implemented a proper renderer using it.

We ended up sleeping on the problem, but once we woke up, we were fully refreshed and fixed the final bugs with the implementation. It was very satisfying to have a proper end product.

The project was presented, and it went down a treat! The prizes were limited-edition laptop stickers that I have proudly stuck onto my laptop ever since.

Returning Home

Alas, all good things must come to an end. It was the final day, so I gathered all my belongings and packed them away into a suitcase. My team attended the closing ceremony and said our goodbyes to the people there. There were so many nice people I met, and I'll cherish the memories made forever.

I caught an Uber alongside some others also needing a flight back and returned to the airport. It was there our team finally disbanded. One amusing thing at the airport was the Hack Club official plushies were just over the weight limit and were tripping all the security alarms. I got through just fine, but it caused a right mess!

It was then I also got to see my very first American passport. Having only seen European ones, it was a right culture shock with pages full of landmarks and a giant eagle on the photo page.

The actual flight was thankfully uneventful. I watched the in-flight entertainment and ate the food, but slowly drifted off to sleep until we landed.

Reflections

Participating in Shipwrecked is an experience I'll remember forever, and I thank Hack Club and the organisers for helping set up such a wonderful event. I have still maintained contact with several of the other people there and arrange to meet up with them at future hackathons.

It was also very enjoyable working in teams. Having spent so much of my time programming solo, it was nice bouncing ideas back and forth to come to informed conclusions.

I've done many other things with Hack Club since, but they are perhaps a story for another blog post...

One thing you can take for granted is that I'll absolutely be doing more hackathons in the future!

Building An Astro Blog

Ethan Hawksley — Thu, 11 Jun 2026 18:39:35 +0000

This article was originally published on hawksley.dev.

I've owned the domain name hawksley.dev for a while now, but I've never done much with it aside from sending email. Over the weekend, I thought I might as well make good use of it and decided to create a blog.

In the beginning, this site had a humble home page with some links to GitHub projects. A blog requires much more infrastructure for me to use it effectively. For one, it'd be great if I could just write my posts in Markdown and have them formatted by my project automatically. Having a look at the options available, the first that stood out was GitHub's Jekyll. It looked nice and had great integration with GitHub Pages, which I'm hosting with at the time of writing. However, it just felt too rigid. I needed something modern that I felt I could get my hands dirty with.

Enter Astro.

Why Astro

In the grand scheme of things, the Astro framework is pretty new at just 5 years old. That hasn't prevented it from gaining popularity rapidly. It holds performance as a key design principle, anything that can be static will render statically. By default, it ships absolutely no JS to the browser, which felt perfect for my use case. I have no need for advertising or heavy tracking scripts weighing down my site. All I need is a place to write.

Learning how to work with Astro was completely painless. I created a new GitHub repository and followed along with their very high-quality documentation to create a blog of my own. At the very end of it, I’d created a nice neat blog that loaded instantly and was easy to write for.

I wasn't satisfied by using the tutorial's blog for my site, though, as it felt too cookie-cutter, and so I started again, now with confidence in the framework.

The Design Decisions

There were some definite design decisions I knew I wanted from the get-go. First-class light mode and dark mode support were a must. Plenty of blogs offered just one or the other, and after a bit of digging, it didn't seem technically hard to implement at all.

Another key principle was mobile-first design. Many of my previous projects started with the key assumption that the reader will be on a laptop or desktop, but that often isn't the case. Mobile devices account for approximately two-thirds of global internet traffic, with the remaining third coming from desktops. I wanted this site to stand the test of time until I inevitably rebuild it again, so it's only natural I designed it with mobile devices in mind.

My final decision I knew I wanted was to have excellent performance scores, one of the very reasons that I chose Astro for the job. Components are almost a certainty in modern web design to ensure consistency across pages, but I needed to write components used at compile time, rather than at run time.

Actually Programming the Site

After creating an experimental fork of my main repository and wiping the directory, I initialised a new blank Astro project with pnpm create astro@latest and scaffolded the directory structure I'd need.

public // Assets such as robots.txt and favicons.
src
  assets // Any assets displayed in the actual site.
  components // Reusable components representing sections of UI.
  content // Markdown files representing the blog.
  layouts // The base layout each page uses.
  pages // The actual pages rendered, combining all parts together.

Development went very smoothly over two days and 15 full hours, with only some minor hiccups along the way.

Google's PageSpeed Insights flagged my planned accent colour International Orange #FF4F00 as having insufficient contrast in light mode, so I had to split into separate accents for light and dark mode. By using global CSS variables that change depending on the theme, I implemented this change painlessly.

I also encountered some CLS issues surrounding my choice of font. I personally love the look of the Inter font and included it in my project¹. However, although 300 KiB may not sound like a lot, on a slow connection it’s a noticeable delay. After some research I discovered the fontTools library and managed to shrink the Inter font to 70 KiB by subsetting the font to only the character sets I need.

The Conclusion

Astro has been a pleasure to work with, and I can easily see myself using it in future projects now I've adjusted to it.

A perfect score has got to be one of the most satisfying feelings after doing a site redesign.

I'm now using IBM Plex Sans and IBM Plex Mono, but they are subsetted to 62KiB and 9KiB respectively, so the advice still holds. ↩