Why we chose Astro over SvelteKit for our hosting comparison platform

Published: (February 23, 2026 at 04:00 PM EST)
7 min read
Source: Dev.to

Source: Dev.to

Why We Chose Astro Over SvelteKit for Our Hosting Comparison Platform

We’re building HostingSift, a platform for comparing hosting providers side‑by‑side—pricing tables, feature breakdowns, filters, user reviews, and more. When we started, we faced one pivotal decision: SvelteKit or Astro?
We went with Astro. Here’s why.

The Project Context

  • Content‑heavy site: 23+ hosting provider profiles, each with multiple plans, pricing tiers, feature specs, and user reviews.
  • Additional pages: comparison pages, category listings, a recommendation quiz, and a blog.
  • Interactive parts: filtering plans by billing period, toggling comparison tables, authentication flows, review forms.

Most of what users see is static content that doesn’t need JavaScript to render. This ratio shaped everything that followed.

Our Love for Svelte

  • Svelte 5’s reactivity model (runes) is elegant.
  • The developer experience is fantastic.
  • SvelteKit is mature, full‑featured, with file‑based routing, SSR, API endpoints, and form actions.

So why not just use it?

The Core Difference

FeatureSvelteKitAstro
Default behaviorAssumes every page is interactive; ships a JS bundle to hydrate each route.Zero client‑side JavaScript by default; pages render as static HTML until you opt‑in.
PrerenderingServer‑rendered by default; you opt‑in to prerender per route.Prerendered at build time by default; you opt‑in to server‑render when needed.
Hydration modelWhole page is a single hydration unit.“Islands” – individual components hydrate independently.

This isn’t a subtle difference; it changes how you think about building pages.

How Astro Works for Us

We compose pages from .astro components (static HTML, zero JS) and Svelte components (interactive, with JS). The Svelte components become islands that hydrate independently, while the rest of the page is pure HTML that the browser renders immediately.

Example: Hosting Profile Page

---
// Import static and interactive components
import Layout from '../../layouts/Layout.astro';
import PlanCard from '../../components/PlanCard.svelte';
import ReviewSection from '../../components/ReviewSection.svelte';
import SpecsTable from '../../components/SpecsTable.astro';

// Fetch data on the server
const { hosting, plans } = await fetchHostingData(slug);
---

## {hosting.name}

{hosting.description}
  • Each island hydrates on its own. If one fails, the rest of the page still works.
  • Static parts (layout, description, specs table, SEO metadata) ship no JavaScript.

Pragmatic Decisions

  • Static pages (homepage, category pages, legal pages, blog posts) are prerendered as plain HTML files—fast, cacheable, no server compute per request.
  • Pages needing fresh data (hosting profiles with live pricing, filtered listings) are marked as server‑rendered. The intent is explicit.

In contrast, SvelteKit defaults to server‑rendering everything and requires you to opt‑in to prerendering—opposite of what our site needed most.

What We Gave Up

Trade‑offDetails
Form actionsSvelteKit’s progressive‑enhancement forms are nice. In Astro we use a Hono API with client‑side fetch, adding boilerplate for onSubmit handlers and loading states.
Learning curveDevelopers must understand both .astro and .svelte files. Deciding where something belongs (static vs interactive) happens dozens of times a day.
View TransitionsAstro’s transitions re‑execute inline scripts on each navigation. We spent extra time guarding Google Analytics and vanilla‑cookie‑consent to avoid double initialization. SvelteKit’s client‑side routing handles this more gracefully out of the box.
API layerSvelteKit’s +server.ts provides tightly integrated API routes. We opted for a standalone Hono server (useful for a future mobile app) which means managing two processes, separate deployments, and CORS configuration.

The Results

  • Homepage JavaScript payload: ~40 KB total.
  • Interactive bits (provider grid, newsletter form) are small, isolated bundles.
  • In a comparable SvelteKit setup, the payload would be significantly larger because every route ships a hydration bundle even for purely static content.

Bottom Line

