身為開發者，每次規劃、開發都面臨無數的判斷、種種的選擇，為什麼要學這個、為什麼要導入那個？
我們最害怕的冒然導入新東西進一個專案，然後 GG～

尤其是新東西一出來、潮潮跟風學一下、玩一下可以，但是要導入正式的專案要考量到的因素就很多
包含這種 Pattern, Practice 是不是經過時間的驗證？是不是主流？適用的情境是什麼？學習門檻高不高等等...

今天想藉由官網首頁的關鍵字，來提供更多資訊，協助大家決定是否導入這個套件，帶大家知道為什麼可以選擇 XState

透過跟大家分享 XState 官網上半部介紹的 3 大關鍵字
Finite State Machine, State Chart 以及 SCXML，一起稍微認識一下這個 library 能帶來什麼？

Finite State Machine 就是指早前介紹到的 數學 計算模型 (Model of computation)

計算模型：描述了如何根據一組輸入值計算得出輸出值，也包含了負責運算、儲存和通訊等結構的具體組織方式。它可以用於測量一個演算法在時間和/或空間上的複雜度。通過計算模型的抽象化總結，我們可以分析出演算法的效能，而避免在具體程式層面，被不同的技術和實現方式造成的效能差異所誤導。 by wiki

也就代表 FSM 一詞，比較屬於概念面、抽象層次比較高，比較專注在數學、理論上，最後實際底層的實作也是依賴各家的作法。

Finite State Machine 理念及簡易實作的部分在前面已經有許多了，在此就不多加著墨。

State Chart 這也是我開賽前相當無感得地方，每次只會想說 State Chart 不就是 State Diagram 、把狀態機畫成圖而已， 每次點那個 link 都給我跳出一篇 1984 年，全英文的 paper，真心傻眼。

後來在各式中英文網站以及最後在 https://statecharts.dev/ 閱讀出的資料才知道，原來...State Chart 是一位有名的數學家 David HAREL 提出在現實世界的複雜系統可以怎麼用一個不錯的視覺表達的形式(A VISUAL FORMALISM FOR COMPLEX SYSTEMS)，簡單來說，就是 FSM 的加強版、現實生活版。

（感謝鐵人賽讓我長大ＱＱ）

SCXML 則更無感，全名是"State Chart extensible Markup Language"，是在我寫到將近尾聲的快第18天，才大概知道是什麼碗糕（僅片面一點點）。之前看到這種縮寫就先忽略了ＸＤＤＤ

簡而言之，就是鼎鼎大名的 W3C 組織基於 Harel 的 State Chart 以及 CCXML (全名Call Control XML，asynchronous event-based blah blah blah)，這兩個東西，以及現實世界中各種可能的 edge case 去制訂出來的規格書及 Markup Language。

這東西大概也早在 (2005 to 2015) W3C 組織 推出 W3C Recommendation 1 September 2015

This document describes SCXML, or the "State Chart extensible Markup Language". SCXML provides a generic state-machine based execution environment based on CCXML and Harel State Tables.

相信官網提出的這三大特色是想要說服使用者（痾～我指開發者），不要看我們 XState 很新而不放心，他其實就是過去非常經典、實用的 State Chart 製作成一個 library 提供 JavaScript 的開發者使用。

從 1984 David HAREL 發展出概念 -> 2005 - 2015 W3C 專家們一系列討論、思考、辯論想遍許多 Edge Case。

而 Finite State Machine 的概念，甚至比這更早就普遍實作在硬體開發上。

所以 XState ...

所以 XState ，就是 Finite State Machine, State Chart 軟體層面的底層實作，並且遵循著 W3C 推出的 SCXML 原則。

相信官網提出的這三大特色是想要說服使用者（痾～我指開發者），不要看我們 XState 很新而不放心，他其實就是過去非常經典、實用的 State Chart 製作成一個 library 提供 JavaScript 的開發者使用。

JavaScript 的開發者也不用擔心自己在風口上，用什麼潮潮 Pattern ，哪天退流行，摔死在路邊上，或者在旁邊哀號「求不要更新，老子學不動了」。

他就是一個很穩、很早就存在、規格也訂得很妥當的程式開發模式。

這叫什麼？換湯不換藥？啊～不是，我想這叫做經典不敗

隨著時代的演進、硬體的進步，以及軟體複雜度、這邊指 JavaScript, Web Application 的複雜度大幅提升，所以感覺很適合導入「狀態機」的概念，將複雜的狀態變簡單、限縮狀態及其轉移的路徑等。

如上述、過去幾篇的介紹，FSM 的概念除了在硬體開發上，在軟體開發也已存在許久，如遊戲軟體，試想一個遊戲同時有那麼多狀態要被記得。

一時找不到來源，FSM 的確適合複雜的狀態處理，據說飛機機師在操作的飛航系統，背後也是透過 Finite State Machine 的方式製作出來，試想要運送一群人在高速飛往空中，人命關天、不容閃失啊。所以開發過程要極力避免 Bug、沒思考到的例外、及意外發生

Aircraft flight sub-state machine for turns

參考文獻

https://xstate.js.org/docs/
https://www.w3.org/TR/scxml/