在 VIEW 專案歷經一個月重構 (採標準三層工廠模式、加入快取相依、簡化預存程序、改進容錯) 後，團隊堅持「不使用框架、不使用視覺化控制項」的原則。本文分享為何在表現層拒絕拖拉元件式開發，以及非控制項式程式設計的長期價值。
<td style="padding:5px">，無法透過屬性或程式碼修改| 維度 | 控制項式 (拖拉元件) | 非控制項式 (手工 HTML/JS/CSS) |
|---|---|---|
| 初期開發速度 | 快 (所見即所得) | 慢 (需手寫標記、樣式、腳本) |
| Bug 掌控度 | 低 (依賴廠商修復) | 高 (原始碼全掌握，即時修復) |
| 長期維護成本 | 高 (版本升級風險、Hack 累積) | 低 (程式碼簡潔、無框架鎖定) |
| UI 靈活度 | 受限於控制項功能 | 完全自由 (原生 HTML/CSS/JS) |
| 團隊技能要求 | 熟悉框架 API | 扎實前端基礎 (HTML/CSS/JS/HTTP) |
「你要實現那麼多功能，乾脆自己寫個語言得了。」
此論點混淆層次：後端技術 (資料存取、交易、安全) 已高度成熟且向下相容，使用框架風險低；前端技術 (UI/UX、瀏覽器標準、裝置形態) 持續快速演進，不可能完全向下相容。Microsoft 自身的「向下相容」往往靠 JS 動態修補錯誤預設屬性，這正是框架脆弱性的證明。
非控制項式開發雖提高初期投入，但換取的是長期可維護性、彈性與掌控力。對於追求高品質、長壽命產品的團隊，建立前端架構治理、採用手工精細打造表現層，是更理性的戰略選擇。
