微信小程序为什么不用HTML5、CSS，自己搞了个WXML、WXSS，很多框架用不了，好处一点不知道？

来源：互联网发布：h5页面源码下载编辑：程序博客网时间：2024/06/10 23:25

转 https://www.zhihu.com/question/51809406

微信小程序为什么不用HTML5、CSS，自己搞了个WXML、WXSS，很多框架用不了，好处一点不知道，以前项目根本没法移植，而且我们习惯的jquery、auicss、图标等完全用不了，也没见WXML、WXSS有什么好处，完全理解不了。。。

关注者

393

被浏览

50833

23 个回答

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

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

还是那句话：

「All problems in computer science can be solved by another level of indirection」

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

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

编辑于 2017-01-13

引子

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

iOS应用为什么不用HTML5、CSS，自己搞了个OC / swift / autolayout / storyboard，很多框架用不了，好处一点不知道，以前项目根本没法移植，而且我们习惯的jquery、auicss、图标等完全用不了，也没见OC / swift / autolayout / storyboard有什么好处，完全理解不了。。。

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

用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只能提供服务，不能营销，不能引流，不能动态改内容逃避打击，不能跳转，不能违规。所以的事情只能按白名单能力（小程序开发文档）来做，白名单没有的，想都别想。而且即使白名单中有东西被坏人利用了，还有一道人工审核来进行把关。不按规则来的，对不起，全部打死。

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

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

编辑于 2017-01-13

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

发布于 2016-10-25

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

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

编辑于 2017-01-13

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

发布于 2017-01-24

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

发布于 2016-10-24

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

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

编辑于 2017-01-14

个人认为原因是微信有自立王国的野心。
推测：微信此举是为了在苹果眼皮底下构建一个自己的APP STORE。
不知各位有没有发现，微信小程序已经作为一个独立的框架登陆了http://w3cschool.cn的首页。和他平行的是：

毫无疑问，在现在这个时间节点，小程序与Android，IOS或是React等根本无法相提并论。但以微信庞大的体量和影响力，从11月公布消息以来就吸引了无数开发者的兴趣。相关教程，开发日志在还没公测时已经多如牛毛。作为一个轻量级webapp，拥有极低的学习成本以及超快的开发速度，它的潜力不应该被低估。（吐槽一句，小程序的IDE真的是烂到爆，我是被IDEA惯坏了吗？）
-----------------------------------------------------------------------------------------
另外本着“先问是不是”的精神，修正题主一个错误的题设:至少Jquery已经有人在小程序上进行了移植stephenml/wx-query。别的框架肯定也有，也请有了解的大大不吝赐教，感谢。

编辑于 2017-01-13

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

发布于 2017-01-13

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

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

编辑于 2017-01-13

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

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

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

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

编辑于 2017-04-04

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

发布于 2017-01-14

功能可控

发布于 2017-01-13

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

编辑于 2017-01-15

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

发布于 2017-01-29

自己造了个React的轮子，然后强迫大家玩？

W3Cschool - 学技术查资料，从w3cschool开始! 是什么垃圾网站？？？

最后送上【张学友表情】

编辑于 2017-01-23

官方文档这两段话应该可以说明两点：微信小程序依然是网页；搞WXML大概是为了提供自己的特性或者组件之类的。
另外，前端技术的标准是在改变的，但小程序开发者不需要修改他们的WXML，微信会将你编写的WXML文件转换以支持对应的新标准。

“javascript && wxss微信小程序运行在三端：iOS、Android 和 用于调试的开发者工具。三端的脚本执行环境聚以及用于渲染非原生组件的环境是各不相同的：在 iOS 上，小程序的 javascript 代码是运行在 JavaScriptCore 中，是由 WKWebView 来渲染的，环境有 iOS8、iOS9、iOS10在 Android 上，小程序的 javascript 代码是通过 X5 JSCore来解析，是由 X5 基于 Mobile Chrome 37 内核来渲染的在 开发工具上， 小程序的 javascript 代码是运行在 nwjs 中，是由 Chrome Webview 来渲染的 ”

“map、canvas、video、textarea 是由客户端创建的原生组件，原生组件的层级是最高的，所以页面中的其他组件无论设置 z-index 为多少，都无法盖在原生组件上。 原生组件暂时还无法放在 scroll-view 上，也无法对原生组件设置 css 动画。”

编辑于 2017-01-26

小程序，为业务而生

发布于 2017-01-14

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

编辑于 2017-01-13

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

发布于 2017-01-12

大概是因为全部特性支持起来太麻烦

发布于 2016-12-13

你看这些图标，不都是web程序吗？直接添加web图标不就成了移动浏览器了吗？微信小程序就是加强了web程序的社交功能吧。

编辑于 2017-01-18

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

发布于 2017-01-13

阅读全文

0 0