JavaScript框架发展的四个时代,你经历过其中几个阶段?( 二 )


在这之前 , 最先进的是jQuery、MooTools等库 。 这些库在他们的时代是非常重要的 , 它们帮助消除浏览器实现JavaScript方式之间的差异 , 这些差异非常重要 。 例如 , IE实现事件的方式与Netscape(网景浏览器)完全不同 , 其方式分别为事件冒泡与事件捕获 。 这就是为什么我们今天的标准最终实现了这两种方式的原因 , 但在这之前 , 你需要使用库来编写能在两种浏览器上使用的代码 。 这些库主要用于制作小型的、独立的用户界面部件 。 大多数应用程序的业务逻辑仍然是通过表单和标准的HTTP请求进行的 , 即在服务器上渲染HTML并将其提供给客户端 。
在这个时代 , 也没有很多构建工具可言(至少我了解到的没有) 。 当时的JavaScript还没有模块(至少没有标准的模块)功能 , 所以没有任何办法导入代码 。 所有的东西都是全局性的 , 要组织好这些东西是非常困难的 。
在这种环境下 , 可以理解JS通常被视为一种用来点缀的语言 , 而不是能用它来写一个完整的应用程序 。 那时开发者最常做的事情是使用jQuery , 为一些UI小部件编写一些脚本就可以了 。 随着时间的推移和XHR的引入及普及 , 开发者开始把他们的UI流程的一部分放到一个页面中 , 特别是对于需要在客户端和服务器之间进行多次来回交互的复杂流程 , 但应用程序的大部分内容还是留在服务器上 。
JavaScript框架发展的四个时代,你经历过其中几个阶段?
文章图片
这与移动应用开始出现时的情况形成了鲜明的对比 。 从一开始 , iOS和Android上的移动应用程序就是用Objective-C和Java等高级语言编写的完整应用 。 此外 , 它们是完全由API驱动——所有的UI逻辑都存在设备上 , 而与服务器的通信则纯粹是以数据形式进行 。 这带来了更好的用户体验和移动应用程序的爆炸性增长 , 直接导致了我们今天关于移动设备和Web网络哪个更好的争论 。
最初 , 用JavaScript来做所有这些事 , 被很多人认为是可笑的 。 但随着时间的推移 , 应用程序开始变得更加雄心勃勃 。 很多社交网络平台增加了聊天、DM和其他实时功能 , Gmail和GoogleDocs验证了在浏览器端也能实现与桌面一样的用户体验 , 越来越多的公司开始提供Web应用开发服务 , 因为在他们看来 , Web在任何地方都可以使用 , 而且更容易长期维护 。 这推动了Web整个行业的发展 。
很明显 , 现在JS可以用来编写更为复杂的应用程序 。 然而 , 当时环境下 , 想要实现这一点还是有些困难的 , 因为那时的JavaScript并不具备今天的所有功能 。 就像我说的 , 所有东西都是全局性的 , 你通常需要手动下载并将每个外部库添加到你的静态资产文件夹中 。 当时还没有NPM , 模块也不存在 , JS也没有今天一半的功能 。 在大多数情况下 , 每个应用程序都是需要定制的 , 每个页面都有不同的插件设置 , 每个插件都有不同的系统来管理状态和渲染更新 。 为了解决这些问题 , 最早的JavaScript框架出现了 。
第一代框架
在2000年代末和2010年代初 , 第一批专门用于编写完整客户端应用程序的JS框架开始出现 。 这个时代的几个著名的框架是:
Backbone.js
Angular1
Knockout.js
SproutCore
Ember.js
Meteor.js
当然 , 还有很多其他或是在某些圈子里更知名一些的框架 。 不过 , 以上这些是我记得的 , 我也常用它们来做原型或进行构建 。
这是第一代框架 , 也正式开启了未知领域的大门 。 一方面 , 这些框架试图做的事情是非常超前的 , 很多人认为它们不会真的成功 。 有许多反对者认为单页JS应用程序(SPA)从根本上来说很糟糕 , 而且后来在时间的验证过程中 , 证明了这些批判者在很多方面是对的 , 例如 , 客户端渲染意味着自动程序不能轻易抓取这些页面 , 而且用户甚至需要等待几秒钟才能开始绘制应用程序 。 很多这些应用程序都是噩梦般的存在 , 如果你关闭了JavaScript , 它们就根本无法工作 。