玩樂學的開發日誌：從單純的 HTML5 到 React

玩樂學的架構不是一開始設計好的，是一路摸索出來的。

第一個遊戲：很快生成，但是存成 HTML 本機打不開

Gemini 的 Canvas 功能非常方便——只要描述你要什麼，它直接在側邊的 Canvas 畫面上生成一個可以互動的 app 或小遊戲，完全不用寫程式。想做一個加減乘除的練習遊戲？說清楚規則，幾秒鐘就出來了，還可以直接在 Gemini 裡試玩，甚至分享都可以。(可以參考零基礎用 AI 打造文章)

第一個遊戲就是這樣生成的。但 Gemini 這類型的 AI 所產生的程式碼都比較趨向現在流行的 React 等新技術，存成 .html 之後，會發現在本機直接打開是無法正常執行的。因為React 需要在終端機跑 npm run dev 才能啟動。

所以改了一個做法：仍是請 Gemini 生成「本機可以直接打開、可以玩的版本」。這次輸出的就是純 HTML + Javascript +CSS，存成一個 .html 檔案，點開就能正常執行。

問題就這樣解決了。

Vanilla JS 為什麼其實不錯

後來搜尋資料，才發現這個「傳統解法」，居然還流行回來了。

首先是每個遊戲是一個獨立的 HTML 檔案，新遊戲上架丟一個 HTML 進去就好，一個改壞了不影響其他遊戲，維護起來很清楚。

更有趣的是，現在業界反而開始推崇「不依賴第三方套件」的 Vanilla JS 寫法——能不靠框架就不靠。這個方向和「為了本機能開才選的」結果一樣，只是動機完全不同。

說到這個，晴空下的呢喃（2011 年做的技能模擬器）當時也是純 JS、沒有用 jQuery。不過動機更簡單：就是想從 JS 學起，先不用套件看看。那時候 jQuery 才是主流，現在 React 是主流，兩次都沒跟，兩次都不是刻意的。

入口網站：AI 也說用 React

遊戲越來越多之後，想建一個入口網站收納這些小遊戲。一樣請 AI 規劃架構。

AI 說用 Next.js。遊戲越來越多，要加入清單按年級、科目篩選；之後要加登入、配合資料庫，框架處理這些比散落的 HTML 省心很多。技術面也說得通：SSR 方便 SEO，API Route 直接處理後端邏輯，AI 協作也更順。說得通，就用了。

複雜的遊戲，也走向 React（笑）

簡單的遊戲是純前端邏輯，Vanilla JS 綽綽有餘。但比較複雜的遊戲——需要後台機制、跨遊戲的進度追蹤——開始往 React 走。 P.S. 還有更重要的，如果想要保護核心機制、演算法等，也是需要後台。

兜了一圈，架構就這樣長出來了：

• 遊戲本體：Vanilla JS，單一 HTML 檔案，本機直接打開就能玩
• 複雜遊戲：React，有後台需求時才用
• 入口網站：Next.js，管清單、篩選、SEO

一開始 Gemini 預設給 React，本機跑不了，改成 Vanilla JS，後來又為了別的理由回到 React。沒有一開始就想清楚，是做的過程中一件事接著一件事決定的。