javascript演变史_虚拟面板：用于HTML 5JavaScript框架的演变

javascript演变史

HTML 5是万维网核心语言的第五个主要修订版，由Web超文本应用程序技术工作组（WHATWG）于2004年提出。 尽管规范正在进行中，但HTML 5的某些部分已经在Safari 4 beta之类的浏览器中实现 。

除了指定标记外， HTML 5还公开了几个新的脚本API ：

在针对应用程序开发人员的新功能中，HTML 5引入了许多新的Javascript API。 这些可以与相应HTML元素结合使用，包括：

• 可以与新的canvas元素一起使用的2D绘图API，用于动态绘制图形，游戏图形或其他可视图像。
• 一种API，允许Web应用程序为某些协议或MIME类型注册自己。
• 引入了新的缓存机制以支持离线Web应用程序的API。
• 用于播放视频和音频的API，可与新的视频和音频元素一起使用。
• 历史记录API公开浏览历史记录，并允许将页面添加到其中，以促进AJAX应用程序中更好的后退按钮支持。
• 跨文档消息传递提供了一种手段，通过这种手段，文档可以在不考虑源域的情况下彼此进行通信，从而可以防止跨站点脚本攻击。
• 甲拖放API来组合使用具有一个可拖动的属性。
• 与新的全局contenteditable属性结合使用的编辑API。
• 一种新的网络API，使Web应用程序可以在局域网上相互通信，并保持与其原始服务器的双向通信。
• 客户端持久存储，带有用于键/值对JavaScript API，并支持嵌入式SQL数据库。
• 服务器发送的事件与新的事件源元素相结合，这将促进与远程数据源的持久连接，并在很大程度上消除了Web应用程序中轮询的需要。

InfoQ最近通过电子邮件举办了一个虚拟小组，讨论了JavaScript框架将如何发展以便利用这些新的API。 该小组的代表来自一些涉及客户端JavaScript的最广泛部署的项目：

• DyPen Schiemann ，SitePen首席执行官兼Dojo的共同创始人
• YUI工程团队Matt Sweeney和Eric Miraglia
• Prototype的核心开发人员Andrew Dupont
• Thomas Fuchs ， script.aculo.us的创建者， Prototype和Ruby on Rails的核心开发人员
• MooTools的核心开发人员David Walsh
• GWT首席开发人员Scott Blum和Joel Webber

在下面，您将找到所提出的问题和每个参与者的答案。

InfoQ：由于HTML 5仍在开发中，因此没有多少开发人员熟悉它带来的新功能。 您觉得Web开发人员最值得注意的功能是什么？

迪伦 ：HTML5是一个非常大的话题。 我们发现许多有价值的功能都是您在Dojo等工具包中已经发现的功能。 例如，具有本机实现的更丰富的表单控件有望实现，包括多个文件上传以及数据属性，因此人们不会抱怨使用允许但不纯的自定义HTML属性的Dojo。 彼得·希金斯（Peter Higgins）最近用1KB的代码编写了一个Dojo Parser补丁，以在浏览器添加该功能后支持该功能。 就是说，对我而言，最有趣的功能是WebSocket，它是由Michael Carter提出的，并由Orbited首先使用API​​垫片实现。 WebSocket对于Comet应用程序非常有用，并且可以认为是Web安全的TCP套接字。

Matt＆Eric： HTML 5包含了一些突破性的构建基块，供那些将浏览器视为应用程序画布的程序员使用，但这样做超出了文档语义的范畴，并扩展到了DOM API的范畴–这是DOM API的另一方面需要关注的生态系统，但不一定是HTML规范的一部分。 我们希望看到HTML 5规范仅限于文档语义的丰富和完善，同时让行为API可以由其他规范来处理。

通常，开发人员应注意HTML5提供的以下与HTML相关的功能：

• 弃用表示性元素和属性
• 更多语义元素
• 更多输入类型和语义
• 自定义数据属性

开发人员正在越来越多地关注HTML 5的DOM API方面，实际上，如果最终将其中一些加以编纂，它们将以重要的方式增加我们工具箱的深度。 浏览器制造商早日采用2D绘图API（通过Canvas元素）和客户端存储API已经引起了人们的极大兴趣，而这种兴趣与浏览器制造商直接相关，后者在规范制定之前就优先考虑了其实现最终确定。 但是，当前草案中提出了许多其他重要更改，包括：

• iframe沙箱
• “ getElementsByClassName（）”支持
• “ classList” API
• 音频/视频（通过音频/视频元素）API
• 离线网络应用程序API
• 编辑（通过contentEditable属性）API
• 跨文档消息传递API
• 服务器发送的事件API

