[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"content-why-mini-program-use-self-developed-tech-stack":3,"$f3prlp54xj7cq":20},{"id":4,"type":5,"slug":6,"title":7,"date":8,"category":9,"tags":10,"body_markdown":12,"permalink":13,"excerpt_src":13,"media_type":13,"media_title":13,"media_author":13,"media_url":13,"rating":13,"layout":13,"pv":14,"admin_only":14,"created_at":15,"updated_at":15,"deleted_at":13,"status":16,"html":17,"excerpt":18,"cover":19},121,"article","why-mini-program-use-self-developed-tech-stack","【问答】为什么小程序自己做了一套开发体系","2017-01-13 13:37","tech",[11],"小程序","\n来自知乎问题[微信小程序为什么不用HTML5、CSS，自己搞了个WXML、WXSS，很多框架用不了，好处一点不知道？](https:\u002F\u002Fwww.zhihu.com\u002Fquestion\u002F51809406\u002Fanswer\u002F140747129)\n\n## 引子\n\n假设我们把问题稍微改一下哈：\n\n> iOS应用为什么不用HTML5、CSS，自己搞了个OC \u002F swift \u002F autolayout \u002F storyboard，很多框架用不了，好处一点不知道，以前项目根本没法移植，而且我们习惯的jquery、auicss、图标等完全用不了，也没见OC \u002F swift \u002F autolayout \u002F storyboard有什么好处，完全理解不了。。。\n\n嗯。我只是改一下题目，不回答。可自行思考。\n\n## 用web做小程序的可能性和限制\n\n为什么没有人问上面改过的问题，而小程序就有人问呢？只是因为小程序和web长得很像，所以就觉得要用web来做吗？那长得像的话是不是就能直接用web做呢？\n\n答案是，大部分是可以的。比如文本、图片、输入框等等，都可以。\n\n但是，也有一部分小程序的功能是web完全不具备的，例如扫码、获取设备信息、获取罗盘信息、等等。\n\n此外，还有一小部分是web做起来很困难的。比如上面有人提到的地图、fixed的文本输入、视频相关、sticky定位等。\n\n除了能力上的限制以外，还有相当一部分是来自于性能上的限制，也即虽然很多东西用web确实可以做，但是性能是很差的。\n\n\u003C!-- more -->\n\n## 打补丁可以吗？\n\n如上面提到的一些能力缺失（以及半缺失），如果使用web的话，是不是打补丁也可以解决呢？答案是肯定的。\n\n但转念一想，如果要靠打补丁的方式去做，那为什么还要选择使用web呢？如果你深入使用过微信公众号的JS SDK就会发现，其实大部分你需要认真用JS SDK的时候（只做分享信息设置的不算），这个页面就已经没法在其它环境中复用了。也就是说，不管怎样，你已经是为微信专门写了一套代码。\n\n## 抛弃标准\n\n（这是一段政治不正确的文字）\n\n对微信来说，如果使用web来做小程序，就意味着要照顾庞大的web标准体系。虽然对大部分的前端工程师来说，使用到的web能力并不是太多，但对浏览器来说，web标准是一套非常繁杂非常闹心的东西，要支持一套完整的web标准体系并不是一件容易的事情。\n\n当然，你可以说腾讯不是有X5了吗？那好，我们抛开实现上的复杂不说，只说支持web标准和小程序的关系。\n\n如果要在web标准的基础上来做，那么打补丁这件事情会变得不愉快。\n\n例如fixed的输入框这件事情，假设客户端可以自行改变容器的高度和定位，在focus的时候做一些hack处理，那么大部分情况下体验是不错的。但是因为web标准在这里，你就不能随意更改一个元素的定位和尺寸。\n\n再比如视频，X5中为了用(shang)户(ye)体(li)验(yi)，重写了视频元素的行为，默认情况下全屏播放，且非全屏的情况下也只能是页面最高层元素，无法被别的元素覆盖。对于看视频、看电视剧、看电影的人来说，这本来是一个不错的用户体验，但是这一棒子却将用视频做页面效果、做直播（边看边聊）的人打死了，导致X5的这一行为至今被骂到死。\n\n这样的例子非常多，如果你既要完整照顾web标准，同时还要在用户体验、性能上做优化，还要在此基础上打补丁，将是一件几乎不可能完成的事情。即使能费九牛二虎之力做得七七八八，也可能随时面临用户的投诉：“为什么这个行为和浏览器不一样？”\n\n而反观小程序的现状，在完全不管web标准之后，想不支持CSS级联就可以不支持，想改canvas API就能改，想增加wx.showToast()就能直接加。\n\n甚至在加载方面也完全不用考虑web的事，一股脑扔给微信，像app一样整体下载就可以了。\n\n这对产品和开发团队来说完全是甩开膀子随便干的节奏。因此对小程序的产品和开发团队来说，放弃使用web来做是一件性价比非常高的事情。\n\n## 重塑开发规则\n\n因为没有了web标准的束缚，小程序团队可以从头制定开发规则，从而在源头上对质量进行一定的把控。\n\n例如小程序可以强硬地要求，fixed的textarea必须添加一个特殊的class，这样小程序就能自己去解决这一场景下的技术难题，而不用绕很远的路去做各种兼容。\n\n例如小程序可以要求textarea不可以出现在scroll-view中，从而避免一些技术难题。\n\n此外，小程序还可以从框架上强制地要求必须不能动态操作页面元素。至于理由是什么，可能和运营规则有关。\n\n总而言之，因为有了一个全新的开发体系，微信相当于直接伴演了上帝的角色，以前web开发中碰到的任何问题都可以有N多方法马上解决。\n\n## 重塑运营规则\n\n上面都是作为技术人员的一些废话。小程序之所有不选用web，个人认为最重要的原因是要重塑运营规则。\n\n众所周知，web以开放互联著称，这意味着任何人可以在web上发布任何程序，并且每一个web都可以和其他web应用互相跳转。此外，web页面的内容是可以随时通过后端或者前端进行控制从而动态显示的。当然，web因为这么多年的发展，标准庞大，能力众多，实在是不能胜举。\n\n这些能力固然是非常棒的，也是web开发人员引以为豪的地方。但是对小程序来说，却未必是一件好事。\n\n看看当前公众号的现状即可知道：刷流量、跳广告、伪造各种页面、发布违规页面等行为屡禁不止。这正是微信最不爽的地方。\n\n因此，小程序的目标很明确，就是重塑一个微信规则下的web。这里的web只能提供服务，不能营销，不能引流，不能动态改内容逃避打击，不能跳转，不能违规。所以的事情只能按白名单能力（小程序开发文档）来做，白名单没有的，想都别想。而且即使白名单中有东西被坏人利用了，还有一道人工审核来进行把关。不按规则来的，对不起，全部打死。\n\n对营销狗（网上取的词，无贬义）来说，小程序毫无用处，因为它几乎将营销的口子全部堵死了。而对用户来说，这才真正是该有的体验。\n\n所以，个人以为，这才是小程序要重建一套开发体系最重大的意义。\n",null,0,"2026-08-28 04:37:17","published","\u003Cp>来自知乎问题\u003Ca href=\"https:\u002F\u002Fwww.zhihu.com\u002Fquestion\u002F51809406\u002Fanswer\u002F140747129\">微信小程序为什么不用HTML5、CSS，自己搞了个WXML、WXSS，很多框架用不了，好处一点不知道？\u003C\u002Fa>\u003C\u002Fp>\n\u003Ch2>引子\u003C\u002Fh2>\n\u003Cp>假设我们把问题稍微改一下哈：\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>iOS应用为什么不用HTML5、CSS，自己搞了个OC \u002F swift \u002F autolayout \u002F storyboard，很多框架用不了，好处一点不知道，以前项目根本没法移植，而且我们习惯的jquery、auicss、图标等完全用不了，也没见OC \u002F swift \u002F autolayout \u002F storyboard有什么好处，完全理解不了。。。\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>嗯。我只是改一下题目，不回答。可自行思考。\u003C\u002Fp>\n\u003Ch2>用web做小程序的可能性和限制\u003C\u002Fh2>\n\u003Cp>为什么没有人问上面改过的问题，而小程序就有人问呢？只是因为小程序和web长得很像，所以就觉得要用web来做吗？那长得像的话是不是就能直接用web做呢？\u003C\u002Fp>\n\u003Cp>答案是，大部分是可以的。比如文本、图片、输入框等等，都可以。\u003C\u002Fp>\n\u003Cp>但是，也有一部分小程序的功能是web完全不具备的，例如扫码、获取设备信息、获取罗盘信息、等等。\u003C\u002Fp>\n\u003Cp>此外，还有一小部分是web做起来很困难的。比如上面有人提到的地图、fixed的文本输入、视频相关、sticky定位等。\u003C\u002Fp>\n\u003Cp>除了能力上的限制以外，还有相当一部分是来自于性能上的限制，也即虽然很多东西用web确实可以做，但是性能是很差的。\u003C\u002Fp>\n\u003Ch2>打补丁可以吗？\u003C\u002Fh2>\n\u003Cp>如上面提到的一些能力缺失（以及半缺失），如果使用web的话，是不是打补丁也可以解决呢？答案是肯定的。\u003C\u002Fp>\n\u003Cp>但转念一想，如果要靠打补丁的方式去做，那为什么还要选择使用web呢？如果你深入使用过微信公众号的JS SDK就会发现，其实大部分你需要认真用JS SDK的时候（只做分享信息设置的不算），这个页面就已经没法在其它环境中复用了。也就是说，不管怎样，你已经是为微信专门写了一套代码。\u003C\u002Fp>\n\u003Ch2>抛弃标准\u003C\u002Fh2>\n\u003Cp>（这是一段政治不正确的文字）\u003C\u002Fp>\n\u003Cp>对微信来说，如果使用web来做小程序，就意味着要照顾庞大的web标准体系。虽然对大部分的前端工程师来说，使用到的web能力并不是太多，但对浏览器来说，web标准是一套非常繁杂非常闹心的东西，要支持一套完整的web标准体系并不是一件容易的事情。\u003C\u002Fp>\n\u003Cp>当然，你可以说腾讯不是有X5了吗？那好，我们抛开实现上的复杂不说，只说支持web标准和小程序的关系。\u003C\u002Fp>\n\u003Cp>如果要在web标准的基础上来做，那么打补丁这件事情会变得不愉快。\u003C\u002Fp>\n\u003Cp>例如fixed的输入框这件事情，假设客户端可以自行改变容器的高度和定位，在focus的时候做一些hack处理，那么大部分情况下体验是不错的。但是因为web标准在这里，你就不能随意更改一个元素的定位和尺寸。\u003C\u002Fp>\n\u003Cp>再比如视频，X5中为了用(shang)户(ye)体(li)验(yi)，重写了视频元素的行为，默认情况下全屏播放，且非全屏的情况下也只能是页面最高层元素，无法被别的元素覆盖。对于看视频、看电视剧、看电影的人来说，这本来是一个不错的用户体验，但是这一棒子却将用视频做页面效果、做直播（边看边聊）的人打死了，导致X5的这一行为至今被骂到死。\u003C\u002Fp>\n\u003Cp>这样的例子非常多，如果你既要完整照顾web标准，同时还要在用户体验、性能上做优化，还要在此基础上打补丁，将是一件几乎不可能完成的事情。即使能费九牛二虎之力做得七七八八，也可能随时面临用户的投诉：“为什么这个行为和浏览器不一样？”\u003C\u002Fp>\n\u003Cp>而反观小程序的现状，在完全不管web标准之后，想不支持CSS级联就可以不支持，想改canvas API就能改，想增加wx.showToast()就能直接加。\u003C\u002Fp>\n\u003Cp>甚至在加载方面也完全不用考虑web的事，一股脑扔给微信，像app一样整体下载就可以了。\u003C\u002Fp>\n\u003Cp>这对产品和开发团队来说完全是甩开膀子随便干的节奏。因此对小程序的产品和开发团队来说，放弃使用web来做是一件性价比非常高的事情。\u003C\u002Fp>\n\u003Ch2>重塑开发规则\u003C\u002Fh2>\n\u003Cp>因为没有了web标准的束缚，小程序团队可以从头制定开发规则，从而在源头上对质量进行一定的把控。\u003C\u002Fp>\n\u003Cp>例如小程序可以强硬地要求，fixed的textarea必须添加一个特殊的class，这样小程序就能自己去解决这一场景下的技术难题，而不用绕很远的路去做各种兼容。\u003C\u002Fp>\n\u003Cp>例如小程序可以要求textarea不可以出现在scroll-view中，从而避免一些技术难题。\u003C\u002Fp>\n\u003Cp>此外，小程序还可以从框架上强制地要求必须不能动态操作页面元素。至于理由是什么，可能和运营规则有关。\u003C\u002Fp>\n\u003Cp>总而言之，因为有了一个全新的开发体系，微信相当于直接伴演了上帝的角色，以前web开发中碰到的任何问题都可以有N多方法马上解决。\u003C\u002Fp>\n\u003Ch2>重塑运营规则\u003C\u002Fh2>\n\u003Cp>上面都是作为技术人员的一些废话。小程序之所有不选用web，个人认为最重要的原因是要重塑运营规则。\u003C\u002Fp>\n\u003Cp>众所周知，web以开放互联著称，这意味着任何人可以在web上发布任何程序，并且每一个web都可以和其他web应用互相跳转。此外，web页面的内容是可以随时通过后端或者前端进行控制从而动态显示的。当然，web因为这么多年的发展，标准庞大，能力众多，实在是不能胜举。\u003C\u002Fp>\n\u003Cp>这些能力固然是非常棒的，也是web开发人员引以为豪的地方。但是对小程序来说，却未必是一件好事。\u003C\u002Fp>\n\u003Cp>看看当前公众号的现状即可知道：刷流量、跳广告、伪造各种页面、发布违规页面等行为屡禁不止。这正是微信最不爽的地方。\u003C\u002Fp>\n\u003Cp>因此，小程序的目标很明确，就是重塑一个微信规则下的web。这里的web只能提供服务，不能营销，不能引流，不能动态改内容逃避打击，不能跳转，不能违规。所以的事情只能按白名单能力（小程序开发文档）来做，白名单没有的，想都别想。而且即使白名单中有东西被坏人利用了，还有一道人工审核来进行把关。不按规则来的，对不起，全部打死。\u003C\u002Fp>\n\u003Cp>对营销狗（网上取的词，无贬义）来说，小程序毫无用处，因为它几乎将营销的口子全部堵死了。而对用户来说，这才真正是该有的体验。\u003C\u002Fp>\n\u003Cp>所以，个人以为，这才是小程序要重建一套开发体系最重大的意义。\u003C\u002Fp>\n","\u003Cp>来自知乎问题\u003Ca href=\"https:\u002F\u002Fwww.zhihu.com\u002Fquestion\u002F51809406\u002Fanswer\u002F140747129\">微信小程序为什么不用HTML5、CSS，自己搞了个WXML、WXSS，很多框架用不了，好处一点不知道？\u003C\u002Fa>\u003C\u002Fp>\n\u003Ch2>引子\u003C\u002Fh2>\n\u003Cp>假设我们把问题稍微改一下哈：\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>iOS应用为什么不用HTML5、CSS，自己搞了个OC \u002F swift \u002F autolayout \u002F storyboard，很多框架用不了，好处一点不知道，以前项目根本没法移植，而且我们习惯的jquery、auicss、图标等完全用不了，也没见OC \u002F swift \u002F autolayout \u002F storyboard有什么好处，完全理解不了。。。\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>嗯。我只是改一下题目，不回答。可自行思考。\u003C\u002Fp>\n\u003Ch2>用web做小程序的可能性和限制\u003C\u002Fh2>\n\u003Cp>为什么没有人问上面改过的问题，而小程序就有人问呢？只是因为小程序和web长得很像，所以就觉得要用web来做吗？那长得像的话是不是就能直接用web做呢？\u003C\u002Fp>\n\u003Cp>答案是，大部分是可以的。比如文本、图片、输入框等等，都可以。\u003C\u002Fp>\n\u003Cp>但是，也有一部分小程序的功能是web完全不具备的，例如扫码、获取设备信息、获取罗盘信息、等等。\u003C\u002Fp>\n\u003Cp>此外，还有一小部分是web做起来很困难的。比如上面有人提到的地图、fixed的文本输入、视频相关、sticky定位等。\u003C\u002Fp>\n\u003Cp>除了能力上的限制以外，还有相当一部分是来自于性能上的限制，也即虽然很多东西用web确实可以做，但是性能是很差的。\u003C\u002Fp>\n","",{"total":14,"totalRoots":14,"comments":21,"pv":14},[]]