前端学习笔记-其之一

本文将梳理前端的发展历史，并对我的react学习进行总结。

前端的发展日新月异。每个时代都自成一套，每次在学习前端时都有翻天覆地的范式变换。

虽然我是游戏服务器、业余后端，但是也还是要写一些前端玩具的。我曾N次试图学习前端而草草收场。虽然已经是21世纪的第三个十年了，但是都是简单的大后端模板渲染或者jQuery加上f12抄代码。非常的不系统、非常的玩具。

最近，借开发 platform 的东风，系统地学习了 react。作为后端，写前端的机会不多。好记性不如烂笔头，在这里简单的记录下。

文章太长了就会烂尾，因此我将文章拆为两部分，这里是部分1。

前端发展史

早期

互联网早期，并没有什么自顶而下设计的学术模型，或者这些闭门造车发论文的模型并没有得到普遍认可。经过物竞天择、适者生存的竞争后。http体系形成了html、css、js三大前端组分。

在当时，并没有人把网页看成为一个http应用，而是将其看成一个联网的界面，最多利用js形成一些轮播图之类的特效。所以他的设计方式与常见的客户端截然不同，是以html界面为主体、css负责进行排版、js负责简单交互和动画。当时的网页在现在被称为静态界面，和当今的web app完全是两个东西。

js出现的比较迟，在其诞生之初也仅仅是类似于已经被淘汰的flash的公司内部产物，用以在网页上执行一些脚本。语法也比较动态、混沌、简单、复杂（是这样的）。

web三巨头的每一个组分，在设计之初都没有想到日后会被拓展成如此复杂的一个系统。当时用户、开发人员、市场规模都不大，所以设计之初就充满了儿戏和玩具感。这为后续的发展埋下了巨量的技术债。

js(java script)的名字都是山塞的java。

http://后面的双斜线甚至是草案注释的一部分……

ajax与jQuery

在工程化以前，我们所说的前端工程师这个岗位还没有这么明确，往往是嵌在各种后端语言中。前端复杂度的增加，使得前端的渲染逻辑、功能逻辑必然需要从后端拆分出。

新世纪后，网页的交互越来越多，为了避免每一次交互都需要加载完整的界面，js 新增了 ajax，允许前端可以通过异步请求与服务器进行数据交互，无需刷新整个页面。这一发展为js奠定了异步和大量函数式编程的基调。

随着 ajax 的增多，人们像写客户端那样交互前端，操作 dom。

前端交互变得复杂后，原生js语法显得太繁琐了。在这个背景下，jQuery出现了，它大大简化了DOM操作和事件处理。jQuery的出现标志着前端开发变得更加便捷，为Web应用的快速发展提供了支持。html逐渐变得不像是应用的主体或者骨架，而是js启动器。jQuery组件式地操作几组html拼装出界面。

前端和后端之间仅仅交互数据和基础的html、css配置，这种模式被称为前后端分离。

前端工程化

js的复杂性、功能性日益增强。有人将js剥离浏览器，变成解释型的脚本语言Nodejs。虽然在后端和脚本语言的生态上尚无法与python抗衡。但是为后面js生态的发展建造了脚手架。

Nodejs也有自己的包管理器npm。开发者通过npm方便地安装、分享和管理项目依赖。这种开发方式使js开始组件化模块化。

于此同时，前端的复杂度仍在增加。需要大型框架来拆拆分渲染逻辑、dom逻辑这些底层的js逻辑。augular、vue、react相继出现。

js自身的语法也在发展，开源组织也从社区中吸收了一些精华推出了ES5、ES6这些版本。这些版本引入了一些新特性，使js焕发新生。不能再讲js视为极为简陋但是图灵完备的脚本了，已经有资格被称为编程语言。

js的动态类型和弱类型特性，方便了小项目的启动和热修改，但是使得大型工程的组织和编写极为棘手。TS出现了，它作为JS的超集引入了类型等新特性。但是需要编译成真正的JS才能正确运行。

也产生了脚本编译成脚本这一奇观。

原始的HTML、JS体系在很长一段时间没有模块的概念。但是大型的项目和框架的体量非常大，如果以单文件或者直接引入源代码的方式会极为庞杂。使webpack、vite等打包工具开始出现。他们利用NodeJS，以使用大型js框架的js为主体，重新组建html和js，支持代码分割、混淆、热模块替换等功能。至此html这个概念其实已经只以组件的形式出现在js体系中了。

