持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第 26 天，点击查看活动详情
这是去年我有幸参与 GIAC 全球互联网架构大会大前端专场的一些零散的思考与总结。可能不是很系统，尽可能表达出我自己的思考，希望也能对大家有一些帮助。
从第一性原理解读前端设计
主讲人：
淘系技术部前端工程师：林阳（連山），2014年上线个人第一个开源框架 IOING，2018年加入阿里，重点参与前端智能化相关工程，期间输出 2 个开源项目，3 份技术专利。
什么是第一性原理
事物（系统）本质的源头，比如下图中一团乱麻的绳子，它的第一性原理就是它的起点。
第一性原理有如下的特点：
-
任何系统都有自己的“第一性原理”
-
“第一性原理”是一种演绎法思维
-
从本质出发，逻辑推理的根基
-
事物的本体、本质、本性
-
理念论、简一性
事物的第一性可能是随着外界条件变化而变化的。比如一个公司不同时间段内的有不同的第一战略目标。第一性原理可以帮助跨越非连续性。
第一性原理如何拆解？
要确定两个关键要素:“目的”和“实现目的的途径”。从目标出发，寻找实现目的的方式。
思考：业务需求中，第一性原理应该是该需求的痛点和目标。开发过程中，遇到问题，应该使用演绎法推断该问题的“第一性原理”——根源问题，从根源问题分析得出方案。
前端如何使用第一性原理
第一性原理与编程
开闭原则是第一性原则，原有其他的开发职责都应该基于开闭原则。
开闭原则 (
The Open/Closed Principle, OCP) 规定“软件中的对象（类，模块，函数等等）应该对于扩展是开放的，但是对于修改是封闭的
JS运行时安全案例
背景：淘宝很多页面由入驻方提供，那如何保证对方的代码是否安全？比如我不希望第三方网页获取 Cookie。我们应该怎么限制他们的能力？
问题：如何限制？在编译的时候去除？还是运行时的限制？最后的方法是运行时限制。比如小程序中直接使用容器的方案，就是容器提供什么能力，用户只能使用这些能力
解决方法一：将不安全变量覆盖? 比如，在系统中禁止弹窗 alert。禁止获取cookie 等等。但缺点很明显——无法枚举完所有的黑名单
找到问题第一性原理
浏览器的安全策略是什么?比如：
-
同源策略
-
沙箱机制
知道第一性原理，该怎么做？
具体的解决方法
iframe 中有一个属性，称为 sandbox。可以控制嵌入网页的权限。将第三方代码放在这个设置了 sanbox 属性的 iframe 中，等同于提供了一个隔离层，即“沙箱”
嵌入的网页默认具有正常权限，比如执行脚本、提交表单、弹出窗口等。如果嵌入的网页是其他网站的页面，你不了解对方会执行什么操作，因此就存在安全风险。为了限制
<iframe>的风险，HTML 提供了sandbox属性，允许设置嵌入的网页的权限，等同于提供了一个隔离层，即“沙箱”。
假如第三方一定要用到类似弹窗的能力，会对外提供，但会做一定的封装，比如统计、判断有没风险等。
但是暴露出来的 API 是存在传入⻛险。外部传入 Object 对象，通过原型链找到内部的 constructor，可以通过 call 的方式调用方法，这个时候它的上下文就是外部的上下文，就可能存在风险。
那么我们如何解决这个问题？通过 Proxy 监听和控制，所有的访问和设置都需要经过代理，在代理过程中，我们会将对象进行序列化，所以最后沙箱内部获取到的是序列化的内容，序列后之后就是安全的。
对于 DOM 节点的操作，也可以通过 Proxy 去解决。比如调用 document.creatElement 的时候，只能创建白名单中的一些 tag。
其他对 DOM 操作的限制，比如点击事件 onClick，我们需要将事件本身等信息外传，就会存在安全问题。跟上面的类似，当传入处理器函数的时候，将它序列化，最后执行。实现一个 Observe 函数，监听回传给处理器的信息，在这个过程中进行序列化和鉴权操作。
以上整体流程如下所示：
智能化出码部分案例解读
要解决的问题：效率问题。其中沟通和编码占用了大部分的时间。如下：
我们的目标是两个重要的步骤，将视觉转换成布局 HTML + CSS 的代码。将 PRD 转换成逻辑 JavaScript 代码。
其中沟通和编码中间需要一个对等协议要完成对接。但是自然语言和程序是有歧义的，自然语言是非结构化的，而编程语言是结构化的。为了消除歧义，需要做到以下几点：
- 结构化收集
- 统一表协议
- 限制信息范围
如何找到对等协议，以下有两种途径去做：
- 通过对现有工作的统计和归纳从而得出要素结论。根据现在的代码去总结归纳常用的跟 PRD 哪些是相关性的。
- 演绎法思维。
小结
第一性原理不仅仅跟编程相关，而是一种思维方式，能够帮助我们更好的解决遇到的问题。第一性原理的概念是抽象的，作者花了很多时间解释第一性原理，也从 JS 安全策略和智能化出码两个实例讲解，深入浅出。
哈啰出行在Flutter上的探索与实践
主讲人：
陈小辉。2020年8月加入哈啰出行，哈啰大前端技术委员会负责人&普惠用车大前端负责人，业务方面主要负责四轮相关顺风车、打车、车主服务等业务研发管理工作，致力于推进哈啰大前端技术架构向跨端端容器方向演进，目前主要聚焦在大前端工程化，多端渲染容器，大前端高可用体系，业务架构治理等方面。
基础架构
在端容器方面上进行探索，目标是
- 标准化。将容器更加标准化，不管是哪个方案，主要采取一个标准，就能很快迁移
- 容器化
- 动态化。业务变化快，发版较快
能力层： 将底层能力通用化，给容器层提供能力，不管容器是什么，都可以使用 容器层：对容器的探索，适配统一化 业务层：支持不同的业务形态
flutter 使用，绿色模块就是要建设内容，比如研发工具、稳定性监控等。
两端变一端，时间可能会变多，但个人感觉从长远的角度讲，还是很有意义的
flutter 生态的探讨
端侧技术比较
- 性能上。flutter 和原生还是有所差异。在单页面应用上，差别不大。一些页面的跳转、动画的需求上会略低于原生
- 发布效率。flutter 没有很大优势。不能动态发布
- 一致性
- 研发效率。需要考虑一些基建等
- 生态。目前是硬伤，急需改善
总结如下：
Flutter优势 ：
- Skia引擎，强一致性
- 接近Native性能体验
- iOS和Android双端研发效率
Flutter不足：
- 生态不完善
- 整体框架在进化过程中
- 缺少动态性
Flutter动态化的实践
基本原理
现在业内有如下的几个方案：
- 类似 RN。通过 JavaScript 的能力去隐射 flutter 组件去渲染
- DSL + Runtime
- 编译产物下发
目前哈啰出行采取的是第二种方案，大致流程：源码转成AST，再将 AST 转换成 JSON，打包，下发到端，解包，解释执行
这种方案存在以下的问题，目前只在一些PV量较少的简单页面上试用
- 需要实现的语法元素比较多
- 符号表和Flutter版本存在相关性