Forem: Carl

The Money Argument for Go Over Java

Carl — Sun, 12 Apr 2026 19:56:00 +0000

I used to think language debates were about developer preference. Tabs vs spaces energy. Then I started looking at cloud bills.

A team I worked with was running a Java microservice on Kubernetes. Thirty pods, each pulling a 900MB Docker image, each sitting at 160MB of memory at idle. The service wasn't even doing anything complex. It accepted requests, talked to a database, returned JSON — that's it.

Someone rewrote it in Go. Same logic, same API. The image dropped to 20MB. Idle memory went under 1MB. They cut the pod count by more than half and the service was faster. Not a little faster. Measurably, obviously faster.

That's when I stopped thinking about languages as a preference and started thinking about them as a cost decision.

The Numbers

I'm not going to make vague claims. Here are real benchmarks from published sources.

Metric	Java	Go
Lambda cold start	~140ms–1500ms (varies by benchmark)	~45ms–140ms
Lambda memory used (128MB provisioned)	~116MB	~43MB
Idle process memory	~160MB	~0.86MB
1GB S3 JSON processing	~8-10s	~2s
Docker image size	500MB-1GB+	10-25MB

Sources: Scanner.dev's Lambda benchmark (2025), Yash Ladha's Lambda comparison (2025), and a Medium analysis comparing idle memory across Java, Go, and Rust.

Cold starts alone tell a story. 13x faster. If you're running serverless at scale, that's the difference between smooth request handling and users staring at a spinner.

Goroutines vs Threads

This is where it gets interesting.

A Java OS thread costs about 1MB of stack memory. It's managed by the kernel. Context switching between thousands of them is expensive. Java 21 introduced Virtual Threads (Project Loom) to fix this. Go has had the answer since 2009.

Go goroutines start at 2-8KB. They grow as needed. They're scheduled by the Go runtime, not the OS. A single Go process can run millions of them. Try that with Java threads. Good luck.

What does this mean in practice? The concurrency model that Java needs thread pools, ExecutorService, and CompletableFuture chains to pull off, Go does with goroutines and channels out of the box. Backpressure, fan-out, rate limiting. Built in.

Fewer Pods, Less Money

Here's where it hits the cloud bill.

Go's memory efficiency means you need fewer pods for the same throughput. That Java service running 30 pods? Go handles the same load on 10-12. Conservative estimate, based on memory alone. Factor in faster startup and lower CPU usage and it gets even better.

Fewer pods means simpler orchestration. Less monitoring. Smaller service mesh. Less config to maintain. The savings compound.

Now think about traffic spikes. Java's answer is autoscaling. Spin up 50 pods, handle the spike, wait for cooldown. You're paying for those pods the entire cooldown period even if traffic already dropped.

Go's answer? A few instances with goroutines absorb the spike. No autoscaling overshoot. No paying for pods you don't need anymore.

The Hidden Costs

Docker image size sounds boring until you do the math.

A 1GB Java image pulled thousands of times across regions adds up. Registry storage, transfer costs, deployment time. A 25MB Go image is 40x smaller. Faster pulls, faster deployments, faster rollbacks.

When something goes wrong in production, "how fast can we roll back" is a real question. 25MB answers it faster than 1GB.

The Tooling Argument

Every team builds internal tools. Migration scripts, health checkers, cron jobs, data pipelines, deployment utilities. In Java, each one needs a JVM installed on the target machine, a fat JAR, and a startup time tax measured in seconds.

Go compiles to a single static binary. No runtime, no dependencies, no JVM. It starts instantly. Cross-compilation is built in — GOOS=linux GOARCH=amd64 go build from a Mac and you've got a Linux binary. Copy it to the server and run it. That's the entire deployment.

This adds up fast. A team with 20 internal tools means 20 fewer JVM installations to manage, 20 faster startup times, 20 simpler Dockerfiles. The operational overhead of Java tooling is invisible until you see how the other side lives.

Why Hasn't Everyone Switched?

If the numbers are this clear, why is Java still everywhere?

Because switching languages isn't a technical decision. It's a business one. Java has millions of developers. Decades of tooling. Managers who built their careers on it. Existing codebases that would cost millions to rewrite.

The hiring argument comes up every time. "We can't find Go developers." But let's be honest. Can you find experienced Java developers? Really experienced ones? The ones who actually understand the JVM, garbage collection tuning, and the concurrency model beyond copy-pasting CompletableFuture chains? In my experience, they're not exactly plentiful either.

There's also sunk cost. If you've got 200 Java microservices, nobody's rewriting them all. That's fine. But the next service? The next internal tool? The next Lambda function? That's where the decision matters.

The infrastructure layer already moved. Docker is written in Go. Kubernetes is written in Go. Terraform is written in Go. The tools that run your Java services are built in Go. The application layer is next.

LLMs Changed the Hiring Equation

This is the part most "Go vs Java" posts miss because they were written before LLMs became a daily tool.

Go has 25 keywords. Java has 67 (and growing). Go has no inheritance, no annotations, no abstract classes, no checked exceptions. The entire language spec fits in your head after a weekend.

