首先，**衷心感谢**25位贡献者，他们完成了并合并了**146个拉取请求**，更新了项目中的几乎每一行代码。同时，感谢数百位问题评论者和插件作者，他们帮助塑造了最新版本。对于一个组件来说，我们拥有一个非常棒的社区。

对于5.0版本，我们有一些有趣的新功能，并且做了**大量**新的技术选择。这包括对这些选择的详尽探讨，因为……为什么不呢？

• 重新设计并重建了用户界面
  • 使用基于 flex-box 的控件布局，便于添加附加组件
  • 改进了控件的可访问性
  • 从 LESS 切换到 SASS
  • 切换到 Material Icons
• 使用 ES6/Babel/Browserify 重建了库，包括模块和类
• 增加了对响应式布局的支持，包括根据视频内容自动调整大小
• 增加了在桌面浏览器中**无需 Flash** 即可支持 HLS 的功能
• 改进了纯音频支持
• 新增了 6 种语言翻译，总数达到 25 种
• 从 Closure Compiler 切换到 UglifyJS（我们**不再混淆对象属性**）
• 切换到 JSDoc 进行文档编写
• 切换到 BrowserStack 进行自动化浏览器测试
• 切换到 Fastly 作为我们的 CDN
• 关于插件的新定义
• Codepen 上新的播放器皮肤设计器
• 关于播放技术（“techs”）的新定义
• 新的项目治理模式
• 新网站和新 Logo！

如果您是 Video.js 用户或 semver 爱好者，您可能正在查看更新日志并心灰意冷（或大声抱怨）。您可能已经在想，每次主版本升级时，您多么不想进行这种大型升级操作。需要明确的是，主要版本之间至少会有*一些*升级成本，因为事情就是这样。**然而**，从 5.0 版本开始，我们计划在主版本上更加宽松，以避免像这样“停止一切”的超大型发布。

事实是，这个版本清理了多年来维护一个流行的开源库所积累的大量技术债务和冗余代码。再次使用代码库变得有趣了（并不是说以前不有趣，爱评判的人），我们认为至少在升级到 ES9000 之前，我们还有至少 6 个月的时间。.严肃地说，我们计划加快发布速度，无论是破坏性更新还是非破坏性更新，以使增量升级的痛苦更小，并且，更快。此外，Chrome 和 Firefox 的版本号很快就会达到数千，我们也想体验一下那种乐趣。

重新设计并重建了用户界面

Video.js 自 2010 年创建以来，一直拥有一个纯 CSS 皮肤（包括 Flash 皮肤）（第一个版本**真的**是纯 CSS，没有图片、字体或 SVG。而且今天仍然可以使用！）。这些年来，我们看到了许多非常有创意的定制，并学到了很多关于用户在使用原生 Web 技术时，希望如何进行播放器设计。对于 5.0 版本，我们既简化了默认布局，又增加了前所未有的灵活性。

Flex Box 布局

控件布局面临的最大挑战之一是保持控制条的灵活性，以便适应插件作者可能希望添加的任何新按钮。在 4.0 版本中，我们使用 CSS float 允许新按钮添加到控制条并流入空间。然而，这导致使用 Tab 键导航控件时，焦点顺序非常尴尬。在 5.0 版本中，我们最终能够利用 flex box，这在保持正确 Tab 顺序的同时，提高了以前版本的灵活性。在 IE8 中（是的，我们仍然支持它），我们回退到 display:table，这出乎意料地好用。

改进了可访问性

可访问性最近一直是一个热门话题，新的法规有助于推动行业发展并定义播放器的可访问性意味着什么。之前提到的 Tab 键顺序是我们可访问性支持中的一个痛点，我们都很高兴在 5.0 版本中修复了这个问题。.此外，经过长时间的争论，我们将 Button 元素改用实际的 HTML button 标签，而不是 div。以前使用 div 在很大程度上避免了外部样式覆盖我们自身样式的问题。对于嵌入到直接向原生元素添加样式的其他框架中（咳，例如 Foundation）的基于 HTML 的小部件来说，这可能是一个大问题。然而，最终我们社区的可访问性专家提出了足够有力的论据，指出仍有许多设备无法很好地处理 ARIA 角色和 JavaScript 增强的 div，因此不能完全依赖它们。

从 LESS 切换到 SASS

