DEV Community: Daniel Bergholz

Testing GLM-5.2 on OpenCode: I'm impressed!

Daniel Bergholz — Thu, 18 Jun 2026 09:51:13 +0000

I have a confession: I roll my eyes at AI benchmarks. Every other week someone on Twitter posts a chart where a brand new model is suddenly beating Opus and GPT, the replies go crazy, and then you actually use the thing and it falls apart on the first real task. Beautiful numbers, ugly code.

So when z.ai shipped GLM 5.2 and the timeline started shouting that an open-weights model was now nipping at the heels of the frontier labs, my instinct was the usual one. Sure. Prove it.

This post is me proving it. I gave GLM 5.2 a real feature to build on my actual production website, with almost no hand-holding, and watched what happened. Spoiler: I was not expecting to write the sentence I ended up writing.

If you'd rather watch me run the whole thing live (including the part where my tools crashed on camera), the video is right here:

The claims I was here to test

Let's get the hype out of the way first, because the claims are genuinely big.

// Detect dark theme var iframe = document.getElementById('tweet-2066938937344495629-856'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2066938937344495629&theme=dark" }

GLM 5.2 is the same physical size as GLM 5.1 (744B total parameters, 40B active), but on the Artificial Analysis Intelligence Index it jumped 11 points, from 40 to 51. That score makes it the leading open-weights model, ahead of MiniMax-M3 (44), DeepSeek V4 Pro (44) and Kimi K2.6 (43). On the overall leaderboard it sits behind only Claude Fable 5 (60), Claude Opus 4.8 (56) and GPT-5.5 (55). For an open, MIT-licensed model you can download the weights for, that is a wild place to be.

Here is the upgrade at a glance:

	GLM 5.1	GLM 5.2
Intelligence Index (v4.1)	40	51
Context window	200K	1M
Total / active params	744B / 40B	744B / 40B
Output tokens per task	26k	43k
Cost per task	~$0.25	~$0.46
Price (in / cache / out per 1M)	$1.4 / $0.26 / $4.4	$1.4 / $0.26 / $4.4
License	MIT	MIT

Two things jump out. First, the context window went from 200K to a full 1 million tokens, which matters a lot for agentic coding where the harness stuffs your whole repo into the prompt. Second, the price did not move at all. Same cost as 5.1, 11 points smarter.

// Detect dark theme var iframe = document.getElementById('tweet-2067135640249209175-119'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2067135640249209175&theme=dark" }

That last row in the table is also the explanation for a complaint you'll see online, and I'll come back to it. Numbers on a chart are one thing. Let's go build something.

My setup: OpenCode plus OpenRouter

For the harness I used OpenCode, the desktop app, which has become my go-to playground for trying models that aren't Claude. For the model itself I routed through OpenRouter.

Why OpenRouter and not OpenCode's own provider? Honestly, a small gripe: OpenCode Zen and the Go subscription have been slow to add new open-weights models. GLM 5.2 wasn't on either yet on the day I recorded. OpenRouter had it on day one, so that's where I went. If you want the model, OpenRouter is the path of least resistance right now.

One note for the regulars here: I'm normally a Claude Code person. I pay for Claude Max and I've said many times on this channel that it's the best agent out there. So this isn't a "Claude is bad" video. It's me, a Claude loyalist, genuinely curious whether an open model can hang.

The test: a real feature on my real site

No toy to-do app. The target was bergdaniel.com.br, my personal website. It's a fully server-rendered Next.js app where, at build time, I hit the dev.to API to populate my blog page and the YouTube API to populate my courses page. Nothing fancy, but it's real code that's actually deployed.

My blog list has grown enough that I wanted a search box. So that was the task. And here's the important part for a model review: I deliberately gave it almost no context. No "by the way, we don't have a database," no "remember this is server-rendered with ISR." I wanted to see whether the model would figure out the constraints on its own or trip over them.

This was the entire prompt:

Help me implement a search feature on the blog page. If possible, use query params and URL state for the search. Example: ?q=. Whenever the user types something on the search, no need to build an explicit submit button, use debounced searches after waiting like 300 milliseconds.

Then I switched on plan mode and hit submit. The honest test of an agent isn't whether it can follow a spec. It's what it does when the spec is vague.

Plan mode actually surprised me

GLM 5.2 is a slower, more deliberate model than the other open-weights options. I'd noticed that the day before. But I'll take a slow model that one-shots the feature over a fast one I have to argue with, so I let it think.

First it researched the codebase and reported back, correctly, that my blog page is a server component calling getArticles, regenerated with ISR every twelve hours. Then it proposed the plan: keep the page as a server component, add a new client component for the search, debounce each keystroke 300ms, then run a replace on the URL so we don't pollute browser history on every letter. Clear X button to reset, empty state when nothing matches.

But the part that got me was the reasoning. It explained, unprompted, why it chose client-side filtering:

Articles are already fetched at build time. Doing the filter client side keeps ISR intact, avoids an extra fetch per keystroke, and lets the URL state be the single source of truth.

That's exactly right. That's the trap I was hoping to watch it fall into, querying the dev.to API on every keystroke at runtime, and it sidestepped it without me saying a word about ISR. It even knew to wrap the component in a Suspense boundary because useSearchParams requires it in Next.js. This is the kind of thing I expect from Opus, not from a model I downloaded the weights for.

Then it did something only the frontier models usually do: it asked me good questions before writing code.

When a search is active, how should the "New" badge behave? (Hide while searching / keep on the first match / always on the latest)
Which fields should search match against? (Title, description, and tags (recommended))
What shows when nothing matches? (A "No articles found" message (recommended))

See that (recommended) in the options? That's a Claude move. When I talk to Claude models, they almost always mark a recommended choice in parentheses, and it's genuinely useful. Watching GLM do the same, with sensible defaults, was the moment I sat up.

The code it actually wrote

Talk is cheap, so here's the real output. This is the code that's deployed on my site right now, copied straight from the repo.

First, the change to the blog page. It stayed a server component, kept the ISR revalidation, and just handed the articles off to the new search component:

// src/app/blog/page.tsx
import type { Metadata } from "next"

import { BlogSearch } from "@/components/blog-search"
import { getArticles } from "@/data-access/blog"

export const metadata: Metadata = {
  title: "Blog | Daniel Bergholz",
  description: "Daniel Bergholz's blog"
}

export const revalidate = 43200 // 12 hours (twice a day)

export default async function Blog() {
  const articles = await getArticles()

  return (
    <main className="my-14 md:my-28 flex flex-col gap-5 max-w-5xl mx-auto">
      <h1 className="font-serif text-3xl md:text-4xl italic tracking-tight">
        Blog
      </h1>
      <hr className="w-12 border-t border-current opacity-20" />
      <BlogSearch articles={articles} />
    </main>
  )
}

Then the new client component. Notice the matches helper that searches across title, description, and tags exactly like I asked, the 300ms debounce, the router.replace with scroll: false, and the Suspense wrapper at the bottom:

// src/components/blog-search.tsx
"use client"

import { useRouter, useSearchParams } from "next/navigation"
import { Suspense, useEffect, useRef, useState } from "react"

import { Article } from "@/components/article"
import type { Article as ArticleType } from "@/lib/types"

function matches(article: ArticleType, query: string): boolean {
  const q = query.trim().toLowerCase()
  if (!q) return true
  const haystack = [article.title, article.description, ...(article.tag_list ?? [])]
    .filter(Boolean)
    .join(" ")
    .toLowerCase()
  return haystack.includes(q)
}

function BlogSearchInner({ articles }: { articles: ArticleType[] }) {
  const router = useRouter()
  const searchParams = useSearchParams()
  const queryFromUrl = searchParams?.get("q") ?? ""

  const [inputValue, setInputValue] = useState(queryFromUrl)
  const debounceRef = useRef<ReturnType<typeof setTimeout> | null>(null)

  const updateUrl = (value: string) => {
    const params = new URLSearchParams(searchParams?.toString() ?? "")
    if (value.trim()) {
      params.set("q", value.trim())
    } else {
      params.delete("q")
    }
    const queryString = params.toString()
    router.replace(queryString ? `/blog?${queryString}` : "/blog", {
      scroll: false
    })
  }

  const handleChange = (value: string) => {
    setInputValue(value)
    if (debounceRef.current) clearTimeout(debounceRef.current)
    debounceRef.current = setTimeout(() => {
      updateUrl(value)
    }, 300)
  }

  const isSearching = inputValue.trim().length > 0
  const filtered = isSearching
    ? articles.filter((article) => matches(article, inputValue))
    : articles

  return (
    <div className="flex flex-col gap-5">
      <SearchInput value={inputValue} onChange={handleChange} />
      {filtered.length === 0 ? (
        <p className="opacity-50 text-sm md:text-base">
          No articles found for &ldquo;{inputValue.trim()}&rdquo;.
        </p>
      ) : (
        <div className="flex flex-col gap-4">
          {filtered.map((article, index) => (
            <Article
              key={article.id}
              article={article}
              newPost={!isSearching && index === 0}
            />
          ))}
        </div>
      )}
    </div>
  )
}

export function BlogSearch(props: { articles: ArticleType[] }) {
  return (
    <Suspense fallback={null}>
      <BlogSearchInner {...props} />
    </Suspense>
  )
}

I trimmed the SearchInput sub-component and a couple of effects out of the snippet above so it stays readable, but everything you see is the model's actual code, untouched. The newPost={!isSearching && index === 0} line is the answer to its own "New badge" question: hide the badge while searching, show it on the latest post otherwise. It wired its own design decision straight into the JSX.

Design-wise, it matched the rest of my site without being told what the site looks like. Same border treatment, same spacing, same muted opacity. When I tested it, typing "Elixir", "React", "Fable", it filtered instantly, and pasting /blog?q=fable straight into the address bar worked too. URL state as the single source of truth, exactly as planned.

The part I didn't expect to like: restraint

After it finished, I ran npm run check and there were a couple of lint warnings. But here's the thing: the warnings were in my Tidewave proxy files, code GLM never touched. And its response was basically, "the one remaining warning is preexisting and unrelated to my changes, so I left it alone."

Some developers will hate that. They want the agent to fix everything it sees. I'm the opposite. If a model starts proactively rewriting files I didn't ask it to touch, that's how you get a 40-file diff for a one-component feature and a code review that takes longer than writing it yourself would have. GLM drew the line exactly where I'd draw it: change what I asked for, run format, check the build, and leave the rest of the repo alone.

For context, my AGENTS.md on this repo has a hard rule:

**IMPORTANT**: After making any code changes, always run:
1. `npm run format` - Format the code
2. `npm run check` - Verify no linting or type errors
3. `npm run build` - Verify the production build succeeds

