Domain Name Change + Upgrading to Astro

The secret of change is to focus all of your energy not on fighting the old, but on building the new.

I decided to change the name of my site from abhisheikhgill.com to agill.io. The reason is simple, less characters to type and while I’m proud of my name, it’s not the easiest to spell. Since I was making some changes to my site, I figured it’d be a good time to see what’s new in the front-end ecosystem. The last time I updated my site was almost two years ago when I moved from Next.js to SvelteKit.

The digital landscape is ever-evolving, and so are the tools we use to build within it. Using SvelteKit for my personal projects used to be a joy. I was attracted to it by its concise syntax, component-based architecture, and the Svelte compiler’s magic, making code simpler. My journey with SvelteKit was fruitful, empowering me to construct applications with minimized payloads and faster user experiences. However, as my appreciation for JavaScript has grown and my understanding of web development has deepened, I started seeking a framework that aligned more closely with plain old vanilla JavaScript. This led me on a quest.

Searching For The Right Tool

It sometimes feels like a running gag we’re all in on when it comes to new JavaScript frameworks coming out every week. And while these rapid developments aren’t appreciated by everyone, I think it’s a great thing. We get more innovation and choice. And eventually someone will come along and synthesize the best of all these tools and we’ll all prosper because of it. One such attempt at doing that is Svelte.

What initially led me to Svelte was all my frustrations with React—many genuine but some perceived, influenced by anti-React sentiment online. There are many fair criticisms of React, such as how easy it is to write suboptimal code and the numerous dependencies required for a functioning app. But these issues do not preclude the possibility of writing clean, scalable, and high-quality React code. Since React is a library rather than a framework, there is no prescribed way of doing things. This flexibility often results in significantly different styles of React code across codebases and even within a single codebase between multiple authors.

While I was dealing with real frustrations using React and researching best practices, I’d often find online content “heavily critiquing” (putting it nicely) React. Some of these critiques are on issues like state management, integrating large number of 3rd party libraries, boilerplate code, and a lack of defined best practices. Svelte claimed to have solved a lot of these issues, especially issues around state management and boilerplate code. So I gave it a shot. One thing I initially enjoyed about Svelte was its terse code. Take a look at this example of a Counter component in Svelte compared to its React equivalent.

//Svelte
<script>
  let count = 0;
  const handleClick = () => count += 1;
</script>

<button on:click={handleClick}>
  Clicked {count} {count === 1 ? 'time' : 'times'}
</button>

//React
import React, { useState, useEffect } from "react";

function Counter() {
  const [count, setCount] = useState(0);
  return (
    <button onClick={() => setCount(count + 1)}>
      Clicked {count} {count === 1 ? "time" : "times"}
    </button>
  );
}

They don’t look too different at first besides the Svelte version using less characters but what you’ll notice is that the reactivity of the count variable in Svelte is inferred whereas in React it is explicit. While it’s nice that the Svelte version of the component contains less overhead I’ve come to appreciate the declarative nature of React. I also don’t like the way Svelte has deviated away from the JavaScript and HTML specifications. For example, using on:click instead of onClick might seem trivial, but it matters for consistency with traditional HTML. In this regard React is closer to the HTML specification.

The creator of Svelte, Rich Harris, confirms my experience here in this post, where he clarifies Svelte’s nature:

I’ve been deceiving you all. I had you believe that Svelte was a UI framework — unlike React and Vue etc, because it shifts work out of the client and into the compiler, but a framework nonetheless. But that’s not exactly accurate. In my defense, I didn’t realise it myself until very recently. But with Svelte 3 around the corner, it’s time to come clean about what Svelte really is. Svelte is a language. Specifically, Svelte is an attempt to answer a question that many people have asked, and a few have answered: what would it look like if we had a language for describing reactive user interfaces?

Sure the React version of the Counter might have more characters and lines of code but it is easy to reason about the code. Unfortunately the story is different under the hood (isn’t it always?). The thing that made me second guess React is the VDOM and all of its abstractions. As a project begins to grow in size and complexity, state management often becomes difficult without 3rd party state management libraries and strict coding standards.

