一. 小程式是否會取代 App：

二. 小程式和服務號的關係；是否會給個人開放？

服務號是否可以轉為應用號？這個不得而知，但我相信肯定有大批的服務號是想轉變為應用號的，一些服務號的功能屬性遠大於媒體屬性，例如有硬體裝置連線需求的服務號、京東購物的服務號、滴滴出行等服務號，如果讓這些服務號主體再去開發小程式未免太折騰，主體下的服務號和小程式之間功能也會有重疊，浪費資源，也佔用使用者的資源，所以我的猜測是認證的服務號是可以轉（升級）為小程式的。在之前訂閱號是可以“升級”為服務號的，如果有這個可能，微信可能也會給出是否“升級”的選擇；因為從得到的訊息來看，微信的態度是訂閱號、服務號、企業號、小程式是完全並行的四種形態，所以服務號的繼續存在一定還有其服務號的意義，但如何升級不得而知，例如粉絲遷移？

小程式是否開放給個人？

在全面開放申請之後，主體型別包括個人、企業、政府、媒體或其他組織，這一點很有意思，小程式是有個人主體型別的，我們知道訂閱號是可以申請個人主體的，但服務號不可以為個人主體的，對此我有很多的疑問，小程式是有微信支付能力的，而小程式可以面向個人開放？稅務問題呢？對於個人來言的可信度整體來說一定要小於企業的可信度的，或者小程式的開放也是對不同組織有區別對待？例如個人開發者是沒有微信支付功能的，不然收款到哪裡？個人賬戶？服務號的微信支付都是關聯企業對公賬戶的，微信不會給你提供逃稅的能力。

三. 小程式商業化是怎樣的？

小程式是否會對開發者收費？對比 iOS 開發者，iOS 開發者是收費的，兩者都是需要經過稽核的，雖然現在沒有任何關於小程式是否面相開發者收費的訊息，但這並不是不可能，服務號、訂閱號的認證是收費的，認證之後獲得了未認證所沒有的能力，比如微信支付；我猜測小程式是會有收費的通道，類似認證費一樣（但可能不會叫認證費），然後獲得未認證所沒有的能力，或者叫其他名字的費用，按年收取。

四. 小程式 與 Native App 之間的關係？

HTML 5、JS 以及相關技術替代原生大家喊了很久了，就是大熱的 React Native 目前看來也依然很不完善。微信的應用應該都是執行在騰訊瀏覽器的X5核心裡，這東西怎麼樣大家心裡也都有數。我感覺還是隻能做一些低互動的應用，大概也就是比網頁快捷方式高一級別，要利用 OS 的炫酷特性，原生還是跑不掉，而且目前原生開發很成熟了，框架庫很多，門檻也很低。

五.不懂程式碼，不會開發怎麼辦？

對於沒有開發能力的商戶，現在會有一些第三方幫助他們去開發，但是也會有一些問題。比如商戶會擔心他的帳號密碼丟失，第三方也不好管理他的程式碼，微信小程式的實際控制權其實不在自己手上。"小程式第三方平臺" 開放後，可以讓商戶的微信小程式開發更省心，透過簡單小程式賬號授權動作，就可以獲得一個小程式，把技術開發這個事情變得更簡單。

上海菜花旗下的靠譜小程式™作為一個成熟的第三方小程式平臺，為想做小程式而沒有開發能力的中小公司，個體戶商家或者個人提供成熟的行業模板，巧妙的介面上設定，後臺能夠進行配置伺服器地址、程式碼開發、上傳、提交與釋出、模版訊息、客服訊息、微信登入等操作佔據小程式大部分市場。

個人覺得意義不大，粗略走馬看了一下那幾多的小程式名目，本人認為微信們的功能已經很精緻了，過多的新增就好象一位身材很苗條的美女忽然一下長胖了，現在的各種App品種繁多五八門，好多人也包括我自己可以說是了就不會去了解更不用說去應用了！其它的我不多說了，就一句:不要弄巧成拙，一盤清淡可口的蘭花菜把鹽放重了！