一文读懂前端技术演进:盘点Web前端20年的技术变迁史

本文原文由作者“司徒正美”发布于公众号“前端你别闹”,即时通讯网收录时有改动,感谢原作者的分享。

1、引言

1990 年,第一个Web浏览器的诞生;1991 年,WWW诞生,这标志着前端技术的开始。

在这将近20年的前端发展史中,我们经历了从最早的纯静态页面,到JavaScript跨时代的诞生;从PC端到移动端;从依赖后端到前端可自由打包开发;从早期的网景Navigator浏览器到现在各家浏览器百花齐放……

我们经历了前端的洪荒时代、Prototype时代、jQuery时代 、后jQuery时期、三大框架割据时代,这其中均是由国外开发者主导,直到如今的小程序时代,才是中国开发者独创的。

这是漫长的技术储备下的成果,最终促成了良好的技术成长收获。期间的前端发展之路,崎岖艰难。

(本文同步发布于:http://www.52im.net/thread-2719-1-1.html)

2、相关文章

3、洪荒时代(1990~1994年)

在1990~1994年期间,前端界发生的大事有:WWW(World Wide Web)的诞生、浏览器的诞生、JavaScript的诞生,没有专业的前端,页面全是由后端开发的。

1990年,万维网之父蒂姆·伯纳斯-李(Tim Berners-Lee)在NeXT电脑上发明了第一个Web浏览器。

▲ 互联网之父——伯纳斯·李(Tim Berners-Lee)

1991年8月6日,Tim在alt.hypertext新闻组贴出了一份关于World Wide Web的简单摘要,这标志了Web页面在Internet上的首次登场。

1990年12月25日,罗伯特·卡里奥在CERN(即位于日内瓦的欧洲原子核研究会)和蒂姆·伯纳斯·李一起成功通过Internet实现了HTTP代理与服务器的第一次通讯(有关HTTP的详细介绍,请见《网络编程懒人入门(六):深入浅出,全面理解HTTP协议》)。蒂姆·伯纳斯·李(Tim Berners-Lee)爵士作为万维网(World Wide Web,简称WWW或互联网)的发明者,被尊称为互联网之父。蒂姆·伯纳斯·李建立的第一个网站(也是世界上第一个网站)是http://info. cern. ch/,它于1991年8月6日上网(即北京时间8月7日)。

最早的Web主要被一帮科学家们用来共享和传递信息,全世界的Web服务器也就几十台。由于仅是用来传递信息,从可视化方式或从传递数量上看,仅比电报强一点点。

当时还没有JavaScript,用的是纯静态的页面。

1993年,CGI(Common Gateway Interface)出现了,人们可以在后端动态生成页面。

Perl由于跨操作系统和易于修改的特性成为CGI的主要编写语言。当然,CGI也支持其他支持标准输入输出和环境变量的语言编写,比如Shell脚本、C/C++语言,只要符合接口标准即可。

但显然,页面的内容更新完全由后端生成,这带来一个明显的缺憾:每次更新都要整页刷新,加上早期的网速情况,这个操作是非常慢的。因此针对这情况,人们从多方面着手改进:编写语言的升级、浏览器的升级、HTML的升级。

1994年,网景公司成立,发布了第一款商业浏览器Navigator。自从这款浏览器面世后,微软推出IE浏览器。虽说有竞争才有发展,但这也埋下了JavaScript分裂的种子。

▲ 1994 年,网景浏览器的截图

同年,PHP诞生。PHP能将动态的内容嵌入到HTML中,提升了编写页面的效率与可读性,其性能也比一般的CGI高。PHP的界定符、循环语句等的发明,深刻影响了后来的ASP、JSP,乃致后来的JavaScript前端模板引擎。

1994年10月,W3C小组也成立了,他们负责HTML的发展路径,其宗旨是通过促进通用协议的发展。

待这一切就绪后, JavaScript于1995年诞生了。

传闻,网景工程师布兰登·艾克(Brendan Eich)只花了10天时间设计出 JavaScript 语言,近乎上帝七日创造世界那么高效。但也因为工期太短的缘故,导致许多瑕疵,因此一直被正统程序员所嫌弃,直到Ajax的出世,才让人们找到理由忍受它的畸形。早期的浏览器都配有一个选项,用来禁止JavaScript语言运行。

兰登·艾克(Brendan Eich):

艾奇不仅是Mozilla的联合创始人,还是JavaScript技术的创始人。自1998年起,他开始深度参与Mozilla各方面的发展工作,包括Firefox浏览器和Thunderbird的研发。2005年,艾奇被任命为Mozilla公司的首席技术官。

JavaScript主要语言特征:

1)借鉴C语言的基本语法;

2)借鉴Java语言的数据类型和内存管理;