This brings me to Solid.js which eliminates the VDOM altogether offering superior state management solutions to React. State changes are reconciled at a granular level improving rendering performance, putting Solid.js not too far behind using vanilla JavaScript on the web. Since Solid.js uses JSX writing Solid code should be straightforward for React developers. Take a look at the Solid implementation of the Counter component.

//Solid
import { createSignal } from "solid-js";

function Counter() {
  const [count, setCount] = createSignal(0);

  return (
    <button onClick={() => setCount(count() + 1)}>
      Clicked {count()} {count() === 1 ? "time" : "times"}
    </button>
  );
}

The above code looks almost identical to the React version minus the fact Solid is using signals, which is a powerful out of the box solution for managing state. The only problem for me is Solid.js’ framework SolidStart is not in v1 yet so there will still be breaking changes. I want my future projects to be able to use Solid.js while still being able to server side render or statically generate web pages where needed. This is when my search led me to Astro.

Why I Chose Astro

Astro emerged as an ideal solution in my search. It promised a blend of modern development practices with a lean approach to delivering content. Here are the key factors that influenced my decision:

• Native JavaScript Support: Astro embraces regular JavaScript, allowing developers to use it out-of-the-box. This was a significant draw for me, as it meant fewer deviations from the JavaScript standards I’ve become accustomed to.
• Flexibility with Reactivity: Astro’s architecture doesn’t lock you into a specific way of handling reactivity. Instead, it provides the freedom to integrate libraries like Solid.js, React, or Angular.
• Optimized for Performance: Built with performance at its core, Astro allows for partial hydration and static site generation, ensuring that users receive the fastest possible load times without unnecessary JavaScript.
• Excellent Content Management: Astro comes out of the box with utilities to easily manage content stored locally or within a CMS.
• Islands Architecture: Astro allows us to run multiple UI frameworks on the same page while sharing state.

The integration of Solid.js within Astro projects was a game-changer for me. Solid.js’s philosophy of compiling away the framework and offering a reactivity model that leverages the JavaScript language itself resonates with my goals of efficiency and simplicity. Most people who are comfortable with React will find Solid.js a breeze to pick up, although you’ll probably have to unlearn some unnecessary patterns like relying on effects to synchronize server state with the client.

This strategic choice means I can develop interactive components only where necessary, relying on standard JavaScript for the majority of my application logic. The result? A more performant, maintainable, and straightforward development process.

I find that most of my pages end up being .astro files while certain features for a project like a contact section will use Solid.js. It’s nice to be able to use Solid to manage state but not have to worry about writing JSX in all of the other files. Now that’s what I call freedom.

Astro Performance Insights

Transitioning from SvelteKit to Astro has significantly reduced the payload size delivered to the client—from 45kb to just 14kb on the main page—while maintaining the same features.

This shift has not only streamlined my development workflow but also dramatically improved my application’s performance metrics. The ability to ship less JavaScript and only hydrate components that need interactivity means that users enjoy faster initial load times and a smoother overall experience. Moreover, Astro’s out-of-the-box support for features like image optimization and lazy-loading makes it even easier to delivered highly optimized apps.

If you’re curious you can see v1 of my site here, built with Next.js, and v2 of my site here, built with SvelteKit.

Final Thoughts

Reflecting on my journey from SvelteKit to Astro, I’m invigorated by the possibilities that Astro opens up for developers. Its commitment to leveraging the best parts of JavaScript, combined with the flexibility to incorporate libraries like Solid.js, makes it an outstanding choice for modern web development projects. The transition has been an enlightening experience, reminding me of the importance of adaptability and the continuous search for better tools in our ever-evolving digital landscape.

Things are always changing in this rapidly evolving field. It’s best to evaluate tools yourself rather than reading too much into the hype. Today, despite its flaws, I see React as an amazing library that can build products worth billions with one caveat, the large learning curve. The stark contrast between well-architected React code and the duct-taped codebases demonstrates why opinions on React are so polarized. And while I would not use Svelte again for future projects (thanks Solid.js!), I appreciate what it offers and brings to the JavaScript ecosystem.

To those contemplating a similar shift or exploring new frameworks, I encourage you to consider Astro and Solid.js. The blend of performance, flexibility, and developer experience might be the change you’re looking for to elevate your projects to new heights. I find it refreshing to be able to get more done while requiring less tools, saves me time and lets me focus on creating value with my code.