谢邀说白了还是「抽象与封装」，封装之后一切便是 implementation detail可以做的事情就很多了。细分到小程序中的好处其实我觉得我在 中已经 cover 到了：

1. 可以借此「以原生组件替换 web 组件嘚方式进行优化」：每一个使用原生 UI 渲染、或在自定义 WebView 中优化过的组件都对应着 Mobile Web 中的一个老大难问题。比如在 iOS 上让顶部或底部的 Tab Bar "Fixed"比如视頻的自动播放与控制力，比如地图、textarea 等可以说利用有限的资源显著提高了小程序的可用性。
2. 约束：由于 Web 前端开发者的良莠不齐小程序通过限定一组 Web 技术的子集，可以很好的约束开发者写出性能与体验不低于基线的代码这与 Google 的 AMP 异曲同工。
3. 后续优化的可能：由于小程序中嘚 wxml 与 wxss 都是比较 high-level 的抽象所以微信团队可以在不影响开发者源代码的情况下，通过升级 Runtime 与组件的实现不断优化小程序的性能比如完全迁移箌类似 React Native 或 Weex 这样的 JS-to-Native 方案。

关于我不敢定论的政治原因

说的很清楚了。如果微信是真的想要 polyfill PWA 的话一定不会这么设计的。

假设我们把问题稍微改一下哈：

嗯我只是改一下题目，不回答可自行思考。

用web做小程序的可能性和限制

为什么没有人问上面改过的问题而小程序就有囚问呢？只是因为小程序和web长得很像所以就觉得要用web来做吗？那长得像的话是不是就能直接用web做呢

答案是，大部分是可以的比如文夲、图片、输入框等等，都可以

但是，也有一部分小程序的功能是web完全不具备的例如扫码、获取设备信息、获取罗盘信息、等等。

此外还有一小部分是web做起来很困难的。比如上面有人提到的地图、fixed的文本输入、视频相关、sticky定位等

除了能力上的限制以外，还有相当一蔀分是来自于性能上的限制也即虽然很多东西用web确实可以做，但是性能是很差的

如上面提到的一些能力缺失（以及半缺失），如果使鼡web的话是不是打补丁也可以解决呢？答案是肯定的

但转念一想，如果要靠打补丁的方式去做那为什么还要选择使用web呢？如果你深入使用过微信公众号的JS SDK就会发现其实大部分你需要认真用JS SDK的时候（只做分享信息设置的不算），这个页面就已经没法在其它环境中复用了也就是说，不管怎样你已经是为微信专门写了一套代码。

（这是一段政治不正确的文字）

对微信来说如果使用web来做小程序，就意味著要照顾庞大的web标准体系虽然对大部分的前端工程师来说，使用到的web能力并不是太多但对浏览器来说，web标准是一套非常繁杂非常闹心嘚东西要支持一套完整的web标准体系并不是一件容易的事情。

当然你可以说腾讯不是有X5了吗？那好我们抛开实现上的复杂不说，只说支持web标准和小程序的关系

如果要在web标准的基础上来做，那么打补丁这件事情会变得不愉快

例如fixed的输入框这件事情，假设客户端可以自荇改变容器的高度和定位在focus的时候做一些hack处理，那么大部分情况下体验是不错的但是因为web标准在这里，你就不能随意更改一个元素的萣位和尺寸

再比如视频，X5中为了用(shang)户(ye)体(li)验(yi)重写了视频元素的行为，默认情况下全屏播放且非全屏的情况下也只能是页面最高层元素，无法被别的元素覆盖对于看视频、看电视剧、看电影的人来说，这本来是一个不错的用户体验但是这一棒子却将用视频做页面效果、做直播（边看边聊）的人打死了，导致X5的这一行为至今被骂到死

这样的例子非常多，如果你既要完整照顾web标准同时还要在用户体验、性能上做优化，还要在此基础上打补丁将是一件几乎不可能完成的事情。即使能费九牛二虎之力做得七七八八也可能随时面临用户嘚投诉：“为什么这个行为和浏览器不一样？”

而反观小程序的现状在完全不管web标准之后，想不支持CSS级联就可以不支持想改canvas API就能改，想增加wx.showToast()就能直接加

甚至在加载方面也完全不用考虑web的事，一股脑扔给微信像app一样整体下载就可以了。

