现场纪要
下面的议题将由微软的宋青见老师为大家介绍PWA和MiniApps。
宋青见：非常感谢大家，今天非常高兴参加MiniApp工作组的会议。
今天的内容也是我和PWA发明人Alex Russell一次讨论对话之后产生的，非常有意思，这也是我为什么会加入MiniApp工作组的原因。
8月6日第二届中国PWA开发者日，我们邀请Alex演讲，他提了一个问题：在他印象里中国的网站是过时的，所有的重点是移动互联网App，所以他应该讲什么比较合适。 我的回答是虽然中国的网站确实是过时的，被忽视的，但中国的Web技术却是蓬勃发展，移动App里大部分的内容采用Web技术实现；特别是近年兴起的小程序，也是Web技术的应用。
Alex是W3C比较资深的工作组成员一直非常关心MiniApp，因为他知道MiniApp在中国的成功。用他说的一句话注解web世界对MiniApp的关注：“所有的Web开发者命运相连”。
虽然现在小程序没有走出海外，在海外发达国家还是website为主，但它在中国已经取得了巨大的成功，它已经代替了Web当年产生时的诉求，而且做得更好。
我叫宋青见，我是来自微软Edge浏览器团队。
我会把Alex的演讲重温一下，并动手做了一些实验附在后面。
谈到小程序，Alex想起了2010年之前的一些往事，当时Chrome浏览器团队支持Chrome OS即Chromebook时，对这个全新的WebOS上如何支持应用的讨论中，Alex他们希望坚持Web原有的技术， 并基于这种技术向前扩展。还有一派的观点是，按照现有的需要，通过应用商店的模式安装应用，切断了Web原有的联系，只用到JS或者是CSS的一些技术。
今天我们谈到Web和MiniApp的时候，又想起了当年发生的往事，历史总是惊人的相似。
2010年的时候，如果说为什么Chrome OS的应用商店应用选择了偏本地的方式，抛弃了Web，主要是的原因是当时的Web缺失了大量的功能。开发者基于当时的Web技术，无法开发出满足需要的应用。
首先就是怎么解决离线化的问题，设备能力的问题，通知的问题及、高性能、本地的存储、更好的UI效果等，这是非常长的清单，是Web缺失的能力，所以通过本地应用加上一些Web技术相结合 的Hybrid的方式才能解决。
虽然当时Web能力上有很多缺失，但是Web的核心开发者，并没有放弃，而是持续改进的动力是真正？实际上他们的动力就是Web发明的初心。
很显然，Web发明时，访问的便利性是基本特性，通过URL链接就可以自由的访问每一个网站，无需中间人的协调，浏览器还认真强化了网页访问的安全性以保证安全的让 用户点击每一个链接来访问不同的网页；直接访问网站并且具备与生俱来的安全特性是因为浏览器的安全沙箱，将开发者的应用放到一个不被信任的“盒子”里。
刚才说的很多小程序的问题，实际上是“墙”的问题，因为中间多了应用的分发模式，切断了与Web的联系，失去了Web的低摩擦模式，即通过一个link就可以触达网站的便利。
虽然坚持Web路线这一派在当时失去了那场争论，但是，之后的几年里，根据开发者的反馈，大大提高了浏览器的能力。
2014年一些会议上首先解决offline的问题上取得了进展，怎么让Website可以离线访问，而不必一直是联线的状态。
后来有了service worker，配合service worker，对原有的Website的改动非常小，它通过增加的声明式的Manifest，由浏览器负责解决声明所需要的能力， 这也变成了PWA的方向。所谓PWA就是渐进式的Web应用。
在此之后，已经解决了offline的问题，解决了通知和系统能力的集成等，在微软的应用商店里也可以上架PWA，只是一个web link，加上一个Manifest，但是和原生应用具备同等的待遇， 被Windows操作系统一视同仁。
举个例子，File handling, 比如打开图片，就可以唤起处理图片的PWA。
后续和设备底层交互的相关的能力就是project Fugu一直在努力推动的，不断为Web体检本地divice的能力。
所有的东西都是在当前WebAPI上支持的，有时候我们讲Web技术，很多人觉得还是十年前，总问能不能访问串口，实际上都是可以的，比如蓝牙，本地文件访问等Web已经支持。
今天已经有了service worker、Project Fugu，已经有了这些能力之后，要支持小程序，我们到底还缺什么？
这是小程序工作组当时的white paper，它很好总结了Web和小程序runtime的区别。
最近的文档有比较好的亮点，现在小程序和PWA之间最重要的区别实际上是分发模式。
其实其他功能性的需求，目前的前端打包和编译框架已经相当成熟，通过编译将小程序语法（DSL）转换为标准的JS和CSS， 甚至最新的Web Component和ES Module的标准都不需要编译JS即可支持MiniApp DSL，技术上讲并没有太大挑战。
所以最核心的问题还是应用分发模式。
回到小程序的模式，因为我们是在工作组探讨，就畅所欲言。很多时候是我个人的观点，如果说小程序能成功，本质的原因还是super app的平台属性需要小程序，本质上是因为它有核心功能， 有很多的用户流量后，可以通过小程序的其他补充性的功能，增强平台的留存，并形成良性循环。
但是，这里面有一个很大的问题，就是平台方的角色很重要，如果平台方非常明智，就欣欣向荣，如果他有利益诉求或者各种各样的原因，整个生态就会受影响。这一切还是掌握在平台的手中！
如果站在W3C的角度，站在Web初创的角度，它对这个问题的看法一定是希望某种平衡。从应用分发的角度，完全依靠一个中间人角色肯定是有问题的。
现在怎么和super app一起沟通合作，当然还有技术问题比如 Native API 的对接实现等。
W3C有一个标准Web Bundle，它可以把网站的所有资源或者部分资源进行打包之后，可以做分发，可以在网站上分发，也可以在其他平台分发，从平台拿到Web Bundle之后，浏览器知道来源于某个网站， 可以自然解决跨域访问的问题。Web Bundle可以让网站的内容更安全，启动速度更快，并保留浏览器核心的最安全的访问应用模式，浏览器做到了隔离以及很多安全属性，并持续不停的迭代。
这些是整个Web标准发展这么长时间的一些进步或者是优势。
当然，包括了整个CSS各种框架，现在Web的技术不仅是JS，还有框架以及各种小程序。Web Bundle是一种标准，我们可以考虑是否用它解决分发的问题。
另一个契机是PC，我们移动端有300万小程序开发者，现在因为疫情或者是远程办公的兴起，加上手机用户触顶，基本没有流量红利了。现在的手机和十几年前的PC遇到了同样的问题， 用户新增已经消失了，现在是在存量里寻找价值的过程。
开发者必然要在存量里寻找需求，这时候出现了PC的桌面复兴。
我个人是看好特别是在中国从移动端形成的内容和体验优势，反哺整个桌面的开发生态。
本质上从开发者角度上只是解决不同宽度的问题，我这里的例子是Twitter的PWA，在不停拉宽度的时候，新的功能块就可以在合适的宽度时呈现。
可以在Twitter，宽度拉宽，它可以显示很多的内容，不需要为桌面开发一个版本。
从抖音和今日头天新推出的PWA都可以看出和移动端APP保持一样的体验的趋势。
现在MiniApp的种类比较多，我们怎么办？Taro也是一种MiniApp方案，我也尝试了Taro，因为它已经解决了支持H5运行，我主要想尝试怎么把移动端的Taro H5显示在桌面上，变成PWA。
其实这个可以参加MiniApp工作组的Hackathon，当时我只是改了7个CSS的文件，因为它原来是全屏拉升的问题，所以说开发环境很友好。
这是改过之后的网页，在此之前，整个网页是屏幕拉满。因为移动端设计的时候，就是按照屏幕拉满设计的。
只需要简单设计一下，到page改一些属性，就变成桌面上可以运行了，也可以把这个网站安装成一个PWA，在Windows角度已经是一个应用，它可以在桌面上创建快捷方式，pin到Taskbar上 ，可以看到PWA在windows上同等对待。
[多媒体演示] 这个网址是微软对PWA的支持文档，https://aka.ms/PWA，有关的文档都在这个网站上。谢谢大家！
王子韬：谢谢宋老师的精彩演讲！现场和线上的同学有问题，可以简单提1~2个问题？
提问：非常受益。但是，刚才您提到的几个区别点里，我认为有一个点，或许你get了，但没有写出来。
因为我自己也在华为一个小程序引擎团队，我们也有小程序引擎在海外用。今天不讲这一点，在海外的runtime，我们认为是组件，在小程序里就可以认为是HTML原生的。不管是前端做了怎样的编译，最后一定要映射成小程序官方，比如支付宝官方小程序所定义的所有组件，不可能超脱组件之外，只能基于组件进行叠加组合。
但只要是官方没有提供的组件，即使Taro有天大的能量，也只能做换转换。它对HTML的规范做了很多裁剪，想运行原生的组件，必须有一个转换。
通常我们认为这和W3C的技术有一些区别的地方，当然它有商业上的考虑，也有安全上的考虑，所谓跳转都会限掉。所以，后面无论是PWA还是小程序的融合上，因为今天子韬也提到，我想提一下这方面还是想做一些工作。
刚才我们看到所有人都提到了US，如果站在DSL来看，虽然底层打开，可以用自己的方式实现，也可以用垫片的方式实现，关键是在小程序上做了隔离层。我在一个会议上比喻成类似Linux的内核态和保护态。
宋青见：我用Taro只是一个尝试，我的兴趣更多是把移动端的网页跑在PC上。
无论是网页端还是MiniApp，实际上Chromium是一个runtime，实际上也有两种不同的观点，MiniApp应用逻辑是用JS，但是显示是用原生方式实现。类似于Flutter这样的想法和思路。
实际上，从开发者角度这一定是解决了某种场景，基于某种问题。从标准角度上讲，这就像套娃一样，你套我、我套你，都可以。
我想说的是我们作为一个标准，我只是有两点建议：第一，我们要思考一些小程序不要只是中国的，小程序技术可以整体推进Web的发展。因为我认为小程序有很好的东西， 是对device能力的封装，封装得很好，比如在JS里怎么访问一个camera，实际上小程序在很多应用上也证明了这一点，所以这方面device API的设计是有优势的。
另一方面，技术路线都可以，保持一种层次也没有问题，从技术上讲，我的观点都是中立的。既然我们想用一个MiniApp的标准，就应该尽可能多的兼容不同技术的实现。这是我的想法。
提问：宋老师，我再提一个问题。或者我分享一点自己的想法，PWA和MiniApp之间，我觉得PWA名字就已经很清楚了，它是渐进式的技术，实际上还是Web ES的技术。 但是，MiniApp本质上已经是一个CS的技术，因为它已经用了多个Web应用，多个Web的切换，ES是内容在一个页面上，加载要顺序加载，这时候会看到一个进度条， 在PC上，大家对这个进度条不会特别排斥，但在手机上看到进度条就很反感，有时候切换小程序，画面没有出来，在转圈圈，这个体验是很大的区别。
虽然除了offline的东西之外，本质让我认为它已经成为了CS的架构，所以这两者之间会有区别。
宋青见：从这一点上讲，推动小程序发展，一定不是在PC，PC上不关心，PC上的性能可以支持重化的能力。但是，手机上尤为明显。
所以，我认为手机小程序的场景是推动移动Web，在手机访问网站的事情上，必须向小程序学习。
刚才你说的架构就是一个 web worker 对应 multiple view，Web里的架构也有service worker，这是project Fugu可以做的事情。Web是一个完全开放的东西，它绝对不会止步不前。 只要有合理的推动力，让技术不断推动。
我认为小程序的需求特别是在手机端，它完全可以推动核心的Chromium，就说project Fugu，就应该满足类似one webworker for multiple pages这样的需求。
王子韬：好的。非常感谢宋老师的演讲！
刚才宋老师提到一个问题，未来的小程序想要更加公平、更加认为的把墙打通，它的分发上、行为上更加公平、公正，更加open，我们确实应该考虑小程序的分发上、小程序的建设上考虑去平台的方式、弱化平台的方式，公平、公正、公开分发的方式。
所以，我的想法是下一步小程序提供统一的开发方式、统一的标准化方式，可能是next have。我们提供更开放的方式，更类似于标准化的方式，是需要桌面、移动的生态合作伙伴共同建立的开放方式。
我们在打好第一步的基础上，next以及next step的基础上，下一步就可以考虑或者同时就可以考虑怎么做得更开放。
非常感谢宋老师！
返回会议总结页面获取其他话题的会议纪要。