Romaji to Kana Converter: Astro — Chapter 5, Exercise 3 ===================================================================== TASK Given this chapter's own real, measured evidence, argue in your own words why Chapter 4's client-side approach should remain this app's actual default. Then name one hypothetical feature this project could add later that would have a genuine, real reason to run server-side instead. SOLUTION The case for keeping conversion client-side rests on two real, measured facts from this chapter, not just a general preference for simplicity. First, the cost is real and large: a direct call to convert() takes roughly a microsecond, while the same call routed through a real HTTP round trip costs on the order of ten milliseconds -- a difference of about four orders of magnitude, measured directly rather than assumed. Second, and just as important, there is no real benefit on the other side of that cost to justify paying it: convert() touches no secret credential, no other user's data, and no shared state that has to live in one authoritative place. It reads exactly what the current user typed and returns exactly what they should see, which is precisely the situation a pure, local function is built for. Paying a real, measured, four-order-of-magnitude cost for zero real benefit is the actual definition of a bad tradeoff, not just an inconvenient one. A hypothetical feature that WOULD have a genuine reason to run server-side: automatic kanji suggestions. Chapter 1 explicitly named full kanji conversion as out of scope for this course precisely because it's a real, dictionary-and-context-dependent problem -- the same kana can map to several different kanji depending on meaning, which means resolving it correctly needs a real dictionary lookup against a data set far too large to ship to every visitor's browser on every page load. That's a genuine, structural reason to keep the lookup on a server: a shared resource (the dictionary itself) that doesn't belong duplicated in every client, and a computation (disambiguating between candidate kanji) that isn't just a small local table like KANA_MAP. Unlike plain romaji-to-kana conversion, a real kanji-suggestion feature would have something real to gain from moving server-side, which is exactly the kind of case this chapter's own closing tip-box said the /api/convert pattern would be ready for. WHY THIS WORKS AS AN ANSWER ---------------------------- It grounds the client-side recommendation in the two real facts this chapter actually measured (a real cost, and the absence of any real benefit) rather than a general preference, and the named hypothetical feature is drawn directly from a genuine, already-documented scope boundary in this course (Chapter 1's own kanji-conversion deferral) rather than an arbitrary invented example.