小程序目前被炒得沸沸揚揚，無數業內業外人士都對此雄心勃勃，希望佔據先機，藉此一統江湖，千秋萬代。這再次證明一點，微信想讓什麼火，什麼就能火。這種能力目前在國內估計也是無人能出其右了……
好了，廢話不多話，言歸正傳。作爲一個要成爲成功人士的男人，利用國慶的時間，我好好的研究了一下微信小程序，發現網上很多言論對於微信小程序的言論，在一定區間存在理解上的誤區。接下來的內容，我假定你已經初步的瞭解過微信小程序，如果你還不瞭解，請移步開發文檔，然後再回來閱讀本文。
一、小程序到底是不是Html5
關於這一點，網上引起的爭議其實是相當大的。最初大家的認知一邊倒的認爲微信小程序就是用Html5來開發，然後當小程序真正出來之後，大家發現原來小程序跟Html5只是比較相似，但具體的規則和寫法卻有着一些差異不同，例如：
小程序的代碼目錄
上圖爲一個小程序的代碼目錄，後綴名分別是wxml、wxss和js。不過微信對wxml的全稱定義也不是weixin xml，而是WeiXin MarkupLanguage，很霸氣的要自成體系感。自然wxss也是WeiXin Style Sheets，一樣的希望給人牛逼哄哄的感覺。
下面是一段wxml示例，相對於早期的xml，擴展了花括號模板的寫法。
wxml示例
到了這個階段，部分質樸的同學就開始比較凌亂了，於是又有一種見解出現，那就是微信小程序不是Html5。好吧，我必須承認，我也一度糾結過，你看，這剛好證明了我是多麼的質樸。但在經過更加深入的分析和研究之後，我想表達一個觀點，
同時通過分析小程序的運行原理，微信小程序在本質上其實就是Html5，小程序的開發過程會用到大量HTML5相關的技術，但並不是全部使用HTML5開發。有 HTML5經驗的前端工程師學習微信小程序的開發相對會更容易一些。微信小程序的運行並不需要一個完整支持HTML5特性的標準瀏覽器內核，但也可以通過添加一些輔助設施，讓小程序在個完整支持HTML5標準的瀏覽器上運行起來。
關於讓讓小程序在個完整支持HTML5標準的瀏覽器上運行起來，有興趣的同學具體可以參見讓你的微信小程序運行在Chrome瀏覽器上。
那既然微信小程序的本質就是Html5，爲什麼微信要如此大費周張的來封裝成我們現在所看到的樣子了？作爲一名產品汪，我的職業病瞬間就爆發了，而且是晚期，無可救治。按照我自己淺陋的推斷來看，可能存在以下兩個原因：
第一個原因，是借用網上不少產品人士的一種觀點，那就是微信需要通過這種方法來轉化開發者，這些開發者未來會逐漸演變成“微信OS平臺”的忠實開發者。其實開發者通常都有患有“斯德哥爾摩綜合症”，一旦在一個平臺上投入了智力資源進行學習，就會開始下意識的維護這個平臺（比如看不到平臺的缺點，只看到平臺的優點）。如果使用HTML5作爲開發方式，那麼現在小程序聚攏的開發者都是爲了流量來的，並沒有投入額外的學習成本，對平臺不夠忠誠。當然這個推斷是否正確，無法評價，只能說是一個仁者見仁，智者見智的問題了。
第二個原因，是從技術的優化角度來推斷的。衆所周知，Html5在短期內，相比於本地應用依然存在無法忽視的性能缺陷。因此也有可能是微信通過完全重構了一個內置的解析器（大概有點類似於NodeJs），在優化提升性能的基礎上，去除了對性能影響比較大且不是必須存在的部分之後，所得到的一個綜合性的解決方案。如果是這樣，那自然不能再引導衆多的開發者直接使用原生的Html5技術來實現小程序的開發了。與其事後陷入各種Html屬性、特性不支持的吐槽聲中，不如直接開始就是一刀切，即避免了麻煩，又能符合自己新產品的定位和需要。當然這一切僅代表我個人的觀點。
第三個原因，是部分技術大牛從技術突破角度來推斷的。比如，也許小程序壓根就不是一個B/S的結構，而是一個C/S的結構。很多人不明白c/s應用爲什麼也可以即點即用，不用安裝。其實這不是微信的首創，首創是一種叫流應用（想了解詳情請百度）的技術。只要是動態語言，加上合適的算法，就可以先下載部分程序並運行，然後邊用邊下，類似於流媒體。我個人認爲這種可能性不大，因爲我很好奇如果真是這樣，那微信對小程序的空間佔用問題會怎麼管理？
好吧，分析到這裏先告一個段落，主要是我已經吃藥了，產品汪的職業病得到了有效的遏制。回顧我們開始提出的問題，就目前所能掌握的情況，我們可以很明確的得到一個結論：
微信小程序本質上就是Html5，或者說是一種優化過之後的Html5。
而至於微信爲什麼這麼做的原因，我相信，隨着微信小程序的測試賬號進一步開放，我們也能夠瞭解到越來越多的信息，屆時有機會，我再繼續爲大家作一些粗淺的分析。
二、移動網站或WebApp能直接改造成小程序
其實，之所以會保留這個認識，主要是由於過去微信公衆號的二次開發經驗，很大程度上給到了我們很多人先入爲主的觀念。
但通過我們上面所分析的第一個問題，可以知道僅管微信小程序本質上就是Html5，但實際上卻是一種優化過之後的Html5，這也就意味着絕大多數的移動網站或WebApp直接改造成小程序的難度很大，因爲裏面有大量的內容需要重寫。比如：頁面的JS腳本邏輯在是在JsCore中運行，JsCore是一個沒有窗口對象的環境，所以不能再腳本中使用window，也就無法在腳本中操作組件，更意味着zepto/jquery這些框架一個都用不了。
我認爲，在相當大一部分情況下，一個以前已經寫好存在的HTML5頁面，並不能通過自動轉換工具變成一個合法的小程序Page，而需要有工程師根據HTML5頁面的功能，使用微信小程序的框架再實現一次。
老闆們可能認爲移動網站或之前公衆號裏的WebApp簡單改改就可以接入小程序，然後對工程師報的工期不可理解，此時工程師可以把此文轉給老闆看，小程序是相當於重新做了一個App，從開發、設計、測試、運維升級都是單獨的一套。哦，你還得加個學習成本和風險，如此新的東西一次搞利索的可能性還真不好說，畢竟小程序現在自己也還是在測試階段……
三、開發小程序的學習成本
關於這一點，正如我之前所提到的，有 HTML5經驗的前端工程師學習微信小程序的開發相對會更容易一些。我在做一個小案例的時候，能夠明顯的感覺到小程序Page的整體設計上有明顯的“反應式”編程風格，相信有vue.js，angularJS，reactive.js開發經驗的同學可以很快上手。當然由於沒有內測資格所以沒法在手機上測試性能，不清楚小程序的這套框架有沒有反應式編程常見的性能問題。這個等公測後先定個小目標，比方說我們寫他個有幾十萬條數據的列表，看看滾動流不流暢就知道了。
考慮到微信的官方示例確實是簡單到不行了，除了能幫助你瞭解一下基礎的項目結構之外，其他的意義並不大，因此我這裏隨意做了一個簡單的示例，供大家初步參考一下。因爲實在太簡單，所以也就沒有放git了，直接用網盤的形式給大家下載好了。下載鏈接
小程序示例
四、結束語
最後再來說說文章標題的事情。好吧，我知道這是一個非常欠抽的標題。在微信小程序沒有全面開放之前，可能我自己也是一樣的不清醒，說不定最後打臉打得嘩嘩的響。這年頭，真應了那句話，一切皆有可能……
但不管怎麼樣，作爲一名技術愛好者、作爲一名產品汪，我依然會在技術與產品的這條不歸路上越走越遠。有時間而且如果大家能夠支持的話，下一篇文章我想爲大家介紹一下微信小程序開發過程中，需要特別注意的幾個要點。
好了，這次的水文就記錄到這裏，順便做個廣告。如果大家覺得這篇文章能夠給自己帶來一點點小小的幫助，那麼也想請大家順手幫我一個小忙。點擊速課網的鏈接，然後進入平臺註冊一個賬號（手機、郵箱或者第三方登錄都可以），以後有時間的話體驗一下我們的產品，如果能給到我一些寶貴的意見，就更加感激了。速課網是一個專注於移動教學課件建設的平臺，目前已達成天使輪，誠邀各位技術大神與運營牛人的加入。