HTML 5试图解决许多大问题，而且远远超出了我们上面列出的范围。

安德鲁：伙计，这里有适合所有人的东西。 “网络存储”的内容（客户端数据库）将变得非常庞大-许多站点已经对其进行了很好的利用。 从一开始就在规范中加入了新的表单控件（néeWeb Forms 2），我仍然迫不及待地想要实现它们。 服务器发送的事件将使它能够做纯粹的“推送”应用程序，而不是依靠不间断的Ajax轮询或脆弱的Comet连接。

我也喜欢自定义数据属性，即使与我列出的属性相比，它只是一个小功能。

托马斯：除了离线功能（主要是持久性存储）之外，我还发现VIDEO和AUDIO标签是最重要的附加功能，因为最终有一种方法可以消除目标和嵌入的麻烦。 当然，要在任何地方都支持该功能还需要一段时间，但这仍然是朝着正确方向迈出的一大步，此外，所有非正式标准的标准化都应导致浏览器的总体性能更好。 隐藏的瑰宝是Web应用程序能够注册协议和媒体类型的能力，以便它们可以像桌面应用程序一样成为默认应用程序（但是从UI角度来看，这里有很多障碍需要克服，因为Joe User不理解什么是“协议”或“媒体类型”）。

David：除非对HTML 5的所有功能都有广泛的支持，否则没有哪个HTML 5功能值得关注。 概念可能值得模仿，但是当很少的浏览器支持时使用特定功能的本机版本会带来麻烦。 这就是为什么我们不使用querySelectorAll的原因：浏览器供应商的不同实现方式可能会带来更多特定于浏览器的黑客行为，而不仅仅是简单地完全避免QSA。

Scott＆Joel：我发现HTML5中最令人兴奋的是那些现在可以使用的功能，而无需开发人员构建完全不同的应用程序版本。 数据库和应用程序缓存API特别有趣，因为应用程序可以实际支持在线和离线模式。 对于移动Web开发人员来说，它们也是一个巨大的福音，因为它们在处理令人难以置信的缓慢而脆弱的移动网络时提供了很多杠杆作用。

我还对其他HTML5功能（例如<canvas>，<audio>和<video>）感到兴奋，这些功能可以解锁当前需要插件才能支持的新功能。 这些标记尚未获得主要浏览器的普遍支持，但随着采用的普及，其使用范围也随之扩大。

InfoQ：您如何看待当前JavaScript框架，以促进诸如内置媒体和脱机支持以及与服务器端进程的高级通信等新功能？ 您的项目的大致路线图是什么？

迪伦： 我们的目标是始终创建填补浏览器空白的内容。 我们希望随着时间的推移，我们所做的事情变得无关紧要（例如规范化事件系统或QuerySelectorAll）。 我们发现在某些情况下，我们会随着时间的流逝而删除代码，但是Dojo的用户并没有注意到差异，因为他们可以继续使用相同的API，只要可行，该API只会包装本机调用。

对于您提到的更多高级功能，Dojo已经支持媒体和脱机支持，以及JSON-RPC和REST之类的东西，甚至可以在服务器端JavaScript环境（例如Persevere）中使用！

Matt and Eric： JavaScript框架的作用是通过提供更丰富的API来改善编程环境，并以在常见浏览器中透明地工作的方式来实现。 在适当的情况下，YUI会采取HTML 5习惯用法（尤其是那些已经在浏览器中引起关注的习惯），并将支持扩展到旧版浏览器，以便即使在新功能实现并传播给大多数用户之前也可以采用新功能。 。 实施客户端存储API是一个示例，其中YUI希望填补HTML 5承诺与当前浏览器提供的内容之间的空白。

安德鲁：像Prototype这样的“中间件”框架-使用难看的，不一致的API，并使它们统一且完整-不会从新HTML5内容中受益匪浅。 一些HTML5功能将使某些任务变得更容易，但是Prototype仍然必须记住“艰辛的路”，直到不再支持最后一种非HTML5浏览器为止。 eh

另一方面，在Prototype之上构建的库-最著名的是script.aculo.us-必须做出一些决定。 Script.aculo.us提供了一个“滑块”控件。 HTML5也是如此。 脚本是否可以在支持HTML5的浏览器中使用HTML5滑块？ 还是坚持使用纯JavaScript版本以确保控件在所有浏览器中看起来都一样？

