获得徽章 0
- 在国内写代码真的比翻译外国文章还累，比如
原型缺交互(因为工期太赶) + 接口不规范(比如非 RestfulAPI)然后只能 FE 在中间 Map。
当然，接口不规范的原因，要追溯到数据库字段就不统一(不同的人实现等)，加上本来数据库字段就是从中文到英文的 Map。
况且，需求文档和原型上的文案，不同的团队翻译出的英文也不一样，这里又有一层 Map。
敲黑板了：「各团队用自己的方言，书写不同的文字，能沟通的好，有向心力？」
PS. 难怪某圈大 V 们的翻(搬)译(运)力都特好，可惜的是一个挖不到，全都说想出国…
PS. 难怪 GraphQL 在国内火不起来呢，什么统一(大)团队语言。不现实的，叫 MapQL 好了(对应到后端就是 DDD…展开等人赞过
510 - api 能力中有个很有意思的特性可以展开讲讲，「服务通知」跟 web-view 组件基本上会互斥很久：微信作为 IM 应用，最核心的能力就是「消息推送」，在官方管控是不可能轻易开放的。
比如，我们假设，用户因为打开第三方应用，而且是动态化的 web 内容，没有任何操作反馈，就可以不受限的被推送骚扰，那微信就被自己的小程序搞废了…
所以，用户不会关掉微信的消息推送，是小程序在服务通知的优势，却也是小程序内 web-view 组件的劣势 。
当然，小程序是否会开放更多的能力给真 web 开发者，真 polyfill 这个 PWA 的第二个关键特性？这取决于微信对 web eco 的态度，至少在技术方案上是有很多解法的~展开等人赞过 评论10 - 一些感想~
框架方面：小程序核心还是 Hybrid 和 Web(view) 实现的一套动态化方案。
而框架们在 Web 领域之所以能蓬勃发展，是因为依赖的浏览器们提供的 API 够底层够标准。
反观小程序类框架就难了，原生自带框架只不过不够完善，或者说框很多但架不够。
如今小程序市场上的框架重心都转移到了多端适配，但任何编译方案都不如直接用 Web(view) 适配的效果好。
所以这个需求其实有点伪，那框架的价值或许变成了为原生小程序提供最佳实践。
在我看来，等第三方框架们都摘掉运行时，退化成纯编译器 & 适配器的那天，小程序自身框架才算真的足够完善了吧…
功能方面：小程序真应该把离线(包)的能力开放出来，并增强 Webview 用 postMessage 和 JSCore 的交互通信能力
这样我们就能用后者模拟 ServiceWorker，真的 polyfill 部分 PWA 的能力，这难道不才是微信赋能 Web 开发者的初衷么？
要不早点让微信内的 X5 支持部分特性也行，管控固然重要，但好歹拿出更多点诚意来吧？期望今年年底的百度智能小程序开源后给微信做做榜样。
听某场的童鞋还吐槽微信的开发者工具，应该多学学 VSCode 整点插件机制，而不是光想着做大而全的 IDE…
PS. 没想到看到这么多外国社区觊觎国内的小程序市场…展开等人赞过 评论18
