稀土开发者大会¶
统计信息：字数 28207 阅读57分钟
¶
稀土开发者大会 2023¶
2023年稀土开发者大会，这个包括很多领域，前沿知识，值得学习。
null¶
主论坛¶
https://juejin.cn/live/2023zlt?utm_source=jjwebdhl
01-技术对产品的影响¶
1.字节副总裁-致辞
计算机技术的发展的目标，主要是为了业务的增长。
具体体现在速度、精度、温度上面。
-
速度指的是开发迭代的速度快，主要涉及底层的云服务以及容器复用快速开发的方面。
-
精度指的是。用户的个性化推荐。根据用户的具体情况进行科学的决策精准的分析。
-
温度指的是用户的内容与交互创新，持续提升用户的体验，传达产品的价值。
产品对于不同使用者的服务角度（以抖音为例，对于创作者的角度。要降低创作者的使用门槛。对于用户的角度。要增加产品的差异性体验）
以表格或者文档为例（对于创作者的角度，要方便创作者进行使用；技术门槛低；对于用户的角度。要便捷灵巧的浏览数据）
02-AiGC 对业绩的发展¶
2. 谷歌云中国负责人
AiGC 对业绩的发展；演讲2023年6月；2024年新技术还有更多
null¶
前端工程实践¶
https://juejin.cn/live/qdgcsj002
01 前端-构建工具-RsPack¶
RsPack 前端构建工具
字节跳动前端团队
rsPack 代码链接：https://github.com/web-infra-dev/rsbuild 目前 1000 星
目录¶
1. Why Rspack?
2. 特性
3. 生态兼容性
4. 从 Webpack 迁移
5. 性能收益
6. 架构设计
7. 展望
1.webpack 存在的不足¶
npm run dev 和 npm run build 启动构建时间比较长，HMR 热更新时间也比较长，浪费时间。
开发者希望更快的打包工具，包括冷启动，生产构建测试；兼顾灵活性。
（实际上开发者希望减少某些 webpack 耗时过程，减少某些 loader 和 plugin 的时间，而不是更换新的工具）
2.rspack 特性¶
rspack 是基于 rust 的高性能web构建引擎（打包工具）
-
Rust 实现，增量编译，HMR 和构建速度更快
-
和 webpack 兼容，不需要从0开始搭建项目开发环境
-
支持多种格式 js jsx ts tsx sass 开箱即用
-
内置多种优化策略，代码分割；代码压缩；摇树
3.生态兼容性¶
loader 好兼容，大量的 plugin 和对应的 API 不好兼容。详见兼容列表。
4.从 webpack 迁移¶
参考官方文档
6.架构设计¶
分成左右两个阶段：make phase 和 seal phase 其中黄色部分是耗时部分。
make phase 接通阶段：模块依赖关系分析（module build and analyze），文件依赖图分析（特殊的有循环引用）。
seal phase 密封阶段：打包压缩（生成 module trunk assets）。
增量编译，大概是在 make phase 时，递归进行编译（循环这个过程）
互动提问环节
1、rspack 和 webpack 打包构建后的产物是否相同，大小是否变化，是否对齐？
解答：目前产物相同，大小不变，可以对齐，但是不会100%一样。
2、未来 rspack 和 webpack 目标是什么？是否和新功能一致？
未来是两个项目，但是主要功能一样，会支持大部分的插件。
3、这个构建工具适应于哪些场景？
小项目，要求很快的速度和基本的使用场景，可以使用 rspack；但是复杂的项目，或者angular，使用复杂的插件，那么这样还是使用 webpack。rust 比较快，社区发展也比较好，所以使用 rust 写 rspeck。
个人思考¶
从技术角度，这个是加强版的 webpack，速度更快，技术领先。
从项目角度，这个社区不完善，简单项目可以使用 rollup，复杂项目使用 webpack，这两个市场占有率这么大，长期稳定。如果再学习 rspack 有成本，所以暂时不会把这个工具使用在项目中，后续观望市场占有率再说。
02 前端-组件化-quarkC¶
低成本、跨技术栈、无框架的组件
哈罗单车前端团队，这个中台团队比较小，可能不超过10人，为了响应降本增效做的这个项目（给业务部门提供公共组件）。
quarkC 代码连接：https://github.com/hellof2e/quark 目前300星
web-component 概念：https://juejin.cn/post/7350502488493867042 简单理解，就是 HTML默认的 video 标签，实际是很多 div + span 组成的，那么这个 video 标签就是 web-component。这个项目也是类似的工作，写了例如 hello-button 这样的原生 web-component 组件。
目录¶
1.聊聊当下主流前端组件的“伤”
2.初识WebComponents
3.利用Quarkc高效构建Web组件
4.面向未来的无框架浏览器原生组件探索与实践
1、前端组件的缺陷¶
通用组件依赖于框架的种类和版本，不能通用（例如 antd 依赖于 react18版本）不能复用，CSS 的效果容易冲突。如果一个企业历史代码比较多，那么不同的项目和人员使用技术栈不同，开发维护比较困难。如果框架版本大升级后，各种组件库都需要升级，比较麻烦。
2、web-component 介绍¶
浏览器调试：在 Performance 中，开启 show user agent shadow DOM 用户代理影子 DOM。
WebComponents 组成三剑客
-
Custom elements(自定义元素):一组JavaScriptAPI，允许您定义 custom elements 及其行为，然后可以在您的用户界面中按照需要使用它们。
-
ShadowDOM(影子DOM): 一组JavaScriptAPI，用于将封装的“影子”DOM树附加到元素(与主文档DOM分开呈现)并控制其关联的功能。通过这种方式，您可以保持元素的功能私有，这样它们就可以被脚本化和样式化，而不用担心与文档的其他部分发生冲突。
-
HTMLtemplates(HTML模板):\和\
元素使您可以编写不在呈现页面中显示的标记模板。然后它们可以作为自定义元素结构的基础被多次重用。
Shadow DOM 的优点也是缺点，就是很好的封装性，外部DOM无法干扰内部组件的样式。
优点：不同功能模块不会互相干扰。
缺点：很多场景下，需要经常改动样式，那么组件库的样式也可能变化，然后需要频繁改动组件库。
实际上就是写了新的 html 原生标签和组件，作为组件库可以嵌套到各种框架中。
但是不同框架的事件处理不同，这也是痛点，兼容性等等也是痛点。所以这个作者使用 quarkC 工具构建组件。
3、quarkC 构建 web 组件¶
这个库把 web-component 重新封装了一次
使用Quarkc的收益
-
【研发提效，降本】跨框架的业务组件，只维护一套代码! 实现:低成本、高效构建跨技术栈组件!(e.g.营销弹窗，抽奖大转盘)
-
【面向未来，稳定】前端框架会继续进代/发展，会有新的版本，新的框架出现。用Quarkc开发“通用型组件”，不会随着“前端框架浪潮”而更新运代
-
【wa3C标准，极致】}高性能、极小的体积
实际上存在的问题：不同版本的兼容性（兼容 react16 react17 react18 的事件？）如果写大量的兼容代码，判断各种框架，性能不太行，处理的细节太多。
根本的解决办法，还是一个公司或者一个项目内部，使用一套基础框架。
4、未来探索¶
互动提问环节¶
1、具体使用场景：主要是新项目中，避免了其他技术框架更新迭代的问题（版本升级）；
2、目前还不支持反向编译：例如 react 有很多良好的社区组件，把 rc-calendar 反向编译成 web-component，然后在其他项目中使用。
工程化，很重要的是社区繁荣。如果没有社区和相关组件库的支持，那么底层组件库使用就不是很广泛了。
从目前文档的热度看，同一个公司很少会选择多种项目栈，所以做这个的动力还是不强，使用没有那么广泛。
03 前端 + chatGPT¶
GPT 结合工程化，实现智能研发
作者：阿里+腾讯前端团队
GPT 使用广泛，目前对于前端：结合前端工程化，将重复的事情自动化处理（对于腾讯新闻，主要是GPT问答，AIGC 写作短文，智能审核，直接查询技术问题）
主要根据上下文进行理解，把上下文生成 AST，然后生成对应的代码树。
04 前端 + ReactNative¶
雪球前端专家，10年从业经验
01 RN 三段同构后的效果：H5 安卓 IOS 三个同构，只需要开发一次即可完成
02 优势
null¶
前端未来¶
https://juejin.cn/live/qdwl005
01-后疫情下的前端未来¶
讲师：腾讯新闻（传统需要1000个编辑，现在优化成100个编辑了）
当前的时代，资金减少，降本增效的时代，这样的情况下，分析前端未来发展：
01 当前前端研究方向概括¶
第1个运行时框架，第2个构件工具，第3个组件库，第4个讲的是服务端
-
框架：React + VUE
-
构建工具：webpack 是大头，但是项目庞大后存在性能问题
-
前端组件库：bootstrap + materialUI + antDesign 比例是 5:2:1
-
nodejs: node 版本更新；无服务端开发
基础技术的演进，会带来前端分工的创新（减少人员），带来单一场景下的体验与效率提升，带来前端方向的变化
02 前端的业务更新和提效¶
-
Business FaaS：微型通用的业务解决方案。
-
代码搭建应用：低代码，或者无代码，然后低代码是这个业务项目的一个实现方式。
-
DDD：业务项目实现范式
Business FaaS¶
前期项目：一个项目+产品经理+前端+后端+测试
中期项目：一个项目+一个产品+一个开发
后期项目：多个项目+一个产品+一个开发
随着业务逐渐成熟，或者衰退，那么就不需要这么多人，就形成了 Business FaaS：微型通用的业务解决方案
通过 webAPI 和 Business FaaS 和 Data API 直接解决。
技术的发展，会促进前端组织架构的发展。
代码搭建应用¶
这里指的是低代码和微应用
当一个企业有多个生产线（多个项目）那么实现一个技术中台，为上层提供通用的基础库和基础组件。
这样可以避免每一套项目内部都有一个基础组件的实现，出现不一致的问题等。
DDD¶
AIGC 是未来的方向
02-编译型前端框架的探索¶
讲师：新加坡 Shopee 高级前端工程师 陈立豪
这部分内容代表讲师的观点，不一定对，仅供参考。
传统三大前端框架的特点：声明式编程（JSX）；虚拟 DOM + diff 算法；组件库繁多。造成了传统框架比较重。
这里介绍了三个新的框架，和传统框架原理有差异，不需要虚拟 DOM 技术，直接操作 DOM，实现页面的更新。
Svelte¶
星标 78K，周下载量100万，目前有30万个项目使用，看起来发展还可以
https://www.npmjs.com/package/svelte
https://github.com/sveltejs/svelte
Svelte是一种构建 web 应用程序的新方法。它是一个编译器，可以将声明性组件，转换为高效的JavaScript，从而精确地更新 DOM。
compiled
Svelte shifts as much work as possible out of the browser and into your build step. No more manual optimisations — just faster, more efficient apps.
compact
Write breathtakingly concise components using languages you already know — HTML, CSS and JavaScript. Oh, and your application bundles will be tiny as well.
complete
Built-in scoped styling, state management, motion primitives, form bindings and more — don't waste time trawling npm for the bare essentials. It's all here.
特点：不使用虚拟 DOM；重新思考响应式编程；其他的语法和 React 函数式编程类似。代码案例如下
// Svelte 实现原生创建元素节点的函数
function element(tag) {
return document.createElement(tag);
}
function text(str) {
return document.createTextNode(str);
}
create() {
button = element('button');
t = text(ctx[0]);
}
// 可以判断哪些变量会触发 DOM 更新；哪些只是属性变化
function instance($$self, $$props, $$invalidate) {
let number = 0;
function onClick() {
$$invalidate(0, number++, number);
}
return [number, onClick];
}
Solid¶
特点：单向数据流，和 React 函数式编程的语法类似；去掉了虚拟 DOM，细粒度响应性等
https://github.com/solidjs/solid
https://www.npmjs.com/package/solid-js
目前 30K stars 下载量 30万，5万个项目使用
Solid is a declarative JavaScript library for creating user interfaces. Instead of using a Virtual DOM, it compiles its templates to real DOM nodes and updates them with fine-grained reactions. Declare your state and use it throughout your app, and when a piece of state changes, only the code that depends on it will rerun.
代码案例
可以看到 createSignal 和 useState 使用方法基本类似，但是内部的实现不同。
import { createSignal } from 'solid-js';
function Counter() {
const [count, setCount] = createSignal(1);
const increment = () => setCount(count() + 1);
return (
<button type='button' onClick={increment}>
{count()}
</button>
);
}
Qwic¶
import { component$, useStore } from '@builder.io/qwic';
export default component$(() => {
const count = useStore({
value: 1,
});
return (
<button onClick$={() => count.value++}>
{count.value}
</button>
);
})
作者总结：前端框架的未来趋势是编译器为基础
提问环节：
1、是否有虚拟DOM更好？不断循环，客户端渲染服务端渲染，有虚拟DOM没有虚拟DOM，可能随着其他技术的成熟，某个时间节点选择比较好的思路等，每次可能在逐步稳步前进。只有不断地进步和前进，没有必要一定说虚拟 DOM 好还是没有虚拟 DOM 阶段。
2、不需要完全学习新的框架和技术的细节，背会API等，主要了解新的框架和已有成熟的框架的差距在哪里，原理上做了哪些优化。
3、中级前端，还想继续提升？多使用新的功能，然后不断学习，持续的学习和实践。
03-web 应用中嵌入 unity 引擎¶
讲师：董天成，阿里的一个项目，然后阿里把这个项目砍了，现在在蔚来。
如何在 web 应用中嵌入原生的游戏 3D 引擎（unity）? WebF 的核心开发者
问题：游戏引擎和 3D 效果，在不同场景下面性能不同。在原生的 ios 或者安卓中，性能比较好，但是不容易修改（新产品出来后，不能让用户都更新到新的APP）；网页应用可以随时更新，但是网页 webGL 性能比较卡，低配设备上容易卡顿发热，内存溢出（自己实际测试过，手机上运行1分钟内就卡顿，这是不能接受的问题）。
产品需要不卡顿，每次的效果可以快速更新
所以作者想要解决，一个页面中使用 3D引擎+传统网页元素，可以同时在 web + ios + android 三个端使用，就是 webF
现在可以支持原生 JS 和 css，主流的前端框架（react vue）但是市场上众多的第三方库，还是不完全支持
代码层面如何支持？
在 前端代码中，使用一个 flutter-unity 的标签作为容器，然后实现和 unity 通信，使用 css 可以定义基础样式，具体通信通过 json 传参即可。
Flutter 中使用 unity 也是类似
webF 不考虑Flutter底层的引擎，主要处理了框架层面，支持了 HTML CSS 等解析器
界面渲染时，也主要处理右侧的渲染部分
局限性：还是不支持其他格式的单位和标签等
性能：和原生应用的 FPS 差不多，内存比原生多100MB
结论：结合了 Native 和 Web 的优势
提问环节：
1、样式兼容问题：¶
还不能兼容100%的CSS，以及市面上很多框架对应的样式问题，团队还在做。
2、WebF 提供了浏览器的 API，不涉及状态管理等问题。¶
底层渲染差别不大，主要是 WebF 和 WebGL 的差距。现在主要是更快的速度呈现给用户。quickJS 更快的加载效率，牺牲一些 JS 执行的效率。页面中很复杂消耗CPU的运算，不如浏览器内置的 V8 的计算速度。
就是一个浏览器内核，类似 RN，Flutter 比 RN 系统兼容性比较好 electron
使用客户端的策略，解决3D的效果（充分使用多线程和多核CPU的效果，实现3D效果，因为webGL JS parse 处理3D比较慢）
04-kotlin 兼容各种终端系统¶
讲师：JetBrains 工程师，范生右
kotlin 创建的目的，是取代 java 的安卓开发语言，是 JetBrains 创建的语言（也为了推广IDE）
使用 kotlin 打造多平台开发应用¶
问题引入：客户端开发中，设备终端很多，各种屏幕尺寸，各种操作系统，各种开发语言让应用开发很困难。所以希望有一套工具开发客户端应用。
Kotlin 语言介绍¶
通过编译，可以生成 JS Java 和原生语言 exe
理论上适配各种平台
开发时也有对应工具，需要同时安装 Android 和 Xcode 等各个系统的开发环境
项目架构：基础的组件（shared）和 不同平台的兼容代码，也有服务端兼容代码
Kotlin 开发组件案例¶
客户端按钮组件
@Composable
fun App() {
Button (
onClick = {
// ...
},
shape = RoundedCornerShape(50.dp),
modifer = Modifer.fillMaxWidth().height(50.dp)
) {
Text(text = "Login")
}
}
服务端
class AuthClient {
private val urlString: String = "..."
private val httpClient = HttpClient {
install(ContentNegotiation) {
json()
}
defaultRequest {
url(urlString)
}
expectSuccess = true
}
suspend fun login(request: Login: LoginReq): LoginRes =
httpClient.post("...") {
setBody(loginReq)
contentType(ContentType.Application.Json)
}.body()
}
其他服务端的框架，还有 Ktor 等框架
总结：kotlin 跨平台，是一个跨平台的语言，生态系统逐步完善
2024年技术大会¶
2024年技术大会：
https://juejin.cn/post/7383650248264171531
https://conf.juejin.cn/xdc2024/?utm_source=zw