当我还是个孩子的时候，我的祖父曾经告诉我他的战时冒险。他曾在第一次世界大战和第二次世界大战中任职。他是一个boy of 1899。
我对故事的娱乐方面感兴趣，而没有理解它们背后的痛苦。坚持我的一件事是，他经常说两次战争是不同的。他们的战斗方式与人口的方式不同。

几年后，我发现对这两场不同的战争的想法不如我的祖父经历的那一场不那么悲惨：万维网 。

在我的职业生涯中，我很荣幸看到网络的诞生以及它从共享文档平台到运行分布式应用程序平台的发展。一路上，我目睹了一些战争。

我会尝试告诉你他们...好像我是你的祖父。
让自己感到舒适：不会很短。

以HTML为中心的时代

一开始，网络仅基于HTML和HTTP。没有什么比这更简单了：使用简单的标记语言描述了文档，并使用简单的协议从一台计算机传输到另一台计算机。 Berners-Lee的想法同时简单而革命性。关键原理是互操作性。让我们记住这个词。

我从90年代初开始探索网络，当时Mosaic是最先进的浏览器。在那些日子里，您必须很好地计划互联网之旅，以避免以基于时间的关税（至少在意大利）散发出自己的流血。对于开发人员而言，创建静态HTML页面并不令人兴奋。它不需要任何真正的编程技能。有趣的部分是通过光荣的CGI脚本在服务器上动态生成HTML。

一切都很清楚和定义。您在服务器端使用了哪种脚本都没关系：Perl脚本，Shell脚本，C程序。重要的是它的输出是HTML，并且通过HTTP传输。
未来看起来很光明。

第一次网络战争

然后，在1995年，JavaScript出现了，场景开始改变。网络客户端还需要开发技能。新浏览器出来了：Netscape Navigator和Internet Explorer。第一次战争开始：the browser war。

浏览器建筑商，基本上是Netscape和Microsoft，竞争提供越来越有吸引力的功能：支持animated GIFs，新的HTML标签（例如：marquee10，blink，blink，font），支持少量或不兼容的脚本语言（Javascriptian，JScript） ，VBScript），对applets的支持，Flash对象，ActiveX组件等。

这是新功能的连续爆炸，但仅由一个浏览器支持，从一个特定版本开始。有一种策略，后来被称为EEE，以击败具有不相容功能的竞争对手。

创建互动HTML页面是一场噩梦。如果您希望该页面可由尽可能多的用户使用，则必须考虑到浏览器支持哪些功能以及用户使用的版本。 Browser sniffing techniques出现了，必须保持最新状态，以免从您的网站上删除用户。要了解我的意思，请尝试看看some sample code from that era。

另一种方法是创建针对一个特定浏览器优化的网页：对开发人员来说更容易的解决方案，但对于用户来说是令人沮丧的解决方案。在整个网络上，您可以找到具有或多或少优雅贴纸的网站，邀请用户使用该网站的优化浏览器：

因此，在第一次网络战争中，我们在浏览器供应商之间进行了激烈的竞争，以提供越来越高级的网络体验。开发人员必须处理浏览器之间以及同一浏览器的不同版本之间的差异。许多人选择为特定浏览器优化其页面，这对遇到可访问性问题并被迫使用多个浏览器的用户感到恼火。

当时，对于开发人员和用户来说，网络不是一个好地方。也不是为了梦dream以求的互操作性。对网络的总体满意度可以总结如下：

标准的作用

在这一点上，您可能想知道标准在所有这些混乱中的作用。特别是W3C的作用呢？实际上，该财团负责定义Web技术的参考标准，主要是HTTP和HTML。但是当时，它的影响（和响应能力）对于像1990年代后期一样动态的网络不足。

通常，W3C的作用仅限于定义为已经接受的HTML特征的标准。例如，在IE成为标准之前，IE实际上引入了iframe，object和koude2。因此，这是一个后验标准化，对开发人员和用户都没有很多好处。

