點擊此處至：《雲windows雲黑群暉雲黑蘋果雲chromeos雲pve，及實現在雲主機網絡安裝雲OS的增強方法(帶鏡像有演示)》
本文關鍵字：web前端演變的歷史,vue,react,pwa,spa,mpa
在《用開發本地tcpip程序的思路開發webapp》等許多文章中我們都講過web/webstack的原型(那文主要講前后端分離的web開發思路)，如果說一種ui代表一種app，(我們用app特指那種需要下載/安裝/運行，區別於用瀏覽器打開作為的那種桌面和移動app，它們一般寄宿在os上用native rendered gui庫發明,體驗為無延遲的UI和APP，可以調用本地的服務)，那么或許在2015年前就從來沒出現過什么嚴肅意義上的web app ui/web app，只有page ui和網站，雖然我們談webapp已經很多年但其實它是個新事物，為了應付日漸龐大的 Web 頁面，經過優化的 JavaScript 引擎已經可以和一些編譯語言的速度相提並論已經不僅是用js實現交互就行了。因此用web打造app的思路出現了，從網站到webasapp而這二種需求看似共享同樣的基礎，但面向它們的設計都不相同，web一開始就被設計成靜態，保有鮮明的內容屬性而非可編程屬性（語義，routerable,可退回/可前進，頁面內容可索引可爬取可seo），因此它要變身“某種用html表達的app”，類似native render ui/native app(甚至整合它們形成多端合一的app:一雲多端的OS+多端合一的APP,universal webui+siteui app)。這不但要求web本身規范變(w3c)，而且要求支撐現有web運行起來的那些東西也要變，甚至變化過后，會破壞現有的web本身。
從siteui page到webapp
首先是硬件和OS平台要為支持它們（而產生變化），webos有chromeos和html手機(基於 Firefox OS 的 KaiOS據稱全球第三大移動os)這種，包括最近出來的fuschia。
然后是web本身的富網頁技術(基於flash的內容創作型工具被面向程序員的js技術代替)要到位，用js寫成用瀏覽器跑出來的ui，會跟真正的原生UI在體驗上相差很大比如延遲高沒有長鏈不能調用攝像頭無法推送無法離線，這一般來自瀏覽器或應用的“webview”支持，（雖然說現在的瀏覽器有localstorage,websocket,webgl,etc.近二年又有service worker.但還是不夠）因此要求增強瀏覽器本身的api(一般來說，正常的瀏覽器page運行在沙盒里沒有權限調用本地api，而特制的瀏覽器如electron這種會面向“發明webapp”的需求保留一些特權API,，這也是它經常被apple mas禁止的原因，微信那個瀏覽器也是增強了私有 api的,實際上，在w3c規范之上定制瀏覽器這種行為就破壞了web的應用形式，故提高webapp體驗的同時又不致於破壞現在的web這是一對矛盾)
webapp的意義：
（這個技術如果成立，web ui可以完全代替渲染原理的遠程桌面形式的remote app，真正實現原生不光跨端甚至跨雲的UI：我們知道，遠程UI的原理大部分都是投屏技術這絲毫不原生，雲沒有自己的原生UI與APP技術:webapp與容器正在填補這個空隙，在前面一些文章中我們多次提到遠程APP這種雲原生APP的需求,曾經我追求這樣的統一本地和遠程的appstack《cloudwall：一種真正的mixed nativeapp與webapp的統一appstack》，但現在看來：正是桌面早已成一套的情況下原生雲UI都做不到成為規范，，所以導致現在都沒有“universal desktop/web app”）
最后也是最大的變化還是語言層上這種appstack本身和開發這種WEBAPP的范式上(因為前端始終是面向程序員的而不僅是內容制作)，事情發生在2015年之后，產生了將web ui作為app ui的技術潮流，並由此誕生了很多 js框架。
我們在前面說到框架，往往是基於對整個ola（os/langsys/applicationdomain）的修正增強補充。"js框架與瀏覽器/server環境"的關系跟"ola與框架"的關系一樣，可以全方位去修補，因此，類似react,vue這樣的東西其意義可大可小，可以是一個庫也可是一個框架。虛擬DOM就是這類框架用來修補目前還跟不上webapp需要而作的框架內暫代方案。
webfront/webfront框架的前世今生
我們來談下webfront/webfrontdev的前世今生（從網站前端到webapp）。首先是自適應、響應式設計，前后端用模版實現分離，DOM API最開始是一些JS框架要面向的全部東西（這些DOMAPI就是網站ui可編程的全部，注意從這里開始，我們嚴格區分siteui與webappui的說法），JQ這些能很好封裝ajax和dom，然后出現了更高級一點的MVC，前后端通過json數據交換實現分離《用開發本地tcpip程序的思路開發webapp》，那種monolith websiteapp的局面(服務器腳本中套前端和模板)被打破,一切用到的展示數據都是后端經由過程異步接口(AJAX/JSONP)的方法供給的，前端盡管展示。。再后來就是MVVC，到這里開始，已有webapp的初級形式，一些網站前端開始謀求progssive(注意這里是網站用的Progressive)。與移動端UI結合，又有pwa,spa,mpa(這里才是webapp化之后的前后端分離技術),
對於webapp:spa,mpa基本上，它們的分離前后端處理方法是把原來后端做的事放到了純前端，SPA 可以在客戶端提供完整的路由、頁面渲染、甚至一部分數據處理； 這往往需要一個比 jQuery 時代更重的 JavaScript 框架，來實現這些原本發生在后端的邏輯(在js下的web開發就是前后端分離又融合又融合又分離全棧技術方向會越來越統一，甚至環境都可以互換，ssr可以放到服務端做，而serviceworker也可以像cloudflare一樣放到服務端做，被稱為大前端，比如angular的出現，使得后端的mvc,和依賴注入等技術在前端也可用，但這只是例子之一)。而且使用虛擬DOM組件來代替raw DOM。----- 目前比較主流框架：vue、react、angular等框架。AngularJS 可以構建一個單一頁面應用程序（SPAs：Single Page Applications）。Vue (pronounced /vjuː/, like view) is a progressive framework for building user interfaces.我們在《elmlang：一種編碼和可視化調試支持內置的語言系統》《why elmlang:最簡最安全的full ola stack的終身webappdev語言選型》講過react和fp和虛擬dom組件（這里的組件並非指腳本語言二進制構件級的概念，而是指前端和瀏覽器DOM層級節點的“組件”，代表前端ui的統一可管理單元，類似桌面的widget），vue就是較它們更為輕量一點的方案，也有虛擬dom和組件，Vue 除了是 React/Angular 這種“重型武器”的競爭對手外，其輕量與高性能的優點使得它同樣可以作為傳統多頁應用開發中流行的 “jQuery/Zepto/Kissy + 模板引擎” 技術棧的完美替代。angular,react,vue都屬於純粹用組件，用程序員的思路來管理前端，雖然這樣可以使得html ui更像webapp ui，但這樣會破壞web的原始語義（比如seo），所以普通網站不太適合用這套框架，這都是網站管理后端，工具化應用用的。
大前端，這就有點像游戲引擎下開發游戲APP的思路了（這里是邏輯渲染引擎）。virtualdom就是從chrome真實渲染引擎中再建立一套編程用的場景管理和渲染實體/節點。而游戲UI/傳統桌面GUI都是組件管理和組件邏輯，這個組件可以是程序上的componet也可以是可視的widget，組件就是變web html模板元素為傳統的gui方式進行開發(template based ui變成了帶狀態的可編程ui widgets)。
PWA 方案（pwa+輕度spa）更接近於 Web 的方式，它是 Web 的增強而不是替代。PWA 一詞出自 Alex Russell 的 Progressive Web Apps: Escaping Tabs Without Losing Our Soul，構成 PWA 的標准都來自 Web 技術， 它們都是瀏覽器提供的、向下兼容的、沒有額外運行時代價的技術。 因此可以把任何現有的框架開發的 Web 頁面改造成 PWA，而且與 SPA 方案不同， 沒有強組件化機制，因此不需要一把重構可以逐步地遷移和改善。
Progressive 是指 PWA 的構建過程。Service Worker 是一個特殊的 Web Worker，PWA 對性能的提升主要靠 Service Worker(cloudflare workers用的類serverless雲函那套)，它是在傳統的 Client 和 Server 之間新增的一層。性能提升程度取決於這一層的具體策略。例如：它可以提供緩存服務,通過service worker在后台更新下載實現頁面離線也可以瀏覽(如material design)，加速應用程序渲染，並改善用戶體驗。
SPA:得益於ajax，我們可以實現無跳轉刷新，又多虧了瀏覽器的histroy機制，我們用hash的變化從而可以實現推動界面變化，純粹依賴原生瀏覽器環境，而無須用到vue,react組件里那些重度方案。
更多etc..
electron開始webapp
雖然web是本身跨平台跨語言的,但它並非嚴格跨端的，上面說到其存在多種瀏覽器以及內置瀏覽器的APP（如微信小程序以微信為宿主）的具體實現形式，這些依然需要在js框架層進行適配，web應用(包括webapp為前端的形式的整個web)都一般有明顯的前后端分離做成“一雲多端”結構，后端一般是傳統意義上的普通網站，（你可以在后端托管具體端，比如小程序端的前端資源文件，和提供小程序框架性的服務API。當然如果是管理性后端你也完全可以可以做成webapp形式)，前端則對應PC/mobile上原生瀏覽器網頁,pwa page(ES5起兼容的普通瀏覽器pwa+spa那套)，webapp spa/mpa,應用內的小程序，H5（這貨也可以理解為原生瀏覽器），等多種形式作為UI端和客戶端。----- 這些客戶端共享webfront技術、w3c規范雖然不是嚴格意義上真正的跨端，但已經做得差不多了，而vue,react等框架用“AST,渲染引擎，bridge,runtime等抽象中間層”進一步實現了“框架和開發層跨端”，(這個跨端才是跨各種運行js的瀏覽器實現而不是傳統意義上的跨OS) ---- ---- 也干脆出現了一些“跨服務商的webapp引擎”，如小程序開發框架，開源小程序引擎，在中國主要是一些電商系和外賣系移動APP的前端，其本質無外乎內置了自己的瀏覽器，加上vue封裝的小程序引擎，處理“提供一個小程序的宿主運行環境（如微信小程序的運行環境：分成渲染層和邏輯層，WXML和WXSS工作在渲染層，JS腳本工作在邏輯層），並植入自己業務的服務性API”的東西，及更多其它事情。
跟普通瀏覽器環境一樣，微信內置瀏覽器一樣，electron也是一種端,它提供了環境(整個v8服務,及它自己特有的一些api和擴展)，支持嚴肅和純粹，追新的webapp創造，，electron可嵌入顯示普通網頁和webapp，你也可以用electron做pc小程序也可以做移動小程序，electron下的小程序也不是普通網頁套個electron殼(比如我要做個blog客戶端就是給個主頁邏輯給electron)，而是網頁意義上真正的app化。
跟它們不一樣的是，electorn還提供了devstack(開發，語言支持，注意這並不是js而是更強大的nodejs/包結構和可開發生態)，框架方面你還需要vue等。vue和nodejs.還有vue-electron這樣的封裝，通過webpack生產webapp打包及流程自動化，產生支持普通瀏覽器js的vue引用。
下文我們就准備使用raw api,使用electron提供一個小程序的宿主運行環境，配合簡單后端，打造我們的移動/PC小程序:一個類《打造小程序版本公號和自托管的公號》miniblog的客戶端。利用它發明多端合一的“小程序”可免去依附於微信這樣的環境(微信小程序審核很費事。一點社交性質，個人版的小程序博客帶評論都不允許。為免責關注程序而不是內容)。