3)借鉴Scheme语言,将函数提升到"第一等公民"(first-class citizen)的地位;

4)借鉴Self语言,使用基于原型(Prototype)的继承机制。

时下,静态语言大行其道,类与接口被证明是构建大工程的最佳实践,人们想不出没有类的语言如何编写业务。因此当时的微软也打造了另一门运行于浏览器的语言——VBScript。

如果继续细探JavaScript的能力,你会发现它早期真的非常空洞,一门没有灵魂的语言,没有包管理机制,也没有像Java与C++那样的打辅助用的SDK,内置的方法也屈指可数。比如说数组方法,早期只有push、pop、shift、unshift、splice、slice、sort、reverse、concat、join等操作。动态调用方面,Function的apply、call操作还没有出现! 

早年的偷懒,导致后来不得不补课:到了2019年,数组上的原型方法,是原来3倍。

除了方法缺乏,还有性能问题,大家讨论用eval还是Function,用哪种循环方式,用parseInit还是~~,就是为了那一点点的性能提升。例如jsperf.com,就是一个专门研究JavaScript性能的网站。

因此JavaScript诞生后,其两大任务就是完善语言特性与提高性能。这两座大山分别由著名的prototype.js与jQuery来搬掉。

在搬掉之前,前端界还有一个曲折实践——第一次浏览器战争,并由其发展而来UA嗅深技术。

4、浏览器战争(1994~2005年)

浏览器战争一共打了三场,IE浏览器vs网景浏览器、IE浏览vs火狐浏览器、IE浏览器vs谷歌浏览器。

第一场浏览器之战打得尤其激烈。

微软的IE浏览器发布于1994年,但此时的网景已经占领绝对优势。微软在落后的情况,反编译Netscape的源码,推出IE与JScript。但是由于Bug非常多,大家不愿意为IE开发网站,因此发掘出UA,专门过滤掉IE浏览器。

UA即Navigator.userAgent ,是用一个字符串来记录用户当前运行在什么操作系统与浏览器中。

当时IE3的UA是这样的:

Mozilla/2.0 (compatible; MSIE 3.02; Windows 95)

程序判断UA信息,假如发现当前运行的环境是IE浏览器的话,就提示用户用网景浏览器打开。因此微软不得不让自己的UA尽量伪装成网景的UA,欺骗用于检测UA的脚本,达到IE浏览器可以跑这些网站的目的。

最终,第一次浏览器之战以微软胜利,Netscape被美国在线收购,而落下帷幕。

第一次浏览器战争年代非常久远了,但其结局告诉我们,其实技术强弱并不重要。那时技术保护并没有这么重视,否则微软的行为可能会被告(谷歌的openSDK仅抄袭几十行代码,被Oracle公司诉讼赔88亿)。

第一次浏览器战争带来了一个问题:尽管当时有ECMA-262(JavaScript规范文档)与W3C(HTML与CSS的规范文档),微软却没有照规范来实现JavaScript、HTML与CSS,导致前端兼容问题的诞生。所以CSS Hack、浏览器判定、特性侦测,这些技术就应运而生。

这个时代最著名的人物是Dean Edwrad,他是最早的近乎完美解决事件绑定的兼容性大神,其addEvent()内置于jQuery最早的版本中。jQuery的作者John Resig看到其超强的技艺,最后放弃推出大而全的框架,专攻选择器引擎。

John Resig:

John Resig是jQuery的创始人和技术领袖,目前在Mozilla担任JavaScript工具开发工程师。著有《Pro JavaScript Techniques》(即《精通JavaScript》)等经典JavaScript书籍。

Dean Edwrad的IE7.js、IE8.js是早期处理浏览器兼容的良药,可以说是一切Polyfill的起源。他写了大量的Hack, 比如在IE如何测量元素的宽高,许多操作DOM的兼容。

这时期太早,中国基本没有参与这次浏览器战争。

5、Prototype时期(2005~2009年)

Prototype是Sam Stephenson写的一个非常优雅的JavaScript基础类库。他是Ruby的大牛,因此Prototype的许多方法名都是来自Ruby界。

Sam Stephenson最大的贡献是发掘了Prototype与创造了Function.prototype.bind,在数组上也写了一大堆方法,其中许多被标准化了。

同期的MooTools也是Prototype挂方法,当时,大家还在前端论坛为这个争吵。还有前端工程师喜欢在当时很出名的前端聚集地——蓝色理想(现沦为设计师网站)上,讨论如何扒脚本、分享弹层、日历等小组件的技术,这在当时已经是非常了不起的事。

Prototype当时还解决两大问题:动画特效与Ajax请求。动画特效是由Scriptaculous提供,我们现在所熟知的各种缓动函数,各种特效的命名与大致的运行形态,都是由Scriptaculous确定下来的。

