以上均爲個人彙總，如有不對歡迎指出！
小程序個人看法（跟技術無關，可跳過）
可能今天在很多人眼中，小程序已經成爲別人印象中的app，功能齊全，且可以完成各種功能以及業務。但是個人從小程序的誕生使用至今，在我眼中他依然是個輕量級應用，雖逐步的壯大，一些功能還是有所限制，但是從功能上的角度卻無法與app相媲美。以微信小程序爲例，也許今天大小限制8M，頁面棧已經是15層，大小可開發約50~70個頁面，的確已經很好的支持業務的開發以及功能的擴張。但是在小程序開始之初，頁面棧僅爲5，包大小限制1M，很多業務的確無法擴展。小程序也因業務的擴展，逐步逐漸支持工程化，如當前支持npm包。但我們從小程序的產品整體設計上，還是不能忘記這個限制，無止境的疊加頁面以及業務。
小程序的運行機制
簡單的藉助大神的思路，描述一下小程序的編譯原理。
我們都知道，小程序頁面由View（視圖層）,App Service(邏輯層)組成。它們在兩個線程中運行（我們傳統的h5,是單線程運行）。他們之間是由系統的JSBridage（常用於原生與h5交互的工具，可自行百度）進行交互的。
視圖層使用 WebView 渲染，iOS 中使用自帶 WKWebView，在 Android 使用騰訊的 x5 內核（基於 Blink）運行。
邏輯層使用在 iOS 中使用自帶的 JSCore 運行，在 Android 中使用騰訊的 x5 內核（基於 Blink）運行。
以上原理借鑑來自大神yck。
看到這裏，是否明白，爲什麼小程序不支持直接獲取dom跟bom了吧？因爲不像h5在同一個層級，在邏輯層時間上壓根沒有dom，只有通過官方的寫法，通過系統層去操作dom。
如有興趣具體代碼，可直接參考yck:https://juejin.im/post/5b8fd1416fb9a05cf3710690
小程序的常用第三方框架
原生
官方概念：官方自帶
筆者觀點：只有原生代碼，才能在對應的小程序環境跑起來。任何第三方框架，都是經過自己的bable編譯成原生支持代碼才能運行。因此，在不考慮多端的情況下，強烈推薦使用原生，這樣可以繞過第三方的坑。
Taro
官方概念:官方命名解釋爲多端統一開發解決方案。京東研發
筆者觀點：這在多端中的需求中，相比原生的優勢。此外，個人實踐的應用中，taro是個人覺得爲數不多兼容性較好的，坑相對較少。此外，官方還提供了taro-ui，ui從性能還有從外觀，個人都是覺得寫得非常的不錯。
此外，他是利用React的方式開發小程序的框架。 使用 React的方式開發小程序的框架，同時支持生成多端應用，此外還支持轉換rn等，如果同一項目需求有多個終端的要求。可以建議使用。
kbone
官方概念：Web 與小程序同構解決方案，騰訊研發。曾有這麼一句話：kbone，十分鐘讓 Vue 項目同時支持小程序
筆者觀點：如果有當前vue項目，急需支持微信小程序的話，可以考慮。這是一個求快不求精的選擇。爲騰訊官方出品，但是時間上的沉澱並不長，坑位估計不會少。有興趣繼續深入可查看：https://wechat-miniprogram.github.io/kbone/docs/qa/#%E7%AD%94%E7%96%91
mpvue
官方概念：基於 Vue.js 的小程序開發框架，從底層支持 Vue.js 語法和構建工具體系
筆者觀點：小程序第三方中較早起家的框架。這是曾經vue開發者非常喜歡的框架，無成本的從vue的開發者，成爲小程序開發者。植入了很多vue的概念，重寫了babel，支持vuex，vue常用api等。不過貌似已經停止迭代了，使用慎重。
uni-app
官方概念：使用 Vue 語法開發小程序、H5、App的統一框架
筆者觀點：歷史悠長，從hridyapp的時代就有了uni至今。將微信的api二次諷刺，用自己的uni-對象替換了wx對應去轉移成對應的api。目前還是有部分使用者，部分培訓機構也有提到（畢竟培訓的都是重點）。
WePY
官方概念：支持組件化的小程序開發框架，騰訊原生框架
筆者觀點：只是略有了解，身邊以及個人無人使用，不評論。
chameleon
官方概念：一套代碼運行多端，一端所見即多端所見，滴滴研發
筆者觀點：同上。
megalo
官方概念：基於 Vue 的小程序開發框架，網易考拉研發
筆者觀點：同上。
小程序如何工程化
我們都知道，當前前端項目都有自己的腳手架，可隨時更改自己的編譯，如create-react-app，vue-cli等都自帶webpack。而小程序的編譯器屬於內置編譯器，我們沒法對進行編譯處理，當我們需要對整個項目進行編譯或者工程化處理的時候，就會遇到瓶頸。這時候我們只能考慮自己嵌入工程化。
實際上，今天的小程序工程化的意義不是特別大。我們曾經有很多需要工程化小程序的需要，比如：支持npm包，支持es7，支持代碼壓縮，支持自定義指令，支持typescript等。
但是，小程序在長達幾年的迭代中，也逐步支持着一些（但是總是慢前端架構一段很長的時間，比如es7到2019年才支持，前端早幾年就可以用）
那當前工程化可以解決什麼問題呢？
1)我們前端框架是否都用了css預處理。如less，sass。小程序由於自身定位是一個“小”項目，所以，官方可能認爲不需要。但是我們實際業務中，或者手寫代碼的習慣，都習慣了less或者sass。
2)植入eslint 等代碼檢查工具
可能當前從這兩個角度出發意義不大。但是，就跟上邊所說，如再有什麼新的技能點，是否還是要慢個幾拍等官方支持？我們可提前做好準備。
使用gulp支持多頁面打包到對應的位置，相信對前端來說不是很困難吧？晚點可上傳demo。
小程序的優勢（相比web）
1.支持服務通知推送。
2.支持緩存數據推送。
3.開放能力
4.支持雲端開發
5.無需考慮兼容性
6.成本較低，體驗較好（相比web）