Why does that matter? Because LLMs generate better Go code than Java code. Less surface area means fewer ways to get it wrong. Ask an LLM to write a Go HTTP handler and it gives you something that works. Ask it to wire up a Spring Boot controller with the right annotations, dependency injection, and exception handling? You're rolling the dice.

This flips the hiring argument on its head. You don't need a team of Go experts with 10,000 hours anymore. You need developers who understand concurrency, networking, and systems thinking. The language itself? Someone with solid fundamentals can pick up Go in weeks, not years. LLMs close the remaining gap.

Java's complexity used to be a moat. "We have all this institutional knowledge." Now that complexity is a liability. Every abstraction layer, every framework convention, every annotation-driven behavior is another place where an LLM can hallucinate and a developer can get lost.

And someone still has to review that code. LLMs generate it, but humans approve it. Reviewing 200 lines of Go with explicit error handling and no magic is a different job than reviewing 200 lines of Spring Boot with annotations, injected dependencies, and framework conventions that hide the actual control flow. One you can read top to bottom. The other requires you to hold an entire framework's behavior in your head.

Go's simplicity isn't just a developer experience win anymore. It's a productivity multiplier in the age of AI-assisted development.

What Go Doesn't Do

I'm not going to pretend Go is perfect for everything.

It has no built-in UI story. If you need a full-stack app, you're pairing Go with a JavaScript or TypeScript frontend. HTMX with Go templates gets you surprisingly far, but it's not a full frontend framework.

That said, separation of concerns is arguably better anyway. Go handles the backend. Your frontend framework handles the UI. Clean boundary.

So What?

If you're an engineering manager evaluating languages for a new service, run the numbers on your own infrastructure. Check your pod counts, your memory usage, your cold start times, your image sizes. Then estimate what those look like in Go.

If you're a developer curious about Go, build one thing. A CLI tool, a small API, anything. You'll feel the difference immediately. The compile speed, the binary size, the memory footprint. It's not subtle.

The language debate stopped being about syntax preferences a long time ago. It's about what your cloud bill looks like at the end of the month. And with LLMs making new languages easier to pick up than ever, the "we can't find developers" excuse is running out of time.

But the fundamentals still matter. Goroutines don't help if you don't understand concurrency. Channels don't help if you can't reason about backpressure. LLMs speed up the syntax. They don't replace the thinking.

That's why I built ByteLearn. Short lessons, focused on one concept at a time, with quizzes that test whether you actually get it. The Go Essentials course covers everything from types to building a concurrent file scanner. Free, no signup wall. If you're making the switch to Go, start there.

Foundations First: Why AI Assistants Still Need a Human Driver

Carl — Mon, 06 Apr 2026 15:42:00 +0000

I went through a phase where I thought I could skip learning SvelteKit properly. I had an LLM. I'd describe what I wanted, paste the output into my project, and move on. Components, routes, database queries. It all looked right.

Then something broke. A page was loading data on the server but the component wasn't reactive. The LLM kept suggesting fixes using $: syntax. Svelte 5 doesn't use $: anymore. It uses runes. The LLM didn't know the difference, and neither did I.

That's when it hit me. I wasn't building anything. I was assembling code I couldn't debug.

The Framework Problem

Here's the thing about modern web stacks. They move fast. Svelte 5 rewrote its entire reactivity model. Tailwind 4 dropped the JavaScript config file for a CSS-based one. Drizzle ORM has its own schema syntax that looks nothing like Prisma. These aren't small changes.

LLMs are trained on older data. They mix up versions constantly. I've seen an LLM generate a perfectly valid Tailwind 3 config and present it with total confidence, even though my project was running Tailwind 4. If you don't know what version you're using and what changed, you'll paste that config in, wonder why nothing works, and waste an hour.

Same with Svelte. The LLM will hand you a component using $: doubled = count * 2 when it should be let doubled = $derived(count * 2). Both look reasonable. Only one works.

Can you tell which is correct without already knowing the framework? That's the question.

It Goes Deeper Than Frameworks

Frameworks are just layers. Underneath all of them is JavaScript, TypeScript, and Node.js. And honestly, these matter more.

Every SvelteKit load function is an async function. If you don't understand Promises and await, you'll stare at undefined for twenty minutes before realizing you forgot to await a database call. The LLM won't catch that because the syntax is technically valid.

TypeScript errors are famously unreadable. When Drizzle infers types from your schema and something doesn't line up, you get a wall of red text. The LLM's instinct is to slap any on it and move on. That "fixes" the error and kills the entire point of using TypeScript.

Node.js runs your server-side code. Your +page.server.ts files, your API routes, your database connections. If you don't understand the difference between what runs on the server and what runs in the browser, you'll accidentally expose database queries to the client. Or you'll try to use window in a server file and get a crash you can't explain.

These aren't framework problems. They're language and runtime problems. And they come up every single day.

The Debugging Gap

This is where the whole thing falls apart. Building is the easy part. Debugging is where you actually need to know things.

When your page renders blank, is it a routing issue? A data loading issue? A reactivity issue? A hydration mismatch? Each one has a completely different fix. The LLM will guess. Sometimes it guesses right. Sometimes it sends you down a rabbit hole that makes things worse.