在早期,谷歌就开始使用iframe实现页面刷新。

2005 年2月,杰西·詹姆士·贾瑞特(Jesse James Garrett)发表了一篇名为《Ajax:一种Web应用程序开发的新方法》的文章后,Ajax被挖掘出,大家才开始重视起这技术的应用。

杰西·詹姆士·贾瑞特(Jesse James Garrett):

杰西·詹姆士·贾瑞特是一名用户体验设计领域的设计师、网页体验设计公司Adaptive Path的创办人,是AJAX技术术语的命名者。

例如IE下的ActiveXObject("Microsoft.XMLHTTP"),这是IE创建Ajax引擎的。假如当时有工程师开发出一个核心库,如果不包含Ajax的封装,便不好意思发布出来。

▲ 一些Ajax书藉

当时前端开发模式是选择一个核心库,找一些组件,或者扒别人的脚本进行开发。

Prototype的源码挺好理解的,代码量也少,只有5000多行,里面的每个方法也很易扒出来,因此一些大公司总有高手能创造自己的Prototype。

但前端开发还是离不开后端,因为前端没有模块机制,当时我们需要用PHP进行打包。

打包是雅虎34条军规之一,可以减少请求数。打包的同时也可以进行混淆,防止代码小偷来窥探。

N年前,前端面试必问的题目:

▲ 模块化的雏型, 在注释中标注它的依赖

这个时期,还没有前后端分离,可国内一些带着深厚后端背景的高手已经入场。

6、jQuery 时期(2009~2012年)

2006年,jQuery发布,它当时的竞争对手很多:Dojo、Prototype、ExtJS、MooTools。

所以那时jQuery的宣传口号仅能说是它的性能上升了100%、200%、300%。直到2009年,Sizzle选择器引擎研发成功,jQuery才取得压倒性的优势。

当时前端界首要面对的是浏览器兼容性问题,jQuery在处理DOM兼容上真是知微见著, 发掘出大量的DOM/BOM兼容方案(例如Dean Edwrad的addEvent(), IE的px转换方案,domReady的doScroll方案,globalEval的兼容方案等)

jQuery也打破了前端开发者的编程思维,之前是按照后端的开发思路来的:做一个业务就先封装一个类,有了这个类后,再想办法传入一个DOM,然后再通过类方法操作DOM。而jQuery是DOM为中心,开发者可以选一个或多个DOM,变成jQuery对象,然后进行链式操作。当时为了改变用户的思维,国内的高手写了不少文章来引导大家。

其次,开发者们已开始注重前后端分离,并要求不能污染Object原型对象,不能污染window全局变量。这样,jQuery只占用两个全局变量。

再次,jQuery非常轻量级,采用Dean Edwards编写的Packer压缩后, 大小不到30KB。并且里面实现得非常精妙,以令人瞠目的手段解决各种兼容痼疾。

为了学习这些技巧,高手们翻了一遍遍jQuery的源码,所以网上有大量关于其源码详解的书藉。甚至前端工程师在面试时也会被考到jQuery的源码实现,这样,jQuery在国内更加流行。

jQuery的流行间接带来以下的发展:

1)促使人们对CSS1~CSS3选择器的学习;

2)促进了浏览器原生选择器引擎document.querySelectorAll、Element.matches的诞生;

3)提高人们对domReady(DOMContentLoaded事件)的认识;

4)促进了Promise与requestAnimateFrame 的诞生;

5)最重要的是降低前端门槛,让更多人进入这行业,前端工程师的队伍越来越壮大。

这样的话,不断涌现出优秀的工程师,他们创造了大量jQuery插件与UI库。为后jQuery时代,人们研发前端模块加载、统一异步机制、 打造大型MVC框架, 甚至伸向后端,接管打包脚本而发明Node.js,来腾出大量时间。

这个时期涌现了大量jQuery-like的库,其中最著名的是Zepto.js。Zepto的出现也标志着我们进入移动互联网时代。那时配套出的著名库还有iScroll、fastclick、Lazy Load、Modernizr、fullPage。

jQuery的链式操作风靡一时,也带来许多问题,当Ajax出现依赖时,就不可避免就出现回调地狱。因此针对这方面的讨论,诞生Deffered与Promise。有关回调地狱的讨论,在后来讲Node.js异步处理时,将会再一次热烈地讨论。因此太阳下没有新事,我们总是遇到相似的问题。

jQuery如此多的选择器也法维护,随着越来越多人涌现这行业,页面的交互也越来越复杂,从Web Page向Web App进化,新的趋势带来新的开发方式。

7、后jQuery时期(2012~2016年)

这时期以RequireJS的诞生为起点,以RN的出现结束。同时解决了前端的模块定义问题,模块打包问题(通过Node.js),JavaScript不依靠其他语言创造了一套自己的工具链。

