用框架是不可能用框架的，這輩子都不可能用框架。

微信小程序上手成本低，開(kāi)發(fā)成本低，流量紅利，推廣成本低等等，很多公司的創(chuàng)業(yè)項(xiàng)目都會(huì)首選小程序來(lái)試水，小程序開(kāi)發(fā)太火爆了,苦逼了前端工程師，又得學(xué)習(xí)新技術(shù)...學(xué)習(xí)讓我快樂(lè)

半年時(shí)間，我已經(jīng)開(kāi)發(fā)了四個(gè)小程序，其中三個(gè)微信小程序，一個(gè)支付寶小程序。原生開(kāi)發(fā)過(guò)，框架也用過(guò)。到底最優(yōu)雅的開(kāi)發(fā)模式是什么呢，聊聊，聊聊。

技術(shù)方案

目前開(kāi)發(fā)微信小程序時(shí)，可選的技術(shù)方案大概有若干種，分別是：

1. 微信小程序原生開(kāi)發(fā)
2. 使用wepy框架
3. 使用mpvue框架
4. 使用taro框架
5. 其他框架

使用框架來(lái)開(kāi)發(fā)，總結(jié)起來(lái)就干了一件事——加糖，但這糖好不好呢，不好說(shuō)。

框架開(kāi)發(fā)的初(li)衷(xiang)

1. 快速迭代
2. 減少開(kāi)發(fā)成本
3. 跨平臺(tái)共享
4. 提升開(kāi)發(fā)體驗(yàn)

框架開(kāi)發(fā)的挑(xian)戰(zhàn)(shi)

1. 必須同時(shí)熟悉微信小程序文檔和第三方框架文檔，給工程師提出了更大的挑戰(zhàn)
2. 框架的不完美，只是閹割版或者修改版的前端框架，并沒(méi)有100%支持框架自身特性
3. 框架構(gòu)建與微信小程序之上，反而導(dǎo)致部分原生支持的特性作廢，比如原生組件，模塊化等
4. 框架生態(tài)不健全，文檔及相關(guān)資源匱乏
5. 微信小程序自身處于快速迭代的狀態(tài)，特性并不穩(wěn)定，不像web一樣有統(tǒng)一的標(biāo)準(zhǔn)

理想很美好，現(xiàn)實(shí)很殘酷

wepy框架來(lái)說(shuō)，組件化的支持不成熟，在實(shí)際的開(kāi)發(fā)過(guò)程中，如果組件嵌套超過(guò)兩層，面對(duì)某些特殊業(yè)務(wù)場(chǎng)景，翻車幾率很高。組件的列表渲染，不支持在 repeat 的組件中去使用 props, computed, watch 等等特性。

mpvue框架是基于Vue.js的核心，屬于修改版的vue框架，用起來(lái)和web端的vue也有些差異。

我的想法

使用第三方框架開(kāi)發(fā)，可以享受框架帶來(lái)的開(kāi)發(fā)便利，但對(duì)于小程序新增的諸多特性和功能，比如WXS模塊、自定義組件和插件等，受制于第三方框架，無(wú)法使用。

而原生小程序的開(kāi)發(fā)模式，又過(guò)于簡(jiǎn)陋，就樣式來(lái)說(shuō)，寫(xiě)慣了less，stylus和sass的同學(xué)一定無(wú)法忍受wxss的這種寫(xiě)法，基于此，決定使用gulp自動(dòng)化工具來(lái)構(gòu)建一套微信小程序開(kāi)發(fā)的基礎(chǔ)模板，在完全保留微信小程序功能和特性的基礎(chǔ)上，又可以的使用less來(lái)寫(xiě)樣式，同時(shí)加入圖片壓縮，命令行快速創(chuàng)建模板等特性，如此開(kāi)發(fā)，快哉，快哉！

wx-miniprogram-boilerplate

后續(xù)會(huì)再加入其它工具，持續(xù)更新，歡迎各位提意見(jiàn)。