小程序杂谈.md

date	tags
2019-05-10	软件

小程序杂谈

首先我还是觉得小程序是个好东西，尽管相比于传统的h5 开发，有时它会让开发者感到束手束脚，甚至令开发者苦不堪言，经常会有烂尾的问题，或者新问题的爆发。对于“小程序是个”好东西，或者“小程序就是个坑”，我随便说几点。

小程序不是技术上的南辕北辙，而是产品上的生态收敛。

h5最大的优点就是可移植性强，只写一次就可以到处传播。微信是可以与h5互动的，通过jsbridge ，h5可以使用部分原生能力，最重要的还是宝贵的账号体系。在微信内的h5，授权流程的体验直接上一个台阶，相比于pc的扫码，以及手机端浏览器几乎是不可用（仍然提示扫码，但是不可操作）。但h5迁移能力强呀，翅膀硬了就不必寄人篱下了，无利不起早，微信不是慈善家。

那我继续提高开放的能力，并且封装一层让平台个性化抑制迁移，并顺便隔离一些不安全的或有损体验的功能，让你在微信上玩的开心玩的放心且只能在微信上玩。小程序说白了就是钦点的特有最佳实践，跟着微信方案走，开发者的应用能力达到最大化，微信自己的生态有了，其实是双赢的。

同构闻起来香吃起来臭。

后来的故事大家也都知道了，各个公司开始实现自家的小程序，这时候同构的价值就体现出来了，写一次多端运行，这价值很高，不过虽然这些小程序往往乍一看都差不多，实则同构难度较大。

能力差异。平台能力不同还好，布局能力不同就难办了，有些硬依赖，别的平台不支持，也很难办，比如微信小程序支持cover view ，头条小程序不支持。

兼容复杂度太大。如果从头开始同构，兼容性对于项目质量的破坏也是不可预测的，兼容性就是维度越多越难解决，同构会引入一大批变量，极端的做兼容情境下，效率甚至不如异构，且代码必乱。

变数大太。社区在变，同构方案也在变，小程序本身把研发挡在h5之外了，同构方案来了，研发又多了一层黑盒，干脆叫摸黑工程师好了。 同构需要从始至终，如果开发差不多再想起同构那基本也就告别同构了。

技术上与h5有交集也有差集，要有拍手叫好和低头骂娘两手准备。

视频中支持cover view ，这个能力让交互式学习开发变容易了，形式也是最优的。不允许直接渲染文本，以及代码包大小限制，让公式渲染采用了服务端的方案，增加了复杂度及调研成本。

页面栈只有五层。webview 只能铺满。代码包大小限制。主动触发的用户授权……等等。小程序我才玩一个月，我觉得坑肯定不止这些，当然也不能忘了拍手叫过的好。

总而言之

毕竟他的地盘他做主，至于研发上的挑战，就是我们应该解决的事啊。