当ECMAScript规格于1997年发布时，事情开始发生变化。JavaScript和其他次要方言必须符合它，以确保浏览器之间的兼容性。但是，仅脚本标准化是不够的。同年，W3C定义了DOM Level 1，该DOM Level 1将浏览器互操作性沿正确的方向移动。但是我们必须等到2000年的DOM Level 2标准化，这稳定了Web开发中发生的混乱。

那一年，W3C走得更远。它定义了XHTML，这是基于XML标准的正式标准的HTML 4版本，但具有可扩展性的优势。任何人都可以通过提供适当的DTD或XML模式来扩展语言。该解决方案在技术上是合理的，但并未完全理解和认为太复杂。此外，XHTML与旧HTML缺乏向后兼容性引起了许多担忧。

这导致了W3C以外的一个新工作组WHATWG的成立，其目标是对HTML的重组，最终会导致HTML5。XHTML注定要在几年内死亡。

。

外部跑步的入侵

与所有战争一样，有些人变得贫穷和利用优势。
在浏览器战争和导致的互操作性缺乏时，许多开发人员转向替代技术。他们中的许多人转向Flash，Java，ActiveX和其他技术，这些技术提供了更多无缝开发和一致的用户体验。他们所需要的只是在用户的首选浏览器上安装运行时。

当时，使用HTML和JavaScript开发交互式和引人入胜的网页是一项艰巨的任务。替代技术（例如Flash）允许将应用程序在本地下载到浏览器，并且与服务器仅具有少量的交互以检索数据并更新用户界面，而无需重新加载整个页面。真正的革命！

与与Internet Explorer和Windows相关的ActiveX不同，Flash和Java applets无论用户的浏览器如何，都保证了一致的用户体验。

付费的价格是使用专有技术和some potential security risks that occasionally occurred。

网络作为标准和可互操作的环境开始破解。
浏览器供应商只是支持外部插件，以将应用程序执行委托给Flash＆Co。Runtimes。接受此Web编程模型的开发人员的优势是不必担心用户使用的浏览器。但是，从适当的意义上讲，他们不再是网络开发人员：他们放弃了实际的网络技术，专门用于开发一个或多个运行时间。用户可以使用他们选择的浏览器，但是他们必须安装并继续更新不同的运行时间。简而言之，针对特定浏览器进行优化的网站已成为针对特定运行时进行了优化的网站 - 毕竟没有太多的收益。

开发人员选择参考运行时非常舒适，但用户继续遭受安装不同的运行时间的困扰，同时保持浏览器的选择。总而言之，这是整体满意度：

以JavaScript为中心的时代

随着Ajax和Dynamic Dom的引入，JavaScript和标准Web技术具有赎回。由于当时称为Dynamic HTML（DHTML），网页的部分更新也成为了使用标准技术的现实。

JavaScript，HTML和CSS是Web的标准三合会。到2005年，JavaScript是先进的前端应用程序开发的真正驱动力。这是Flash，Java等专有解决方案的新竞争对手。

几年后，网络的后卫发生了历史性的改变：光荣的Netscape Navigator的继任者Netscape Communicator离开了现场。 Mozilla project从骨灰中诞生。该项目将诞生Firefox。同时Chrome诞生了。

这是一个新的网络时代的曙光。

网络是JavaScript

JavaScript的复兴以及使Web生态系统与专有技术具有竞争力的愿望，这对旨在简化DOM操作，与服务器的Ajax交互，并与CSS集成的图书馆的扩散有很大的动力。

。

。

2006年，jQuery诞生了，注定是网络上使用最广泛的图书馆。很快，MooTools，Backbone，Ember和其他人在那里与之竞争。

现在，开发人员拥有出色的盟友，可以创建动态而有吸引力的网络接口，而无需重新发明轮子。 JavaScript库的数量以前所未有的速度增长。 没有新的JavaScript图书馆出生。

没有一天过去了

生态系统是在其中一些库中创建的，即专门从事特定任务但基于特定核心库的库。例如，jQuery UI是一个用于构建Web接口的库，该库使用jQuery进行DOM操纵和其他低级任务。 Bootstrap也出生于基于jQuery的UI库。