HTML5提供了多年来我们一直使用纯HTML和JavaScript进行近似处理的某些东西的本机实现，这真是太好了。 如果我们全部转向HTML5并抛弃所有旧的浏览器，这意味着大多数库将能够从其源文件中删除大量代码。 但是我们必须将旧代码保留一段时间。

Prototype和script.aculo.us没有长期的路线图，但是我知道一旦四个主要浏览器中的至少两个支持某个功能，我就会开始认真考虑使用该功能。 请记住，HTML5不会一次全部实现。

托马斯：是的，它们将会发展，并将随着浏览器的实现逐步支持这些新功能。 对于框架而言，这并不是什么新鲜事物，尽管它主要是错误，而不是在发布新浏览器版本时必须解决的功能。 现在，对于script.aculo.us，最大的新“游乐场”可能是CANVAS元素，当然它可以利用我们放入Prototype中的所有内容，例如insertAdjacentHTML（）DOM API可能比我们HTML处理方式快现在插入到DOM中。

大卫：我们认为我们可能会做一成不变的事情：将API从浏览器实现中抽象出来，并修复存在分歧的问题。 在一定程度上，我们可以为较旧的浏览器开发解决方案以提供跨浏览器的稳定性，但是我们会提供无法检测并处理（或伪造）的功能。 我们不要忘记IE6拒绝死亡。 我们要真正依靠这些功能还需要很长时间。

至于路线图，我们可以想象我们将利用使我们能够首先制作更小，更快的库的功能。 因此，例如，如果我们可以为支持H5的浏览器构建更快的选择器引擎，那么我们将更多地关注于此，而不是仅仅启用仅少数前沿浏览器支持的功能。 将规范集成到我们的API中将可能意味着性能提高和字节节省，这在短期内对我们来说是更大的成功，直到更高级的功能在浏览器市场中更加流行为止。

Scott＆Joel：借助GWT，我们倾向于将重点放在可以在主要浏览器上实现的功能上，但是根据给定用户正在运行哪种浏览器，我们可以提供不同的实现。 举一个具体的例子，我很容易看到我们提供了一个稍微抽象的存储API，根据用户的使用情况，它可以使用Google Gears或HTML 5持久存储。 GWT的好处是，最终用户只需下载自己的浏览器支持的特定实现，因为我们可以提前编译所有可能的排列。

InfoQ：随着HTML 5向客户端添加了如此众多的强大功能，一些人认为，JavaScript和DOM的现有范例正在达到极限。 您是否认为我们应该在不久的将来考虑其他模式？

Dylan： jQuery和Dojo之间的主要区别之一是jQuery以DOM为中心，而Dojo还尝试在边缘粗糙的地方修复JavaScript。 像Mozilla Labs的Bespin这样的应用程序指出了需要以非DOM为中心的开发，而且我一直认为DOM是JavaScript开发人员的工具，而不是某些采取的方法（如果您无法代表更改）带有DOM，则不应在浏览器中完成。 坦率地说，我认为我们已经在使用不同的工具包来使用不同的范例了。

Matt和Eric：浏览器生态系统允许使用替代模型，实际上其中许多模型已经开发。 Flash / Flex / AIR是“替代模型”的一个很好的例子，它是HTML / DOM / CSS网络的一部分（并与之并行）。 可以说，当您在iPhone而不是移动Facebook网站上获取Facebook应用程序时，您也在投票支持一种新模型。 迄今为止，还没有任何替代模型能够以其廉价的覆盖范围和可访问性来克服网络进入的低障碍。

将来我们应该“考虑其他模式”吗？ 我们认为，作为应用程序开发人员，每当我们构建新应用程序时，我们都在考虑替代方案。 如果当今大多数应用程序都是Web应用程序，那么这仅表明浏览器的价值主张仍然很有吸引力。 我们认为浏览器中还有许多未发现的价值，并且智能地规范的发展（与ECMA 3.1的发展一样）将继续有效地改善基础。

安德鲁：那是艰难的。 有些人希望浏览器解释标记。 有些人希望浏览器在视口中绘制像素。 取决于您要构建哪种类型的应用程序。 这与替换DOM无关。 这是关于寻找其他与DOM互补的模型，以便您可以选择最适合工作的工具。 我认为CANVAS和SVG在这里都有潜力。

托马斯：我不这么认为-HTML / CSS / JavaScript组合已被证明非常有用且用途广泛，并且所有部分都在积极发展。 无需更换。

大卫：我们如何在“眼前的未来”？ H5给我们带来的任何使我们能够改变模式的东西都只有在多年的可用性之后才可用。 此外，该模型现已得到很好的定义和理解，并已在数十亿个网页上使用。 我们认为它不会很快改变。

