昨天晚上，微信宣布「為方便開發者靈活配置小程序，小程序現開放內嵌 Web 頁面能力」。
在這之前，如果有人問我，在微信中做一個產品，是用小程序還是 Web 頁面 (嚴謹，既不是 HTML5 更不是 H5…) 的時候，我會這么說：
產品上，Web 上能做的，小程序中大部分都能做。小程序上能做的，Web 上不一定能做。
營銷上，Web 能用到的入口，除了朋友圈以外，小程序都可以用。小程序能用到的若干入口，Web 不能使用。
關于后一點，朋友圈分享現在普遍會用海報來做，在這點上 Web 和小程序的能力其實是一樣的，都是只能幫你保存圖片到相冊，再請用戶手動發送到朋友圈。而小程序獨有的發現 - 小程序、搜索框快捷方式等對用戶回訪特別重要的入口，Web 頁面是不能使用的。
那么，昨天的發布意味著什么？簡單地說，小程序的開發成本有了很大的下降。
微信小程序剛剛上線的時候，由于小程序使用類似
HTML、CSS 和 JavaScript 等 Web 語言的方式進行開發，讓一些媒體誤以為小程序就是 Web 開發，歡呼將「迎來 Web
開發的春天」。我自己的第一份工作就是 Web 開發工程師，Web 開發入門確實比較容易；可是盡管小程序使用了 Web
語言，那只是語法上的一致，整個開發模式完全不同，更接近于原生 App 的開發而不是
Web。打個比方，對在看這篇文章的大多數人來說，讀中文要比讀英文更容易，但假如你看不懂英文版的《量子力學導論》，翻譯成中文版你也不一定能看懂。開發小程序，需要有專門的、獨立于
Web 團隊之外的團隊，按小程序的規范重新設計、重新開發，不能將已有的產品直接遷移過來。
可以理解微信當初做這個決定，是希望開發者按照微信的要求，為微信的用戶重新去思考、設計一套全新的用戶體驗，而不是將已有的
Web 頁面搬進來。歷史上，包括 Microsoft 的 Windows Phone 平臺、Google 的 Chrome Packaged
App 都冒過類似的險，而其實 Apple 也做過類似的決定——Steve Jobs 2010 年 4 月親筆寫過一篇文章，解釋為何
iPhone 不支持 Flash (Thoughts on Flash)，其中 重要的原因是，Apple
不希望第三方開發者將已有的產品直接搬過來，而是希望開發者能直接在 iOS (當年還叫 iPhone OS) 進行開發，為 iPhone
的用戶提供 好的體驗。這些決定賭的是，新平臺 (小程序或 iOS) 帶來的商業上的好處， 終會讓開發者們愿意付出這個成本。
那時候的 iPhone 還很弱小，但后來的歷史證明 Steve Jobs 賭對了——Adobe 公司今年 7 月宣布，將在 2020 年 終停止 Flash 的更新和分發。
微信，則在昨天支持了開發者直接嵌入已有網頁。
所以，如果你已經有一個網站，可以直接在小程序中套個殼，把網站中的 Web 頁面搖身一變成一個小程序。至于這和直接分發 Web 頁面有什么區別——
產品上，Web 上能做的，小程序中大部分都能做。小程序上能做的，Web 上不一定能做。
營銷上，Web 能用到的入口，除了朋友圈以外，小程序都可以用。小程序能用到的若干入口，Web 不能使用。
細心的你可能已經注意到了，上面這兩條并沒有任何變化… 對，在小程序的用法上其實沒有任何變化，只是開發成本下降了。
那么，在今天之后，使用微信小程序框架開發的「原生」小程序，和嵌入已有的 Web 頁面的「Web」小程序，在用戶感受上會有什么區別呢？
「原生」小程序，整個小程序是提前下載的，不會有 Web 頁面打開時的頁面加載感。我們過去的可用性研究表明，這是用戶對一個界面是「Web」還是「原生」的 主要判斷標準。對于偏工具型的小程序，「原生」的感受應該會更好。
「原生」小程序對體驗的控制更完整，自己要做的事情也更多。例如 Web 頁面中用戶可以選擇頁面上的文字復制，而在「原生」小程序界面中，這是需要單獨添加的功能。
「原生」小程序提供了一些專屬的控件和 APIs（接口），如展示群信息、發送推送等，這些只有使用小程序框架開發才能使用。
所以，如果需要和微信生態整合得更緊密，可以使用「原生」方式開發；如果追求快速遷移已有 Web 產品，嵌入 Web 頁面更快。
注意，微信小程序嵌入網頁的功能，目前還不對個人開放，且對網頁的域名有要求。
后，來講講輕芒小程序+ 相應的變化。輕芒小程序+ 是目前唯一面向內容創作者的免費小程序解決方案。在微信昨天的更新后，我們也會陸續推出新功能，包括：免費支持嵌入網頁能力，如果你已有網頁，可以借助輕芒小程序+ 無代碼、自助生成一個小程序等等。