在版本 4 中，最初选择使用 Less 而非 Sass 的主要原因是它可以在浏览器中运行。我们知道我们想开始使用预处理器，但我们仍然希望提供皮肤设计器之类的功能，这意味着我们需要能够在客户端进行所有预处理。Less 完全适合这项工作，并使我们能够开始在外观和工具方面对皮肤进行现代化改造。

自那时起，由于 Emscripten 的出现，Sass 也加入了浏览器支持的行列。这意味着我们可以自由选择两者中的任何一个，所以所有贡献者都戴上 Less 或 Sass 品牌的拳击手套，一直打到只剩下两只手套，结果是 Sass 赢了。除了这场混战，我们决定在版本 5 中选择 Sass 作为新基础皮肤还有几个原因。

• **熟悉度。**开始开发新基础皮肤的核心贡献者对 Sass 更有经验，并且更喜欢它。
• **速度。**除了允许我们无需 Ruby 即可使用 Sass 之外，LibSass 速度非常快。
• **流行度。**你的父母是对的，不是所有事情都是人气竞赛……但当你需要在两个基本等效的*工具中做出选择时，它就是。我们希望选择一个更多开发者会熟悉的工具，而这似乎就是 Sass。值得一提的是，在问题追踪器上也经常有人提出使用 Sass 的请求。
• **社区。**这与流行度息息相关，但 Sass 社区庞大且不断发展，目前流行的项目都在使用它（并正在转向它），并且每天都有新的工具涌现，同时还有 Compass 和 Bourbon 等行业标准。

我们在切换过程中做出的一些与工具无关的重大改变

• 我们拆分了源文件。
• 如上所述，我们切换到了基于 Flexbox 的布局。“IE8 怎么办？”你又问。表格。真的。
• 改进了对响应式布局的支持。
• 我们简化了源代码中明确允许的定制量，以鼓励人们在基础皮肤*之上*进行构建，而不是直接修改它。
• 关于简化，我们尝试尽可能地简化基础皮肤。我们的目标是让设计师能够在基础之上构建*任何东西*，而无需完全从头开始。
• 以及更多！

切换到 Material Icons

版本 4 中切换到图标字体对 Video.js 来说是一个巨大的胜利。它允许设计人员通过*纯 CSS* 来样式化组件图标颜色等基本操作。它简化了代码库，使我们无需担心图像精灵或其他图像优化等问题。我们遇到的唯一反复出现的问题是向图标集添加新图标的过程，这最终只需要将字体重新上传到 IcoMoon 并重新导出即可。

在版本 5 中，我们对图标集进行了全面更改。首先，我们选择了一套新的图标：Google 的 Material Icons。这在外观方面是一个巨大的进步，但在添加新图标方面，我们遇到了同样的问题。为了解决这个问题，我们为项目创建了新的 字体工具。

该工具非常简单，但它允许任何人编写一个 JSON 配置文件，指向他们有权访问的任何 SVG 文件。该工具的输出是字体文件本身，以及一个新的 SCSS 部分文件，该文件在核心项目构建时被导入到我们的 Sass 工作流程中。

我们主要使用 Material Icons，但偶尔也需要从其他集合中引入社交媒体图标，这个过程极大地简化了操作。看到图标集中缺少您想使用的图标了吗？试用一下这个工具，并告诉我们您的想法！

使用 ES6/Babel/Browserify 重建了库，包括模块和类

5.0 版本带来了一些启示，我们摒弃了“非此处构建症候群”，并迈向了后现代开发实践。

当我们开始开发新版本时，最初计划只使用 browserify 和 CommonJS 模块，但当我们仔细研究 Babel 上正在进行的出色工作时，再次转向 ES6 模块并为未来节省一次代码转换工作就变得理所当然了，同时也能获得许多出色的新 JavaScript 特性。

撇开关于 JavaScript Class 有效性的任何争论，Video.js 始终在其内部 UI 框架中使用类。我们曾使用自定义的类实现，这自然与其他自定义实现不兼容，因此转向 ES6 为在越来越多的人使用 ES6 类的情况下，与其他框架的潜在互操作性打开了大门。

随着转向模块化，我们也打开了使用 npm 这一庞大生态系统的大门。我们开始淘汰一些非核心的内部库，这些库曾要求我们在几乎所有方面都是专家，并用其他社区构建的模块取而代之。到目前为止，这包括 lodash 和 raynos/xhr 等库，我们正在积极寻找可以共享更多代码的机会。