GLM followed it to the letter. It formatted, it checked, it built, and it stopped. That's an agent reading its instructions and respecting their boundaries, which is harder than it sounds.

Then OpenCode crashed

Now for the honest part, because I'm not going to pretend the run was flawless. Right after I asked it to clean up the commits, OpenCode froze and threw a JavaScript error in the main process. The whole app went down on camera.

To be clear, that's an OpenCode problem, not a GLM 5.2 problem. The model's work was fine. The harness around it fell over. I relaunched, my changes were still there (just not pushed yet), and I pushed them up to deploy. Annoying, but the kind of thing that happens with fast-moving tools, and worth showing instead of editing out.

The built-in review caught something real

OpenCode ships a /review command that spins up a code-reviewer sub-agent. I pointed it at the commit GLM had made and let it go.

It found no bugs, which matches my read of the code, but it did flag two minor things: a subtle input drift while typing, and an acceptable flash on deep links. The input drift was real. The URL-sync effect was re-setting the input from the trimmed URL value about 300ms after each keystroke, which could strip trailing whitespace under your cursor. GLM fixed it cleanly:

// src/components/blog-search.tsx  (the fix)
// Keep input in sync when navigating back/forward. Skip when the URL already
// reflects the current input (e.g. trailing whitespace stripped on write) so
// the visible value doesn't shift under the cursor mid-typing.
useEffect(() => {
  if (queryFromUrl === inputValue.trim()) return
  setInputValue(queryFromUrl)
}, [queryFromUrl])

One thing worth flagging if you try this: GLM is eager to commit. The moment I used the word "commit" once, it started committing every subsequent change on its own, which isn't my default preference. I like the model to wait for my go-ahead. But to be completely fair, Claude and Codex do the exact same thing once you mention committing, so I can't single GLM out for it. At least it didn't push without asking.

So, is it actually worth it?

Remember that "43k output tokens per task" row in the table up top? That's the answer to everyone calling GLM 5.2 slow. It isn't slow because it's weak, it's slower because it thinks more: 43k output tokens per task versus 26k for GLM 5.1 and 24k for MiniMax-M3. You're paying in latency for more reasoning. After watching the plan it produced, I'll take that trade. A model that one-shots the feature after thinking for an extra minute beats a fast model I have to correct three times.

And the cost? This is the part I forgot to mention in the video, and it might be the most convincing number in the whole post: the entire session, the planning, the implementation, the code review, and the fix, cost me $0.265. That is not a typo. Twenty-six cents to ship a real feature to production. Artificial Analysis has GLM 5.2 on the Pareto frontier of intelligence versus cost, and this is what that looks like once you stop reading charts and actually build something. For an open, MIT-licensed model whose weights you can run yourself, that is hard to argue with.

Here's the sentence I didn't expect to write: this is the first time an open-weights model has genuinely impressed me on real code. Not "good for an open model." Just good. The code quality was there, the architectural instincts were there, the questions it asked were the right ones, and the speed felt close to Claude, maybe even a touch faster. From this one feature, GLM 5.2 gets my stamp of approval. I'm genuinely happy we have an open model at this level: competition is good, open weights are good, and a model you can self-host writing Next.js code this clean is a great sign for where this is all heading.

If you want to try it yourself: grab OpenCode, point it at OpenRouter, select GLM 5.2, and give it a real task instead of a benchmark. The z.ai docs have the rest of the details.

If you made it all the way down here, you're awesome, thank you for reading. Let me know in the comments whether you've tested GLM 5.2 and whether it impressed you as much as it impressed me. See you in the next one.

How I Used AI to Rebuild My SaaS From Scratch

Daniel Bergholz — Tue, 16 Jun 2026 19:40:11 +0000

On my previous video, I explained why I migrated my SaaS, CourseShelf, away from React and Inertia to Phoenix LiveView. Today I want to talk about the part everyone actually asks me about: how I did it. Did I just point an AI at a giant codebase and walk away? Did I automate the whole thing?

Short answer: I tried. Four times. And the way it ended is not the way Twitter told me it would.

Let me give you the boring details first so nobody is confused. The model was primarily Claude Opus 4.7, and the harness was Claude Code via the desktop app. I've been playing around with OpenCode, the Codex desktop app, and people keep recommending the Pi coding agent — but for this specific migration, it was Claude Code, and I have a whole separate video coming about my setup. Not today. Today is about the four attempts.

Attempt 1: the lazy test

I have this thing I like to do from time to time that I call the lazy test. I try my absolute hardest to be the laziest person alive, give the AI the smallest possible prompt, and see what comes out. It's a great way to measure how much the models have improved. I still remember when I used to write two or three giant paragraphs of context just to get something usable. Now? Two or three lines and the model often nails it. So I was curious how far "nothing" would get me.

I'd heard people on Twitter saying you can do these crazy automations — "just tell Claude Code, 'hey, migrate Bun from Zig to Rust,' and it just works." Okay. Let me try the equivalent for my app.

The prompt was basically: "please migrate this codebase away from React, use LiveView, make no mistakes." And I didn't just use Opus 4.7 — I cranked it to max effort. Then I waited. And waited. A little under an hour. Like 40, 45 minutes.

The results were horrendous.

Now, to be fair, my effort level here was a hard zero. I spent ten seconds writing that prompt and maybe two brain cells crafting it. I was judging the output on two things: UI fidelity (does the new UI look like what I had live in production, or is Claude inventing random new components?) and code quality (is this clean and maintainable?).

On UI fidelity I gave it a 2 out of 10. The funny part is the first ten minutes were genuinely good — I reviewed the homepage and it was very close to the React version. But every page after that looked like a completely different application. It felt like I'd asked Claude to build a brand new product from scratch instead of porting one frontend to another. It hallucinated components, random styles, the works.

And the code quality? When Claude actually wrote code, it was okay. But halfway through the task it announced "I'm done, I finished the migration" — and then I'd find a hundred to-do comments scattered around: "this is pending, we'll fix it later, but for a v1 this is good enough." On some pages there was literally a placeholder component rendered on the frontend that said "this page isn't built yet, coming soon."

Bro. NO. Unacceptable. First attempt: complete failure.

Attempt 2: batching the work with sub-agents

Then I tried a skill that Boris introduced on Twitter, called /batch. The idea is that when you're facing one huge task, you batch it into smaller ones — instead of one main agent trying to do everything in a single marathon conversation, you explicitly tell Claude to spin up sub-agents, one per slice of work. One agent migrates the homepage, another does the blog page, another does the playlists page, and so on.

// Detect dark theme var iframe = document.getElementById('tweet-2027534984534544489-605'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2027534984534544489&theme=dark" }

I genuinely thought this would help a lot, because attempt 1 taught me something important: context rot is real. The first few pages and components Claude migrated were great. But after minute twenty or thirty, it started hallucinating and going off-script. Batching attacks that directly — each agent has a short, focused context instead of one enormous degrading one.

And the results were better. Much better, honestly. My effort level was still zero — the only difference from attempt 1 was typing /batch at the start of the prompt. This time it took way longer before Claude started hallucinating, and I got around two or three pages that were genuinely good, both in LiveView code and in fidelity to the React version.

But Claude still pulled the same move: "hey, we're done, the migration's finished," followed by to-do comments and "coming soon" badges on the frontend. Better, but not enough.

Attempt 3: I stop being lazy

At this point I accepted the obvious: Claude does not have a crystal ball, and it cannot read my mind. I needed to be explicit. So I wrote a big markdown file with all the instructions I wanted it to follow, and I kept using the batch skill on top of it.

My effort level went from zero to about four. I spent 20–30 minutes crafting what I thought was the perfect plan, and I actually had to use some brain cells this time.

The biggest improvement here wasn't UI fidelity — it was code quality. Because Claude kept reusing conventions I had invented purely for the React/Inertia world, and porting them to LiveView where they made zero sense.

The clearest example: serializers. In Inertia you can't just query the database, grab an Elixir struct, and hand it to the frontend. You have to convert the struct into a plain map of props first. So in v1 I had a whole layer of *JSON modules doing exactly that. Here's a real one from the old codebase:

# courseshelf-v1/lib/courseshelf_web/controllers/course_json.ex
defmodule CourseshelfWeb.CourseJSON do
  @moduledoc """
  Functions for serializing course resources
  """

  alias Courseshelf.Courses.Course
  alias Courseshelf.Utils
  alias CourseshelfWeb.ChannelJSON
  alias CourseshelfWeb.PlatformJSON
  alias CourseshelfWeb.TagJSON
  alias CourseshelfWeb.UserJSON

  def serialize(nil), do: nil
  def serialize(%Ecto.Association.NotLoaded{}), do: nil

  def serialize(%Course{} = course) do
    %{
      id: course.id,
      title: course.title,
      slug: course.slug,
      description: course.description,
      thumbnail_url: course.thumbnail_url,
      view_count: Utils.format_number(course.view_count || 0),
      # ...a dozen more fields...

      # Relationships
      tags: TagJSON.serialize(course.tags),
      channel: ChannelJSON.serialize(course.channel),
      platform: PlatformJSON.serialize(course.platform),
      submitted_by: UserJSON.serialize(course.submitted_by)
    }
  end

  def serialize(courses) when is_list(courses) do
    Enum.map(courses, &serialize/1)
  end
end

And then the controller called that serializer for every single prop before handing it to React via Inertia:

# courseshelf-v1/lib/courseshelf_web/controllers/course_controller.ex
conn
|> assign_prop(:courses, CourseJSON.serialize(courses))
|> assign_prop(:pagination, pagination)
|> assign_prop(:sort, sort_string)
|> assign_prop(:tab, "courses")
|> render_inertia("courses/index")

This middle layer only ever existed because of the React boundary. And Claude was faithfully recreating it in LiveView. I had to keep telling it: "Claude, bro, just query the database and use the result on the frontend. There is no need for this middle layer." In LiveView you assign the struct directly to the socket and render it — done.

For UI fidelity, I went a different route. I explicitly told Claude to use the Playwright MCP to screenshot the live website, compare it to whatever it had just written in LiveView, and fix the discrepancies. And… I'm pretty sure Claude completely ignored that step. Same result as before: two or three pages that were extremely close to the original, and then everything else was new components invented from scratch, style guide ignored.

So attempt 3 was a good plan for code quality and still a bad result for UI fidelity. And after the third try, I was honestly starting to lose my patience and consider that maybe this wasn't going to be fully automated.

Attempt 4: I stop automating and start driving

And ladies and gentlemen, that's exactly what I did.

I took that big markdown plan and converted it into a proper skill, then manually invoked it, page by page. I wanted to personally see every component and every page and confirm they were identical to the React version, with no code smells in the LiveView underneath.