I've watched this happen in real time. Someone pastes an error into an LLM, gets a suggestion, applies it, gets a new error, pastes that one in, gets another suggestion. Thirty minutes later they've changed six files and the original problem is buried under five new ones.

If they'd understood the error message in the first place, it would've been a two-minute fix.

So What's the Right Approach?

I'm not saying don't use AI. I use it constantly. It's incredible for scaffolding, for generating boilerplate, for exploring APIs I haven't used before. It saves me hours every week.

But I use it like GPS. It tells me where to turn. I'm the one driving. And if it says "turn left into a lake," I know not to.

Here's what actually works:

Learn JavaScript first. Not just syntax. Understand async/await, closures, how this works, array methods. This is the foundation everything else sits on.

Pick up TypeScript. Read the errors yourself. Understand what generics do and why Drizzle uses them. Don't let the LLM any its way out of type safety.

Understand Node.js basics. Server vs client. Environment variables. Modules. How your SvelteKit app actually runs.

Then learn your frameworks. Once you know the language, picking up SvelteKit or Tailwind or Drizzle is just learning an API. The concepts transfer.

Use AI to go faster, not to skip steps. Ask it to generate a component, then read every line. Ask yourself: do I understand why this works? If the answer is no, that's your cue to learn, not to move on.

Follow up more on https://bytelearn.dev/blog

The Multiplier Effect

Here's what I keep coming back to. AI doesn't replace knowledge. It multiplies it.

If you understand your stack, AI makes you two or three times faster. You can describe exactly what you want, evaluate what you get back, and course-correct in real time. That's a genuine superpower.

If you don't understand your stack, AI gives you code you can't evaluate, can't debug, and can't maintain. You'll ship it. It'll break. And you'll be stuck.

The developers who invest in actually learning the fundamentals are the ones AI makes dangerous. Everyone else is just along for the ride.

So yeah. You still need to learn the thing. The tools got better. The job didn't get easier. It got different.

The Multimedia Myth

Carl — Thu, 02 Apr 2026 15:53:48 +0000

I used to think I was a "visual learner." I'd pick a video tutorial over documentation every time. Twenty minutes of someone explaining closures while typing in VS Code? Perfect. I'd watch the whole thing, nod along, and close the tab feeling like I understood closures.

Then I'd try to use one and realize I had no idea what I was doing.

This happened enough times that I started questioning the whole setup. Not the specific tutorials, but the format itself. Is video actually a good way to learn programming? Or does it just feel like one?

The Study That Started It All

The idea that multimedia is better for learning comes from real research. Richard Mayer's multimedia learning theory showed that combining relevant visuals with text can reduce cognitive load. A diagram of the event loop next to an explanation helps. That part is solid.

But the industry took "relevant visuals help" and turned it into "video is better than text." Those are completely different claims. And the second one was never proven.

Most programming tutorials aren't even multimedia in any real sense. They're someone talking over a code editor. There's nothing visual about explaining JavaScript closures that text couldn't do better. It's just text delivered slowly through someone's mouth.

Why Reading Is Harder (and Why That Matters)

When you read, your brain does real work. You build the mental images yourself. You pause on a confusing sentence, re-read it, think about it, move on. You're constructing a mental model from scratch.

When you watch a video, someone else did that work for you. The instructor visualized the concept, chose the metaphor, paced the explanation. Your brain is just receiving.

That's why video feels easier. It is easier. And easier means less encoding. Less effort means weaker memory.

I think about it like this: reading a novel and watching the movie are completely different experiences. The reader who imagines a character's face remembers the story differently than the viewer who was handed one. One exercises the mind. The other entertains it.

Programming concepts are abstract. Variables, closures, promises, type systems. None of these are visual. They're symbolic and logical. Text with the occasional diagram is almost always the better format for this kind of material, because it forces you to do the mental work that creates understanding.

Where Video Actually Wins

I'm not saying video is useless. It's the right format when the information is spatial, physical, or auditory:

Tool navigation. Seeing someone use a UI, understanding spatial layouts. You need to see this.
Physical skills. You can't learn to swim from a book. Motor learning needs demonstration.
Spatial reasoning. Circuit diagrams, architecture layouts, things that are actually visual.
Sound. Pronunciation, music, tone. Text can't capture these.

But for abstract concepts like programming? The video is doing something text already does, just slower and with less effort from you. And less effort is the problem, not the solution.

The "Learning Styles" Thing

"I'm a visual learner" is one of those things everyone says and nobody questions. The idea that people have dominant learning styles (visual, auditory, kinesthetic) has been studied a lot. It's mostly a myth.

What research does support is different. It's not that people are visual or auditory. It's that subjects are. Swimming is kinesthetic. Music is auditory. Programming is abstract and symbolic. You match the format to the content, not to the person.

Saying "I'm a visual learner" when studying TypeScript generics is like saying "I'm a hammer person" when the job needs a screwdriver. The preference is real. The effectiveness isn't.

LLMs Didn't Replace Learning. They Replaced Lookup.