jQuery的出现让前端工程师开发更加轻松,假如工程师想实现一个功能,现搜索出一个jQuery插件来实现。那时候大家在前端网站就整天介绍jQuery插件,很少讨论一些底层的实现。

前端工程师通常编写一个页面,会引入十多个乃至几十个jQuery插件,页面上塞满了Script标签。众所周知,浏览器是单线程,Script的加载,会影响到页面的解析与呈现,导致著名的白屏问题(当时前端用力过猛,body中的所有东西都是动态生成的)。

jQuery另一个问题是全局污染,由于插件的质量问题,或者开发的素质问题,这已经是IIEF模块或命名空间等传统手段无法解决了。

于是一些优秀的前端工程师们决定向后端取经,引入模块机制。早期,这种模块机制在Dojo、EXT这些框架中都是内置的,但是显然说服不了另一个框架的用户用对方的模块机制,于是有人立志要统一这种模块定义方式,成立了CommonJS。

但不料,CommonJS内部也有派系,谁也说不服对方。终于有一个人忍不住自己独立开发出RequireJS,其模块规范即为AMD。AMD最大的优势是它支持各种插件,且简单明了,并且提供shim机制加载以非AMD规范编写的JavaScript代码。

但在CommonJS诞生很久一段时间后,在后端的Node.js出现时才有用武之地。而国内,则流行另一种规范风格,背靠阿里的大旗,有人推出了SeaJS,号称其规范为CMD。其实无论国内还是国外,都产生许多模块加载器,但最后还是被淘汰了,规范一个就够了,不宜过多。

但是前端工程师的创造力就是这么惊人,从无到有,再到泛滥成灾,一年足矣。这可能与前端代码是开源的原因。最后有人统一了前两种规范(AMD、Node.js模块),同时还支持老式的“全局”变量规范。

自此,JavaScript开发模式焕然一身了,大家只要在代码外面包一层就可以全世界通用,不用担心全局污染的问题。

其次,jQuery开发者需要解决大段HTML的生成问题,之前jQuery有$.html, $.append, $before等方法,可以将一大段符合HTML结构的字符串转换成DOM再插入到页面上。

但现在我们想分离出来,让HTML独立到不同的文件中,然后插数据,这就是前端模板。前端模板的情况与模板规范一样,从没有到多如芝麻的境地。这时筛选一个好用且性能高的模板是一件让前端工程师头疼的问题,那时网上有许多评测文章来介绍它们。

前端模板技术可以用一个公式来描述:

HTML = template(vars)

有了前端模板后,又诞生了前端路由,基于它们,人们发明一个新词汇SPA。作为这个时代的尾声,来自Ruby界的高手Ryan Dahl发明了Node.js。前端工程师们欢呼:可以不用传统的后端就能自己写一个网站了!

▲ Node 之父 Ryan Dahl

Node.js的发展就不详述上,很快它就冒出海量模块、路由、状态管理、数据库、MVC框架都有了。这时,前端就缺自己的MVC框架了。Node.js转眼就十岁生日了。

著名的MEAN架构,是JavaScript全栈开发的先锋。当时涌现了大量的MVC与MVVM框架。最先火起来的是Backbone.js,使用纯正的MVC模型, Backbone.js是jQuery最后的支持者,它强依赖于jQuery。

Backbone.js的作者还搞了另一套编译语言CoffeeScript, 里面的箭头函数、类机制、 解构赋值等语法糖都深深影响了后来的ES6。

接着下来是谷歌的Angular,微软的Knockout.js,苹果的Ember.js这三个MVVM框架,MVVM就是比MVC多一个数据绑定功能,但这数据绑定功能是非常难实现。Knockout是使用函数代替属性的技巧实现,它的设计影响到后来的Mobx;Ember.js是基于Object.defineProperty;Angular是将函数体转译成setter()、getter()函数。

大公司的介入,对个人开发者影响是很大,毕竟大家都爱迷信大公司,因此局面一下子就稳定下来。大公司还带来了全新的开发模式,早期都是找一个核心库,再搜刮一大堆插件,然后自己写业务代码,最后后端打包。

大公司将后端开发经验挪用过来,用Node.js开发了一套CLI,里面包含了脚手架生成, 打包脚本、语法风格检测、环境变量插入,代码复杂度检测,代码提交时自动跑单元测试, 图片与JS压缩等功能。ESLint、JSLint、JSHint、CSS Lint、 htmllint等就是那时期出现的。

但CLI的出现导致了前端的分裂,以前大家都使用jQuery,但自CLI帮你建好项目的那一刻起,就将你划归某一子阵营,你是Angular?Ember.js?还是jQuery?对了,jQuery没有大公司支撑的阵营被快速边缘化。

