筆者對網站的認知為前端、後端及資料庫，使用者在瀏覽器頁面按下按鈕或是表單請求，觸發前端事件，將收集起來的條件打包送往後端，後端接收條件後去資料庫據此處理判斷，撈出使用者想要的資料後，後端將頁面、資料回傳給前端，前端再將相應資料呈現在頁面上，這就是最原始的前後端交流。
後來有人發現每次都要重新整理頁面實在太麻煩，而發展出了可以非同步執行的 Ajax 技術，假如一個事件 A 沒做完的話，其他事件 B, C 不會等 A 做完，而是會自己往下做，如此一來當使用者發送表單請求時，網頁不會一直跑小圈圈等待重新整理，而是會先讓使用者看到頁面，其他事在使用者看不到的地方繼續處理，這樣大大提升了使用者體驗。
由於動態網頁規範已經被 JS 統一，即便後來出現強型別的 TypeScript（也就是 Angular, React, Vue 等前端框架使用的語言），最終仍要編譯成瀏覽器認識的 JS，且 TypeScript 也是基於 JS，所以一個後端工程師若要自己寫個網站，就不可避免地必須跟 JS 打交道，對於習慣強型別的人來說無異從頭拓荒，若是遇到公司規範不嚴又遇到喜用任意型別的同事，一個變數可以一下使用 number，一下又使用 string，就足以讓人抓狂了，幸好這時 Blazor 出現了。
Blazor 是 Browser 和 Razor 的合成字，代表在瀏覽器上執行的 Razor 元件。
Blazor 分為兩種模式，WebAssembly Hosting 及 Server Hosting，簡單來說就是 Client side 及 Server side，兩者各有優缺點。不過在繼續說下去前要先說明 WebAssembly 是什麼。
WebAssembly 簡稱 Wasm，是一種二進位表示語言，任何程式語言經過特定編譯都可以轉成 Wasm，Wasm 的優點是將整個程式傳到瀏覽器而不需要伺服器，由於是二進位且已經編譯過的關係，渲染網頁的速度會比 JS 更快，檔案也會更小。
Blazor WebAssembly 是將編譯過的 dll 檔案及 .NET 執行環境打包後發送到使用者的瀏覽器，所以第一次建立連線時會比較慢；Blazor Server 則是在伺服器跟瀏覽器之間建立 SignalR 連線，當瀏覽器觸發事件後，Server 處理完不是整頁重新整理（將所有 Html 元素送往前端），而是透過 SignalR 將變化的元素（如 div）送往瀏覽器，這是因為 Blazor 也是如 Angular 使用 SPA（Single Page Application）模式，從頭到尾只有一個頁面，上面佈滿了不同功能的 Components，觸發事件只會更新相關 Component。
Blazor WebAssembly
優點：
- 因為檔案都在瀏覽器上，速度相較於 Blazor Server 更快
- 不需要伺服器
- 不需要隨時跟伺服器連線
- Client 端的瀏覽器被充分利用，減輕伺服器負擔
- 可以架在任何伺服器上，例如雲端、微軟的 Azure 甚至 CDN（Content Delivery Network，一種將資料暫存到離使用者地理位置更近的模式，比如說我如果想登入主機在美國的網站，速度一定比主機在台灣的網站慢得多，CDN 會將資料暫存在離台灣比較近的地區的主機，如香港、新加坡，讓使用者連線速度更快）
缺點：
- 第一次載入會花比較多時間，因為瀏覽器要下載 .NET runtime 等元件（註：鐵人賽前筆者建立了新的 Blazor WebAssembly 專案，發現已經沒下載元件了，微軟官方圖片也沒看到有下載元件，或許是新版本有所改動）
- 受限於瀏覽器的處理能力
- Client 端的軟硬體都很重要
Blazor Server
優點：
- 載入速度比較快
- 可以充分利用伺服器的能力
- 任一 Client 使用這軟體唯一需要的只有瀏覽器
- 由於原始碼不會傳到 Client 端所以會更安全
缺點：
- 需要伺服器
- 需要跟伺服器保持連線
- 由於資料來回傳遞，延遲感會更重
- 不容易提升運算能力，因為一個伺服器能承受的 Client 端有限，微軟給出的資料為一個單核配有 3.5G 記憶體的 Blazor Server 可以處理 5000 個連線；一個四核配有 14G 記憶體的 Blazor Server 可以處理 20000 個連線。
若將 Blazor WebAssembly 和 Blazor Server 的優缺點分別列出，可以看到沒有一種模式是最完美的，只有最適合的。如果已經有了其他程式語言架構的伺服器如 PHP, Node 或是 Rails，需要一個提供給使用者且不需要時刻連線伺服器的 Client 端程式，Blazor WebAssembly 就是很好的選擇，且 Blazor WebAssembly 具有 PWA（Progressive Web App）功能，雖然以網站模式開發卻能讓使用者像下載軟體一樣下載到桌面或是手機，知名網站如 Twitter, Pinterest, Starbucks 都是知名例子，如果用電腦開啟 Twitter 網站，就能在網址列最右方看到下載的按鈕；而如果需要從無到有生出一個需要頻繁連線伺服器（如對資料新增、修改、刪除）的網站，就適合用 Blazor Server。
不過 Blazor 畢竟是微軟的新產品，筆者也只用過 ASP.NET Core 搭配 Blazor，Blazor WebAssembly 想跟 PHP 等非微軟語言開發的後端整合或許會有其他要注意的地方，若有相關需求的人可能要多方考量。
講了一大堆文字，想必還是很多人跟筆者一開始接觸時一樣沒有看懂，明天筆者會將兩種專案都建立起來，讓大家看一下兩者差在哪裡。
- 引用： What is Blazor
- 引用： ASP NET Core blazor hosting models
- 引用： The Differences Between Blazor WebAssembly And Blazor Server
- 引用： 了解 WebAssembly 的基礎使用方法
- 引用： WebAssembly design
- 引用： WHAT IS A CDN & WHERE DOES IT SHINE?
- 引用： Twitter
註：本文程式碼透過 .NET 6 + Visual Studio 2022 重構，可點選原文連結與重構後程式碼比較學習，謝謝閱讀，支持原作者
- 本文 Markdown：點選瀏覽