我們首先需要考慮兩個方面，開發成本和推廣成本。

原生APP一般要同時開發iOS和Android兩套，而小程序只需要做一套。毫無疑問，這點是小程序最大的優勢，從這個角度來看，小程序是“跨平臺“的。
 

具體到開發效率上，很遺憾，在現階段，開發一套完整邏輯的應用程序，小程序的開發效率是低于APP的。小程序獨立出了一個封閉的生態。

我們經常說不要重復的造輪子，可小程序現在是裸奔，你得自己去造輪子。而iOS和Android經過經年的累積，已有大量的成熟組件可以使用。

相反，小程序目前還處于內測階段，沒有任何優秀的第三方組件可以使用。而官方提供的組件，接口非常的少，實現功能沒問題，但你想自己去定義組件屬性、樣式是很困難的（這點真的很奇怪，所有組件沒有任何設置樣式的接口）。

我們團隊做了個簡單的對比，開發同樣一款簡單的天氣應用。iOS拿到UI設計稿后，輕車熟路兩天搞定，各種交互不需要UE，都是iOS常用動畫。web前端這邊，拿著設計稿去找UI：

這個透明的狀態欄我沒法實現，因為小程序的狀態欄必須要有 ； 底部的Tab欄我只能設置顏色和圖片，設計稿里的樣式我做不出來； Banner輪播的指示點我改不了。

我們在小程序開發中遇到最棘手的2個問題：

1. 缺少統計、繪圖組件，以前的echarts和hightcharts都無法使用，只能用canvas去繪制，耗費的時間之多可想而知。我們目前正在著手修改一款基于canvas的開源繪圖組件，讓其支持小程序。

2. 小程序不支持WebView，大量已被靜態化好的HTML頁面完全沒辦法在小程序上展示。如果要支持格式化的文本顯示，目前思路有二種：

• 編寫工具，用正則表達式解析HTML，并轉化成小程序的標簽。這個過程很繁瑣，不僅要處理標簽還要處理樣式。比如html中的 ul 簽，處理起來就很棘手；再比如小程序里的中是不能嵌套的（嵌套后內部的text樣式無效），而這樣的嵌套在html中太常見了。

• 編寫一個針對wxml的文本編輯器，用這樣的編輯器重新錄入和格式化文本（這就是小程序帶來的一個挺好的機會）

小程序原生支持WebView的可能性很小。如果支持WebView，那以前用HTML5開發的各類WebApp又可以在小程序里跑了，iOS —-> 微信—-> 小程序—-> WebView，這復雜的結構是要逆天的。但有可能微信會開放一個只支持CSS+HTML的WebView，不能運行javascript。

開發者在開發小程序之前一定要預先對這些技術問題做充分的了解，并在設計上、功能規劃上盡可能的規避。

現階段，你想按照你的UI設計去開發，困難不小。有人說目前小程序還在內測，未來會有大量的組件出現。會有組件出現我毫不懷疑，但組件的質量怎么樣，開發者的熱情有多高，能不能形成一個良好的社區氛圍，這些都是未知數。中國能夠靜下心來做開源的開發者，真的挺少。

至于推廣成本和用戶獲取上，很多人都認為小程序會有絕對的優勢，它處于微信內部，理應離微信關系鏈條更近。可微信至今沒有給小程序分享的接口，也許以后會給新的接口，也許會將小程序綁定到公眾號，借助公眾號來傳播，也許根本不給小程序提供分享的接口。

誰知道呢？

APP獲取用戶成本高的一個根本原因是用戶手機里的APP已經飽和了，我們不能拿一個新興生態的用戶獲取成本和一個已經飽和的生態做對比。

當小程序的生態也飽和的時候，這個成本還低嗎？點開你微信里的訂閱號，刺目的紅色數字有沒有亮瞎你的眼？而你又認真去閱讀的文章有幾篇？大量刷來的用戶那不叫用戶，想獲取一個真實的用戶的成本從來都不低。

這里還是建議各位開發者，把精力真正的放在產品上，不要一味的盯著著微信的傳播優勢和平臺優勢。小程序由于門檻較低，競爭的激烈程度將遠超iOS和Android。

Web發展這么多年, 積累的大量前端人才，極有可能被這波熱潮釋放。把精力投入在打磨產品上，結合自己產品的特點適度營銷，這才是王道。