对于个人开发者,他们是没有能力开发这么功能完备的CLI,于是出现了Code Climate、Travis CI、CircleCI这样的平台。它们的出现标志着jQuery小作坊时代的终结了。

▲ CircleCI官网

前端开发者也出现分化:有些人转向后端,出现了CNode的门户网站。另外一些人开始搞工程化。一时间出现上百种构建工具,出名的有Grunt、Gulp、FIS3、webpack、 Rollup、npm-script。 

你方唱罢我登场,这些构建工具均会经历时代的考验,如大浪淘沙般,最后存活得仅为寥寥。

因此在这场工程化的盛宴中,注定把许多低层次的jQueryer淘汰掉。jQueryer在空闲之余培育出的前端模板、前端路由、MVC框架、模块加载器、Node.js构建工具,却不料最终成为它自己的挖墓人。

jQuery的时代一去不返了,再没有人关心拖了N年的Bootstrap 4终于发布了,没有人知道jQuery3.5的瘦身计划,也没有人问jQuery的源码,渐渐地,大家不关注jQuery的工具链了。

8、三大框架割据时代(2016~至今)

React是突然爆发的,虽然它是与Angular是同时期发布,但因为JSX怪异的语法让人们远离它。此时已经进入移动互联网的中期,大公司都有自己的App,或者基于原生,或者基于Hybird(详见:《盘点主流移动端跨平台UI技术:实现原理、技术优劣、横向对比等》、《最火移动端跨平台方案盘点:React Native、weex、Flutter》)。

Hybird是用WebView加载一个网站或一个SPA。

由于原生成本太贵,需要招两套班子,一套安卓的,一套iOS的;而Hybird则一直存在性能问题。于是在2017年,Facebook推出了React Native(RN)。

RN的性能不比原生差多少,比Hybird能好些, 其次使用JSX开发界面比原生的快;RN 只需要低成本的前端开发人员就能上手了。中国国内经过瀑布流(图片导购)、团购、P2P、区块链等全新商业模式的开发浪潮后,前端人员数量大增。现在,他们只要稍微培训就可以转型为App开发。

在开发RN的过程中,人们开始了解React一系列的优胜之处。比如JSX背后的虚拟DOM技术,虽然事实证明虚拟DOM不会带来性能的巨大优势,但保证了你怎么写其性能不会太差。

React为了引入JSX,必须需要引入编译,这又间接促成Babel与webpack的壮大。尤其是Babel, 让我们在很旧的浏览器中使用非常新的语法,甚至一些还没有定案的语法。React从14升级到React 15,强制使用class语法,让这个推了好久的语法糖终于大规模落地。

之前如果JavaScript想使用类,只能自己模拟类,由于没有官方的实现,只能任由各优秀工程师发挥。而普通人想用好类,需要了解很复杂的Prototype机制。 

现在只用几个新关键字就可以得到这一切。

如果对比Python 2与Python 3间的升级,JavaScript实在太辛运了!针对CSS逻辑功能过弱的问题,我们也有了新的解决方案:Less、Sass、PostCSS与CSS Modules!

谷歌在发布Angular的同时,也发布了一个叫Polymer的框架,那时它想推广一种叫Web Components的浏览器自定义组件技术。这其实是微软在IE5就玩剩的HTC技术的升级版。虽然它没有火起来,但它将Script、Style、Template三种内容混在一个文件的设计,启发一个留美华人,再结合当时的Backbone.js、Angular等设计,Vue.js横空出世。目前,这是国人最成功的前端框架了。

尤雨溪:

尤雨溪是Vue.js框架的作者,HTML5版Clear的打造人。尤雨溪毕业于上海复旦附中,在美国完成大学学业,本科毕业于Colgate University,后在Parsons设计学院获得Design & Technology艺术硕士学位,现任职于纽约Google Creative Lab。

除此之外,国人也弄了好几套迷你React框架与迷你Vue框架。这有点像jQuery时代,大家疯狂做迷你jQuery框架一样。

总的来说,最有创造力的是React团队,做出状态管理器、CSS-in-JS、Flow静态类型检查、devTool、Fetch、前后端同构、Fiber、suspend、并发渲染等名词层出不穷。其中,状态管理器拥有上百套, CSS-in-JS也拥有上百套,Flow则让前端尝鲜到接口编程的好处,间接推动TypeScript发展。这三大框架无法比拼个一二出来:Vue.js有国人的拥趸,React与Angular有大公司光环。

三大框架的缠斗从PC领域扩展到移动端:React有RN, Vue.js有Weex,Angular有ionic。想当年我们为了兼容浏览器,攒了一大堆浏览器侦探的Hack,全部贬值为垃圾了。