这对最终用户意味着什么？

这应该会使 Video.js 的最终用户更容易使用，特别是如果他们自己使用 browserify。通过此更改，用户只需在他们的 app.js 或需要实例化播放器时 require('video.js')。此外，使用 browserify 编写的插件也可以非常容易地通过 browserify 和 require 添加。当然，您也可以使用 Babel 和 ES6 模块。例如，您的 app.js 在假定使用 browserify 和 Babel 进行 ES6 语法编译的情况下可能如下所示：

// import videojs
import videojs from 'video.js';
// import several plugins.
// Each requires videojs itself and registers itself accordingly.
import 'videojs-playlist';
import 'videojs-thumbnail';
// this isn't ready yet, unfortunately
import 'videojs-contrib-hls';

// make a player
let player = videojs('my-video');
// initialize some plugins
player.playlist(myplaylist);
player.thumbnail(myThumbnailConfig);

增加了对响应式布局的支持，包括根据视频内容自动调整大小

观看旧金山视频技术交流会上的这段视频，快速了解一下。

*真正*支持响应式布局是长期以来的需求。我们过去提供了关于如何在旧版本中实现它的提示和指南，但现在它已无缝集成到播放器中。首先，您可以直接向嵌入代码添加两个简单的 CSS 类：vjs-16-9 和 vjs-4-3。

<video class="video-js vjs-16-9 vjs-default-skin" ...></video>;

或者您可以在选项中将播放器设置为流体布局，它将**自动更新以匹配内容的宽高比**，无论您是否设置了宽度、高度。

var myPlayer = videojs(id, { fluid: true, preload: 'metadata' });

这实现起来非常棘手，但非常值得。我们有一个jsbin 示例页面，您可以在其中尝试不同的选项。

增加了在桌面浏览器中**无需 Flash** 即可支持 HTTP Live Streaming 的功能

我们一直在努力消除视频播放使用 Flash 的最后一个借口，并已达到了一些重要的里程碑。videojs-contrib-hls 1.0（是时候了！）将使用 Media Source Extensions（一种高级视频元素 API）在 Chrome 和 Microsoft Edge 中提供 HLS 播放。除了在 JavaScript 中进行所有操作带来的增强调试能力外，大部分计算已移至 Web Worker，并在支持的平台上进行硬件加速。这意味着即使是 60fps 或 4k 流也能流畅播放，并且您的电池消耗也会减少。作为这项工作的一部分，我们已将用于重新打包 HLS 视频的代码拆分到 video.js 组织中的一个单独项目：mux.js。如果您对视频在比特级别的工作方式感兴趣，请查看一下！我们一直在寻找新的贡献者。

从 Closure Compiler 切换到 Uglify（我们**不再混淆对象属性**）

在 4.0 版本中，我们将 Google 的 Closure Compiler 引入了我们的构建链。其**高级优化模式**在当时比 UglifyJS 节省了 25% 的文件大小。缺点是它要求我们以非常特定的方式编写代码，并混淆内部对象属性，这使得贡献、调试和编写插件变得更加困难。今天的现实是，随着 gzip 和带宽的改进，Video.js 用户越来越少地要求我们从库中榨取最后一点文件大小。因此，在 5.0 版本中，我们已切换回 UglifyJS。插件作者们，欢呼吧！

改进了纯音频支持

嘿，你知道吗？Video.js 也支持 HTML5 audio 标签。试试看，告诉我们你的想法。

<audio id="my_audio_1" class="video-js vjs-default-skin" controls data-setup="{}"><source src="MY_AUDIO_FILE.mp3" type="audio/mp3"></source></audio>

新增了 6 种语言翻译

自从我们在 Video.js 中实现本地化以来，世界各地涌现出了一波贡献。5.0 版本新增了丹麦语、波斯尼亚语、塞尔维亚语、克罗地亚语、芬兰语和土耳其语。这使得支持的语言数量达到 25 种！

关于插件的新定义

插件与 Video.js 4.x 中的工作方式大部分没有改变。您仍然以相同的方式注册和使用它们。唯一的主要变化是，如果您在播放器的配置中实例化一个插件，该插件将在播放器准备就绪之前运行。这样做是为了让插件在进行一些 UI 工作或将自己添加为播放器的子元素时，能够尽早进行。这意味着需要播放器准备就绪的插件需要自行处理，否则将不支持通过播放器配置进行实例化。例如：