Astro isn’t a replacement for Svelte; it’s a composition layer that lets us keep Svelte 5 for all interactive components while handling routing and page composition in a way that aligns with a content‑first site. The default‑zero‑JS philosophy, island‑based hydration, and build‑time prerendering made the decision clear for HostingSift.

Client‑side Router Overhead

The framework’s client‑side router adds baseline overhead before any of our code even loads.

Server‑side OG Image Generation

Astro’s endpoint model makes Open Graph image generation straightforward:

  • Dynamic OG images for every hosting profile, comparison page, and blog post.
  • Built with Satori (for SVG → PNG conversion) and Sharp (image processing).
  • Implemented as a standard API route that returns a PNG buffer – no special configuration needed.
// src/pages/api/og-image.ts
import { satori } from 'satori';
import sharp from 'sharp';

export async function GET({ params }) {
  const svg = await satori(/* … */);
  const png = await sharp(Buffer.from(svg)).png().toBuffer();
  return new Response(png, { headers: { 'Content-Type': 'image/png' } });
}

Build Times Stay Fast

  • Prerender 50+ static pages.
  • Generate sitemaps.
  • Compile Svelte islands.

All of this completes under 30 seconds. Adding a new provider hardly impacts the build because most steps run in parallel.

Deploying SvelteKit

“SvelteKit works everywhere in theory. In practice, the smoothest path is deploying to Vercel.”

  • Vercel: adapter-auto detects the platform automatically; the integration is polished.
  • Self‑hosting: possible with adapter-node, but you must configure things that Vercel handles for you out‑of‑the‑box.

Self‑hosting on a Hetzner ARM64 VPS

Our stack runs on a single Hetzner ARM64 VPS:

  • Astro site
  • Hono API
  • PostgreSQL
  • All behind nginx and Cloudflare

Cost: ~ €5 / month.

Deployment steps

# 1️⃣ Install the Node adapter
npm i -D @astrojs/node

# 2️⃣ Build the project
npm run build

# 3️⃣ Run with PM2 (or any process manager)
pm2 start ./dist/server/entry.mjs --name astro-site

No adapter quirks, no platform‑specific edge cases – the output is a standard Node.js server.

Cost Angle

PlatformPricing ModelTypical Pro PlanHidden Costs
Vercel / NetlifyUsage‑based$20‑$25 / moFunction execution time, bandwidth, overage spikes (e.g., bot crawls)
Fixed‑cost VPSFlat monthly fee€5 / mo (Hetzner)Predictable – traffic can double/triple with no bill change
  • Managed platforms give CI/CD, preview deployments, edge functions, zero‑config scaling – valuable for teams that don’t want to manage infrastructure.
  • VPS offers control and cost predictability; scaling up is just moving to a larger box.

Architecture Overview

  • 23 hosting providers, hundreds of plans, comparison pages, a quiz, a blog, user auth, admin panel – all on a single Hetzner box.
  • New provider profiles = just data.
  • New interactive features = new Svelte islands dropped into existing pages.
  • New static pages = .astro files with no client‑side cost.

Framework Choice

  • Would SvelteKit have worked? Absolutely. For a more app‑like product (dashboards, real‑time collaboration, heavy client state) we’d pick SvelteKit without hesitation.
  • For a content‑first site where interactivity is the exception, Astro with Svelte islands proved the right call – not because SvelteKit couldn’t do it, but because Astro’s defaults already point in the direction we wanted.

Takeaway: There’s real value in not having to fight your framework. Astro gives you the minimal client payload you need, while still letting you sprinkle in Svelte where interactivity matters.

0 views
Back to Blog

Related posts

Read more »

Understanding importmap-rails

Introduction If you've worked with modern JavaScript, you're familiar with ES modules and import statements. Rails apps can use esbuild or vite or bun for this...

My Developer Portfolio — Umer Azmi

Hi, I'm Umer Azmi, a Frontend Developer and Python Developer from Mumbai, India. Projects and Contributions 👉 https://github.com/UmerAzmihttps://github.com/Ume...