在这时期,一种全新的后端渲染崛起,称之为前后同构,既拥有早期SEO的功效,又能复用大量的业务逻辑。随着国内移动互联网的发展,获客成本提高,各种有效的商业模式都进入红海,但只有头部用户能赚到钱,马太效应越来越严重,纯粹的技术解决方案已经无法满足商业诉求了。

9、小程序时代(2017~至今)

小程序时代与三大框架的时代几乎重合,但是出自不同一批人,决战的平台也不一样。

一直以来前端技术都是由国外开发者主导的,即便是Vue.js也是由美国的华人创造的。但是国内外的技术更新是存在代差,国内通常延期两三年,这个时间差可以让一些模仿者得以生存(如SeaJS、FIS、avalon)。但随着封闭的时间越来越长,国内肯定也会诞生自己的专有物种。小程序就是其中之一。

小程序的出现有着明显的商业诉求,因为马太效应,一些超大流量的App诞生了。这些大流量App集成了许多功能,但显然公司再多员工,也无法所有功能全是自己弄,于是产生小程序这种“外包”的手段。

小程序是国内前端技术的一次厚积薄发:底层运行的迷你React的虚拟DOM, 内置组件是使用Web Component,API来源于Hybird的桥方法,打包使用webpack,调试台是Chrome console的简化版, WXML、WXSS的语法高亮也应该是webpack或VS Code的插件, 模块机制是Node.js的CommonJS……其中最值得一提的是微信开发者工具,以后开发者工具成了各种小程序/快应用的标配。

但微信小程序一开始的复用能力非常弱,没有类继承,不能使用npm, 不支持Less、Sass, 因此基于它的转译框架就应运而生。第一代转译框架是wept、WePY、mpvue,它们无一例外是Vue风格的。因为WXML的模板指令与Vue非常相似,只是改一下就能兼容。当时也出现了一个MINA的框架,听说是微信团队开发的,可以单独架起Node.js后端,让小程序运于浏览器中,方便做单元测试。

第一代转译框架主要是基于Template标签实现组件机制,自定义组件机制是以后的事了。这就造成了利用第一代转译框架编写的小程序项目很难升级。那时候是个人开发者的天堂,这些框架都是某一大牛独力开发的。

第二代转译框架是大公司主导的,因为需要兼容的小程序越来越多,百度、支付宝、字节跳动、小米、华为等公司都推出自己的小程序和快应用。个人开发者很难凭个人力量去开发转译框架,这时候各大团队纷纷推出自己的轮子:如京东的Taro、滴滴的Chameleon、网易的Megalo、去哪儿网的nanachi、百度的Okam等。

在这个时期,Angular显然落伍了,一是Angular升级太快,国内的高手还没有消化好,新一版的Angular又发布了。二是国内缺乏迷你Angular的轮子,导致庞大的Angular无法塞进小程序中。

国外谷歌发布了Flutter跨平台转译框架,但是它的编写语言是Dart,它也无法跨界到小程序中。

未来不仅国内一线巨头争夺小程序,二三线的巨头也可能会加入小程序的混战中,例如有人称360也在打造自己的小程序平台。小程序这种新的流量变现模式深刻地影响了国内的互联网布局。

10、结束语

当初JavaScript被误解为最糟糕的语言,时至今日它是最流行的语言:GitHub 60%的开源项目都是与JavaScript有关。

以前,从事这行业的人被称为页面仔,现在他们的起薪有的比PHP、JAVA、C++等后端还高。甚至有人说,“任何可以使用JavaScript来编写的应用,最终会由JavaScript编写。”

我们前端开发者触及的领域不仅仅是浏览器,还可以做后端,做桌面端,做手机端,做小程序端,前端开发者的性价比越来越高,越来越重要。可谓是时代造英雄。

笔者有幸成为前端开发者大队伍中的一员,也坚信我们前端开发者以后的路会越来越宽,越来越好走。

附录:有关Web即时通讯技术的文章

Web即时通讯新手入门贴:
《新手入门贴:详解Web端即时通讯技术的原理》

Web端即时通讯技术盘点请参见:
《Web端即时通讯技术盘点:短轮询、Comet、Websocket、SSE》

关于Ajax短轮询:
找这方面的资料没什么意义,除非忽悠客户,否则请考虑其它3种方案即可。

有关Comet技术的详细介绍请参见:


更多WebSocket的详细介绍请参见:


有关SSE的详细介绍文章请参见:
《SSE技术详解:一种全新的HTML5服务器推送事件技术》

更多WEB即时通讯文章请见:
http://www.52im.net/forum.php?mod=collection&action=view&ctid=15