这些图书馆使开发人员不得不直接与HTML和CSS合作以创建UI元素的负担。此外，他们还提供了处理不同浏览器之间标准支持的剩余差异的优势。与以前的网络时代相比，开发人员的生活大大简化了。 jQuery图书馆成为标准的一种，您可以到处找到它。如此之多，以至于许多初级开发人员很难将jQuery与JavaScript和DOM 区分开。许多人甚至都不知道dom是什么。对许多人来说，$()是一个JavaScript功能！

用户生活在那几年也变得更加容易。通常，浏览和与网页互动的经验非常一致。用户可以使用他们想要的任何浏览器，除了Internet Explorer 6和一些以后的版本。

到目前为止，Web前端应用程序主要是JavaScript应用程序。开发人员只需选择目标库生态系统并使用兼容的UI库即可。构建Web UI成为JavaScript代码的问题。 HTML只是将代码拉入浏览器的钩子。渲染是由基本库的DOM操纵动态执行的。您当时是Single-Page Applications时代。

很快来到了AngularJS和后来的React。此后不久，Vue到达了Web前端开发的新三合会。

另一个网络战争？

今天，我们可以说网络的大多数前端开发都是基于这三个生态系统：角，反应和vue 。我们可以说发生了一场战争吗？
如果我们将当前情况与第一次网络战争进行比较，我们不能说存在相同的冲突。通常，浏览器供应商正在确保对标准的一定程度的依从性，这些标准最终是主动的。用户的浏览体验并没有与当时相同的问题。
但是我们是否实现了我们梦dream以求的互操作性？

更仔细地看，那些在当前情况下缺乏互操作性的人是前端开发人员。在第一次战争中，他们曾经选择一个浏览器，并为其构建了为其优化的页面，以使网络开发更容易。现在，他们被迫选择一个JavaScript生态系统并为其构建对其进行优化的应用程序。当然，在用户方面，赢得了重大胜利。用户不在乎哪种JavaScript框架开发人员使用了哪些JavaScript框架。这很公平。

但是，开发人员无法在另一个JavaScript框架中重复其工作结果。 React组件只能在React应用程序中使用。如果您在Angular或Vue应用程序中需要相同的组件，则必须重新创建它。
简而言之，浏览器之间的战争现在是JavaScript框架之间的战争。也许有点安静，但不能免除偶尔的宗教战争。
当前情况可以总结如下：

返回网络平台（和平与爱）

当前的战争不像浏览器战争那样大声（相信我，这根本不是）。但这并不意味着这不是问题。在过去的几年中，我目睹了三个主要JavaScript框架之间的前端开发人员技能分歧。我还看到了基本的Web平台标准技能的损失。

似乎基本知识的总体丧失类似于JQuery成功后发生的事情。几个库简化了开发人员的寿命，并弥补了HTML，JavaScript，DOM等的缺点。但是与此同时，HTML已经发展，JavaScript已经发展，DOM已经发展，CSS已经进化了。

。

。

Web Components标准为我们提供了足够的基础架构，使网络成为前端开发的可互操作平台。有人批评这项技术过于低水平，但是有一些libraries使开发人员的生活更加轻松。

您可能会说这与JavaScript Frameworks是相同的恶性循环。这是错误的，因为Web组件通过设计可互操作。选择Stencil或Lit或任何其他图书馆都是开发方便的，与所得组件的互操作性无关。

我们真的想继续这场沉默的战争吗？将这些能量引导到一个标准的生态系统中，每个人都可以自由使用自己选择的工具来创建可以在网络上用作开发平台的组件，这不是更好吗？让我们将Web 从用于运行应用程序的平台转换为撰写应用程序的平台。让我们补充一下缺少的作品来恢复可互操作网络的原始梦想。

作为开发人员，下次您开始一个新项目问自己一个简单的问题：我真的需要JavaScript框架吗？
也许是时候给网络带来一些和平了。我的祖父（不仅是他）会很高兴。