Start of something new
When Remix became freely available, I immediately jumped on the hype wagon and started learning it. I even started re-writing my website in it, because:
- I loved the concept of Remix: keep more aligned with the web platform itself,
- I wanted to focus on learning the framework itself (without another side project),
- I wanted to get rid of Next.js / Vercel (more on this later),
- …
- (and because as a professional procrastinator re-writing one’s website feels so productive - even if it isn’t)
Out of all those reasons, the frustration with Next.js was the thing that gave me the final push to start re-writing the site.
Next.js
When Next.js announced the app router, I didn’t feel excited, I felt like:
“I have to re-learn this framework that I already put hundreds of hours into… for what?”
Next.js to me felt amazing already. I didn’t understand why there is a need for this big shift.
I liked the idea of RSCs, but at that time they were not stable. Now the framework that I have used (and still use) for work and built so many apps with, wants me to use this in production? They weren’t forcing the migration of course, the pages router was still supported, but I still felt annoyed. So many big companies use Next.js for their production apps, I expected the framework to only release a new version when it was production ready…
I always knew web development is a field that changes rapidly. New libraries and frameworks come out every week. I have no issue with that, if and when better solutions came along I was happy to jump ship. However, the new way of doing things had to offer something, that would make me want to use it. I need to be sold on a new piece of software before I start using it. RSCs did not (and if I’m being honest, still don’t) really give me that “this is amazing, it improves my workflow so much” feeling.
Even if I found RSCs to drastically improve my workflow, there was still the other elephant in the room: having to re-learn something that I’ve already learned.
I still love Next.js, and I think it’s a great framework, however personally I wasn’t compelled to re-learn the framework. I thought, if I have to spend time doing that, I might as well pick up something new instead, that I actually am compelled to learn. Remix became free around this time, so naturally I was drawn to it.
Remix
When Remix came out, at first, I didn’t get the hype. Is this just another framework? How is this different to anything else that I’ve already learned and use? They were talking about something like “less spinners” and “the web platform” on their landing page, but I was satisfied with my current tooling (Vite + vanilla React, Gatsby, Next.js), and I didn’t “get it”.
Couple months go by, Remix becomes free to use, and Next.js starts pushing the app router and RSCs. I’m drawn to Remix again.
Something feels different this time. Something clicks.
I realised that this is a framework, that doesn’t try to re-invent the web. Rather, it tries to push existing web standards on developers. It isn’t so much different than what PHP or Ruby already did, it just puts some extra magic on top of them. It doesn’t feature SSG, like Gatsby, nor the SSG/SSR mixture, like Next.js. Rather it just used a regular, simple Node.js server for serving the website. It works everywhere Node.js works, and it works well (compared to Next.js, which heavily favors Vercel).
Remix is not revolutionary. Yet it feels like a fresh take on things. Why? Because as developers fiddling around with SPAs, JAMstack sites, APIs, SSG and SSR, we forgot simplicity is better than complexity. Using Remix after all this complex tooling just felt amazing. Using its API felt simple and natural, I did not have to read docs for hours to get it.
We went full circle. We used PHP, Ruby, Python etc. for serving our websites from the server. We got into adding more interactivity with jQuery, and then immediately got hooked when SPAs came along. We loved how simple it was creating interactive websites with React. We didn’t miss the server. But then its shortcomings re-surfaced. We got loads of loading spinners. SEO suffered (just to name a few). We came up with solutions to problems that wouldn’t have even existed if we didn’t switch to SPAs in the first place. We came up with SSG. Now we’re switching back to using tools like Next.js and Remix, that offer the benefits of the server while retaining the interactivity. So was this all even worth it? I’d say yes, and going full circle was necessary. It opened our eyes into realising that the best solution is neither using only the server, or using only the client, but rather to integrate them in a way that maximises potential.
Gatsby and Next.js appeared to solve the problem of relying too much on client vs. server. Remix appeared to re-think the web and integrate the best of both worlds.
So… is this site now using Remix?
TL;DR: No.
I didn’t lie in the introduction however. I did start re-writing this website using Remix, and I loved it. So why didn’t I end up shipping the new version with Remix?
While using Remix, I realised it has great potential, and that from now on wherever I write a complex web app, it’s probably taking the priority for me vs. Next. The problem? This website is not a “complex web app”. Remix’s tooling felt too much for something like this. I didn’t want to run a Node.js server for a blog. There is literally zero need for it. The content barely changes, and if it does, SSG works fine. As much as I love Remix, a good developer chooses their tools not based on emotion, but based on which tool is best for the given job. No matter how amazing a tool is, one shouldn’t just use it for every problem.
For a small website like this, god’s honest truth is that one doesn’t even need a framework. I could have just as well used vanilla HTML, CSS to build it.
Which is what I basically did.
Astro
To make the developer experience a little bit better though (mainly for templating), I used something called Astro.
Astro is technically a framework, and there is much to it, however what I love about it is how incremental it can be. I literally did not have to learn a single thing (besides how to create a new Astro app) in order to start working with it. Its .astro files are essentially .html files with extras. If you can write HTML, you can use Astro.
“The
.astroUI language is a superset of HTML: any valid HTML is valid Astro templating syntax! So, if you can write HTML, you can write Astro components!”
It’s selling point is that it’s simple and fast. Yes, it can be extended to support SSR (and many other things) via plugins, but on a core-level, it’s simple as hell.
It was designed in a way that makes it fast by default by shipping less (or even zero) JS. It uses the islands architecture that means whenever you need client side interactivity, you can plug in a client framework anywhere within your site (it supports React, Preact, Svelte, Vue, Solid etc., and you can even mix them!).
Next and Remix etc. are great, but they are often overkill. Astro was perfect use case for a small website like this, and I loved the developer experience. I will likely be using it again for projects where I don’t need all the power of JS.
I’m not sure who said this or where I saw it, but this quote sums up my experience perfectly:
“Don’t overcomplicate things unless sticking to your simpler solutions starts to feel painful.”
Thanks for reading my first blog post! I’m still very new to writing, so there might be “gaps” as I translate my thinking to words.
These blog posts are mainly written for myself so that I can improve my writing, but if some people find it and even just 1% of those find it useful, it accomplished more than I’ve ever wanted it to.
-
If you liked this post and would like to read new ones too, consider subscribing to my RSS feed.