(本文同步发布于:http://www.52im.net/thread-2719-1-1.html)

相关推荐

鸿蒙原生即时通讯/IM系统RainbowTalk v2.8版发布,基于MobileIMSDK框架、ArkTS编写

💧 此版本解决了若干bug,以及ui和功能细节优化,同时支持最新鸿蒙7.0系统。

hellojackjiang2011的博客 163

深度剖析IM消息乱序的根本原因及优化方法

本文深度剖析即时通讯IM消息乱序的问题,梳理IM客户端时间戳不可信、多端并发、群消息扇出重试三大核心陷阱,拆解微信、钉钉、企业微信的时序设计方案,并从锚点设计、多端去交错、幂等兜底、可观测性等维度,给出IM项目消息时序性保证的落地优化策略。

hellojackjiang2011的博客 293

IM聊天不掉线?生产级WebSocket断线重连、心跳保活实战

本文将给出一套生产级Web端即时通信方案,包括心跳检测保活 + 指数退避重连,代码直接能跑。

hellojackjiang2011的博客 315

IM全文检索技术(五):vivo敏感词匹配系统的技术实践

本文将从算法选型入手,结合两个实际场景来介绍谛听系统的敏感词匹配算法。包括底层算法选型思路和两种实际场景下提升敏感词精准度、降低漏杀率的方案。

hellojackjiang2011的博客 189

Nginx生产级WebSocket实时长连接负载均衡,一文搞定

本文从基础配置、生产配置、Docker / K8s、安全、排障、性能调优,系统性讲清 WebSocket 在 Nginx 中的正确打开方式。

hellojackjiang2011的博客 308

即时通讯IM离线消息该怎么存?全面盘点主流存储方案

离线消息是IM系统的核心能力,当用户不在线时,消息必须可靠存储,待用户上线后完整推送。本文将对比主流的离线消息存储方案,帮你找到最适合业务场景的架构。

hellojackjiang2011的博客 310

移动端实时音视频聊天框架 RainbowAV v2.2.7发布

1)

hellojackjiang2011的博客 247

都HTML5了,Web端即时通讯技术到底该用什么?一文即懂!

本文分享的是 Web 端最常用即时通讯技术(包括 WebSocket、SSE、WebRTC、轮询等)的原理、优缺点与适用场景等,以及生产环境下的高并发场景下的进阶实践。

hellojackjiang2011的博客 341

基于开源MobileIMSDK框架,即时通讯IM产品RainbowChat v12.1发布

此版本新增了短信验证码的注册和登录功能,解决了Android 16手机上发送文件失败等问题。

hellojackjiang2011的博客 209

IM千人群聊该不该用消息写扩散?详细算算成本账!

本文将为你详解 IM 群聊消息的写扩散技术原理以及写扩散过程中的服务端详细性能成本,同时对比了市面上IM大厂的技术方案,给出分规模架构选型与以及性能优化策略等。

hellojackjiang2011的博客 402

直播系统聊天技术(十):基于实时消息总线的活动系统架构设计

本文分享的是网易云音乐技术团队基于实时消息总线技术,解决了直播活动系统的模块灵活组合、消息治理与异步履约等问题,希望能给你带来启发。

hellojackjiang2011的博客 369

轻量级Web端IM即时通讯框架MobileIMSDK-Web,基于Socket.io库

MobileIMSDK-Web是一套Web端即时通讯框架,超轻量级、极少依赖,高度提炼、简单易用。

hellojackjiang2011的博客 286

socket长连接在手游场景下的技术实践

本文介绍了37手游基于B站goim框架自研长连接系统的实践。系统采用分层设计,支持多协议和发布/订阅机制,用于直播弹幕、实时推送等场景,实现了高性能与业务适配。

hellojackjiang2011的博客 403

基于开源MobileIMSDK框架,即时通讯IM产品RainbowChat v12.0发布

RainbowChat 是一套基于 MobileIMSDK 开源通信框架的产品级移动端IM系统。可能是市面上开放源码的,唯一一款同时支持TCP、UDP、WebSocket三种网络通信协议的IM产品。

hellojackjiang2011的博客 518

社交场景下的统一即时通讯im消息流交互层模块化技术实践

这些IM场景,在消息流的展示形式上是极为相似的,同时每个业务又有着自己特殊的交互需求。基于此,我们对IM消息流能力做了标准化的构建,来减少IM功能的业务接入成本;同时也是为了统一各个业务的技术方案,减少跨业务开发的理解和维护成本。

hellojackjiang2011的博客 571

现代IM系统中聊天消息的同步和存储方案探讨

本文内容主要涉及IM系统中的消息系统架构,探讨一种适用于大用户量的消息同步以及存储系统的架构实现,能够支持消息系统中的高级特性“多端同步”以及“消息漫游”。在性能和规模上,能够做到全量消息云端存储,百万TPS以及毫秒级延迟的消息同步能力。

hellojackjiang2011的博客 75

即时通讯安全篇(十六):对称加密 vs 非对称加密?一文搞懂

