Romaji to Kana Converter: Astro — Chapter 1, Exercise 2
=====================================================================

TASK
In your own words, explain why this course treats the client-vs-
server conversion question as something to explore across Chapter 5
-- the same way its still-outlined Next.js sibling does -- while its
completed Angular & Express sibling decided that question up front,
and explain why this course's own MVP needs no database at all where
its Premier League Predictor: Astro sibling does.

SOLUTION

Part one -- client-side vs. server-side conversion:

Astro and Next.js are both full-stack-capable frameworks in their own
right. Astro has real server endpoints available (this site's own
Premier League Predictor: Astro course builds several), and Next.js
has real API routes built into the same codebase as its frontend. For
either framework, "should this specific piece of logic run in the
browser or on the server" is a genuine, open design question with
real tradeoffs on both sides -- nothing about the frameworks
themselves forces an answer, so both courses treat it as exactly
that: a real comparison, built and measured directly rather than
argued about, in a dedicated chapter.

Angular, by contrast, has no backend story of its own -- it's purely
a frontend framework. If the Angular course also left the question
open, its own "client-side" answer would need no second technology at
all, and Express would never actually appear in that course. Since
that course's own stated reason for existing is to give Angular a
real, paired Express backend, deciding upfront that conversion logic
lives on the server is what guarantees the course actually delivers
what it promises. This course has no equivalent structural pressure --
Astro can do either approach well on its own, so there's nothing
forcing an early decision, and Chapter 5 gets to be a real comparison
instead of a foregone conclusion.

Part two -- no database needed:

The real difference is what each app actually has to remember. This
converter takes one input and produces one output, with nothing left
over afterward -- the exact same romaji always converts to the exact
same kana, every time, with no history, no accumulated state, and
nothing that needs to survive between one visit and the next. A
season of Premier League predictions is the opposite: a fixture
entered in gameweek 3 has to still be there in gameweek 30, next to
every other fixture, prediction, and league-table row from the whole
season, which is precisely the kind of information that has to
persist somewhere durable between visits. That's a database's actual
job, and it's a job this converter never has.

WHY THIS WORKS AS AN ANSWER
----------------------------
Both halves trace the real, structural cause rather than restating
the surface-level fact. The client-vs-server difference comes down to
whether a course has a reason to decide the question early (Angular
does, because its whole reason for existing depends on it) or not
(Astro and Next.js don't). The database difference comes down to
whether the app actually has anything that needs to persist between
visits -- not a general rule about Astro apps needing or not needing
one, but a fact specific to what each of these two apps actually does.