[前端技术治理0x01] 作为前端，你真的需要框架吗

前言

已经到2022年了，前端又涌现出了不少的框架。

各位会不会又觉得“学费了”了呢。

在不停的追逐“新框架”“新技术”的时候，不妨停下来看看，问题到底是什么，学框架、换框架、用框架到底有没有意义。

我最近有一个命题：PC中后台技术治理。就不提什么架构了，中后台糊页面哪要啥架构。

现在就职于一家传统公司搞数字化，传统公司嘛，很多东西都不成熟，技术栈也非常乱，React 有，Vue 有， JSP 也有，JQ 也有，啥奇奇怪怪的都有。

那治理是为了啥呢？第一目的并不是开发效率/人效 这类能效问题，而是产品体验一致性的问题，要让各种各样的产品长的看起来是一个爸妈下的崽，这个对于公司品牌价值的支撑还是蛮重要的，毕竟是门面。能效的问题可以稍后排排。很多时候熟练比较重要，写代码多一点拷贝复制其实也能用。如果有同学对中后台提效感兴趣，我后面也会写，也可以评论一下聊聊，问的人多了我自然会把那个的优先级往上提一提，个人还是能在中后台效能这块说上点话的。

回归正题，为了达成体验一致性，主要的事情是处理不同技术栈的兼容以及推广同一套设计系统。

我们在这篇文章里主要浅聊一下在治理的命题下如何处理不同的技术栈的问题。

Frameless 概念

先提一下这个东西能够带来最大的好处 ——— 治理问题分层，渐进式工程。这个真的非常非常重要，治理这件事情本身就吃力不讨好，投入的精力不少，提效上不太明显，如果不能最大程度减少用户的改造成本、心智负担，这件事情就只能让老板层面强推了。当它演变成一个的 80%政治任务(或者说半政治任务，因为长远来看真的是双赢) 的时候，不得不说是一种悲哀。

正文：

扫描二维码关注公众号，回复： 14234100 查看本文章

最近其实什么环境无关、微前端、bundleless 啥的都有提，我关注社区不是很多，微前端有了解，bundleless的话自己搞过，也是为了治理，这里不细聊。

除了bundleless，其他的两个主要都是为了除了不同技术栈的不兼容问题，其实也就是 React 和 Vue 之间兼容或者同框架的不同版本的兼容，比如 Vue2 Vue3 的混合应用。

那么这里还是提出一个更明确的概念，Frameless，挺通俗的，就是不用框架！

2022 年，纯原生能够做非常多的事情，Frameless 的核心也非常的简单，ESModule + Web Component，由于 ESModule 在解析时会有一个自己的上下文环境^[1]，React16 与 React17，Vue2 与 Vue3 并不会有什么很严重的冲突，毕竟不做格外处理也不会占用同一个namespace，你完全可以做到如下的事情：

import react17 from 'https://esm.sh/react@17';
import react16 from 'https://esm.sh/react@16';
console.log('17', react17);
console.log('16', react16);

// 如果你想在浏览器devtool里看一下
import('https://esm.sh/react@17').then(console.log)
import('https://esm.sh/react@16').then(console.log)
// 这个也可以
// 至少在 https://native-spa-route.vercel.app/ 这个页面下没有做 script-src 的限制，可以直接请求的。
复制代码

esm.sh 真是个好东西，之前搞 bundleless 的时候发现的。 还有 jspm 也不错，比较老牌了。

在浏览器中使用 ESM 可以做到比较无痛的加载 Vue/React 等“框架”。还剩下3个问题：

1. SPA 体验
2. 样式隔离
3. 工程处理

其中3与1、2都有关系，3我打算到时候单独讨论。

SPA 体验

这个其实说起来不就是路由处理嘛。。。没有啥很高深的东西，各种拦截、hook、封装封装就好了（我是能用党真的很对不起呢.jpg）