Here's what I think happened. Tutorial videos were never popular because of the video format. They were popular because they were the best guided explanation available.

Before LLMs, if you were stuck on something specific, your options were:

Read the docs (often poorly written, assumed too much)
Search Stack Overflow (fragmented, someone else's problem)
Watch a 20-minute video just to find the 2 minutes you needed

For that use case, LLMs are better. They're instant, specific to your problem, and you can ask follow-ups.

But there's a catch. LLMs work when you already know enough to ask the right question. If you understand TypeScript and you're stuck on a conditional type, an LLM will get you unstuck fast. If you don't know TypeScript at all, you don't even know what to ask. You'll get an answer, but you won't know if it's the right approach, whether you're learning the right things in the right order, or what you're missing.

LLMs are a lookup tool, not a learning system. They don't give you structure, progression, or a way to test whether you actually understood what they told you. They solve the problem in front of you without building the foundation underneath it.

For getting unstuck, LLMs win. For actually learning a topic from scratch, building the mental model, in the right order, and checking it stuck, you still need structured material and active recall. The format of that material matters. And for abstract concepts, text beats video.

So What Does Work?

If video tutorials create the strongest illusion of learning, and re-reading creates the second strongest (I wrote about that in the previous post, what's left?

Reading. Actual reading. The kind where you engage with text, pause to think, and then test yourself on what you just read. It's not glamorous. It doesn't feel as productive as watching a polished tutorial. But the effort your brain puts into processing text is exactly what makes the knowledge stick.

The best format for learning abstract concepts is condensed text followed by active recall. Read the concept. Close it. Try to explain it. Take a quiz. See what you actually retained versus what you only thought you understood.

It's slower. It's harder. It's uncomfortable. That's the whole point.

This is part 2 of a series on effective learning. Previous: You're Not Learning, You're Just Reading. Next: Why 700-Page Books Exist

TypeScript's `never` Type: The Most Misunderstood Keyword in the Language

Carl — Wed, 01 Apr 2026 14:43:59 +0000

You're writing TypeScript, everything's going fine, and then you see it:

Type 'string' is not assignable to type 'never'.

Your first reaction is probably "what the hell is never?" You didn't write it. You didn't ask for it. And the error message isn't helping.

Most people Google it, find a one-liner explanation ("a type that represents values that never occur"), nod slowly, and move on without actually understanding it. I know because that's exactly what I did.

But never is one of those things that clicks once you see why it exists, and then you start using it on purpose.

The Opposite of `any`

Here's the mental model. TypeScript has two extremes:

any: "this could be literally anything, I don't care"
never: "this can literally never happen"

any is the top. Everything is assignable to it. never is the bottom. Nothing is assignable to it (except another never). They're opposites.

let anything: any = "hello";    // ✅ fine
anything = 42;                  // ✅ fine
anything = true;                // ✅ fine

let nothing: never = "hello";   // ❌ error, can't assign anything to never

If any means "I give up on type checking," never means "if we ever get here, something went wrong."

Where You've Already Seen It

The most common place never shows up is in functions that don't return. Not functions that return nothing (that's void), but functions that never finish:

// void: the function finishes, it just doesn't return a value
function log(message: string): void {
  console.log(message);
  // implicitly returns undefined, the function completes
}

// never: the function never completes
function crash(message: string): never {
  throw new Error(message);
  // nothing after this line ever runs
}

Think of it like this: void is a car reaching its destination and stopping. never is a car driving off a cliff. Both "don't return a value," but for very different reasons.

An infinite loop is another example:

function forever(): never {
  while (true) {
    // this never ends
  }
}

The Real Power: Catching Your Own Mistakes

The throw example is fine, but it's not why never matters. The real power is something called exhaustiveness checking, using never to make TypeScript yell at you when you forget to handle a case.

Say you have user roles:

type Role = 'admin' | 'user' | 'guest';

function getPermissions(role: Role): string {
  switch (role) {
    case 'admin': return "Full access";
    case 'user':  return "Read and write";
    case 'guest': return "Read only";
  }
}

This works. But what happens six months later when someone adds a new role?

type Role = 'admin' | 'user' | 'guest' | 'moderator';

The getPermissions function still compiles. No error. No warning. The new 'moderator' role silently falls through and returns undefined. You won't find out until a user reports a bug, or worse, gets the wrong permissions.

Here's the fix:

function getPermissions(role: Role): string {
  switch (role) {
    case 'admin':     return "Full access";
    case 'user':      return "Read and write";
    case 'guest':     return "Read only";
    default:
      const _exhaustive: never = role;
      return _exhaustive;
  }
}

Now when you add 'moderator' to the union, TypeScript immediately throws a compile error:

Type '"moderator"' is not assignable to type 'never'.

Why? Because after handling admin, user, and guest, TypeScript narrows role down to 'moderator' in the default branch. And 'moderator' can't be assigned to never. The compiler is literally telling you: "Hey, you forgot to handle this case."

This is the pattern. You're using never as a safety net that catches future mistakes at compile time instead of runtime.

How TypeScript Narrows to `never`

This works because of type narrowing. As TypeScript moves through each case, it eliminates possibilities:

function getPermissions(role: Role): string {
  // role is 'admin' | 'user' | 'guest'

  switch (role) {
    case 'admin':
      // role is 'admin'
      return "Full access";
    case 'user':
      // role is 'user'
      return "Read and write";
    case 'guest':
      // role is 'guest'
      return "Read only";
    default:
      // role is... nothing. All options exhausted. Type is 'never'.
      const _exhaustive: never = role;  // ✅ compiles
      return _exhaustive;
  }
}

Every case removes one member from the union. When they're all gone, the only type left is never, the empty set.

The Impossible Intersection

Here's another way never shows up naturally. What's a value that's both a string and a number at the same time?

type Impossible = string & number;  // never

There's no value in JavaScript that's simultaneously a string and a number. So TypeScript represents that as never. It's not an error. It's TypeScript correctly saying "this type has zero possible values."

This matters in practice when you're building complex conditional types or filtering properties. If a type computation results in an impossible state, TypeScript prunes it with never instead of crashing.

`never` in the Wild: Filtering Object Types

Here's a real-world use. Say you want to extract only the string properties from an object type:

type StringKeysOnly<T> = {
  [K in keyof T]: T[K] extends string ? K : never;
}[keyof T];

interface User {
  id: number;
  name: string;
  email: string;
  age: number;
}

type StringKeys = StringKeysOnly<User>;  // "name" | "email"

The never values get automatically filtered out of the union. number keys like id and age map to never, and TypeScript drops them. Only "name" and "email" survive.

Why It's Called the "Bottom Type"

In type theory, never is the bottom type. Every type system has one. Rust calls it !, Scala calls it Nothing, Haskell calls it Void.

The bottom type is a subtype of every other type. That sounds weird, but it makes sense: if a value can never exist, it technically doesn't violate the rules of any type. You can assign never to anything:

const n: never = crash("boom");

const s: string = n;   // ✅ fine
const num: number = n;  // ✅ fine
const b: boolean = n;   // ✅ fine

This isn't useful in everyday code, but it's why the type system stays consistent. never is the mathematical zero of TypeScript's type algebra.

Quick Reference

Situation	Type
Function returns nothing	`void`
Function never returns	`never`
Impossible intersection (`string & number`)	`never`
All union members exhausted after narrowing	`never`
Filtered-out branch in conditional types	`never`

The Takeaway

never isn't some obscure academic concept. It's TypeScript's way of representing impossibility, and that turns out to be incredibly useful.

Use it for exhaustiveness checking in switch statements. Understand it when you see it in error messages. And know that when TypeScript narrows a type down to never, it's telling you something important: "This should be unreachable. If it's not, you have a bug."

The developers who understand never write code that catches mistakes at compile time. Everyone else finds them in production.

I'd love to hear from you. Reach out to https://bytelearn.dev/

The Real Talk: SvelteKit vs Next.js vs Nuxt.js in 2026

Carl — Thu, 26 Mar 2026 05:55:10 +0000

You don't need another "which framework is best" article that ends with "it depends." I'm going to actually compare these three with real numbers, honest trade-offs, and a clear picture of where each one makes sense.

Check for more posts on https://bytelearn.dev/blog

Why Only These Three?

I know someone's going to ask about Astro, HTMX, Solid, or Phoenix LiveView. They're good tools, but they're solving different problems. Astro is a content-first static site builder. HTMX enhances server-rendered HTML, not a full application framework. Solid is impressive but the ecosystem barely exists. Phoenix LiveView means committing to Elixir.

SvelteKit, Next.js, and Nuxt.js are the three full-stack JavaScript meta-frameworks going after the same space: modern, interactive web apps with SSR, routing, data loading, and deployment baked in. That's the comparison that matters.

Svelte 5 Changed This Conversation

If you've read framework comparisons written before 2024, they're outdated. Svelte 5 is a different beast.

The old criticism was fair: "Svelte has no runtime, so every component ships its own update logic. At scale, that adds up." True, in Svelte 4. But Svelte 5 introduced runes ($state, $derived, $effect) backed by a small shared runtime using signals. What that means in practice:

Components share reactivity infrastructure now instead of each carrying their own
The "bundle size crossover" argument? Basically dead
Reactivity is explicit. You know what's reactive because you wrote $state, not because the compiler magically tracked it
The runtime is still tiny (~5-8KB gzipped) next to React (~42KB) or Vue (~30KB)

Everything people liked about Svelte (the compiler approach, the clean syntax, the speed) stayed. The one real architectural weakness got fixed. That shifts this whole comparison.

Quick Overview

	🎯 SvelteKit	🔷 Next.js	🌿 Nuxt.js
UI Library	Svelte 5	React 19	Vue 3
How it works	Compiles away the framework	Virtual DOM + Server Components	Virtual DOM
Runtime shipped to browser	~5-8KB	~40-50KB	~28-32KB
Reactivity	Runes ($state, $derived)	Hooks (useState, useEffect)	Composition API (ref, reactive)
Build tool	Vite	Turbopack / Webpack	Vite
Backed by	Vercel (Rich Harris)	Vercel	NuxtLabs

🏎️ Performance

53% of mobile users leave a page that takes more than 3 seconds to load. For e-commerce, every 100ms of latency costs real money. This isn't abstract.

	🎯 SvelteKit	🔷 Next.js	🌿 Nuxt.js
Framework JS (gzipped)	~5-8KB	~40-50KB	~28-32KB
Time to download on 3G	~0.2s	~1.2s	~0.8s
Runtime update speed	⚡ Direct DOM updates	🔄 Virtual DOM diffing	🔄 Virtual DOM diffing
Hydration	Full	Selective (with RSC)	Full
Lighthouse scores	✅ Excellent	✅ Excellent (with RSC) / ⚠️ Mixed (client-heavy)	✅ Good

Here's what people skip over: JavaScript is the most expensive byte you can send to a browser. An image and a JS file of the same size aren't equal. JS has to be downloaded, parsed, compiled, and executed before your page becomes interactive. SvelteKit's tiny runtime means users are already clicking around while other frameworks are still waking up.

It compounds, too. Svelte's compiler produces smaller component output. A product card in Svelte might compile to 1-2KB. The React version with hooks and runtime bindings? 5-8KB. Across dozens of components, that adds up fast.

🧑‍💻 Developer Experience

SvelteKit — Less Code, More Done

<script>
  let count = $state(0);
</script>

<button onclick={() => count++}>
  Clicked {count} times
</button>

No imports, no hooks, no ceremony. Svelte reads like HTML that happens to be reactive. The runes system makes it obvious what's reactive. You declared it with $state, end of story.

Next.js — Powerful, but You Feel the Weight

'use client';
import { useState } from 'react';

export default function Counter() {
  const [count, setCount] = useState(0);

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

You need 'use client' because Next.js defaults to server components. You import useState. You use a setter function instead of direct assignment. It works, but it's more code for the same result. And the constant "is this a server component or client component?" question gets old.

Nuxt.js — Comfortable Middle

<script setup>
const count = ref(0);
</script>

<template>
  <button @click="count++">
    Clicked {{ count }} times
  </button>
</template>

Vue's Composition API is genuinely pleasant to use. <script setup> killed most of the old boilerplate. It sits between Svelte's minimalism and React's verbosity, and for a lot of developers, that's exactly the right spot.

How They Compare on DX

	🎯 SvelteKit	🔷 Next.js	🌿 Nuxt.js
Boilerplate	Minimal	Moderate-high	Moderate
Learning curve	Gentle	Steep (RSC, caching, App Router)	Moderate
Lines of code for same feature	Fewest	Most	Middle
"Just works" factor	High	Medium (lots of config decisions)	High

🧱 Architecture & Features

	🎯 SvelteKit	🔷 Next.js	🌿 Nuxt.js
SSR	✅	✅	✅
SSG	✅	✅	✅
Server Components	❌	✅ (RSC — zero client JS)	❌ (experimental)
Streaming SSR	✅	✅	Partial
File-based routing	✅ (+page.svelte)	✅ (page.tsx)	✅ (pages/)
Nested layouts	✅	✅	✅
API routes	✅ (+server.ts)	✅ (route handlers)	✅ (server/api/)
Middleware	hooks.server.ts	middleware.ts (edge)	server/middleware/
ISR	Manual (prerender + invalidation)	✅ Native	✅ (routeRules)
Edge runtime	Via adapters	✅ Native	✅ (Nitro)

About Server Components

This is Next.js's strongest card. React Server Components render on the server and send zero JavaScript to the client for those parts. If you're building something content-heavy (docs, a product catalog, a blog) where most of the page is static with a few interactive bits, RSC is a real architectural win.

SvelteKit and Nuxt don't have anything like it. SvelteKit's counter-argument is that even when it ships JS, it's so little that the gap narrows. Fair, but architecturally, they're different approaches and RSC has genuine advantages for the right use case.

📦 Ecosystem & Integrations

This is where SvelteKit is weakest. No way around it.

	🎯 SvelteKit	🔷 Next.js	🌿 Nuxt.js
UI component libraries	Growing (shadcn-svelte, Skeleton, Melt UI)	Massive (shadcn, MUI, Radix, Chakra, etc.)	Strong (Vuetify, PrimeVue, Nuxt UI)
Auth solutions	Lucia, custom	NextAuth, Clerk, Auth0, dozens more	Nuxt Auth, Sidebase
CMS integrations	Works but often DIY	First-class SDKs from most CMS providers	Good plugin support
Third-party SDKs	Often missing or community-maintained	Almost everything ships a React SDK	Good Vue plugin ecosystem
Module/plugin system	Adapters, no official module system	npm ecosystem	Nuxt Modules (200+, polished)
State management	Built-in ($state, stores)	External (Zustand, Jotai, Redux)	Pinia (official)

I want to call out Nuxt's module system specifically. It's best-in-class. Need auth? npm i @sidebase/nuxt-auth, add it to your config, you're done. Image optimization? @nuxt/image.

SEO? @nuxtjs/seo. These aren't weekend projects on npm. They're well-maintained, well-documented, and they actually save you days of work.

🚀 Deployment

	🎯 SvelteKit	🔷 Next.js	🌿 Nuxt.js
Vercel	✅ Great	✅ Best (optimized)	✅ Good
Cloudflare	✅ adapter-cloudflare	✅ @opennextjs/cloudflare	✅ Nitro preset
Node.js server	✅ adapter-node	✅ Works (some features limited)	✅ Nitro preset
Docker	Easy	Heavier	Easy
Static export	✅ adapter-static	✅ output: 'export'	✅ ssr: false
Vendor lock-in concern	Low	Medium (some features Vercel-optimized)	Low (Nitro is flexible)

One thing to keep in mind: Next.js can be deployed outside Vercel, but features like ISR, image optimization, and edge middleware work best (or sometimes only) on Vercel. Projects like OpenNext exist specifically to fill these gaps on other platforms, and that alone says a lot about the vendor lock-in concern. SvelteKit and Nuxt don't have this problem.

🏗️ When to Pick What

Pick SvelteKit if:

🏎️ Performance and bundle size are top priorities: mobile-first, global audience, e-commerce
🧹 You want to write less code and ship faster
🧑‍💻 Solo dev or small team that values simplicity over ecosystem breadth
📱 Your users are on phones or slow connections
🆕 Starting fresh, no legacy codebase to worry about

Pick Next.js if:

📄 Content-heavy app with selective interactivity (RSC is built for this)
🏢 Enterprise project that needs the biggest ecosystem and hiring pool
🔌 You need first-class integrations with every SaaS tool out there
📈 Planning to scale the team significantly
☁️ All-in on Vercel

Pick Nuxt.js if:

⚡ Rapid prototyping with drop-in modules for common features
🌿 You prefer Vue's template syntax and reactivity model
🌍 Need maximum deployment flexibility. Nitro runs basically everywhere
🧩 Want "batteries included" without hunting for third-party solutions
👥 Team already knows Vue

The Bundle Size Thing

I'm giving this its own section because it directly hits your users' wallets and patience.

On a 3G connection (still common in much of the world), here's what your users sit through just waiting for the framework to load. Not your app. Just the framework:

	Download time (3G)	Parse + Execute	Total framework tax
🎯 SvelteKit	~0.2s	Minimal	~0.3s
🌿 Nuxt.js	~0.8s	Moderate	~1.1s
🔷 Next.js	~1.2s	Heavier	~1.6s

1.3 seconds between SvelteKit and Next.js. Just the framework. Your app code, images, fonts, API calls — all on top. For someone on a phone in a coffee shop or on a bus, that's the difference between staying and leaving.

Svelte's compiler makes this worse for the competition as your app grows, too. More components = bigger gap.

🤖 The AI Factor

Nobody talks about this yet, but it matters more every month.

If you're using Cursor, Copilot, Kiro, or whatever LLM tool to write code (and most of us are at this point), the framework you pick affects how good that generated code turns out.

Svelte has a structural advantage here, and it's straightforward: fewer ways to do things means fewer ways to get it wrong.

When an LLM generates a React component in Next.js, it has to make a bunch of decisions:

Server component or client component? Does it need 'use client'?
Which hook: useState, useReducer, useMemo, useCallback?
Fetch data in a server component, a route handler, or useEffect?
Context provider? Wrapper component?
Is this fetch call cached by default or not?

LLMs get these wrong all the time. The server/client boundary and caching behavior are the biggest traps, and they're the hardest bugs to spot in code review.

Same component in SvelteKit:

State? $state.
Derived value? $derived.
Side effect? $effect.
Data loading? load() in +page.ts or +page.server.ts.

One way to do each thing. Small API surface, strict conventions, simple lifecycle. LLMs do well here because there just aren't that many wrong answers available.

Vue/Nuxt is somewhere in between. The Composition API is clean, but ref vs reactive, watch vs watchEffect, Options API vs Composition API (LLMs mix these up constantly), and the occasional toRef/toRaw/unref dance trips up humans and machines alike.

In practice:

	🎯 SvelteKit	🔷 Next.js	🌿 Nuxt.js
LLM accuracy on first try	High, few ways to be wrong	Medium, server/client boundary is a trap	Medium, ref/reactive confusion
Common LLM mistakes	Rare (sometimes old Svelte 4 syntax)	`'use client'` misuse, caching bugs, wrong data fetching pattern	Mixing Options/Composition API, reactivity unwrapping
Code review burden	Light	Heavy, need to verify architectural decisions	Moderate
Prompt complexity	Simple, "build me X" usually works	Needs context: "server component, use RSC, don't cache this..."	Moderate, "use Composition API, script setup..."

If you're a solo developer or small team leaning on AI to move fast, the framework that gives you correct code with less hand-holding is a real multiplier. Svelte is clearly ahead here.

So Who Wins?

I've built with all three. Here's where I land:

Svelte 5 moved the needle. The old knocks ("no shared runtime," "doesn't scale," "too niche") are either solved or shrinking. What's left is a framework that ships less JavaScript, updates the DOM faster, and needs less code to build the same thing. For most web apps in 2026, those are the things that actually matter to users.

Next.js has Server Components, and for the right architecture that's a genuine edge. Nuxt has the best module ecosystem, and that saves real time when you're prototyping. Both are solid choices.

But if you're starting something new today and you care about building fast and loading fast — SvelteKit should be the default, not the alternative.

The web got bloated. Svelte is pushing back. And with version 5, it's hard to argue against the results.

What are you building, and what did you pick?

I'd love to hear from you. Reach out to https://bytelearn.dev/

Why You Should Still Learn to Code in the Age of AI

Carl — Tue, 24 Mar 2026 00:00:00 +0000

A few months ago, I built an iOS app. I have zero Swift experience. I described what I wanted to an LLM, iterated on the output, and had something working in a couple of days.

So… why bother learning anything anymore?

I’ve been thinking about this a lot, and I don’t think the answer is as simple as people on Twitter make it sound. AI makes experienced developers faster. It does not make inexperienced developers experienced. Those are very different things.

The iOS App Problem

Yes, I shipped that app. But here’s the part I usually skip over: it took me roughly three times longer than it would’ve taken someone who actually knows Swift. And the AI wrote perfectly fine code — that wasn’t the issue. The issue was me.

I couldn’t tell when the code was good versus when it just happened to work. When something broke, my entire debugging strategy was pasting the error back and crossing my fingers. I had no idea how UIKit works, so I couldn’t steer the conversation anywhere useful. I was basically along for the ride.

Now compare that to how I use AI when I’m working in Go, which I actually know. I’ll be building a service and say something like, “Let’s use channels here instead of a mutex — the access pattern is fan-out and I want backpressure.” Or I’ll look at what it spits out and go, “This works, but just use an atomic here — we’re only incrementing a counter, a mutex is overkill.” I know where race conditions tend to show up, so I can ask it to add checks in the right places. I can decide whether something even needs concurrency to begin with.

Completely different experience. I’m not hoping the output is correct. I know whether it is.

What Actually Changed

AI didn’t remove the need for knowledge. It shifted where you spend your time.

Before, a huge chunk of coding was mechanical. Looking up syntax you forgot, writing boilerplate, checking which function takes which arguments. That stuff is basically gone now, and honestly, nobody misses it.

What’s left is the part that was always the real job anyway: making decisions. Picking the right data structure. Knowing when a simple approach beats a clever one. Catching the edge case that’ll wake someone up at 3 AM. Understanding why one design scales and another falls apart.

AI generates the code. You’re the one who decides if it’s actually good.

Every Line Still Needs a Reviewer

This one doesn’t get talked about enough. Every line of code that ships to production needs someone to review it. A human. Who gets what it does.

If you can’t review it, you can’t ship it. Well — you can. But you’re shipping code you don’t understand, and eventually that catches up with you.

I’ve already seen this happen. Someone generates a whole feature with AI, it passes the basic tests, gets merged. Two weeks later there’s a weird bug nobody can figure out because nobody actually understood the code when it went in. The person who “wrote” it can’t fix it either, because they didn’t really write it.

Learning is what makes you the person who can actually fix things when they break.

Better Knowledge, Better Conversations

The thing I keep coming back to is this: the more you know about a topic, the better your conversations with AI get.

When I first started using AI for Go, my prompts were lazy. “Write me an HTTP server.” Now I’ll say something like, “Set up an HTTP server with graceful shutdown, a 30-second timeout on the handler context, and structured logging. Just net/http, no frameworks.”

The output I get back is wildly better. Not because the model improved — because I got more specific about what I actually wanted.

Same thing applies everywhere. If you understand JavaScript well, you can tell the AI to avoid certain patterns, use specific browser APIs, handle the edge cases you know exist from experience. If you don’t have that background, you get generic code that works in the demo and breaks in production.

So What’s Worth Learning?

I’m not arguing you should memorize every API or hand-write everything from scratch. That ship has sailed. But there’s a baseline you need:

How things actually work. Not every low-level detail, but the mental model. How does async code execute? What happens when you write to a database? Why does this layout break on mobile?
When to reach for what. Knowing that both a mutex and a channel can solve your concurrency problem is step one. Knowing which one fits better and why — that’s the part AI can’t do for you.
How to read code with a critical eye. AI will hand you something that looks right. Sometimes it is. Sometimes it isn’t. You only develop that instinct by writing enough code yourself.
Fundamentals over frameworks. Frameworks come and go every couple of years. Data structures, networking, how databases actually work, security basics — that stuff stays relevant for your entire career.

Where This Leaves Us

The developers doing well right now aren’t the ones who stopped learning because AI can write code. They’re the ones who kept learning and now use AI to move way faster than before.

It’s like power tools. A table saw makes a carpenter faster. It doesn’t turn someone who’s never touched wood into a carpenter. The saw doesn’t know what you’re building or whether your measurements are off. It just cuts where you point it.

AI is the best tool we’ve ever had for building software. But it’s still a tool. And a tool is only as useful as the person holding it.

So learn the thing. Understand it for real. Then let AI help you build faster than you could alone.

Originally published at https://bytelearn.dev.