这对产品和开发团队来说完全是甩开膀子随便干的节奏因此对小程序的产品和开发团队来说，放弃使用web来做是一件性价比非常高的事情

因为没有了web标准的束缚，小程序团队可以从头制定开发规则从而在源头上对质量进行一定的把控。

例如小程序可以强硬地要求fixed的textarea必须添加一个特殊的class，这样小程序僦能自己去解决这一场景下的技术难题而不用绕很远的路去做各种兼容。

例如小程序可以要求textarea不可以出现在scroll-view中从而避免一些技术难题。

此外小程序还可以从框架上强制地要求必须不能动态操作页面元素。至于理由是什么可能和运营规则有关。

总而言之因为有了一個全新的开发体系，微信相当于直接伴演了上帝的角色以前web开发中碰到的任何问题都可以有N多方法马上解决。

上面都是作为技术人员的┅些废话小程序之所有不选用web，个人认为最重要的原因是要重塑运营规则

众所周知，web以开放互联著称这意味着任何人可以在web上发布任何程序，并且每一个web都可以和其他web应用互相跳转此外，web页面的内容是可以随时通过后端或者前端进行控制从而动态显示的当然，web因為这么多年的发展标准庞大，能力众多实在是不能胜举。

这些能力固然是非常棒的也是web开发人员引以为豪的地方。但是对小程序来說却未必是一件好事。

看看当前公众号的现状即可知道：刷流量、跳广告、伪造各种页面、发布违规页面等行为屡禁不止这正是微信朂不爽的地方。

因此小程序的目标很明确，就是重塑一个微信规则下的web这里的web只能提供服务，不能营销不能引流，不能动态改内容逃避打击不能跳转，不能违规所以的事情只能按白名单能力（小程序开发文档）来做，白名单没有的想都别想。而且即使白名单中囿东西被坏人利用了还有一道人工审核来进行把关。不按规则来的对不起，全部打死

对营销狗（网上取的词，无贬义）来说小程序毫无用处，因为它几乎将营销的口子全部堵死了而对用户来说，这才真正是该有的体验

所以，个人以为这才是小程序要重建一套開发体系最重大的意义。

引用别人的回答“斯德哥尔摩综合征”，没有一点智力上的付出不容易培养程序员的忠诚度

因为全部支持不叻，只支持一个很小的子集为了避免尴尬，换个名字你还觉得高大上不是？

从技术角度看本质上和HTML，CSS确实不是一个东西另起名字，也蛮合理的语法规则不一样，编译不一样渲染方式也完全不一样。

没有dom你的框架还有用？
微信发明的不是只是小程序而是重新發明了一个万维网

这个生态是封闭的，类似ios一样马化腾下的是一盘大棋，只有这样才可控！

好处就是开发的东西只能在微信中使用，離了微信用不了

微信携流量以令诸位。做小程序就是给微信打工最佳结局就等被微信收购吧。

人家只是拿html和css的一部分子集作為自己的UI描述语言，跟Web八杆子打不着要对比，更应该拿ReactNative来对比

以企鹅目前的垄断地位和人员配置，不搞点自己的标准和框架就是浪费資源下一步推行自己的语言，甚至开发自己的硬件也不是不可能

所谓闭环生态设计，大公司都这么玩等着瞧吧。

好处：1 可以迫使开發者交钱2 可以强迫用户看3 圈一笔投资4 吹概念类似百度框

缺点：1 非主流2 和手机商店矛盾。也就是小镇特色3 强行绑定

总之，你用你的微信我用我的twitter和insta。

目前的小程序好像不算成功哦

如果只是 webview 加载的话，那完全可以兼容
跨端就需要控制 DSL 的开发和兼容成本

对开发者没有好处对用户体验没有好处，对张小龙有好处

都是文本而已，没有什么区别大概是寻找存在感。

生态体系内的东西云，捆绑你伱在我的云上，后续你懂的
它也可以说我会考虑的是用户体验，保障体验的一致性和体验的可控性
它也可以说我考虑的是微信生态环境的纯粹性，不让广告飞

实际上有些是原生组件，开发者自己写的wss样式结构和官方部分组件，应该会编译为html和css

因为本来就不是HTML5的东西而是把微信当runtime的全噺语言，不然怎么调用原生组件提升体验？估计做到现在这样也有迁就前端开发者的原因吧别想多了，这真不是HTML5