此时逻辑和客户端开发比较相像，打包、资源等。

前端的复杂程度的提升使得浏览器变得极为庞大，js或node的功能也极为全面，生态也很好。这使得前端逐渐吞噬了客户端开发或移动客户端开发的市场。出现了react native、elecron等库。客户端也逐渐吸收前端体系，形成qss、flutter等等。

移动客户端也将js的某些超集囊括其中形成微信小程序等等。甚至主流移动操作系统也开始这样做，安卓有快应用和原生鸿蒙（不是1.0、2.0的套壳apk二进制，而是native的官方小程序，主要是为了能低成本的完成原生营销+不丢弃安卓这一目的），ios也有类似的东西。

期间也出现了很多诸如https等对原http的补丁，但是他们对于前端基本是透明的。弥补了http最初只是用于局域网，秉承着开放、平等、协作、快速、共享而设计带来的一些缺陷。

由于HTTP最开始只是传输html等的纯文本协议，在工程化前端面前不仅不够方便，也会有性能问题。因此，WebAssembly或WebSocket等技术开始流行，前者支持用二进制替代js，提升性能减少网络流量损耗，后者支持全双工通信，优化逻辑的复杂度。

现代前端往往脱离HTML静态网页而存在，对于搜索引擎极为不友好，也会导致浏览器载体为了渲染损耗巨量性能。除了WebAssembly，SSR(服务器渲染)也开始流行。后端渲染出成型的HTML、CSS、JS，提供给前端。

在HTTP设计之初，路径用来定位静态资源的位置。前后端分离，使路径也会被用来指代虚资源api等。

前端的工程化使得往常的web概念都变成了方便软件工程设计的虚概念。现代的web应用也不是以html文档的形式组织的，因此开发者希望改变路径也不再需要加载全部网页。而仅仅触发应用的某一个逻辑。随后出现了一类拦截路径变化、跳转、前进后退的前端框架，被称为前端路由。web应用变成了一种带有路径作为快捷方式或参数的客户端。在后端上，http标准也增加了json、流等数据形式，让后端对特定的路由返回需要的数据（json等），而不是文件或者静态资源。

SAP

综上我们组建了一套与设计之初严重不符的巨无霸，我们称之为SAP单页应用。这是一种通过AJAX和前端路由实现的Web应用，将多个页面整合成一个单一的HTML文件。使用多种协议或方法加密、压缩协议。与后端完全分离，后端仅提供API数据。

配合NodeJS与SSR，可以在服务器直接渲染页面，网页路径等逻辑也完全由node实现。甚至打包时的编译（TS->JS）和打包的时间都以分钟记算。

此时写代码比较多的开发者发现了我们这玩意很像传说中的WEB大后端先辈。

PHP！！！

前端通过一代人的努力，重新发明得到了PHP！！！

不得不说技术的发展确实有一定的相似性。

当然这也就是一个段子，其实两者之间还是有很大的区别的，一般也不会将SAP+SSR全部使用，除非是由前端团队主导的全栈项目。

后文

事实上渲染、路由这些概念和逻辑不会随着技术框架的变化而消失，不管是大前端、低代码、还是什么别的DSL、xml java注入，都只能将逻辑封装成最小可用黑盒，我们依然是需要去拼装这些逻辑。甚至可能因为框架采用了大量的hack或者自创的DSL等原因失去IDE的高亮、补全等特性。

所以一切的语言的发展的最终形式都会走向某种共同的交点，只是封装的侧重点不同。这也就是为什么大前端的终极形式（我称之为巨前端）和PHP如此相似，java框架逐渐减少了xml的使用转为写代码，策划写需求文案往往把自己变成lua工程师的原因。

即使chatgpt等技术发展到极致，也只能引导你认知自己想要什么，最终用自然语言清楚地描述出自己想要的逻辑，而无法真正的消灭逻辑。

指望用当前技术水平下博学但是不够聪明的通用AI和功能强大但是参数极为复杂的专用AI替代人类，最后可能也只能消灭掉重复没有意义的劳作，所有人都换了一种形式写代码。

扯远了，放几个表情轻松下🤣😂

应该单独出一篇拓展下后面的思考。