本文将以通俗案例讲解加密本质,介绍对称加密(含 AES、迪菲–赫尔曼密钥交换)与非对称加密(RSA)原理、特点及应用,并阐释其数学基础。

hellojackjiang2011的博客 397

网络编程入门如此简单(五):UDP跟TCP相比,到底差了什么?

本文将通俗易懂地为你类比解释UDP与TCP的核心差异,包括如何基于UDP实现TCP的可靠传输:通过模拟三次握手、添加序列号与确认机制解决顺序和丢包问题,利用滑动窗口控制流量,并引入拥塞控制算法来动态调整发送速率等。

hellojackjiang2011的博客 448

基于WebSocket的IM即时通信方案在H5游戏场景下的技术实践

本文将从H5游戏场景下的实时信息更新需求切入,探讨下在类似这种高并发、低延迟的业务需求中,如何使用 IM 方案来解决频繁的数据更新问题,也顺便介绍下 WebSocket 的基本运作流程等。

hellojackjiang2011的博客 1069

鸿蒙Next原生IM即时通讯RainbowTalk,纯ArkTS编写,基于开源MobileIMSDK框架

RainbowTalk 是一套基于 MobileIMSDK 开源通信框架的产品级纯血鸿蒙NEXT端IM系统。RainbowTalk 由纯ArkTS编写、全新开发,没有套壳、也没走捷径,原生“纯血”。

hellojackjiang2011的博客 1227

如何保障分布式IM聊天系统的消息可靠性(即消息不丢)

本文主要聚焦分布式IM聊天系统消息可靠性问题,即如何保证消息不丢失。

hellojackjiang2011的博客 732

如何保障分布式IM聊天系统的消息有序性(即消息不乱)

本篇主要总结和分享分布式IM聊天系统架构中关于消息有序性的设计和实践。

hellojackjiang2011的博客 835

B站即时通讯IM消息系统的新架构升级实践

本文要分享的是B站IM消息系统的新架构升级实践总结,内容包括原架构的问题分析,新架构的整体设计以及具体的升级实现等。

hellojackjiang2011的博客 714

AI大模型爆火的SSE技术到底是什么?万字长文,一篇读懂SSE!

本文从SSE(Server-Sent Events)技术的原理到示例代码,为你通俗易懂的讲解SSE技术的方方面面。

hellojackjiang2011的博客 786

腾讯新闻APP的消息推送Push架构技术重构实践

本文主要分享的是腾讯技术团队近年来对腾讯新闻消息推送PUSH系统做的架构优化和技术实践。

hellojackjiang2011的博客 843

移动端弱网优化专题(十五):字节跳动移动端网络HttpDNS优化实践

本文要分享的是字节跳动团队针对火山HTTPDNS Cache2.0通过自研网段库与动态划分算法,将缓存粒度从“城市-运营商”细化为“网段”,解决了传统方案的城市级调度污染问题。配合缓存分级、预取等优化,在提升调度精准度的同时保证了高命中率,最终实现了服务端调度准确性提升和客户端性能优化。

hellojackjiang2011的博客 720

转转客服IM聊天系统背后的技术挑战和实践分享

在当今互联网时代,高效的用户服务是提升用户体验的关键。转转自研的客服IM聊天系统作为用户与客服沟通的桥梁,承担着传递信息、解决问题的关键角色。然而,消息数据的流转并非一帆风顺,本文将深入探讨IM系统在消息传递过程中遇到的问题和挑战,以及相应的技术解决方案。

hellojackjiang2011的博客 1096

ChatGPT如何实现聊天一样的实时交互?快速读懂SSE实时“推”技术

本文将带你快速认识SSE实时通信协议,包括它的技术原理、常见使用场景、与同类技术的对比以及简单的示例代码等。

hellojackjiang2011的博客 124

全面适配iOS 26液态玻璃,基于开源IM即时通讯框架MobileIMSDK:RainbowChat-iOS端v10.2发布

RainbowChat是一套基于开源IM即时通讯聊天框架 MobileIMSDK 的产品级移动端IM系统。

hellojackjiang2011的博客 1157

可靠传输的TCP协议send成功就意味着数据一定发出去了?

本篇文章我们以TCP协议的网络编程逻辑,从Socket缓冲区的角度去拆解,为什么号称可靠传输的TCP协议,在代码中调用send并成功发出数据,并不意味着这个数据就一定通过物理网络发出去了。

hellojackjiang2011的博客 125
上一篇: 网易云信技术分享:IM中的万人群聊技术方案实践总结
下一篇: 一文读懂前端技术演进:盘点Web前端20年的技术变迁史
jackjiang2025
jackjiang2025 网际时代技术分享账号 网际时代技术分享账号
博客等级 码龄8年 700粉丝 318原创
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值