我这里有写了一个路由处理库，基本上是可以做到 SPA 体验的，在线体验地址

手机的话最好用比较高级的浏览器打开，我这边用IOS 15.3.1 微信内置的不行，safari可以。

截止 2022年6月5日 01:42，这个库还有些东西没写完，主体功能是OK了，custom render 还没 demo，还没确认可用性，大概率有bug。

使用方法也很简单：

先初始化一下

import { preload } from 'native-spa-route';
preload();
复制代码

然后用 <native-route></native-route> 就可以了，具体可以参考上面那个URL的dom结构，也可以去 github 上看 index.html 文件。比啥文档都强(绝对不是我懒.jpg)。

其他的就是一个通用 Header、通用 Side Menu，基本上来一个封装一个 web component 就行了，也可以用现成的改， @shoelace-style/shoelace 的成熟度让我有点惊讶，完全是生产可用的状态了。

顺便附上页面结构图：

一些别人问我比较多问题

1. 组件间/应用间/各种间 的 通信问题

这个其实很好解，Custom Event 解决 80% 的诉求。其他的，用一些辅助工具库吧，也挺多的。

细节一点，平级组件通信

1. 可以委托父组件处理（比较万能，需要格外处理）
2. 可以直接发 Event（组件会有多实例的时候要注意，其他时候完美）

父 => 子

1. props 走起，单向数据我最喜欢了，MVVM 虽然可以减少代码量，用起来比较方便，但是容易造成心智成本指数级提升，除非你拆分的足够好，场景足够内聚，不然小心使用。
2. 还是 Event

子 => 父

1. event pop
2. document operate，如果你用 Web Component，this.parentElemet 就可以

2. 组件间/应用间/各种间 的 上下文共享问题

基本同上，但是上下文这个东西比较特别，他是一个有状态的逻辑实体，也绑定一个DOM实体，建议直接挂DOM上，用的时候就这样 document.querySelector('xxx').ctx, 或者这样 this.parentElement.ctx。

更多的问题在于制定一个 Context 标准。

3. 资源优化问题

哎呀你这个 ESM 文件太碎了呀，好多请求？？？

哎呀你这个构建咋搞, 资源咋复用？？？

首先，如果你有很强的工程能力，这个建议自己搞，就是一个联合构建事情。

这个东西在我的计划中，我需要先搞定公司的联合构建方案，有例子了再去搞社区的，但是思路不复杂，把各种 repo 拉到一个地方统一构建一下就行了，vite 很好用，直接用就行，不要在工具上纠结太多，啥适合用啥。我那个 native-spa-route 就是用 vite 的，但是demo的构建使用 zx + esbuild, 很简短很方便。

4. 你这个跟微前端有啥区别啊

首先，区别在一开始就出来了，微前端有用！毋庸置疑，但是他是用来兼容的。我的命题是治理，不知道大家有没有听过 “巨石应用” 的说法，这个东西会导致一个产品的维护成本指数级提升，到最后谁都搞不动，本质上是模块化的设计没有做到位，以及适当的约定越来越多的，很多时候真的，约定真的很适当，但是人多了，每个人习惯都不一样，各种各样约定放一起，得，改不动了。

当然，治理是第二阶段的目标，在刚开始，兼容才真正的目标。

总之得结合你们的场景考虑，我已经走到治理了，你或许就不一定。

我的一阶段治理目标：应用框架我给出来，白嫖工程红利，大家开心的糊页面，想用啥用啥，React、Vue 都行。Vue2 Vue3 都没关系。

样式隔离

这个，我真的不想讲太多，基本上 class prefix 够用了，不行上 ShadowDOM。

问题在哪里？

打头的就是兼容性，具体查 MDN 或者 caniuse。要落地得自己去找你们管数据的要一下打点数据，跑个简单的分析。

2022/6/5-02:33 困了.. 先发一版

参考链接

链接之后补！！！自己的上下文环境^[1]