People keep asking how big this skill is. It's not huge — 152 lines, which I think is very reasonable. It encodes all the explicit decisions I didn't want Claude guessing at: what not to port, simplification rules, database schema parity, SEO parity, and a firm reminder to actually run the tests. Here's the simplification section, verbatim from the skill:

<!-- courseshelf-v2/.claude/skills/migrate-v1-to-v2/SKILL.md -->
## Simplification rules

One purpose of the migration is to remove v1 complexity that existed only
because of Inertia/React boundaries.

Do not carry over these patterns unless there is a strong new reason:

- JSON serializer layers whose main job was converting structs to props
- Controller prop plumbing that only existed for Inertia
- React-only indirection, state workarounds, or hydration-oriented conventions
- Compatibility abstractions built around frontend constraints that no longer exist in LiveView

In v2, prefer:

- Calling context functions directly from LiveViews/controllers
- Assigning structs and maps directly
- Phoenix-native forms, routes, and state transitions
- Smaller, clearer modules over migration-era abstraction layers

That serializer rule is the same lesson from attempt 3, now written down once so I never have to repeat it in a prompt again. And here's what the v2 version actually looks like in practice — no serializer, the context function returns a %Playlist{} and it goes straight onto the socket:

# courseshelf-v2/lib/course_shelf_web/live/playlist_live/show.ex
def mount(%{"username" => username, "slug" => slug}, _session, socket) do
  case Playlists.get_user_playlist_by_username_and_slug(
         socket.assigns.current_scope,
         username,
         slug
       ) do
    nil ->
      {:ok,
       socket
       |> put_flash(:error, gettext("Playlist not found"))
       |> push_navigate(to: ~p"/playlists")}

    %Playlist{} = playlist ->
      owner? = Playlists.playlist_owner?(socket.assigns.current_scope, playlist)
      socket = maybe_track_view(socket, playlist, owner?)

      {:ok,
       socket
       |> assign(:playlist, playlist)
       |> assign(:owner?, owner?)
       |> assign(:items_count, length(playlist.items))
       |> assign(:progress, Playlists.compute_progress(playlist.items))
       |> stream(:items, playlist.items)}
  end
end

The skill also makes the testing non-negotiable — it asks Claude to write LiveView tests and to run mix precommit before calling anything done, so we don't bypass the project's own rules.

Because I was manually calling this skill for every single major feature, my effort level jumped from a 4 to a solid 9 out of 10. And I want to be precise about what that means: I did not automate the migration. I automated the skill — the playbook — but the actual work, I was driving by hand. Sure, AI wrote the code, but I was manually starting like five parallel Claude Code sessions, then reviewing each page and each diff myself.

The payoff: UI fidelity went from a 6 to a 9, and code quality is a flat 10.

	Effort	UI fidelity	Code quality
Attempt 1 — pure lazy	0	2	to-do comments everywhere
Attempt 2 — `/batch`	0	a bit better	still "coming soon" badges
Attempt 3 — big markdown plan	4	still bad	much better
Attempt 4 — manual skill, page by page	9	9	10

Why isn't fidelity a 10? Because under the hood, v2 uses daisyUI for Phoenix, and v1 used shadcn/ui on the React side. If you've used my software before, you'll notice the buttons are slightly different, the dropdowns are slightly different. But I think that's completely acceptable — I'm deliberately using a different UI library, so some divergence is expected. It's not 100%, but it's about 90%.

The code smell I had to teach away

Code quality being a 10 wasn't free either. Every time I caught a code smell from Claude, I'd stop and write another skill correcting it.

The best example is around LiveView interactions. LiveView has state, kind of like useState in React — except LiveView state can only change on the server. So every time you touch it, you're doing a round trip over the websocket. For some interactions, like simply opening and closing a dialog, Claude was using LiveView state. That means a user clicks "add to library," waits ~200ms for the server round trip, and then the dialog opens. That interaction shouldn't be slow — it's pure client-side UI. I'm not fetching anything, not validating anything, just opening a modal. That should never be backend state.

So I wrote a skill about it. The core principle is one question:

<!-- courseshelf-v2/.claude/skills/liveview-interactions/SKILL.md -->
**The decision test:** *Would the server's response change what the user sees?*

- **No** → client-side. Use `Phoenix.LiveView.JS` commands directly from
  `phx-click`, or a colocated hook. No `handle_event`, no `:foo_open?` assign.
- **Yes** → server-side. `phx-click="event_name"` with a `handle_event/3` is correct.

The rule I gave Claude, in plain terms: only trigger a handle_event if you absolutely need the server — to fetch extra data, run validation, run a changeset. But if all you're doing is opening a dialog, use the JS module and push a client-side event instead. Here's the right pattern from the actual codebase — the edit button opens the modal instantly with JS.show, and a colocated hook prefills the form from data-* attributes, no server involved:

# courseshelf-v2/lib/course_shelf_web/live/playlist_live/show.ex
<.button
  variant="secondary"
  type="button"
  id="playlist-show-edit"
  phx-hook=".PrefillEditPlaylistForm"
  data-playlist-name={@playlist.name}
  data-playlist-description={@playlist.description || ""}
  data-playlist-is-public={to_string(@playlist.is_public)}
  phx-click={
    JS.show(to: "#edit-playlist-modal", display: "flex")
    |> JS.focus(to: "#edit-playlist-name")
  }
>
  <.icon name="hero-pencil-square" class="size-4" />
  {gettext("Edit")}
</.button>

The server only gets involved when there's a real mutation to run. Then it does its thing and tells the client to close the modal — one push_event after the save succeeds:

# courseshelf-v2/lib/course_shelf_web/live/profile_live/show.ex
def handle_event("save_profile", %{"user" => params}, socket) do
  case Accounts.update_profile(socket.assigns.current_scope, normalize_profile_params(params)) do
    {:ok, user} ->
      {:noreply,
       socket
       |> assign(:profile, user)
       |> assign_edit_form(user, true)
       |> push_event("edit-profile-modal:close", %{})
       |> put_flash(:success, gettext("Profile updated successfully"))}

    {:error, %Ecto.Changeset{} = changeset} ->
      {:noreply, assign(socket, :edit_form, to_form(changeset, as: :user))}
  end
end

After I wrote that skill, the results improved. But notice the loop: I had to read the code, find the smell, and then ask Claude to fix it. That's exactly why the effort level stayed at a 9.

Was it worth it?

Here's the honest math. If I had been able to fully automate this with my lazy approach, I could probably have migrated the entire CourseShelf in one night. Instead, because I migrated every single thing by hand, the whole process took almost two months — call it 35 to 40 days. And remember, this is not my full-time job. CourseShelf is a side project, so 40 days of work outside my day job is a serious chunk of my life.

But because the code quality is a solid 10, I feel completely comfortable maintaining this codebase for the long run. In my humble opinion, this is the cleanest codebase I have ever worked with — I'm not joking, it might be the best software I've ever read. I don't want to shut this thing down because it's hot garbage. I'm genuinely proud of it.

So would I love to one day get a great result on the first lazy attempt? Absolutely. But I don't think we're there yet — not if you have high standards for code quality. The AI wrote almost every line of CourseShelf v2. It just needed me sitting right next to it, reviewing every page, writing a new skill every time it drifted. That's the part Twitter leaves out.

If you made it this far, you're awesome. Let me know what other questions you have about how I did this, and I'll see you in the next one.

Claude Fable 5 review: I let Anthropic's new "bazooka" loose on my SaaS

Daniel Bergholz — Wed, 10 Jun 2026 19:50:21 +0000

Claude Fable 5 just launched, and I did what any reasonable person would do: I woke up at 6 AM, got flashbanged by an announcement page with no dark mode, read the whole thing, and then let the model loose on my production SaaS to see if the hype is real.

I recorded the whole experiment, including the exact moment Claude talked back to me for the first time ever. If you'd rather watch than read, here's the video:

This post is the written version of that experiment: what the announcement actually says, the benchmark everyone should be paying attention to, the feature Fable 5 built in my codebase (with the real code it wrote), and my honest verdict at the end. If you only care about the verdict, feel free to scroll. I do the same thing.

Fable vs Mythos: same model, different safeguards

The announcement opens with a sentence that sets the tone: Fable 5 is a Mythos-class model that Anthropic made safe for general use. It's state of the art on nearly all tested benchmarks, and the longer and more complex the task, the larger its lead over previous models.

That matches the vibe on Twitter perfectly. People are describing Fable 5 as a bazooka: point it at a huge problem, like a giant migration or a feature that touches your whole codebase, and it will run for a very long time without hallucinating. But it's still a bazooka. If you need to change two files, it's probably overkill.

Now, releasing a model this capable comes with risks, so Anthropic shipped it with heavy safeguards. And I do mean heavy: from my own testing, if you dare to mention the word "security" or anything slightly adjacent to it, Fable 5 shuts down the party and your query gets rerouted to the next most capable model, Claude Opus 4.8.

This is also where the naming confusion comes from, so let me save you some scrolling on social media:

Claude Fable 5: what we normies get. Full capabilities, with classifier-based safeguards on top (cybersecurity queries get rerouted, etc.).
Claude Mythos 5: the same underlying model with safeguards lifted in some areas, available only to a small group of cyber defenders and infrastructure providers.

Same model. Different guardrails. That's it.

The benchmark that actually matters: FrontierCode

Every announcement comes with the classic benchmark chart where the new model beats everything, and yes, Fable 5 wins everywhere. But there are two benchmarks worth zooming into.

The first is the classical SWE-bench Pro, which, let's be honest, some people say is outdated. Models have learned to ship slop code that still scores high on it.

The second is the interesting one: FrontierCode, a new benchmark created by Cognition (the company behind Devin). Instead of only asking "does the code pass the tests?", it grades what real maintainers care about: would this PR actually get merged? They built it with 20+ open-source maintainers, and they grade behavioral correctness, regression safety, scope, test correctness, and code quality.

Here's how the hardest tier (the "Diamond" set) looked before Fable 5, straight from Cognition's post:

