现代前端UI框架反思
背景
最近了解了一门新框架 alpine.js，再惊叹其简洁的同时，开始反思前端框架（特指 vue react 之类的 UI 框架），真如我们所需要的吗？如果我还在用 jquery，你或许会说我老古板，但是，网络上曾经流传一个段子，“2019年你如何启动前端开发”，nodejs, webpack, babel, cli... 各类工具充斥着我们的视野，以至于让我们开启一个前端应用开发，需要九牛二虎之力，花费大量力气去解决、配置各种编译打包工具。虽然工具给我们在工程化方面带来了很多可能性，甚至衍生出 typescript，以及前两天字节开源的 modern.js 这样的项目，但不可否认，纯粹前端魔法的乐趣，在这些工具面前逐渐被消磨了，慢慢的，前端开发，特别是在特定项目中的前端开发，编程了工具配置和框架使用的纯搬砖工作，所以面试只需要面工具和框架，就好了，有点太偷懒了。我开始疑惑，10 年前刚开始玩前端时候的乐趣和惊叹去哪里了？
我们从来都是在这条曲线上前行，在“乐趣-工程”和“严谨-魔法”这两个象限的探索也并非没有过，却基本上属于前端的异类。实际上，前端除了常见的信息流系统外，还有类似游戏、绘图等其他类应用，但它们却不在主流前端的队伍中。市面上 100 家公司招前端，有 100 家要求熟悉特定的前端框架，这使得类似 figma 或 photopea 这样的应用在国内显有遇见。
我在过去两年没事的时候，就会把玩一些框架，感受它们的奇特之处。比如 cycle.js 或者前面提到的 alpine.js，会有一些体会。随着框架技术的普及，不同的公司，可以轻轻松松出自己的框架，比如阿里的 rax，比如 taro 等等。2020 年微前端话题火了，我又开始看相关的框架，自己也造了一个 mfy，直到 webpack foundation 出来，我彻底懵了，这和 sea.js 有本质区别吗？这刺激我思考，是不是技术兜兜转转又回到了从前，或者用优雅的词描述叫“螺旋式上升”？前段时间在某乎表达了对某 v*t* 工具的看法，马上就被它的作者猛怼了两段话，我原本以为能写出这么优秀的工具的作者应该是会用技术说服人，没曾想热度大压死人，哎。。。如果说 bundless 是接下来的趋势，那我在想，为什么还要服务端去 compile 那一下呢？我们全部人都写 ESModule 的代码不就好了吗？“以前的 npm 遗留问题”，不就是用 export 包一下的事情吗？bundless 个啥？
这些略带情绪的想法，促使我思考，前端领域的种种所谓工程化、工具链，是否真正为开发人员或产品本身解决了问题，还是带来的问题更多一些？今天刚看到一个叫 livewire 的项目，以及最近接触《数据密集型应用系统设计》一书，感觉整个前端是否真的为技术系统的发展带来了什么价值，没有了前端，或者说，没有了时下那么复杂的 modern 前端，这些应用系统是不是没法设计出来，或者出来也很难用？我想答案是否定的，可以说，即使没有现在这么复杂的前端工程化，只需要利用 livewire 这类工具，就可以让后端人员独立完成大部分数据驱动的应用（类似 figma 或 photopea 这样的应用则后端无力）。这么来看，前端这些年，轰轰烈烈的发展，发展了个响？
Web 技术过时了
现在 2021 年，似乎很多 web 技术都过时了。比如基于 css 的阴影、过渡动画、圆角、栅格等等，这些具体的东西，在前端越来越少人提及，大家一开口都是 css in js，或者 styled-components，甚至现在提出来 dynamic styles 等等。几年前我们所依赖的 web 基础技术，现在好像过时了，虽然每年都有国际国内的 css 大会，但是，并不是主流，而在众多前端大会中，大家都在讨论的是低代码、工程化、跨平台开发、 设计、serverless 等等。新概念层出不穷，各类架构设计狠狠内卷，看上去一派繁荣景象，实则令人担忧。
在过去的几年里，web 前端技术确实发展了。例如 PWA、WebAssembly、WebRTC 等技术的出现，HTML5 和 CSS3 的演进，但很多技术，对于趴在框架上完成业务系统的开发者们而言，它们的出现或发展对于自己的工作几乎没有任何帮助，内心毫无波澜，甚至觉得是在乱搞飞机。与其说 web 技术式微，不如说其下沉。例如 webrtc 等技术，如果不用封装库，一般开发者根本不知道怎么用，甚至不知道有这玩意。离开了高级的封装库，一些开发者根本不知道该怎么使用，比如在 jQuery 时代，很多人不会原生的 DOM 操作，而到了 react 时代，甚至不知 DOM 为何物。
除了 web 应用之外，基于 web 技术的跨端实现也层出不穷，react native 开头，后面衍生了一大堆基于原有 web 写法的原生应用开发方式。但这类跨端方案只能写 UI，需要调用系统层组件的能力全都做不到。基于 JS 运行时的客户端，性能又不怎么样，美其名曰更少的人力做更多事，实则是用三流的人写三流的应用。
或许，不是 web 过时了，而是不带这些低劣的人和应用们一起玩了，随着 webassembly 的发展，逐渐把 web 应用转交给其他语言的开发者，让这些搞来搞去在搞各种工具链自以为是的前端开发好自为之。
没有性能，不成方圆
现在一个应用打包之后几个 M 再正常不过了。代码中充斥着 O(n2) 的多层遍历，美其名曰“先抗住再优化”，这种论调我可以理解为“功能我实现了，不到万不得已，你根本不知道我堆了一堆屎”。除非团队有明确的指标和负责任的技术领导，否则，一个项目的性能永远会失控。而这些毫不在意的性能，正在慢慢毁掉软件领域的优秀积累，一代比一代差，到最后，上个世纪的软件开发能力和素质，将被望尘莫及，最后封神，但实际上，却是一代一代堕落而至。
在数据结构和算法上欠下的债，总有一天会在重构中还回来。
All in JS 的赌徒心态
把所有东西都写在一个 js 文件里，导致代码功能混杂在一起，自以为是增加了灵活性，实际上是不知所措的愚蠢表现。
例如，市面上所有的 UI 组件库都声称自己是在统一设计语言下的产物，比如 antd 是 ant design，比如 semi design，但是从它们的官网，我完全读不出它们的 design 究竟为何物。说白了，他们是先有所谓的组件库代码，然后再来谈设计。所以，在他们的资料中，设计语言是附属品，代码，而且是特定条件下的代码才是主体。
真正的 UI 组件库，一定是让使用者先了解设计，再有通用的 css，最后才是各种框架的封装库，而框架的封装应该是可远的，而不是主体。本末倒置是这个时代，不单单是前端领域，的核心竞争力。就像前几天某大厂买星项目一样，为了完成 kpi 而毫无敬畏之心，这样的公司，你能肃然起敬？
抛弃 css 成为前端乐此不疲的事，说明前端（或者整个行业）越来越不在乎（或者说没有话语权）应用的设计与性能的平衡。说白了，就是懒。
类似 styled-components 这类方案的流行，本质上就是牺牲性能和合理组织的偷懒行为，因为你可以把样式用 js 来写，从而不用去思考写东西该怎么去实现，其他交给工具，不管是编译时，还是运行时。
结语
近几年这种前端发展的风气，反过来说明前端的问题在于天花板低（门槛也低），就和一些低门槛没有利润的行业一样，看上去琳琅满目，实际上一地鸡毛。而且，由于惯性，这种局面基本上是不可能打破了，让人感到无比凄凉。不过，好在越来越多的后端技术栈开始去兼容前端，这也就意味着未来的应用形态也会慢慢重回统一，在一个架构中去实现，而非前后端分离。而且，我相信这种前后端一致性，才是未来的趋势。
-
前端确实很多时候都是在折腾，圈地自萌，但这也是前端社区的一部分，让前端生态变得相当繁荣。但从另一个角度看，很多东西不做也不知道有没有用。#1101 rxliuli 2021-11-04 14:32
-
另外 vite 挺好用的，比它的前辈 snowpack 兼容性好得多#1102 回复给#1101 rxliuli 2021-11-04 14:59
-
楼主用心思考了，说得很好，切中行业弊端。alpine.js是一个非常优秀的框架，感兴趣的话可以了解下一个比它设计更加简单易用的前端框架：https://daggerjs.org，编码方式十分贴近原生js，同时又提供了数据绑定和监听功能。非常赞。#1250 隔壁老王 2022-11-11 19:21
SSO统一用户管理系统设计
我以前在《同一公司下多个产品共享用户的权限设计系统》和《独立产品权限体系设计》两篇文章中讨论过用户权限系统，但是，两篇文章更多是从工作经验角度出发，今天读到一片硕士论文，从理论层面探讨了这一设计的可能性。
来源 https://www.docin.com/p-1419313536.html
而且这篇文章还给出了具体的数据库表设计：
从上图可以看出，该论文的作者，和我考虑的是一致的。SSO是，你的多个产品，使用统一的用户认证、权限体系。这和我前面第一篇文章提到的方式是一致的。而且，该论文更加坚定了我把应用的权限也设计到整个用户权限体系中统一设计的思路。
-
赞#1103 东 2021-11-04 22:18
前端框架发展脉络与趋势预测
前两天做了一个视频，聊了前端框架的话题，包括上一期robust也聊了前端框架的话题。对前端框架的发展的梳理，我觉得已经做的不错了。
本文再简单总结一下。
我把整个前端框架的发展，分为3个大阶段，其中黄色的框是jquery为王的阶段，典型框架有angularjs, backbone等，这一阶段的框架实际上也是数据驱动，比如angularjs和backbone，所以，我们不能用数据驱动来划分它们和后来的react、vue的区别。
绿色的框这一阶段有两个特征，一个是react、vue大行其道，另一个是类似babel、webpack这样的工具是开发工作的基础。在16、17年时，流行起来一句话，叫“学不动了”，意思是前端发展太快，冒出来很多东西，其中包括了对新框架的谈笑。但是，从上图可以看出，其实在这一阶段（上图中没有列举出类似cyclejs这类框架），并没有像上一个阶段一样那么多框架林立，而是被react、vue、angular统治，所以，有的时候，我们的感觉和实际的情况有一些差别。和上一个阶段不同，这一个阶段react作为主导框架，追求的是某种极客层面的快发体验，特别是react，在runtime上探索出了时间切片等。但是，react持续在runtime上下功夫，或许会错过下一个阶段。
蓝色框是第三个阶段，也是我们当下正所处的阶段。这一阶段的特征是基于编译的框架开始大行其道。以svelte为典型，vue3跟进，框架们都在想办法，让开发者在源码中使用比较特殊且体验更好的语法来写组件，然后通过编译器，把这一写法转化为运行时放到浏览器中跑。甚至，像alpine这类框架，直接在运行时进行解析和运行。这种基于编译的模式（实际上，angular2+的模板语法也是这种模式），可能是接下来这段时间前端框架的主要方式。
windows10 C盘后面有一个恢复分区，无法扩展C盘的解决办法
今天公司给装了一个新的500G的盘，导致我电脑瞬间多出很大一块空间。而看着越来越小的C盘，想到我以前也有拿D盘补C盘的操作，这次我索性把整个D盘干掉，来一个500G的C盘，岂不是爽歪歪。网上搜索了一下方法，windows自带的磁盘管理工具就可以满足，于是开开心心的打开磁盘管理，把D盘删了，然后按照指示，右键C盘扩展卷，然后，M的，这个选项是灰色的，用不了……
这么尴尬吗？我一看，在C盘后面还有一个很小的分区，写着“恢复分区”，大概是系统故障的时候跑一个特殊的小系统来做引导的吧。这个我没意见，但是你为啥插在C盘和D盘之间？？磁盘管理工具又不能把它和D盘调换个位置。难道就这么卡住了？
又搜索了一下，https://www.diskgenius.cn/ 这个工具可以调整磁盘，于是下载下来试试。折腾了一下，发现可以采用一种变通的方法来处理。它可以调整磁盘大小，而且很诡异的是，调整磁盘大小时使用拖拽的形式，两边都可以拖，这就可以直接通过这个能力，把哪个“恢复分区”搞到最后面，把空出来没有的部分和C盘连在一起。
通过上面这个地方调整“恢复分区”大小，进入之后可以看到如下界面：
通过拖动的方式，把这个分区搞到最后面去，这样把空的空间留了下来。
这样愉快的调整完“恢复分区”之后，我想，继续用这个软件调整C盘的大小，结果，同样的方法提示这个磁盘加密，没法搞。难道没办法了？
这时，我又突然想到，回磁盘管理工具试试，在磁盘管理工具中使用右键扩展卷功能，竟然成功了。于是，我就有了一个接近500G的C盘，爽歪歪~
-
这样恢复分区的大小会改变吗，调整完以后会不会出问题呢#1126 历史进程 2021-12-05 15:40
-
不会，没什么影响，就是你自己要做好数据备份先#1127 回复给#1126 否子戈 2021-12-05 22:05
-
太感谢了。弄好了！#1156 回复给#1127 路兹 2022-01-14 10:33
-
太感谢了，非常管用~~特别是中间说到的那个：磁盘大小调整时可以拖拽，刚开始还不敢拉，后边会拉了果然很好玩，果然诡异哈哈哈#1191 吾 2022-05-09 07:11
-
感谢感谢#1205 zain 2022-06-28 14:35
-
太对了哥，事情办成了大的小的全保住了。完美！你TN就是个天才！
-
你是我的神#1254 zbvb 2022-11-22 22:16
-
夸张了#1255 回复给#1254 否子戈 2022-11-22 22:26
-
试了一下，成功了……真是个莫名其妙的方法🤣#1263 嘟噜噜 2022-12-16 20:11
搭建起自己的vscode在线版本
我有一台服务器，放在那里特别久了没怎么用，今天在下班地铁上突然想到，我可不可以在平板上写代码？搜了一圈发现还是要上vscode在线版才行。于是回来就开始撸。
code-server超级简单，一个安装脚本解决：curl -fsSL https://code-server.dev/install.sh | sh，完成后修改~/.config/code-server/config.yaml，再运行code-server命令，就可以开始在线写代码了。为了安全，该用export PASSWORD="xxx"来配密码。
之后解析了一个域名过去，nginx代理转发，这个也很简单。
然后用certbot搞定https，这样就完整搭建了整个vscode在线版本。
另外，在我的pad上，竟然发现edge打开一片空白，而华为自带的浏览器打开迅速。再使用“添加到桌面”，code-server提供了PWA，直接全屏玩，真挺用心了。
JS角度看什么是多态？
多态的简单解释是，调用相同的接口传入相同的参数，由于被调用的设备不同产生了不同的副作用/效果。例如同样是console.error，在chrome浏览器里面和在nodejs的command inline interface里面，效果就不同。基于这一特性，我们可以对接口进行抽象，简单的例子如下：
interface Person {
sing(song: object): string;
}
function sing(person: Person, song: object): string {
return person.sing(song)
}
上面的代码里面，我们创建了一个sing函数，它接收person这个对象，并调用它的sing方法。由于类型的约束，接收的person一定会有sing方法。但是，这个person.sing这个方法会做什么事呢？对于sing这个函数它并不知道，它只是调用了person的sing方法而已。所以，我们基于多态实现person。
class Person1 implement Person {
sing(song: object) {
const { lyric } = song
console.log(lyric) // 打印到屏幕上
return lyric
}
}
class Person2 implement Person {
sing(song: object) {
const { lyric } = song
Audio.paly(lyric) // 播放声音
return lyric
}
}
两个类实现了相同的Person接口，但是在实现的时候，又使用了不同的副作用，这就是多态。
那么，多态有什么用呢？对前端有什么影响呢？
第一点，是代码写法上的变化。
以前我们喜欢extends来得到一个具体的类，比如 class Person 有一个 sing 方法，我们通过 extends 来覆盖这个方法。这也就意味着，你的代码里面，一定会引入原来的 Person，并且原来的 Person 里面的 sing 方法一定会在最终打包的代码里面，虽然它永远都用不到。而新的写法是在调用函数的时候，把类的实例传入进去，这把引入模块的工作交给函数外部去做，这就让到处这个函数的模块的代码瞬间减少了。
第二点，是架构设计上的变化。
以前我在架设react项目时，会以View作为入口，应用的一切都是先有View，在View中去引入需要用到的Model等其他模块，这也就意味着，应用以View为顶层入口，所有的代码层层引入，绑定在了一起。现在，我们利用多态，换一个角度。我们让开发者自己写入口，这个入口我们称为Controller，我们提供的框架不是让View去使用Model，而是反过来，让Controller去使用View，让Model去使用View。这个场景下面，View必须按照接口约束提供接口给Model使用，这个时候，我们写Model就可以反过来考虑控制View（这里的Model是指ViewModel）。这种转变非常神奇，从框架层面，它颠覆了传统前端的开发方式。
之前一直想买一个Pad，但老婆觉得太贵没必要就一直没有买。昨天实在没忍住，在得到老婆允许后，一咬牙就买了这一台matepad。我主要的想法是想基于手写笔做一些事情，例如记笔记，上网课。昨天拿到手后开始调教，现在已经感觉差不多了。手写笔非常有感觉，可以随便涂涂画画，但实际上用来写作的话，速度比较慢，因为辩识手写肯定有一个误差，而且写完一个字的速度没有打字来的快，所以在需要大量字的时候我还是倾向全键盘输入。
自己团队的难处与众不同，奇特的困难降临在他们身上，偏偏别人得以幸免。
--http://www.umlchina.com/book/softmeth_pre.htm
过去半年用Edge替换了Chrome，在运行上，感觉和chrome没有差别，甚至还有一些特别的功能，以及没有墙的感觉，挺好。但是，这两个月陆续发现Edge占用内存上升，CPU占用增加，另外还有一个微软的software update在那里一直跑，依依不舍，用回了chrome，瞬间电脑不卡了。。。卧槽，不卡了。。。今天还看到一个消息，Edge新标签页强制广告关不掉，真垃圾，作恶多端。