斯科特和乔尔：哦，我认为当前的范式不会接近其极限。 但是它比以往任何时候都更加Swift和有机地发展。

一方面，您将投入大量新精力来使浏览器变得更好（带有V8的Chrome，带有TraceMonkey的Firefox，带有SquirrelFish Extreme的Safari，当然还有IE8）。 无论您喜欢哪种浏览器，用户都将拥有一个功能强大的平台，供开发人员在其上进行构建。

同时，开发人员可用于该平台的工具每天都在变得越来越好。 也许不足为奇，我认为GWT推出时是革命性的。 但是几周前我们刚刚发布了GWT 1.6，它比最初的GWT甚至是您一年前可以使用的GWT更具吸引力。 随着空间的成熟，使用其他工具可以全面看到同一件事。

因此，我可以肯定地说我们在这里还有很大的发展空间。

InfoQ：有人建议使用其他客户端语言，例如。 Ruby。 您是否认为JavaScript足够强大？ 是否需要进行重大整容？ 也许有更多的DSL技术？

迪伦：我认为我们很有可能会看到DSL，以及服务器端JavaScript的持续入侵。 有一个新的服务器端JavaScript组引起了极大的兴趣。 JavaScript本身从来不是真正的问题。 问题在于浏览器实现如何支持DOM-JavaScript交互，并且以前JavaScript引擎要比Mozilla，Google，Apple和Opera的最新进展慢得多。 我已经考虑了将Python或Ruby作为客户端语言使用的含义，坦率地说，我认为它不能解决人们遇到的问题。

Matt和Eric： JavaScript在ECMA 3.1中得到了改头换面，这是我们目前真正需要的。

浏览器可以免费支持替代脚本引擎。 只要它们按照规范实现DOM API，使用哪种脚本语言就没有关系。 包括Yahoo的Douglas Crockford在内的一些人认为，为了使Web迈出下一步，必须考虑到安全性而构建的新语言。

安德鲁：完全不会切换语言-JavaScript背后的势头太大。 我喜欢中止ES4提议的许多新功能-运算符重载，Ruby风格的包罗万象的方法等等。 可悲的是，ES4试图做太多事情。 我喜欢我们最终将在ES 3.1“妥协”中使用吸气剂和吸气剂。 但是我认为ES 3.1尝试做的不够。 简而言之，我将通过各种方式使JavaScript更具动态性。

托马斯：是的，我认为JavaScript几乎是“那里”。 不应将其扩展为“真正的OOP语言”，因为它具有非常强大的原型机制，因此就可以了。 这样可以制作各种编程风格，并可以在开发时根据个人喜好进行自定义。 JavaScript和Ruby实际上有时非常接近（并且Prototype JavaScript框架在很大程度上尝试向JavaScript添加更多Rubyism！）。 是的，更多的DSL技术将是很好的-将来我想在JavaScript中看到的仅有两件事是一种捕获丢失的方法名称的方法（又名Ruby的method_missing）和一种定义内联函数（块）的快捷方式，如下所示避免总是写函数（）{...}。

大卫： JavaScript是地球上最成功的编程语言之一。 尽管还有其他语言的问题较少（我们知道Valerio很喜欢用Lua编写，因为他很喜欢它），但Javascript的真正问题在于浏览器中的实现。 框架为我们解决了很多问题，但是可以肯定的是，JavaScript的规范可以并且将会得到改进。 框架的目的有3个方面：1）从它们不同的浏览器中抽象出来，并为较旧的浏览器提供支持2）提供更丰富，更方便的API 3）提供规范中未包含的功能（例如效果或可排序对象）或图片库）。

在一定程度上，我们总是会有做错事情的浏览器，我们需要＃1。 就API继续吸引用户而言，我们需要＃2。 在规范不努力提供丰富功能的程度上，我们需要＃3。

我们只是看不到任何变化很快。

Scott＆Joel：我认为JavaScript作为一种语言具有强大的功能，有时甚至可能过于强大。 您可能需要诸如64位整数或金融应用程序对BigDecimal的本机支持之类的东西，但是JavaScript面临的最大挑战似乎是尝试构建和管理大型手写代码库的实际方面。 当我们第一次创建GWT时，我们打赌，JavaScript的高度灵活性使人们喜欢使用它进行编码，这也使其很好地用作编译器目标语言，因此将其视为一种汇编也很有用。网络语言。

您可以在InfoQ上找到有关JavaScript框架和Rich Internet Applications的更多信息！

翻译自: https://www.infoq.com/articles/js-for-h5/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

javascript演变史