在2017年1月12日 weex conf 2017下午的技術實踐論壇上， weex團隊的勾股詳細講解了weex和web開發體驗的異同。他主要從weex 中的 web 标準、weex 中的 web 研發模式以及其它注意事項展開了此次分享。
本文根據現場分享和幻燈片整理而成。
weex 中的 web 标準<b></b>
weex中的web标準主要包括html/css/javascript三個次元。
<b>html</b><b></b>
目前weex支援的components約為15個，具體元件如下圖所示。
相比于完成的html文法标準，weex所缺失的内容可以總結為三部分：
塊級語義化标簽，如section、 article等；
内聯文本标簽，如strong、em等；
表單類标簽，如button、select等。
對于缺失的内容，weex提供了特定的的解決方式。對于缺失的塊級語義化标簽，可以通過自定義标簽的方式去定制，如<section>标簽可以通過<div>的方式代替（兩者行為類似），并且降低了成本。具體代碼如下：
采用div替換後：
對于内聯語義化标簽，如<strong>标簽，也可以<text style="font-weight: bold;">方式替換，效果完全相同。
對于表單類标簽，如<input>/<textarea>等文本輸入相關的标簽現已支援；radio可以利用<image>+<text>拼接實作；checkbox可以利用<switch>代替；<select>标簽可以通過picker或自定義定制得到。
<b>css</b>
對于css，從命題次元角度考慮：首先，css選擇器種類繁多；其次，css有很多屬性，相同或不同的屬性有着各種屬性值和機關。weex在支援css方面具有以下特點：
從上層文法角度來看，weex目前支援單個class選擇器，這也是css在js中的最佳實踐；
由于目前的vue 2.0前端架構、上層建築以及周邊元件足夠豐富，目前weex現已支援postcss/css next。
<b>javascript</b><b></b>
在weex運作時，隻有一個javascript引擎執行個體。在weex中，盡管可以同時打開多個頁面，但這些頁面是共享一份javascript（這和傳統的網頁有差別）。之是以這麼做是為了讓裝置在端上的資源能夠得到充分利用，但這同時帶來了長效的javascript記憶體洩露的問題。
目前，除了通過封裝的方式控制記憶體洩露之外，還可以強制“use strict”，因為在該模式下無法随意建立全局變量；此外，還可以強制object.freeze全局變量，在此之後對全局變量或對象隻能進行讀操作。
<b>js service</b><b></b>
未來，我們希望在javascript引擎中建立js service層，該層可以橫跨多種js架構統一管理；同時可以橫跨所有執行個體，實作多執行個體統一管理，使得能力、資料和記憶體得到有效管理和增強；甚至可以将polyfill、amd 實作、第三方庫引入、native 回調函數管理、全局資料共享、全局路由管理、worker...等功能都在js service排程實作。
vue 2.x 在weex和web中的差異<b></b>
vue 2.x 在 weex 和 web 中的差異主要展現在平台、功能、樣式、編譯環境上，下面來一一解讀。
<b>平台差異</b>，vue.js最初是為 web 平台設計的，雖然可以基于 weex 開發原生應用，但是 web 開發和原生開發畢竟不同，由于運作平台存在差異，weex 不支援 vue 中與 dom 相關的功能：
不支援事件冒泡和捕獲機制，.prevent 、.capture 、.stop 、.self 等事件修飾符在原生環境中無意義；
鍵盤事件的 .{keycode | keyalias} 修飾符在原生環境中無意義；
無法通過 vm.$el 擷取界面元素，原生環境中沒有 dom element；
無需自行調用 vm.$mount，預設會将入口元件挂載到原生應用的視圖中；
不支援 v-html 和 v-text 指令。
<b>功能差異</b>，weex 中僅引入 vue runtime 的功能，這樣做除了可以減少代碼體積以外，還能減少運作期編譯模闆的負擔，提升性能。具體的差異有：
定義元件時不支援使用 template 屬性；
不支援使用 x-templates；
不支援使用 vue.compile。
<b>樣式差異，</b>weex 中的樣式是由原生渲染器解析的，出于性能和功能複雜度的考慮，weex 對 css 的特性做了一些取舍，使其更符合最佳實踐：
weex 中隻支援單個類名選擇器，不支援關系選擇器，也不支援屬性選擇器；
在 weex 中，寫在元件 <style> 裡的樣式隻能用在目前元件中，預設是 scoped 作用域。
<b>編譯環境的差異，</b>在 weex 中使用 vue.js ，你所需要關注的運作平台除了 web 之外還有 android 和 ios ，在開發和編譯環境上還有一些不同點。針對 web 和原生平台，将 vue 項目源檔案編譯成目标檔案，有兩種不同的方式：
針對 web 平台，和普通 vue 2.x 項目一樣，可以使用任意官方推薦的方式編譯源檔案，如 webpack + vue-loader 或者 browserify + vueify ；
針對 android 和 ios 平台，我們提供了 weex-loader 工具支援編譯 .vue 格式的單檔案元件；也就是說，目前隻能使用 webpack + weex-loader 來生成原生端可用的 js bundle。
研發模式<b></b>
較為合理的移動開發模式應該是單頁研發、多頁聚合，也就是先把一個移動應用拆成多個頁面，每個頁面可以獨立設計和開發，中間通過路由方式或排程的方式串聯起來。
這種方式和web中的spa方式産生一定的交集。spa（single-page application）即單頁化應用，它的優勢在于避免了多個頁面重複加載資源（所有資源第一次全部加載好，打成bundle）；其次，可以友善地自定義專場效果；再者，它幾乎沒有頁面之間的等待；此外，spa與全局資料、全局狀态共享可以做到天衣無縫地結合。
但在實際使用spa的時，也遇到很多痛點，如頁面首次打開的開銷；記憶體管理問題，多個頁面共享一個記憶體；原生路由的配合/開放規則的應對；所有頁面必須基于相同的js架構等問題。
那麼weex的研發模式又是如何實作的呢？
首先，weex堅持每個頁面一個js bundle；再者，支援原生的轉場效果；同時，運作時優化、緩存和預加載也進行充分的實踐；此外，還通過js service進行資源複用和全局資料/狀态管理。
經過這些改進之後，即便非單頁應用，weex也可以實作頁面秒開；同時，不同的團隊/個人可以自由選擇js架構；還為記憶體管理提供了更好的引導，并支援原生&開放規則的路由。是以，是時候向spa說再見了！
<b>工程研發</b><b></b>
從工程研發角度來看，weex中web開發過程必定需要如下幾類上層建築：
初始化項目，因為前端越來越複雜，有很多環境需要配置，是以一個優秀的、極度簡單的腳手架變得越來越重要，建議使用weex-toolkit或vue-cli；
開發環境，前端主流編輯器均可應用在weex中。
調試，因為無法完全在浏覽器内調試，建議在真機情況下調試，目前weex提供了端上預覽、hot-reload以及native調試工具。
測試，目前與macaca測試架構結合使用。
打包，目前社群有多種打包方式供選擇，如webpack/babel/postcss。
釋出，釋出目前不是某個具體的工具，但每一家公司都會有自己搭建、釋出、緩存推送的平台，也可以沿用web研發的最佳實踐。
監控，可以采用曝光埋點、互動埋點等方式，也可以沿用web研發中的監控最佳實踐。
其它注意事項<b></b>
在具體實踐中，總結了一些具體事項：
長列表性能優化 ，可以<list> / <cell>對記憶體做進一步回收，有一點需要注意的是預設對圖檔進行回收（即圖檔在可視區外會自動回收）；
流式渲染，通過append=“tree|node”可以控制渲染的顆粒度，進一步優化首屏渲染效果；
view嵌套層級不宜過多，最好不要超過10層；
推薦 devtool 真機調試。
<b> </b>