Model	FrontierCode (Diamond)
Claude Fable 5 (max effort)	~30% (from Anthropic's chart)
Claude Opus 4.8	13.4%
GPT-5.5	6.3%
Gemini 3.1 Pro	4.7%
Kimi K2.6 (best open-source)	3.8%

The previous king scored 13.4%. Fable 5, on max effort, scores slightly more than 30%. That is not an incremental jump, that's more than doubling the state of the art on the benchmark specifically designed to punish slop.

However (and this is a big however), take a look at the cost axis of that same chart. On high effort, Fable 5 already costs around ten bucks per task, which is roughly Opus 4.8 territory. Crank it to x-high or max effort and the sky is the limit. API pricing is $10 per million input tokens and $50 per million output tokens. Keep that in mind for later, because it shapes my entire recommendation.

Oh, and the announcement also casually mentions that Fable 5 beat Pokémon FireRed using only vision: just screenshots, no terminal access to the game. It also built a solar system simulator that predicted a solar eclipse. Cool party tricks, but let's test something that actually pays my bills.

The catch nobody is talking about: you lose it on June 23

This is the part of the announcement I haven't seen anyone cover, and it's very important.

From June 9 through June 22, Fable 5 is included in the Pro, Max, Team, and Enterprise plans at no extra cost. On June 23, it gets removed from those plans, and using it will require usage credits. If capacity allows, they say they'll extend the included window.

Reading between the lines: Fable is expensive to run. Maybe they genuinely don't have the capacity to host this model for everyone. Or maybe they do, and they want to charge API pricing for it instead of including it in the subscriptions. To be honest? I think they're just money hungry, and what we're getting right now is essentially a free trial.

So don't get too comfortable. You have about two weeks to fully test this thing. Which is exactly what I did next.

Let's build a real feature in CourseShelf

Enough announcement reading. I opened the Claude desktop app with CourseShelf (my SaaS, full-stack Elixir/Phoenix LiveView; you know the story if you've been following the channel), bumped the effort level from medium to extra high on the 1M context window, and kept one eye on my five-hour usage limit, which started at 0%.

My prompt was deliberately vague, because I wanted to see how it thinks:

I want to increase user engagement. Help me improve the app or build new features. What do you suggest we do? Give me a list.

After running for almost one minute, I got a list of genuinely good suggestions. The one I liked most was number nine, profile badges / curator milestones: cheap gamification that rewards contribution (writing reviews, adding courses) rather than just consumption. It even noticed I already had a course-milestone notification type in the codebase to build on. So: "I really liked suggestion number nine. Work on it."

Here's the timeline, because the token economics matter as much as the output:

~1 min in: reading the codebase. Usage: 2%.
7 min in: still running, 109 lines changed so far. Usage: 7%.
11 min in: it's doing browser testing on its own, taking screenshots of the app with the preview to check its own work. Usage: 9%.
~12 min: done. Usage: 9%.

Quick math: one small-ish feature ≈ 10% of my five-hour limit. So on extra-high effort I could ship roughly ten of these before hitting the wall. Reasonable, honestly.

The moment Claude pushed back at me

I opened the app in my own browser to test. Profile pages now showed achievement badges (Course Scout, Playlist Pro, First Finish, Seasoned Reviewer) and they worked. But when I hovered over a badge, I got a question-mark cursor, and after a couple of seconds a native browser tooltip showed up: "Added 5 or more courses to the catalog."

So it had used the built-in title attribute instead of a frontend component. I appreciate using browser defaults, but I wasn't sure this was good UX. So I typed:

I wonder if it would be better UX if we allowed users to click on the engagement metrics and open a modal that explains what the metric means, instead of just showing the built-in browser titles.

And then something happened that I have never seen from Claude before. It agreed with the problem, and then it pushed back on my solution:

Honestly, the title tooltips have a real gap I should flag. They're desktop hover only. Mobile users and keyboard users get nothing. That said, I would tweak the shape of the fix: instead of one modal per badge, I would do one achievements modal for the whole system.

This is incredible. Previous versions of Claude Code would simply say "All right, I'm gonna ship that, no problem." Every older model was a robot with zero opinions: whatever you asked, it would do without question. That was literally my biggest complaint about them. I want a genuine pair programmer, someone with opinions and experience. Fable 5 has opinions. And its opinion was better than my idea. I said yes, obviously.

Six minutes later (usage now 12%), the modal was built: badges became clickable, opening a single achievements modal that lists every tier with the locked ones dimmed, plus an info icon. Is the UI top-notch? Honestly, no. There's a bit too much information in that modal to absorb at a glance. Good, not great. But functionally, it nailed it.

Sanity-checking the code

Before shipping anything an AI writes to production, I do a sanity check. This is the actual code Fable 5 wrote, straight from the commit.

It properly created a Phoenix context, and I love the design decision documented right in the code: badges are computed on the fly from the canonical count queries. No new table, so the badges can never drift from the real numbers:

# lib/course_shelf/achievements.ex
defmodule CourseShelf.Achievements do
  @moduledoc """
  Derives profile achievement badges from a user's contribution counts.

  Badges are computed on the fly from the canonical count queries — no
  table backs them, so they can never drift from the real numbers and
  earning one requires no write path.
  """

  @tier_thresholds [
    courses_added: [1, 5, 25],
    reviews_written: [1, 10, 50],
    playlists_created: [1, 5, 15],
    courses_completed: [1, 10, 50]
  ]

  def progress(user_id) when is_integer(user_id) do
    Enum.map(@tier_thresholds, fn {category, thresholds} ->
      count = count_for(category, user_id)

      tiers =
        thresholds
        |> Enum.with_index(1)
        |> Enum.map(fn {threshold, tier} ->
          %{tier: tier, threshold: threshold, earned?: count >= threshold}
        end)

      %{category: category, count: count, tiers: tiers}
    end)
  end

  defp count_for(:courses_added, user_id),
    do: Courses.count_user_submitted_courses_by_id(user_id)

  defp count_for(:reviews_written, user_id),
    do: Reviews.count_user_reviews_by_id(user_id)

  # ... playlists_created and courses_completed follow the same pattern
end

On the frontend, it used pattern matching to map badge tiers to the different CSS variants, which is exactly how I'd write it:

# lib/course_shelf_web/live/profile_live/show.ex
defp achievement_name(:courses_added, 1), do: gettext("Course Scout")
defp achievement_name(:courses_added, 2), do: gettext("Course Curator")
defp achievement_name(:courses_added, 3), do: gettext("Catalog Builder")
# ... same pattern for reviews, playlists, and completions

defp achievement_icon(:courses_added), do: "hero-squares-plus"
defp achievement_icon(:reviews_written), do: "hero-chat-bubble-left-right"

defp achievement_variant(1), do: "neutral"
defp achievement_variant(2), do: "primary"
defp achievement_variant(3), do: "warning"

And it wrote proper LiveView tests for the frontend, including the accessibility cases it brought up, not me:

# test/course_shelf_web/live/profile_live/show_test.exs
test "renders the highest earned badge per category as a button that opens the modal",
     %{conn: conn} do
  target = user_fixture()
  review_fixture(user: target)
  library_fixture(user: target, status: :completed)

  {:ok, lv, _html} = live(conn, ~p"/profile/#{target.username}")

  assert has_element?(lv, "#profile-achievements")
  assert has_element?(lv, "button#achievement-reviews_written[phx-click]", "First Review")
  assert has_element?(lv, "button#achievement-courses_completed[phx-click]", "First Finish")
  refute has_element?(lv, "#achievement-playlists_created")
end

I told it "This looks great. Commit and push on main" (sorry, PR purists, it's my side project), opened a terminal, ran git log, and there it was: feat: add achievement badges and explainer modal to profiles. Very nice commit message, by the way. If you're wondering whether AI can write good Elixir in 2026: that argument is long dead.

The token bill

Final tally: ~900 lines of code changed, 15% of my five-hour usage limit. And here's the thing to internalize: the one round of feedback I gave took my usage from 9% to 15%. If you go back and forth with Fable 5 a few times on extra-high effort, your usage will evaporate.

So the economics are simple:

If Fable 5 one-shots your feature: extra-high effort is fine. You can survive.
If it doesn't one-shot it: you're going to burn a ton of tokens. Drop the effort to high or medium, or use a different model entirely.

And to be fair to Fable: this one was essentially a one-shot. The feature worked on the first try; the modal round was me nitpicking the UX, and Claude turned my nitpick into a better architecture than I asked for.

Final verdict: 9/10

I rate Claude Fable 5 a solid 9/10. It's a bazooka, and it's the best model available right now. And I say this having recently used Codex and some of the Chinese models via opencode: Fable 5 beats all of them by a wide margin. It's extremely thoughtful, it runs for a very long time without losing the plot, and for the first time ever it pushed back on my ideas and gave me something better.

But it is extremely token hungry. My honest recommendation for right now:

Don't make it your default model for day-to-day work, unless your company has an infinite token budget (in which case, go wild).
Use Fable 5 to create plans, then let Opus execute them. Best of both worlds at current prices.
Remember the clock: it leaves the subscription plans on June 23. Test it while it's included.

My read on the industry: both Anthropic and OpenAI are shipping the best models they possibly can first, and optimizing for cost later. First we achieve AGI, then we make it cheap. I'd bet that in six months to a year we get a Fable 5.5 or 5.6 at the same level of performance for a fraction of the price. That's the moment this becomes everyone's default.

If you made it all the way down here, you're awesome, thank you for reading! Do you think Fable 5 is really the best model available, or is it just hype? Let me know in the comments. And if you skipped the video at the top, it's worth watching just for the moment Claude pushes back on me.

Moving my SAAS away from React (and Inertia) to Elixir

Daniel Bergholz — Tue, 02 Jun 2026 18:22:23 +0000

If you've been following my journey, you know I went all in on Elixir a while ago. I left the React treadmill behind, picked Phoenix, and to keep React on the front end I used Inertia.js. For a year, I was happy. I built my SaaS, CourseShelf, and I had a lot of fun doing it.

And then I deleted all of it. 345 commits later, I have completely rebuilt CourseShelf from scratch, this time on full-stack Elixir with Phoenix LiveView. No more React. No more Inertia. No more Node.js.

This is the story of why I did it.

The honeymoon was real (and then it ended)

I want to be fair to Inertia here, because Inertia is genuinely great. When I first adopted it, I was writing every line of code by hand, and the experience was wonderful. You get the productivity of Phoenix on the back end and you get React on the front end, glued together without a REST API in the middle. For someone coming from the React world, it felt like the best of both worlds.

But about six months ago I recorded a video with a title that probably gave away the ending: "Do I regret picking Inertia over LiveView for my SaaS?" And the honest answer was yes.

If you want the full side-by-side, that video does a proper comparison. But the TL;DR is simple: LiveView is simpler. Not just fewer layers of code, but fewer layers of infrastructure.

With Inertia, my React front end couldn't render itself on the server for free. To get good SEO, I needed server-side rendering, and to get server-side rendering I needed a pool of Node.js workers sitting next to my Elixir app, rendering React to HTML before sending it down. So I was maintaining two ecosystems instead of one. Elixir for the back end, and a whole Node.js runtime just to draw the first paint.

The real killer: AI agents couldn't write Inertia code

Here's the thing that actually pushed me over the edge.

Inertia was a joy when I was hand-writing everything. But the moment I started moving toward agentic coding, the cracks appeared. Not a single AI agent out there could produce good Inertia code. I'd ask for a feature, and the agents would just keep spinning, generating code that didn't fit the pattern, didn't wire up correctly, didn't work.

And I realized: this is a ticking time bomb. Someday I'm going to sit down to build a feature, and I simply won't be able to, because the agents will choke and I'll be back to writing every layer by hand.

To be fully transparent, a lot of this wasn't Inertia's fault as a library. It was specifically the Inertia Phoenix port. If you're a PHP/Laravel developer using Inertia, you have far more official support, more tooling, and the AI agents write much better code for you. You even get Wayfinder for end-to-end type safety between your backend and your frontend.

We don't have that in Elixir. For v1 of CourseShelf, I was creating the types of everything by hand. I literally had a types/ folder, and every time I added a resource on the back end, I had to go write a matching TypeScript type on the front end. No code generation. Pure manual labor.

// assets/js/types/course.ts  (CourseShelf v1)
export type Course = {
  id: number
  title: "string"
  slug: string
  url: string
  description: "string | null"
  thumbnailUrl: string | null
  difficultyLevel: DifficultyLevel
  status: CourseStatus
  estimatedDuration: number | null
  price: number | null
  insertedAt: string
  updatedAt: string
  // ...and on, and on, kept in sync by hand
  submittedBy?: User
  platform?: Platform
  channel?: Channel
  tags?: Tag[]
}

So: a paradigm the AI couldn't help me with, a port with second-class tooling, and a types folder I babysat by hand. I made the call to switch to full-stack Elixir.

The new stack

The biggest change is the front-end layer, which I'll get to. But I also used the rebuild as an excuse to rip out an expensive piece of my infrastructure: managed Postgres on Fly.io, where I host everything.

Fly's managed Postgres is an amazing service. But it costs around $38/month for the first tier (one database plus a read replica), and I just don't have the scale to justify that. If you go to CourseShelf right now, you can count the accounts: I have 89. On a great day, when I tweet about it and get a traffic spike, I'll see around 130 users. On an average day it's more like 20. That is nowhere near enough to warrant a $40/month database.

So I switched to unmanaged Postgres, which runs me about $7/month. The catch with unmanaged is that I'm now responsible for my own backups, so I added Tigris, another Fly.io service. It's S3-compatible (you literally use the AWS CLI to poke at it), and since I'm only storing tiny database backups, I'm paying essentially nothing for it.

And the front end, of course, is now LiveView.

One file vs. three

Let me show you the thing I love showing in every video: how much simpler the front end gets.

In LiveView, you basically have one layer. One file defines your queries, your mutations, and your markup. Here's the actual course listing page from CourseShelf v2:

# lib/course_shelf_web/live/course_live/index.ex
defmodule CourseShelfWeb.CourseLive.Index do
  use CourseShelfWeb, :live_view

  alias CourseShelf.Courses

  @page_size 15

  @impl true
  def mount(_params, _session, socket) do
    {:ok,
     socket
     |> assign(:page_title, gettext("Courses"))
     |> assign(:page_url, url(~p"/courses"))}
  end

  @impl true
  def handle_params(params, _uri, socket) do
    search = params |> Map.get("search", "") |> to_string()
    page = parse_page(params["page"])

    result =
      Courses.list_active_courses(page: page, page_size: @page_size, search: search)

    {:noreply,
     socket
     |> assign(:search, search)
     |> assign(:page, result.page)
     |> assign(:courses, result.entries)}
  end

  @impl true
  def render(assigns) do
    ~H"""
    <section id="courses-grid" class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 xl:grid-cols-4 gap-5">
      <.course_card :for={course <- @courses} course={course} from={@current_url} />
    </section>
    """
  end
end

If you're new to Elixir, here's the quick tour:

mount/3 is your first render. Think of it as the useEffect that runs once. I'm just assigning some SEO stuff here.
handle_params/3 runs right after mount on this page. This is where I query all the courses and assign them to a courses variable.
render/1 draws the page, and it reaches into those variables through the assigns argument.

Inside the markup, notice <.course_card ...>. Unlike React, where a component is uppercase, here you call a component with dot syntax. The :for={course <- @courses} is LiveView's nice little syntactic sugar for a loop, and the @ is sugar for "reach into assigns and grab this variable."

That's the whole thing. Query my courses, assign a variable, loop over it. One file.

Now let me show you what the same page looked like in Inertia.

First, I needed a controller. That's file number one:

# lib/courseshelf_web/controllers/course_controller.ex  (v1)
conn
|> assign_prop(:courses, CourseJSON.serialize(courses))
|> assign_prop(:pagination, pagination)
|> assign_prop(:sort, sort_string)
|> render_inertia("courses/index")

See that assign_prop(:courses, CourseJSON.serialize(courses))? That serialize call is the problem. I cannot send an Elixir struct to a React front end. I have to convert it into a plain map first. So that's a whole separate module, file number two:

# lib/courseshelf_web/controllers/course_json.ex  (v1)
defmodule CourseshelfWeb.CourseJSON do
  alias Courseshelf.Courses.Course

  def serialize(%Course{} = course) do
    %{
      id: course.id,
      title: course.title,
      slug: course.slug,
      thumbnail_url: course.thumbnail_url,
      difficulty_level: course.difficulty_level,
      # ...every single field, by hand
      tags: TagJSON.serialize(course.tags),
      channel: ChannelJSON.serialize(course.channel),
      platform: PlatformJSON.serialize(course.platform)
    }
  end

  def serialize(courses) when is_list(courses), do: Enum.map(courses, &serialize/1)
end

And then, finally, file number three: the React page that receives the props and renders them, with that hand-maintained TypeScript type from earlier sitting behind it.

// assets/js/pages/courses/index.tsx  (v1)
export default function CoursesIndex({ courses, pagination, sort }: Props) {
  return (
    <div className="grid grid-cols-1 sm:grid-cols-2 md:grid-cols-3 lg:grid-cols-4 gap-5">
      {courses.map((course) => (
        <CourseCard key={course.id} course={course} />
      ))}
    </div>
  )
}

So to render a course listing — the easy case — I'm navigating through a controller, a JSON serializer, and a TypeScript component. Three layers. And listing data is the simple part; mutations are a whole different beast.

This is why LiveView is absolute cinema for me. One file versus three.

The infrastructure bill nobody warned me about

The cost story isn't just the database. The most painful lesson was about memory.

I run the same size server for both v1 and v2: one machine, 1GB of RAM, 1 CPU. But here's the difference.

CourseShelf is a public website, so I need good SEO, which means I need server-side rendering. React is not a server-first framework, so to render it on the server I had to lean on that Node.js worker pool I mentioned. By default the Inertia Phoenix library spins up four Node.js workers. "Perfect," I thought, "I can server-render React, that's all I needed."

It's never that simple.

Each Node.js worker was eating about 150MB of memory. Four of them is 600MB — gone, just for rendering. Meanwhile Elixir's own baseline for a SaaS this size is around 200–300MB. Out of a 1GB machine, I was constantly bumping against the ceiling. My memory usage hovered between 90% and 100%, and my server would randomly fall over with out-of-memory crashes.

The frustrating part? A year and a half ago, AI wasn't what it is today, and I didn't have the infra knowledge to debug it. I just knew my "performant Elixir app" kept crashing, and it made me furious. So I left it broken and ate the occasional crash.

Same machine today, with the JavaScript layer completely removed, my memory usage averages 250MB. A quarter of what's available. The thing that used to run at 100% now idles at 25%.

	v1 (Inertia)	v2 (LiveView)
Database	Managed Postgres, ~$38/mo	Unmanaged Postgres, ~$7/mo
Server	1GB RAM / 1 CPU	1GB RAM / 1 CPU
Front-end runtime	Elixir + 4 Node.js workers	Elixir only
Avg memory usage	90–100% (constant OOM crashes)	~25%

"But you lose all the nice front-end stuff, right?"

This is the part everyone pushes back on. After I posted about the switch, the same questions kept coming up on Twitter, so let me answer them with real code from the new codebase.

"You'll lose rich UI interactions."

Loading states? Load-more buttons? Drag and drop? All there.

For simple stuff — toggling a class, a transition, showing or hiding an element — Phoenix ships an entire module for it: Phoenix.LiveView.JS. You write what looks like an Elixir function right in your markup, and it runs entirely on the client with zero server round-trips:

<button
  phx-click={
    JS.show(to: "#description-full")
    |> JS.hide(to: "#description-truncated")
    |> JS.show(to: "#show-less", display: "inline-flex")
    |> JS.hide(to: "#show-more")
  }
>
  Show more
</button>

And when you need real JavaScript — like drag-and-drop — you use hooks. The new thing I love here is colocated hooks: the JavaScript lives in the same file as the markup it controls. No separate hooks directory, no importing each file one by one.

For the playlist reordering on CourseShelf, I dropped the minified SortableJS library into assets/vendor/, exposed it on the window in my root app.js...

// assets/js/app.js
import Sortable from "../vendor/sortable"
// Expose Sortable to colocated hooks (e.g. .PlaylistSort).
window.Sortable = Sortable

...and then wrote the hook right next to the grid it powers:

# lib/course_shelf_web/live/playlist_live/show.ex
<div id="playlist-items-grid" phx-hook=".PlaylistSort" phx-update="stream" ...>
  <div :for={{dom_id, item} <- @streams.items} id={dom_id} data-item-id={item.id}>
    <.playlist_item item={item} ... />
  </div>
</div>

<script :type={Phoenix.LiveView.ColocatedHook} name=".PlaylistSort">
  export default {
    mounted() {
      this.sortable = window.Sortable.create(this.el, {
        handle: ".playlist-drag-handle",
        animation: 150,
        onEnd: (evt) => {
          if (evt.oldIndex === evt.newIndex) return
          const ids = Array.from(this.el.children)
            .map((child) => child.dataset.itemId)
            .filter(Boolean)
          this.pushEvent("reorder_items", { ids })
        }
      })
    },
    destroyed() {
      if (this.sortable) this.sortable.destroy()
    }
  }
</script>

Drag a card, drop it, and pushEvent tells the server the new order. Reload the page and it's persisted. Feels great.

"Every page navigation is a full reload."

Nope. This is the most common misconception about LiveView. The whole goal of LiveView is to replicate the React feel as closely as possible.

Open your network tab and you'll see one WebSocket connection established on first load. After that, every page transition reuses that same socket — LiveView just patches the page, sends down the bits that changed, and renders them. No new HTTP request, no full reload.

The one caveat: when you cross between a public page and a private page, you do get a full refresh, because I'm tearing down the unauthenticated socket and opening an authenticated one. But navigating within the authenticated app — dashboard to settings and back — reuses the same socket. You pay the loading cost once, and everything after is instant.

"Is AI actually good at LiveView?"

This is the one that matters most to me, given why I left in the first place. And the answer is yes — AI is extremely strong at writing LiveView.

The reason is that LiveView now ships with an AGENTS.md file packed with guidance on how to write proper Elixir, Phoenix, and LiveView code. The agents pick it up and the results are great out of the box. (I actually split mine into two files to save a bit on context, but the default already gets you most of the way.)

This is the exact opposite of my Inertia experience. There, the agents spun forever. Here, they ship.

"I'll miss shadcn/ui."

Worry not, my friend. The latest version of Phoenix uses daisyUI by default, with dark and light themes out of the box. I actually stripped out the light theme on CourseShelf to keep things simple, but you get it for free. My buttons, inputs, badges, and modals are all daisyUI tokens — btn-primary, bg-base-200, text-base-content — so I'm barely writing custom CSS anymore.

Was it worth it?

The migration took me almost a month, and it was genuinely tiresome. 345 commits of rebuilding something that already worked is not most people's idea of fun.

But look at what I got: one front-end layer instead of three, a server that idles at 25% memory instead of crashing at 100%, a database bill cut from $38 to $7, one ecosystem to maintain instead of two, and — most importantly — a stack the AI agents actually understand. The ticking time bomb is defused.

The "perfect tech stack" doesn't exist. But the perfect stack for me, right now, building the kind of product I'm building, is full-stack Elixir and LiveView. If you went through a similar journey to mine, maybe it'll be yours too.

Go test the new CourseShelf and let me know how it feels — does navigating between pages feel fast? Does the UI look good? I want every bit of feedback I can get.

And if you reached the end of this post, you're awesome. Thank you for your time.

Announcing CourseShelf: Rotten Tomatoes for Online Learning

Daniel Bergholz — Wed, 21 Jan 2026 22:10:59 +0000

Back in 2019, I created TechSchool, an open-source platform to help people find free programming courses. The idea was simple: fight back against predatory coding bootcamps that charge thousands of dollars for content that's often worse than what's available for free on YouTube.

TechSchool worked. People found great courses. The community grew. But over time, I started noticing something.

The limitations of TechSchool

TechSchool had two big problems:

One, it was limited to tech. My friend who wanted to learn guitar couldn't use it. My mom who wanted to learn cooking couldn't use it. The core idea of community-curated courses was valuable, but I was artificially limiting who could benefit from it.

Two, adding new courses required opening a Pull Request on GitHub. Great for developers, terrible for everyone else. Most people who want to learn don't know what Git is, and they shouldn't have to.

I kept thinking: what if we could build something bigger? A place where anyone could discover quality courses in any subject, reviewed by real learners instead of marketing departments?

Enter CourseShelf

CourseShelf is the spiritual successor to TechSchool. Think of it as Rotten Tomatoes for online learning.

Here's the core idea: when you're looking for a movie to watch, you check Rotten Tomatoes or IMDb. You trust the crowd more than the trailer. Why should finding a good course be any different?

Right now, if you want to learn something new, you either:

Trust the platform's algorithm (which prioritizes engagement, not quality)
Trust sponsored reviews (which are basically ads)
Hope you get lucky

CourseShelf fixes this by letting real learners review and rate courses. No fake reviews. No sponsored content. Just honest opinions from people who actually completed the course.

Website: https://thecourseshelf.com

What you can do on CourseShelf

Here's a quick overview of the features:

Discover courses across any subject, not just tech
Read and write reviews with star ratings
Save courses to your library to track what you want to learn
Create playlists to curate learning paths for yourself or others
Follow other learners to see what they're learning and recommending
Verify your channel if you're a course creator on YouTube

Right now, the platform supports YouTube courses and books. We have plans to add support for other platforms like Coursera, Skillshare, and Domestika in the future.

For course creators

If you're a content creator, CourseShelf has something special for you. You can verify your YouTube channel and get a verified badge on your profile. This helps learners identify official creators and gives you credibility.

Verified creators also get access to analytics: see how many people are viewing your courses, what they're saying in reviews, and how you compare to others in your category.

I created TechSchool because I was frustrated that my free courses had fewer views than paid garbage. CourseShelf is my attempt to fix the discoverability problem for all creators who are putting out quality content.

The tech stack

I built CourseShelf using Elixir and Phoenix with React and TypeScript on the frontend via Inertia.js. If you've read my blog post about leaving React for Rails and then Elixir, you know this is the stack I fell in love with.

Phoenix gives me the productivity of Rails with the performance and reliability of the Erlang VM. Inertia.js lets me use React without the complexity of building a separate API. It's the best of both worlds.

Disclaimer

CourseShelf is currently in beta. We're actively adding features, fixing bugs, and improving the experience based on feedback. If you find something broken or have a suggestion, please let me know!

Some features are limited during beta, but the core experience of discovering and reviewing courses is fully functional.

Join the community

I built TechSchool because I believe tech education should be accessible to everyone. I'm building CourseShelf because I believe all education should be accessible to everyone.

If you're a self-taught learner, a course creator, or just someone who's tired of wasting money on bad courses, give CourseShelf a try. And if you know a great course that deserves more attention, add it to the platform!

Let's build the largest community-curated database of online courses together. We are all gonna make it 🔥

Stay up to date with new features and announcements:

Twitter: @courseshelf
LinkedIn: CourseShelf

Thank you

If you reached the end of this post, thank you for your time. Building in public is scary, but seeing people use something I created makes it worth it.

Have questions? Want to chat? Find me on Twitter @danielbergholz or drop me an email.

See you on CourseShelf!

My AI-Powered Workflow for Writing Elixir and Phoenix with Windsurf

Daniel Bergholz — Mon, 10 Mar 2025 14:41:03 +0000

There's a ton of stuff out there about using AI to write JavaScript and Next.js code, but what about Elixir and Phoenix? Are they getting left behind in the LLM code generation game? Well, yes and no. Can we make it better? Definitely. Is it worth the effort? Hell yeah. And can we actually become those legendary 10x engineers by writing Elixir with AI-powered tools like Cursor or Windsurf? You bet we can!

First, why Windsurf and not Cursor?

This year I tried using both Cursor and Windsurf for a month to see which one I'd stick with. The code they generated was pretty much the same (not surprising since they both use Claude 3.5 Sonnet). But Windsurf was better at understanding my codebase and grabbing ideas from my existing files, plus its UI just felt smoother and more intuitive. Honestly though, these AI tools are copying each other's features so quickly that it probably doesn't matter which one you pick - they're both solid options.

Does AI generate good Elixir and Phoenix code?

AI can handle the basics pretty well. Need a simple controller that renders a page? Or a basic LiveView with a bit of server-side state? Claude's got you covered.

But here's the thing - the more niche your tech stack gets, the less reliable AI becomes. Take my setup for example: I use Elixir, Phoenix, React, and Inertia for my side projects. The Inertia adapter for Phoenix is super new and not widely adopted yet (which is a shame - this combo is incredibly productive and performant). There's just no way current AI models have enough training data on this specific stack to generate useful code. The more specialized your tools, the more you'll need to rely on your own expertise rather than AI assistance.

This isn't just an Elixir thing - it's the same story with any tech that hasn't gone mainstream yet. Languages like Zig, Gleam, or Scala (and whatever frameworks people build with them) just don't have nearly as much code floating around online as JavaScript or Python do.

How to improve?

I mainly use two features in Windsurf: memories and rules.

Memories are like Windsurf's personalized notepad. Did Claude mess up by using assign/3 instead of assign_prop/3 inside a controller to pass Elixir data to React? Just point out the mistake. If Windsurf thinks it's important, it'll remember this for your entire coding session and avoid repeating the error.

You can be direct about it too: "Hey, you got X wrong. The correct way is Y. Please create a memory for this."

Rules are more permanent and explicit. Just create a .windsurfrules file in your project's root directory with specific instructions (similar to how .cursorrules works). These rules will guide Windsurf every time it helps with your code.

Here is my current .windsurfrules for Phoenix + Inertia:

You are an expert in Elixir, Phoenix, PostgreSQL, JavaScript, TypeScript, React, Inertia, and Tailwind CSS.

# Elixir and Phoenix Usage

- In controllers, use `assign_prop/3` to assign props to the Inertia page and then `render_inertia/2` to render Inertia pages.
- In controllers tests, use `inertia_component/1` to assert the component name and `inertia_props/1` to assert the props.
- When generating migrations, use `mix ecto.gen.migration <name>`
- Use plural form for context modules (e.g., "Users" for users table)
- Use singular form for schema modules (e.g., "User" for users table)
- Context files are usually inside a folder named after the resource (e.g., lib/my_app/users.ex)
- Schema files are usually inside a folder named after the resource (e.g., lib/my_app/users/user.ex)
- Prefer keyword-based queries over pipe-based queries
  - For example, use `from(u in User, where: u.age > 18, select: u)` over `User |> where(age: 18) |> select([u], u)`
- Use `dbg/1` to debug code.

# React and Inertia Usage

- Pages are in assets/js/pages. Use default export for pages.
- Components are in assets/js/components. Use named exports for components.
- Utils are in assets/js/lib.
- Inside pages, get the props from the controller as regular props from the function argument.
- When dealing with forms, use the `useForm` hook from Inertia
- Use absolute paths for local imports using `@/`
- If you need to merge tailwind classes, use the `cn` function from assets/js/lib/utils.ts.
- Import Radix components from "radix-ui", not from "@radix-ui/react-dialog" or "@radix-ui/react-button" etc.
- Always create the mobile version of the component along with the desktop version.
- Use lucide-react for icons.
- Use kebab-case for file names.
- If the page or component uses a type for a resource from the database, like users or courses, create the type in the assets/js/types folder.
- Prefer types over interfaces.

# General Usage

- When debugging data from the database, if the postgres_my_app MCP is not avaiable, use `psql my_app_dev -c "<your query>"` to connect to the database and then run the query. There is also the my_app_test database for testing.
- Use the `mix check` command after generating lots of files to check the Elixir and React code for errors and code quality. If you encounter format errors, use `mix format` to fix them.
- If any of my requests are not clear, ask me to clarify.
- If you have better suggestions, feel free to suggest them.

Getting Up-to-Date Info

This is a super underrated feature when working with frameworks that change all the time (like Next.js) or more niche ones (like Phoenix). Remember: AI is great at general knowledge, but the more specific you go, the less likely it'll get things right. To fix this, just use the @web directive and drop in links to any documentation you think is relevant.

Sanity Check After a Long Coding Session

It's all fun and games when Claude spits out 20 new files and everything looks fine. But are you actually checking all these files for formatting issues, type errors, or compilation warnings? And how do you make sure your code quality isn't tanking over time? Sometimes AI misunderstands what you want and goes off on a tangent, potentially wrecking hours of your hard work.

That's why I made a simple script called "check" (my mental "sanity check") that I ask Claude to run after long coding sessions to make sure everything's still good.

# mix.exs

defp aliases do
  [
    check: [
      "format --check-formatted",
      "cmd npm run typecheck --prefix assets",
      "deps.unlock --check-unused",
      "compile --warnings-as-errors",
      "credo --strict"
    ]
  ]
end

This script does a few key things: checks for formatting issues (my .windsurfrules file tells Claude to just run mix format to fix these), runs the "typecheck" script from my NPM project (React + Inertia) in the assets folder, looks for unused dependencies, checks for compilation warnings like unused variables or aliases, and finally runs credo in strict mode to catch problems like oversized functions or deeply nested conditionals.

This way, you can sleep easy knowing your app not only works but also has solid code quality with no warnings or errors hanging around. This is just my version of the check command - feel free to create your own with checks that make sense for your project. And if you want Claude to run both the "check" script and your tests after generating code, just add that rule to your .windsurfrules file!

A Word of Caution

This pro tip isn't specific to Elixir, but worth mentioning: be careful with generating code using AI - it can get expensive fast. Don't let the $15/month price tag fool you. This month alone I bought extra credits for Windsurf 3 times ($10 per 300 new credits). That brought my monthly cost to $45!

How to avoid this? My rule is simple: only ask Claude to generate code once I'm really confident about what I want to build. If you have a clear PRD (Product Requirements Document), there's a 95% chance Claude will "one shot" the solution. This is way better than going back and forth, generating code, rejecting it, and generating again.

TL;DR: Spend more time planning rather than generating code. In this new era, code has become a "low level thing" that machines generate, while we humans can focus on higher level problems like crafting a good plan for an MVP, figuring out what users actually want, achieving product-market fit for our startup, etc.

Moral of the story

Look, AI definitely has some blind spots with Elixir and Phoenix code - but as I've shown throughout this post, there are some pretty simple workarounds for most of these issues.

From my experience, the productivity boost is totally worth dealing with these little hiccups. That mythical "10x engineer" everyone talks about? It's not just hype - anyone can get there if they're willing to embrace these new tools.

The real trick is keeping an open mind and constantly trying new stuff. Don't get stuck doing things the old way just because that's how you've always done it.

Announcing TechSchool: A free and open-source platform to learn programming

Daniel Bergholz — Tue, 05 Mar 2024 22:52:54 +0000

Since 2019 I have published free courses on my YouTube channel. Many times, people have commented on my videos something like "Wow, this course is amazing! It's a lot better than the expensive course I purchased!". I started reflecting after that. Why on earth is someone getting paid thousands of dollars selling a course that is worse than the one I made for free? Also, why does my course only have 100 views on YouTube? This isn't fair.

Identifying the problem

There are lots of people who want to learn programming and also lots of free courses available. However, most of the time, these two groups don't meet each other.

Why? Two reasons. One is that multiple VC-backed predatory coding bootcamps spend millions of dollars targeting newcomers and telling them that the only way to get into the industry is by spending all their money on expensive online courses. Two, the YouTube algorithm is super hard to master. If you recently created a channel, it can take years to reach a bigger audience.

The solution

What if we could easily find all the free courses out there without the YouTube algorithm standing in our way? That's where TechSchool steps in. It is a platform that contains all the free content that might be flying under the radar. It is also open-source, which means anyone who knows a cool course can easily open a PR to add it.

Website: https://techschool.dev
Discord: https://discord.gg/C4abRX5skH
GitHub: https://github.com/danielbergholz/techschool.dev

Let's fight back against the expensive barrier to entry! Tech education should be free and accessible to everyone! We are all gonna make it 🔥

Disclaimer

TechSchool is forever a work in progress. We are all collectively adding more content over time, so if you don't like the options available right now, wait a couple of weeks and then re-visit the website! I'm sure you'll find something new.

The tech stack

I have it all explained on the README, but in summary, I decided to use Elixir and Phoenix, because it's a freaking AWESOME combo. I'm also using Live View on all pages, so hopefully the transition between them is super smooth!

From Next.js to Rails then Elixir: My journey through React.js burnout

Daniel Bergholz — Wed, 10 Jan 2024 23:29:41 +0000

I've been a web developer since 2019. I used React.js and React-based frameworks like Gatsby, Next, Remix, Astro, and Hydrogen. I've never been fully content with any of these tools, but, as a beginner who was deep into the JS ecosystem, all that I could hear from my peers was something along those lines: "This is the way, any other programming language is either slow or old".

As a result, I got used to a huge amount of complexity: Multiple separate repositories, thousands of libraries and frameworks to achieve simple things, GraphQL, microservices, serverless, static site generation, incremental static regeneration, partial hydration, redux, redux-thunk, babel, webpack, react server components, server actions, etc. This list could go on for another 10 minutes.

Until one day I said ENOUGH IS ENOUGH! Let's take a look at the complete timeline of me slowly going mad. This will take a while, feel free to make some coffee before the long read!

The timeline of the burnout

Gatsby.js

I remember finishing my bootcamp and thinking: "Finally I'm able to build my portfolio!", and so I did. There was only one small problem, I wanted to index on Google, but using the good old create-react-app made this mission nearly impossible. Soon I learned about SEO and React's hydration cycle, which led me to the "solution" of this problem: Gatsby.js. The idea of static site generation was simply revolutionary for me back then, after all, nothing is faster than pre-rendered HTML files, right?

I decided to learn this new framework by reading the docs and let me tell you, this was NOT a fun experience. I have never heard of GraphQL before, and apparently, you needed it to generate all the static files (what the hell???). I asked some of my internet friends if having a hard time learning all of this overengineered crap was normal, and they replied with "Skill issue, try harder!". So I tried harder, and after finally learning it, I ported my personal website to Gatsby.

Most of my pages were successfully indexed on Google, and for a couple of months, I was extremely satisfied with the result. Then another problem appeared: A LOT of my developer friends started saying "Gatsby is dead! Next was created to simplify static site generation and also provide server-side rendering".

Next.js

I took a quick glance over the Next documentation and immediately fell in love. I was able to do the same things as Gatsby without GraphQL and with a third of the code! Once again, I ported my portfolio to another framework: Next.

This time I truly had a wonderful experience. Deploying to Vercel was a breeze, the getStaticProps and getServerSideProps functions were simple, yet extremely powerful, I could choose the rendering style per page, a lot of flexibility in general.

Unfortunately, something I learned the hard way: In the JavaScript ecosystem, all the good things come to an end.

Remix

I remember extremely well when Remix was announced. Multiple tech influencers started publishing content about it (as always). However, back then I read on the home page that it did not support static site generation, just server-side rendering, so I thought "Wait a sec, all those years investing on the JAMstack are thrown away here? No way, this framework ain't gonna last". However, to my surprise, not only did Remix survive, but it was acquired by Shopify and emerged as a prominent competitor to Next.

After a couple of months had passed, I decided to give it a try. And once again, I was surprised, the main motto of Remix is to use the web fundamentals, and not an overly complex caching system like Next. So the mental model I needed in my head when coding in Remix was 10 times simpler: No global state manager, just use the URL, fewer client-side states, move all that logic to the server, and use cookies, going full stack without a REST API in the middle is super easy, just move your database queries to the loader function.

Leaving the Matrix

Then, out of nowhere, the truth was presented to me, and I took the red pill. Multiple questions started emerging in my head: Isn't Remix just like all the other "old and boring" frameworks like Rails, Laravel, and Django? We have been doing fullstack web development with server-side rendering for decades, but the JavaScript mafia decided collectively that this approach was trash, and moving everything to the client was the future. Did the same mafia decide that Rails was right all along? And doing all those over-engineered monstrosities with JS frameworks was not the right move? I started questioning everything. This "new" way of doing web development was a lot simpler and faster.

I'm DONE with Next and Vercel

I reached my tipping point with Next.js app router. Here is a comprehensive list of everything wrong that Vercel is pushing to Next:

What was once simple: The getStaticProps and getServerSideProps functions, now became complex and cumbersome. Currently, there is no specific place to add your API calls or database queries, you can write them wherever you want! We started mixing the business logic with UI once again, after making the same mistake with PHP multiple years ago. Do frontend developers not learn from the past? What happens if I delete a button? Does this break my user authentication flow because the database call was inside it? Your front end should be 100% trashable and replaceable. The competitive advantage you have against your competitors is the business logic, which should be completely isolated from the UI layer.

Next is now server first. Which doesn't sound that bad right? After all, this solves the SEO issue and shows fresh content to the user immediately. The problem is that most of the existing Next codebases relied on client-side libraries, like Styled Components and a couple of global state managers. What does this mean? With breaking changes like this happening constantly, your app becomes legacy software in a couple of weeks instead of years. More time is spent to keep all dependencies up to date rather than doing what matters: Shipping features.
Vercel hired multiple React core team members from Meta. This presents a serious conflict of interest because these engineers are now (allegedly) shipping features that are beneficial to Next instead of prioritizing the ones that could help all the React-based frameworks like Remix.

I couldn't take it anymore. I said to myself: You know what? I am tired of re-learning the same framework over and over again, and I completely disagree with this new paradigm.

Not surprisingly, other content creators were going through a similar situation:

The Path to Enlightenment

TL;DR: I was extremely tired. After getting burned out from all the React tools, my journey for simpler web frameworks started. Here are the prerequisites I was looking for:

Batteries included
Convention over configuration
Good developer experience
Modern and performant frontend

My first instinct was to take a look at the top frameworks from the Stack Overflow Survey 2023. Immediately I cut out from the list anything JS, C# and Java related. I never had any desire to learn the last two, they look ugly and verbose. So the remaining options were: Laravel (PHP), Django (Python), Rails (Ruby), and Phoenix (Elixir).

Python is a language that I used during my Network Engineering degree and I had a very pleasant experience. Django seemed to follow the convention over configuration philosophy, but what turned me down from it ultimately was not having a good built-in tool to work on the front end. Most people on forums said they were using HTMX and Alpine, however, both are external dependencies that you need to install.

Giving up on Laravel was extremely hard because it has an amazing cost benefit, with hundreds of official packages to handle pretty much anything a startup might need, like hosting, authentication, stripe payments, etc. For the front end, they created inertia.js, a very simple and elegant way of keeping the high productivity and powers from Laravel while using React on the front end. To be 100% honest here, the only reason I didn't choose Laravel was because of PHP's syntax, it looks ugly as hell with a bunch of $ and -> everywhere.

Ruby on Rails

Ruby on Rails needs no introduction. It's the OG of web development frameworks, with the revolutionary "build a blog in 15 minutes", which is still impressive to this day. Before I start ranting about all of the problems I found, let's start with the good stuff.

Similar to Python, Ruby is that language that you can show to non-technical people and they will understand what the software is trying to do. It is by far the easiest to read and the most beautiful language I've ever seen. I quickly realized that writing visually pleasing code was a priority for the Rails team, and that was new to me.

Not to mention that Rails pretty much invented the "Batteries included" and "Convention over configuration" philosophies, so this wouldn't be a problem. Inside one single documentation, everything I needed for any type of web application was available.

On the frontend side, there is Hotwire, a very simple and lightweight approach to all the UX improvements provided by SPA frameworks. I've always been curious to test the limits of this library, it looks very promising.

Alright, so on paper Rails passed on all of the prerequisites I wanted on a framework. Let's try it! The first thing I tested locally was the rails scaffold command. And immediatly I was SHOCKED. One single command generates everything I need for a CRUD? No way!

On Node + React land, to achieve the same thing, I would need to manually write all the code (there are no generators here) and install a bunch of libraries like: Vite, prisma, express, react router, redux, redux-thunk, vitest, cypress, react testing library, zod, typescript, eslint, prettier, 1000 different plugins, and maybe even GraphQL or tRPC. Basically a package.json with 900 dependencies already.

After the initial shock from rails scaffold, I was shocked once again when I opened the code from the controller:

class ArticlesController < ApplicationController
  def index
    @articles = Article.all
  end

  def show
    @article = Article.find(params[:id])
  end

  def new
    @article = Article.new
  end

  def create
    @article = Article.new(article_params)

    if @article.save
      redirect_to @article
    else
      render :new, status: :unprocessable_entity
    end
  end

  def edit
    @article = Article.find(params[:id])
  end

  def update
    @article = Article.find(params[:id])

    if @article.update(article_params)
      redirect_to @article
    else
      render :edit, status: :unprocessable_entity
    end
  end

  def destroy
    @article = Article.find(params[:id])
    @article.destroy

    redirect_to root_path, status: :see_other
  end

  private
    def article_params
      params.require(:article).permit(:title, :body)
    end
end

Is this all of the backend code? Just a couple of lines? That's impossible! This is so simple that it looks like a "low code" tool. It's simple, elegant, and extremely readable, which is something we rarely find in the JS land.

Okay, okay, you must be thinking right now: "This crazy react dev from the internet said he ended up using Elixir, so there must be some things wrong with ruby!". And you are right my anonymous friend, there were some things that annoyed me quite a lot, let's talk about them.

First, we need to address the elephant in the room: Moving from React + Typescript to a dynamically typed language is not easy. From the moment I started writing code and no intellisense or dropdown filled with code suggestions show up on my VScode, I felt blind and lost. This is a terrible feeling, I could make a typo on a function name and didn't realize it until the website is in production! I know we can write tests, but this is the type of mistake that I want to identify immediatly on the IDE, and not during tests or deployment.

Another thing I thought I would like, but ended up hating it: Too much magic. Inside a Typescript codebase, I can click on top of any class or function, go to the source and see how it's implemented. On Rails, where the hell do I do validation (for example)? Do I create a private function inside the controller? Is there a especific folder for this? NOPE, the correct place to do it is inside the model. Why? Because that's how it works, you either adopt the convention or have a hard time writing ruby code. I simply cannot develop an "intuition" on how everything works under the hood, I have to blindly trust that the maintainers did a good job at organizing everything.

And to finish my frustrations, I started writing frontend code. How do I create components? Partials. How do I define the prop types of this component? There is no way to do that, you need to open it up and visually look for all the variables inside it. How about doing some interactivity? Creating states? Well, there is Hotwire with Stimulus, but as you can see, you need to manually create your "re-render" function, it doesn't figure out a way to re-render the page automatically after changing a state like React.

// src/controllers/slideshow_controller.js
import { Controller } from "@hotwired/stimulus"

export default class extends Controller {
  static targets = [ "slide" ]

  initialize() {
    this.index = 0
    this.showCurrentSlide()
  }

  next() {
    this.index++
    this.showCurrentSlide()
  }

  previous() {
    this.index--
    this.showCurrentSlide()
  }

  showCurrentSlide() {
    this.slideTargets.forEach((element, index) => {
      element.hidden = index !== this.index
    })
  }
}

Once Again I got frustrated. I got reeeeeeeally close to finding the perfect framework! What is the next framework on my list that I wanted to try if Rails failed? Elixir.

Elixir and Phoenix

I have to be honest, I was running low on patience. I tried multiple different ecosystems, and I was almost convinced to just stick with Ruby on Rails and give up on my quest to perfection. Until a video appeared on my YouTube recommended section:

Hold on! Here we can see a React developer saying a bunch of nice things about functional programming, Elixir and Phoenix Live View. Maybe I should give it a try!

The first thing I did was open the documentation for Elixir and Phoenix, and I really enjoyed the fact that all packages are documented in the same way using Hex Docs, you just need to get used to one interface in order to learn new things.

Another good thing is that you can truly learn Elixir just reading the docs, no need for an expensive course! On every other ecosystem, I had to learn the language through a paid course and then learn the framework by reading the docs.

Then it was time to start writing code. Very quickly I understood that functional programming is very different from OOP. Let's do a small comparison:

// JS
const obj = {name: "daniel"}
obj.age = 25

// result: obj = {name: "daniel", age: 25}

# Elixir
obj = %{name: "daniel"}
obj = Map.put(obj, :age, 25)

# result: obj = %{name: "daniel", age: 25}

Or you could achieve the same thing with a simpler syntax using the pipe operator:

# Elixir with pipe operator
obj = %{name: "daniel"} |> Map.put(:age, 25)

# result: obj = %{name: "daniel", age: 25}

Initially you might find it less readable and more complex, but I promise that over time it makes sense! Well, at least for me it did. As a React developer, I got used to seeing multiple functions everywhere, even front end components are functions! Not to mention the fact that creating a class is sometimes viewed as a code smell by the JavaScript mafia. My brain was already "shaped" for this new paradigm, it just felt natural to me. Since my Network Engineering degree in university, I had several classes about object oriented programming, but it never "clicked". I couldn't model complex problems into classes and objects. Using multiple functions to "mutate" a variable over time is how I model things in my mind.

How about the main framework? Is Phoenix batteries included? Convention over configuration? YES IT IS! To be honest, the ecosystem is not at the same level as Rails, but it's 95% there. Unless you need an ultra-specific feature, Phoenix got you covered.

I was almost sold on Elixir, 2 things were missing from my list: Good developer experience and modern/performant front end code.

José Valim announced he was experimenting with adding types to the language, but Elixir doesn't have them currently, so I got concerned. How do I get intellisense and autocomplete without types? Soon I discovered these features aren't necessarily related. After installing the ElixirLS extension on VScode I was surprised. It's possible to define a function inside a random module on a random folder, import it somewhere else, and get the intellisense and documentation for it! I have those benefits from statically typed languages without the hassle of writing types, simply amazing!

My Future with Elixir: set-theoretic types - The Elixir programming language

We announce and explore the possibilities for bringing set-theoretic types into Elixir.

elixir-lang.org

My final concern on the frontend was addressed by Phoenix Live View. On the code side, this was the exact piece of the documentation's home page that convinced me:

You can define "props" to every component, and if the types mismatch, you get an error in your IDE, just like react! Impressive!

How about the UX? Is there a full page load whenever a user clicks on a link? Hell no! Live view establishes a WebSocket connection with the client, and then every page transition is just a content swap made through the Websocket, no new HTTP request is made. Also, all of the state is managed on the server side, which means that rich user experiences like Trello, which used to be very janky on the client side due to an excessive amount of javascript being loaded, are now super fast! Elixir handles all the complex state logic and sends the updated pieces of the page to the front end. Take a look at the full explanation here:

Since we are using WebSockets for builing the UI, creating "live" applications like Twitter takes only a couple of lines of code!

Conclusion

It's safe to say that the "perfect tech stack" doesn't exist. The silver bullet that solves all the problems is an illusion that we create in our minds to keep searching and building the most optimized tool.

However, at an individual level, the perfect stack does exist. Because each developer has preferences, and you can easily find a tool that fits your criteria. If you had a similar journey to mine, perfection might be Elixir and Phoenix! So give it a try, maybe you'll love it as much as I do now.

If you reached the end of this blog post, you are awesome! Thank you so much for your time, and I hope I could bring some value into your career.

DEV Community: Daniel Bergholz

Testing GLM-5.2 on OpenCode: I'm impressed!

The claims I was here to test

My setup: OpenCode plus OpenRouter

The test: a real feature on my real site

Plan mode actually surprised me

The code it actually wrote

The part I didn't expect to like: restraint

Then OpenCode crashed

The built-in review caught something real

So, is it actually worth it?

How I Used AI to Rebuild My SaaS From Scratch

Attempt 1: the lazy test

Attempt 2: batching the work with sub-agents

Attempt 3: I stop being lazy

Attempt 4: I stop automating and start driving

The code smell I had to teach away

Was it worth it?

Claude Fable 5 review: I let Anthropic's new "bazooka" loose on my SaaS

Fable vs Mythos: same model, different safeguards

The benchmark that actually matters: FrontierCode

The catch nobody is talking about: you lose it on June 23

Let's build a real feature in CourseShelf

The moment Claude pushed back at me

Sanity-checking the code

The token bill

Final verdict: 9/10

Moving my SAAS away from React (and Inertia) to Elixir

The honeymoon was real (and then it ended)

The real killer: AI agents couldn't write Inertia code

The new stack

One file vs. three

The infrastructure bill nobody warned me about

"But you lose all the nice front-end stuff, right?"

"You'll lose rich UI interactions."

"Every page navigation is a full reload."

"Is AI actually good at LiveView?"

"I'll miss shadcn/ui."

Was it worth it?

Announcing CourseShelf: Rotten Tomatoes for Online Learning

The limitations of TechSchool

Enter CourseShelf

What you can do on CourseShelf

For course creators

The tech stack

Disclaimer

Join the community

Follow us

Thank you

My AI-Powered Workflow for Writing Elixir and Phoenix with Windsurf

First, why Windsurf and not Cursor?

Does AI generate good Elixir and Phoenix code?

How to improve?

Getting Up-to-Date Info

Sanity Check After a Long Coding Session

A Word of Caution

Moral of the story

Announcing TechSchool: A free and open-source platform to learn programming

Identifying the problem

The solution

Disclaimer

The tech stack

From Next.js to Rails then Elixir: My journey through React.js burnout

The timeline of the burnout

Gatsby.js

Next.js

Remix

Leaving the Matrix

I'm DONE with Next and Vercel

The Path to Enlightenment

Ruby on Rails

Elixir and Phoenix

My Future with Elixir: set-theoretic types - The Elixir programming language

Conclusion