编码之道|前端之变(五)(王者归来)
本周继续就前端之变阐述自己的思考。
这是本系统的第五篇,前四篇为:
- 前端之变(一):技术的变与不变
- 前端之变(二):不变的前端
- 前端之变(三):变革与突破
- 前端之变(三):进击的前端
本篇我就来探讨与分析一下,究竟是谁给前端带来了如此巨大的改变,前端这些年究竟发生了什么事情?
我还是从前端的发展历史开始说起吧.
前端发展史
文章图片
上面这个图用时间线的方式浓缩的讲述了前端重要技术的一个发展史。这个图中有几个比较重要的时间点:
- 2006年 JQuery发布
- 2008年 Chrome&V8发布
- 2009年 NodeJS发布,同年ES5发布
- 2012年 Typescript发布
- 2013年 React发布
- 2014年 Vue发布
如同我在前面的文章所阐述的,JQuery与React,Vue完全不能类比。
JQuery是『前』前端时代最有名的框架,而React与Vue则是『后』前端时代最有名的框架。它们之间的差异并不属于量变这种程度,完全是质变。
那很显然的,呼之欲出的,2008年v8引擎的发布与2009年NodeJS的发布这两个技术,是导致前端发生翻天覆地改变的原因所在。
v8引擎 v8引擎是一个JavaScript引擎,它是Chrome带来的一个开源的引擎。
JavaScript引擎是做什么用的?如果用一句话来形容,就是
将JavaScript翻译成操作系统CPU能"读懂"的代码
在2021年的现在,这玩意并不多,主流的就下面几个:
- Chrome的v8引擎
- Mozilla的SpiderMonkey引擎
- Apple的JavaScriptCore引擎
事实上,能做引擎的少之又少,这个东西的复杂度超乎想象,可能与操作系统相提并论了。据说v8引擎有上百万行代码。
v8引擎是C++实现,它的大致原理就是将JS代码翻译成机器代码,然后交由CPU去执行。
chrome的v8引擎是给自己的用的,因为浏览器的一个非常重要的工作就是要解释与执行JS。所以最开始v8引擎就是chrome用来给浏览器用的。
这本来没什么,但是2009年NodeJS的出现,打破了v8引擎只用在浏览器中的做法。
NodeJS的横空出世 2009年,NodeJS出现了,官网对它自己的定义及描述是:
Node.js? 是一个基于 Chrome V8 引擎 的 JavaScript 运行时。关于NodeJS到底是个什么东西,我简单的画了个它的架构图:
文章图片
从这个架构图上可以很明显的看到,它用上了v8引擎。
先简单讲下这些东西是什么:
libuv一个异步事件循环的C库。它在运行时负责一个事件循环(Event Loop)、一个线程池、文件系统 I/O、DNS 相关和网络 I/O,以及一些其他重要功能。
c-ares、crypto (OpenSSL)、zlib等提供了对系统底层功能的访问,包括网络、压缩、加密等。
Bindings桥接层,负责JavaScript与C,C++打交道的
C/C++ Addons允许你添加额外的C或C++库,但你要为它们写Addons,这样JS才能调用它们。
事实上,如果我们不看v8与JS,就会发现,这完全是一个C/C++的环境,对吧。这也是为什么NodeJS能跨平台的原因所在。因为C/C++是支持所有系统的。
v8引擎呢?一个C/C++的环境为什么可以用JS来编写代码?
我前面讲过chrome的v8引擎就是负责将JS代码翻译成机器代码。这就是为什么NodeJS需要v8引擎的原因所在。因为有了这个引擎,你才能用NodeJ编写服务器端的代码,调用系统底层API,诸如网络,文件等。
有心栽花花不开 最开始NodeJS的出现,其实本意并不是来优化或改变前端编码的,它最开始的本意可能在于:
在传统的Java之外,提供一个新的后端编码解决方案
我们都知道,在服务器端编码语言中,一直是Java占据优势地位。Java是跨平台的语言,是源于JVM这个虚拟机实现的。
NodeJS的出现很显然提供了另一种方案,它与Java有很大的差别
- 它不是使用Java,而是使用更具大众性的JavaScript语言来编写后端代码
- 它不是Java那种线程阻塞式的,而是基于异步+事件循环的实现,这种实现比线程阻塞式的高效多了。
- 更重要的是,它似乎统一了前后端编码。前后端编码再不是两群不同的难以沟通与交流的人,而是用着同一种语言的一群人。
前些年我所在的公司有一段时间,也有使用的NodeJS来编写一些服务的后台的案例。
当然,至少在这个方面,意图能取代Java,成为后端的主流编程语言上,NodeJS并未成功。
后续我会就这一点阐述下我的思考。
无心插柳柳成荫 从前端的发展时间线上来看,NodeJS的出现最开始对前端本身的影响与冲击并不大,所以直到NodeJS出现4年之后的2013年,React才姗姗到来。
至少最开始的几年时间,能编写后端服务器代码的NodeJS对前端开发并无太多实际意义,前端人员还是写着JS,用着JQuery,仍然在JS+HTML+CSS中打转。
NodeJS这种能使用JS与原生操作系统原生交互的能力,在后端的发展上,虽然没有对Java造成有效的冲击,但它却带来了一个可能最开始自己也没有意料到的结果:
它颠覆了前端的编码方式
如我在前面所述,在『前』前端阶段,前端编码一直在JS+HTML+CSS中打转,不管chrome的v8引擎多么高效,性能多么好,它也只是辅助浏览器更高效的执行与解析JS而已,它并没有为JS带来任何与原生操作系统交互的能力。
而这种JS能与原生操作系统进行交互,诸如读写本地文件系统,网络等的能力,对于前端进入『后』前端阶段,是至关重要的。
想像一下,如果没有这种与原生系统交互的能力,今天前端的主流的一些技术与工具,没有存在的可能性:
- React,依赖这种能力将JSX翻译成JS
- less,sass这些编程式css,没有办法翻译成css
- 前端的包管理npm,没有读写本地文件系统的能力,所谓的依赖管理压根无从谈起
- typescript将不复存在,v8引擎难道认得ts?是由tsc将ts翻译成js文件,浏览器才能识别
NodeJS作为一种语言,显式的意图是与Java在后端领域竞争,无疑未有成功。但它做为一种隐式的支持,支撑了前端技术的革命性的变更,却是大获成功。
所以,在2021年,当一个程序员下载与安装NodeJS的时候,很大可能他并不是想用NodeJS编写一个后端服务,而是为了编写前端的代码而已。
这才是NodeJS现今最真实的处境,它在前端的作用远超它在后端的作用。
王者的归来 所以,没有任何疑问,对于前端来说,NodeJS是当之无愧的王者。
在『后』前端阶段,任何一个主流技术都可以有替代方案:
- 你可以不喜欢React,去选择Vue,
- 你也可以在typescript与javascript中任选一种你喜欢的,
- 你也可以在less,sass,css自由的切换,没有哪一种是限定你不得不使用的。
它没有让你去编写后端程序,甚至可能你在前端编码中都意识不到它的存在,但它对你所使用的现在前端几乎主流所有技术都是不可或缺的。
除非,只有一种可能,
你再次退回到『前』前端阶段,去使用JQuery,使用单纯的HTML,用css来控制样式,这并不是不可以。就算是在2021年,你依然可以这样做。
你觉得这会有价值么,无论你持有什么立场,心中都明白,这并不是一种选择,这就是一种退化。
我们已不可能再回到那个『前』前端阶段了。
引领式变革 前端的改变不仅仅是影响到自己,一些优秀的框架,它不仅仅是借鉴其它端优势的理念,在一些方面甚至走的比其它端更远,做的更好。
以致于其它端又要回过头来,向前端的理念学习。
比如前端的声明式UI就是一个例子
我在这几年编写移动原生开发,与2020年编写前端开发,在UI上给我的感觉是截然不同的做法。
移动端主流仍然是命令式UI编程,而React已经是声明式UI编程
很显然,声明式UI编程更胜一筹,所以现在无论是android的jetpack,还是iOS的swift ui,都在向react学习,也都是声明式UI编程的方式了,虽然这些还未成为移动端的主流,但往声明式UI发展也是移动端不可逆转的趋势。
【编码之道|前端之变(五)(王者归来)】下一篇,我将继续探索与分析前端之变,讲述前端引领式的变革 – 前端之变(六): 从命令式UI到声明式UI
推荐阅读
- 论刘备的成功之道
- Jsr303做前端数据校验
- 04.19读《生养之道》分享
- 7、前端--jQuery简介、基本选择器、基本筛选器、属性选择器、表单选择器、筛选器方法、节点操作、绑定事件
- 前端代码|前端代码 返回顶部 backToTop
- 经营者养成笔记读后感
- [丰声]简字·第66期|[丰声]简字·第66期 家庭问题树的心理原因与化解之道
- 2019-08-06上篇一、观天之道,执天之行,尽矣。
- 前端|web前端dya07--ES6高级语法的转化&render&vue与webpack&export
- 前端自学笔记01