It seems to be a trend: I'm back with an update much later than planned. But I haven't forgotten about this little project, and I have a small (yet also big?) update for you. Roughly two weeks ago, I pushed an update to the site that, aside from a minor style change, might have gone unnoticed. However, there's not a single line of code from the previous version of the site running today.
For the past few months, I've been planning this change. Oddly enough, this was after migrating my blog to AWS Lambda, making it entirely server-side rendered. You could argue that the previous version was better in some ways, it certainly was faster, though this version isn't exactly slow. But I wanted to do something special for Advent of Code this year, which required a hybrid rendering approach and a more dynamic site.
Without diving into too many details, I've rewritten the site in Leptos, replacing the previous Yew implementation. This change allows for a nearly-as-fast site while providing a more reactive experience.
Yew is a powerful web development tool, and I plan to keep using it. Getting it to work in a serverless context had its challenges, particularly when it came to hybrid rendering. While it is possible, I found the documentation for these features somewhat limited, which made it harder to implement the solution I wanted. That said, Yew is still evolving, and I look forward to seeing how it progresses.
So why Leptos? I'd been considering Dioxus for a while, but I came across this Reddit post from the creator of Leptos. Though it naturally had some bias, it highlighted issues I also had with Yew, particularly WASM binary sizes, which initially pushed me towards an SSR model. Plus, it promised better performance, and I was sold. In practice, I haven't seen massive performance gains, but Leptos has been a joy to work with. It reduces the boilerplate I was dealing with in Yew, and overall I've found it much more enjoyable.
I also switched from a Styled Components-derived library to Tailwind CSS to help decouple styling. I'm a bit torn about this decision. On one hand, it has sped up development significantly, but on the other, I'm not overly impressed. I may explore alternative solutions in the future, I do prefer the styled components approach. CSS remains the biggest impact on the site's performance since it's delivered separately from the HTML.
Looking ahead, I'll be moving on to other projects and topics, both related and unrelated to this site. This site will continue to evolve, but I also have a few new ideas brewing beyond it. Stay tuned!
Why make all these changes? Rebuild the site from scratch just to end up with a similar look and slightly slower performance? Well, I wanted something that could help demonstrate Advent of Code. I've been participating in AoC since 2019. For those unfamiliar, Advent of Code is a yearly programming challenge leading up to Christmas, a fantastic challenge for developers, whether you want to solve as many puzzles as possible or try a new language. I highly recommend giving it a shot. I started with Java but, for the past 2-3 years, I've been using Rust.
With Advent of Code 2024 just around the corner, I thought it would be fun to integrate my solutions directly into the site. With the old version, I could've set up APIs to process Advent input, but that brought up concerns about security and cost-effectiveness. The idea of Lambda functions getting stuck in loops for 15 minutes at scale wasn't appealing, and API Gateway limits of 30 seconds before a timeout didn't help. Sure, an asynchronous processing solution was possible, but I wanted something ready before December 1st.
And so, here we are: Ugvx Advent of Code. I've kicked things off with an implementation for Day One, parts one and two for 2023. This includes both a short write-up of my solution in Rust and, after each section, the ability to run that solution in your browser using WebAssembly. This also allows you to feed in your own AoC input without that data leaving your computer. (Though I may limit this on new write-ups to ensure fairness and avoid giving anyone an edge in the competition.) Lastly, it will be interesting to see how well this approach scales as solutions grow more complex and resource-intensive, but I'm excited to explore that challenge.
I'll continue working on the 2023 solutions as we approach December 1st. It's a great opportunity for me to get some Rust practice in, and a bit of writing practice too.