.NET8 Web專案框架評選
先下結論
個人推薦
Blazor Web App - Server mode 特性: MPA, SSR, SSG 語言: C# 為主, JS 為輔 較易於實作 SEO。 前後端使用相同語言 C# 開發；進階的 UI 操作才用 JS 實作。 Blazor 資源也如預料越來越多。
React and ASP.NET Core 特性: SPA, CSR 語言: 前端 react.v18 後端 C#
Next.js The React Framework for the Web React 的標準答案。已到第14版了。
.NET8 新的 Web 專案框架要點介紹
以下專案類型以 Visual Studio 2022 提供為主。
Blazor Server App
.NET6 開始支援。 個人評為 WebForm 下一代接班人。通訊方法改用 SignalR 其底層是 web socket。
Blaozr WebAssembly App
.NET6 開始支援。 可以開發 SPA, CSR 特性 web app。個人評為與 react 競爭項目。通訊方法也與 react 一樣以 RESTful 為主。
Blazor Web App - Server mode
.NET8 開始支援。 基本上特性與 Blaozr Server App 一模一樣。通訊方法亦是 SignalR 。
Blazor Web App - WebAssembly mode
.NET8 開始支援。 基本上特性與 Blaozr WASM App 一模一樣。通訊方法也以 RESTful 為主。
Blazor Web App - Auto mode
.NET8 開始支援。 號稱支援 Full Stack。經測試與 WASM 比較靠近。 通訊方法若是 Server mode 用 SignalR ； 若是 WebAssembly 則以 RESTful 為主。
號稱自動調適 SSR 或 CSR 模式，實際上只有 page 載入時是 SSR 載入後變成 CSR 而已，這有跟沒有一樣。Auto mode 其實一點也不 auto 若要最佳化要一一手動設置 @rendermode 。
Auto mode 這項技術是全新的嘗試能否被大眾接受個人是有懷疑的，個人建議觀察個二年再決定也不遲。
React and ASP.NET Core
支援 .NET6+ ，因為以 react 為主也要安裝 node.js 。 微軟為 react 開發的標準答案有改了。這次前端工具改用 Vite。 Vite 宣稱支援 Full Stack，然與 ASP.NET Core 合作的部份 SSR 還沒有找到標準正解。預設開出來的專案模式仍是 SPA, CSR 特性。
專案框架比較表格
Blaozr Server App
.NET6+
C# 為主, JS 為輔
MPA, SSR
SignalR
Blaozr WASM App
.NET6+
C# 為主, JS 為輔
SPA, CSR
RESTful
Blazor Web App - Server
.NET8+
C# 為主, JS 為輔
MPA, SSR, SSG
SignalR
Blazor Web App - WASM
.NET8+
C# 為主, JS 為輔
MPA, CSR
RESTful
Blazor Web App - Auto
.NET8+
C# 為主, JS 為輔
MPA, Full Stack
SignalR, RESTful
React and ASP.NET Core
.NET6+, Node.js
前端 react, 後端 C#
SPA, CSR
RESTful
縮寫清單
WASM - WebAssembly。
SEO - Search Engine Optimization 搜尋引擎最佳化。
SPA - Single Page Application 單頁應用。
MPA - Multi Page Application 多頁應用。傳統的就是了。
CSR - Client Side Rendering 客户端渲染。
SSR - Server Side Rendering 服務端渲染。
SSG - Static Site Generation 靜態網站生成。傳統的就是了。
下面為各雜項題目
Interactive Render modes - Blazor Web App 互動模式
有三種：Server mode, WebAssembly mode, Auto mode，請參考
什麼是 Vite?
簡單的說 Vite 是一個 DevServer 與前端 build 工具。在 Visual Studio 2022 開發環境會建立 proxy server 它只在開發環境有效正式環境會不見。若真要部署成 proxy server 模式需另外再使用反向代理服務,如 Nginx 配置代理規則。
Vite 是近幾年前端業界熱門的建構工具 (build tool)，它大幅地簡化了前端建構的流程與時間。Vite 的核心功能有幾點：
作為開發伺服器 (dev server)：讓開發者可以在本地 (localhost) 進行開發。Vite 的熱模組更新 (hot module replacement) 提供開發者非常好的開發體驗。以開發 React 來說，當有任何的改動後，Vite 的熱模塊更新會以非常快的速度重新渲染本地的頁面，同時會保留當下的任何狀態 (state)。
打包程式碼：Vite 背後是透過 Rollup 進行打包，高度優化部署到生產環境 (production) 的打包結果。
目前前端社群中的絕大部分框架，都採用了 Vite，包含 Astro, Nuxt, SvelteKit, Solid Start, Qwik City 都是；基本上除了 Next 與 Angular 之外，熱門的框架都是選 Vite。
已知 Vite SSR 方案
vite-plugin-ssr
Vite SSR
其他方案未通過估評
關於 SSR 實作
SSR 與伺服端有綁定相依性。各種 SSR 實作方案第一步都會問伺服端的實體是那一種？
是 Next.js (react) 有它的 SSR 解法。
是 Nuxt (vue) 有它的 SSR 解法。
是 express server 有它的 SSR 解法。
各種前端開發方式都有它自己的 SSR 解法會這樣應該與 url routing 有絕對關系。
而 ASP.NET Core 伺服端本身就是 SSR 了，只是製作 UI 畫面時非常不好用。
ASP.NET MVC 本身就是 MPA, SSR, SSG 了，只是製作前端 UI 畫面時超級不給力。
到現在為止個人認為最佳的 SSR, SSG 實作方案是 WebForm。
WebAssembly 為何無法取代 JavaScript?
就規格來看 WebAssembly 在各方案輾壓 Java Script。然到了實務面...下面問答可以回答這個現實：
摘要原因如下
web app 綜合速度影響最大的是網路傳輸部份，雖然 WebAssembly 的計算速度比 Java Script 快10倍以上。綜合速度來說一般的 Web 應用 WebAssembly 並沒有比 JavaScript 好。 以例子來說明：
JavaScript 綜合速度: 2秒(網路傳輸) + 0.5秒(UI渲染) + 0.1秒(計算) = 2.6 秒 WebAssembly 綜合速度: 2秒(網路傳輸) + 0.5秒(UI渲染) + 0.01秒(計算) = 2.51 秒JavaScript 在 Web 應用相關的資源在方方面面都太成熟了；反觀 WebAssembly 就很貧乏。
各家 Browser 都是用 JS Engine 實作之上再放 WASM Engine。除非改成用 WASM Engine 實作，之上就能放各種語言 JS, TS, Rust, C#, Go 等等等。實際上若改用 WASM Engine 再掛上 JS module/plugin 再掛上 JS app 那可能比現在還要慢。
WebAssembly 在 Web 應用的優勢在 Web 3D 渲染畫面就是網頁遊戲這種級大量的運算，在實務上大部份的 Web 應用都是看看網頁、填寫表格而已。
Tailwind CSS 非常棒，但要精通等同要再學一套完全獨立的 CSS 指令，這…代價不符效益。適用於 CSS 狂人。適用於一人開發的全客製化 CSS 的小型或超小型網站。
Material UI 也很棒，延用現有 CSS/SCSS 指令即可。
(EOF)
Last updated