Project Overview & Why This Fits Directly Onto the Existing Site

This is one of three courses building the exact same tool in three genuinely different architectures — a web app that takes romaji (Latin-alphabet-transliterated Japanese) text and converts it into hiragana and katakana. Romaji to Kana Converter: Angular & Express is already complete, and committed to a real, dedicated Express API from its own Chapter 5 onward; Romaji to Kana Converter: React & Next.js remains outlined. This course — the Astro variant — takes the most direct real angle of the three: the site this converter is actually meant to join is itself already built in Astro, so this isn't a hypothetical "how would you build this in Astro" exercise so much as "here's what adding this directly to the real, live site would actually look like."

What the App Actually Does

• Convert romaji text — typed Latin-alphabet Japanese, like konnichiwa — into both hiragana (こんにちは) and katakana (コンニチワ).
• Handle real Japanese-specific edge cases correctly — long vowels, the small っ (sokuon, doubled consonants), and particle exceptions (は pronounced "wa," へ pronounced "e") — covered in real depth in Chapter 3.
• Ties directly into content already on this site — the existing Japanese-language lessons and the kanji tiles/reference-materials pages, both real, immediate practical uses for a working romaji-to-kana tool once it's live, and the real focus of Chapter 8's own capstone.

Full kanji conversion is explicitly out of scope for this course — a genuinely bigger, real dictionary-and-context-dependent problem (the same word in kana can map to several different kanji depending on meaning), deliberately deferred as a real future project of its own rather than something this course pretends to solve as a side effect of romaji conversion.

Why Astro for This One

Of the three variants in this trio, this is the one built specifically to answer "could this genuinely just be a page on my real site" — and the answer here is a real, literal yes, not a metaphor:

• Astro is already the real, live framework this site runs on. Adding this converter later isn't a port from one framework to another — it's adding one more page to a project that already exists, using exactly the same tools every other page on the site was already built with.
• No database needed at all, for the core MVP. Converting romaji to kana is a pure, stateless function — type something in, get an answer back, nothing to remember between visits and nothing to persist. That's a genuine, deliberate contrast with this site's own Premier League Predictor: Astro course, which needs a real SQLite database from its own Chapter 1 precisely because a season of fixtures, predictions, and league standings does need to persist — see the finding below.
• Astro's own component model gives this just enough interactivity without deciding anything upfront. A form and a script can run entirely client-side inside a normal static Astro page, with no special configuration at all — which is exactly what keeps Chapter 5's own client-vs-server comparison a real, open question rather than one this chapter quietly settles by how the project gets set up.

Unlike the Angular course, this one has no structural reason to decide the question early — Astro can genuinely do either approach well, so there's nothing forcing a choice before the real evidence is in. Chapter 5 builds both versions for real and compares them directly, rather than asserting one is better.

Setting Up: A Plain Astro Project, No Database, No Adapter Yet

A local Node.js install is assumed from here on. Scaffold a fresh Astro project first:

Visiting http://localhost:4321 should show Astro's own default starter page — confirmation the project itself is set up correctly, before a single line of conversion logic exists.

Astro renders every page statically by default, and this project is deliberately left in that default state for now. Verified directly against Astro's own current documentation: a freshly scaffolded project always starts in output: 'static' mode, with the entire site pre-rendered to plain HTML at build time — and that default is genuinely correct here, not just left unexamined, since nothing about romaji-to-kana conversion actually requires a server at all yet:

A minimal project structure, following this site's own established Astro project convention rather than inventing a new one — deliberately without a lib/db.ts or a data/ folder, since this app has nothing to persist:

A minimal placeholder page confirms the setup works before any real conversion logic exists:

Reloading http://localhost:4321 should now show this exact page — a real, working Astro project, statically rendered, with nothing installed or configured beyond what a fresh scaffold already provides.

Where This Course Is Headed

A real romaji-to-kana mapping table (Chapter 2); the genuinely tricky edge cases — long vowels, sokuon, and particle exceptions (Chapter 3); building the actual input/output UI in Astro (Chapter 4); the real client-vs-server comparison this chapter deliberately left open (Chapter 5); styling this to actually match the existing site's own look (Chapter 6); deployment (Chapter 7); and a capstone shipping this as a real new page on the live site, closing with an honest look at kanji conversion as a genuine future sub-project of its own (Chapter 8).

Hands-On Exercises