videojs('my-video', {
  plugins: {
    playlists: {},
  },
});

作为 Video.js 5 更新以及从 Google Closure Compiler 切换到 Uglify 的一部分，我们一直致力于改善插件体验。我们确保导出了我们在自己的代码库中使用的一些实用函数，以便更轻松地编写插件。这样，如果 Video.js 中提供了诸如 merge 之类的函数，插件就不需要自己包含额外的代码了。

此外，我们鼓励插件作者将他们的插件发布到 npm 上。如果插件被标记为 videojs-plugin，它们将显示在我们炫酷的新插件列表页面上。

Codepen 上新的播放器皮肤设计器

现在我们对设计器采取了略微不同的方法。我们没有暴露默认皮肤的所有 CSS 属性，而是设置了一个模板启动器，它选项更少，让您更容易进行更常见的自定义。

它还使用了 Codepen，这是一个很棒的服务，比我们自己托管设计器好得多。如果您用它制作了一个很酷的皮肤，请务必告诉我们。在 Twitter 上 @videojs 或在设计器上评论。

http://codepen.io/heff/pen/EarCt/left/?editors=010

新的项目治理模式

我们紧随潮流，正在为项目实施一个类似于 Node.js/io.js 和 0MQ 的 C4.1 的治理模式。除了围绕项目建立更好的结构外，它还降低了成为项目官方维护者的门槛。我们的目标是拥有一个更多样化的人员和公司来代表 Video.js 的领导层。

改进了播放技术或“技术”的定义

我们最受欢迎的插件（YouTube 插件）的创建者承担了改进播放器与技术之间关系的任务。“技术”是我们用来描述播放器 API 与底层视频对象之间转换层的术语，这些底层视频对象可以是 HTML5 视频元素、像 Flash 和 Silverlight 这样的插件，或者像 YouTube 和 Vimeo 这样的其他播放器。如果您已经构建了一个技术或有兴趣构建一个，请查看 5.0 版本中的更改。

从自研文档解析器切换到 JSDoc

在上一版本中，我们有一个自定义构建的文档生成器，它使用 esprima 解析 AST 并仅从代码中创建了大量 API 文档，JSDoc 标签补充了其余部分。这仍然可能是一个好项目，但它的维护成本过高，并且对插件作者来说太受限了。

对于 5.0 版本，我们已切换到 jsdoc。查看新的文档网站。有人想帮我们设计它吗？:)

切换到 BrowserStack 进行自动化浏览器测试

对于 5.0 版本，我们已将自动化测试的浏览器提供商从 Sauce Labs 迁移到 BrowserStack。BrowserStack 是一款跨浏览器测试工具，提供桌面和移动浏览器，目前正在逐步推出对真实移动设备的支持。我们迁移到 BrowserStack 旨在减少之前构建中出现的超时错误、构建时间和误报。这种稳定性使我们能够将测试覆盖范围扩展到 iOS、Android 以及所有支持的 Internet Explorer 版本。

切换到 Fastly 作为我们的 CDN

即使有积极的浏览器端缓存，vjs.zencdn.net 上 CDN 托管的 Video.js 版本每月下载量也超过 20 亿次。Video.js 的文件大小相对较小，但每月仍产生 34 TB 的流量。我们之前是借用 Brightcove 的 Akamai 账户，但 Fastly 主动提出免费托管该库。我们尝试了一下，并爱上了它。完全披露一下，我们的测试发现 Fastly 在国际表现上不如 Akamai，但 Fastly 的用户界面、API 和实时清除功能都非常出色，这使我们的 CDN 部署过程变得简单得多。

新网站和新 Logo！

我们简化了一些。你觉得怎么样？

如果您不方便直接贡献 Video.js，我们随时欢迎您为网站提供帮助。网站每月获得**超过 20 万独立访问量**。请在网站仓库贡献。

救命！

正是我们的社区让 Video.js 保持实际良好且**真正免费**（Apache 2 许可），所以不要害羞。加入进来，提交一个 bug，构建一个插件，或者设计一个皮肤。

总而言之，这是充满出色工作的一年。谢谢！