Frontend.FYI

November 6th

Why I switched from Next.js to Astro for my course platform

Hey there!
​
This email comes with mixed feelings.
While it's centered around Next.js—a topic beyond just frontend—it's a nod to every engineer who's asked, "Is it just me?" when you hit a wall with bugs or stuff just not working right. Spoiler alert: it's not just you.

So, why the mixed feelings?

Firstly because I've been saying for weeks that I'm working hard on the course platform for Frontend.FYI PRO, but until two weeks ago I made one step forward and two steps backwards every week. And I feel bad about that. But you know what? Making estimations is very hard, especially if you have so many unknowns in your project. There's so many things that can work against you in that case.

Basing your decisions on promises rather than experiences

Which brings me to my second point. I love Next.js and Vercel, and I am super excited about their new app directory. So of course that was my solution for the course platform back in August. The Vercel team had very strong confidence in the app directory being production ready – according to them there are already lots of companies using it successfully in production. So who am I to doubt this – I committed.

Well.. Here we are, weeks later, and I've literally lost so much valuable time debugging vague issues in Next App directory with very little documentation, issues or attention from the Vercel team. This isn't because they don't care, but it is because the app directory isn't mature enough yet.

There is however one thing that bothers me the most: their promise about the app directory being stable. While it might be stable for simple apps, as soon as you are making more advanced apps you could run into issues where there's simply no solutions for yet. What are you gonna do then?

When you're building a company, and committing to using a certain tool based on promises out there, it could turn out to be very costly if you decided to make the jump. Exactly what happened to me.

What did I get stuck at with Next.js?

If Next.js details don't interest you, feel free to skip ahead.

After multiple encounters with obstacles, I questioned my choice but always found workarounds—until the inefficiencies piled too high. The last straw was the incompatibility between route groups in combination with parallel routes, a problem not mentioned in any documentation, only hinted at in a buried GitHub issue. It resulted in me making a frustrated Twitter thread about it, and a response from Tim Neutkens.

The cost of cutting-edge

Working with the latest technology sounds appealing. Especially with all these influencers (many who are bought by the companies who make the product..), sharing how great it is! You feel left behind if you don't try it!

But that bleeding edge has this name for a reason. It comes with a price you have to pay. And I paid it big time – with weeks of my valuable time getting lost. Time I couldn't spend on building that course for you!

So when someone is promoting a certain tool next time (or me raving about Astro in a second!), don't jump on it immediately. Let it mature, let it proof itself. New and shiny tools sound cool, but come with quite some issues in the beginning. Issues that often aren't highlighted enough when you make the decision to start using it. On top of that – if there's a company behind it making money, expect them to show the product from it's best side. Leaving out some nuances.

So then I decided to switch to Remix...I mean Astro..

So when I finally flipped that table hard enough, I decided I had to switch. But to what? My first instinct was Remix. I like their approach of sticking to standards on the web, and it seems to do everything I wanted. So I dove into it and starting building the platform – again.

It didn't take long till I ran into quite some complex code to configure my MDX files and read them from disk in the way I wanted. Perhaps it's the little experience I have with Remix making my code overly complicated (I looked at Kent's website as an example) – but I quickly got the same feeling I got with Next.js. It felt like if I went into this rabbit hole now, I might again end up with a lot of lost time with debugging and Googling for solutions. Time I couldn't afford to lose yet again.

So despite Remix being a great product (just like Next.js!), it still felt too risky for me. Which is when I started to play around with Astro. A framework mainly focussed on building static (content) sites. It didn't take long for me to see it could do so much more than that. After I made a small POC I also realised that everything felt so 'simple', so effortless to achieve.

The main reason I looked at Astro is because a static content based site is for 90% what my course platform is. Perhaps that's even 90% what you guys are building out there too! And adding things like paywall, authenticated content, api routes all was possible with pretty little effort too. It felt like it brought the good parts of Next.js, without the complicated overhead.

Often this simplicity might mean it's not capable enough. But when trying to add the paywall, user accounts / user data, reading MDX files from disk — everything just worked. It felt refreshing.

So eventually I decided to take this jump again. Take ANOTHER risk. Not a risk because Astro isn't stable either, but because it's new to me. However, by making a small proof of concept having all the features instead of starting to build without knowing all of it's capabilities, I have a very good feeling about the framework. And you know what, in the past two weeks I finally made a lot of progress! I couldn't be more happy to finally see things come together.

So should you all switch to Astro now?

Not necessarily. It's an option worth considering, depending on your needs. My advice and main takeaways:

1. Don't believe all promises you see on the internet. A lot of 'tech influencers' are paid by companies in one way or another to promote their product.
2. Don't jump on something new immediately if you can't afford to lose time with debugging, or eventually needing to redo everything with a different solution. Take calculated risks.
3. Making correct estimations is nearly impossible if you're gonna use new tools. Even if you think it works in a certain way, often it does not.
4. It doesn't matter how much experience you have. You will always make mistakes – that's how you learn and grow.
5. Don't decide on using any tool based on hype. Experiment with it first, and only then decide to adopt certain technologies. We all like shiny new things, but they come with a cost if we won't use them responsibly.

​

So what about that Framer Motion course I'm building? The shift to Astro means I'm behind on the Framer Motion course, but progress is back on track. The release won't be all at once, but module by module. Keep an eye out for updates or follow me on Twitter where I share progress videos like this!​ The goal is to release (most of) the course before the end of the year. And it's worth the wait! Curious about the course? Check out the landing page for a sneak peek— it's looking soooo good! ​ Check the course landing page

Less hype, more results

The frenzy around the latest frameworks can make you feel left out. Yet, skipping the early adopter phase spares you the headaches. Let others test the waters; stick with proven technologies that serve you well. While avoiding the hype may not always be popular, it's a strategy for long-term success.

That's why me sending an email around this topic is quite unique. I try to stay away from teaching hype as much as possible, but rather try to teach you generic real world practices. I don't like to play the hype game. Perhaps that makes my content less popular, but in the long run that's the smartest move I think! It's what will get you the job you desire.

​

Thank you for reading, and I hope this insight aids your tech decisions in some way.

— Jeroen.

Follow me on Twitter or subscribe on Youtube.
And don't forget to check out PRO while it's stil €99 (one time purchase, lifetime new content)!

Hi, I'm Jeroen After over a decade of writing frontend code and teaching my colleagues, I decided it was time to teach a wider audience the craft in frontend engineering. Which is when I started Frontend.FYI.