-
Notifications
You must be signed in to change notification settings - Fork 4
5.0 Blog Post
First and foremost, THANK YOU to the 25 contributors who completed and merged 141 pull requests and updated just about every line of code in the project. And thank you to the hundreds of issue commenters and plugin authors who helped shape this latest version. For a widget, we've got a pretty awesome community.
For 5.0 we have some interesting new features, and we made A LOT of new technology choices. This will include an exhaustive dive into those choices, because...why not?
- Redesigned and rebuilt UI
- A flex-box-based controls layout for easier add-ons
- Improved accessibility of the controls
- Switched from LESS to SASS
- Switched to Material Icons
- Rebuilt the library in ES6/Babel/Browserify including Modules and Classes
- Support for responsive layouts including auto-sizing to the video content
- Support for HTTP Live Streaming in desktop browsers WITHOUT Flash
- Switched from GCC to UglifyJS (we STOPPED mangling object properties)
- Improved audio-only support
- Added 6 more language translations, bringing the total to X
- New definition around plugins
- New skin designer on Codepen
- New governance model
- Improved the definition of a playback technology or "tech"
- Switched to JSDoc from a home-grown docs parser
- Switched to BrowserStack for automated browser testing
- Switched to Fastly for our CDN
- New Website and Logo!
- (other plugins?)
[pic]
Video.js has had an all-CSS skin (including for Flash) since it was created in 2010. Over those years we've seen some very creative customizations and learned a lot about what users are hoping to do with player design. For 5.0 we've both simplified the default layout and also add more flexibility than ever before.
One of our biggest challenges with the layout of the controls is keeping the control bar flexible, and able to accomodate any new buttons that a plugin author might want to add. In 4.0 we used CSS floats to allow a new button to be appended to the control bar and flow into space. This however led to a very awkward tab order for anyone navigating the controls with the tab key. In 5.0 we were finally able to take advantage of flex box, which improves on the flexibility of the previous version while also maintaining tab order. In IE8 (because yeah, we still support that) we fall back to display:table, which works surprisingly well.
Accessibility has been a [hot topic as of late](link to 3play article), with new regulations helping push the industry forward and defining what accessbility means for a player. The tab-order mentioned previously was an eye sore in our accessiblity support, and we're all happy to have that fixed in 5.0. Addtionally, after a long debate, we switched our Button elements to use the actual HTML button tag instead of divs. Using divs previously gave us a large degree of safety from external styles clobbering our own styles. This can be a big problem for html-based widgets that are dropped into other frameworks that add styles directly to native elements (ahem Foundation). In the end however the accessibility experts in our community made a strong enough case, pointing out that there's still a number of devices that do not handle ARIA roles and javascript enhanced divs well enough to fully rely on them.
The original decision to use Less over Sass in version 4 was largely driven by the fact that it could be run in the browser. We knew we wanted to start using a preprocessor, but we still wanted to provide things like the skin designer which meant we needed to be able to do all pre-processing on the client. Less was totally appropriate for the job and allowed us to start modernizing the skin in appearance and tooling.
Since then, thanks to Emscripten, Sass has joined Less in the browser. This meant that we were free to use whichever of the two we liked, so all the contributors put on Less or Sass branded boxing gloves and fought until two gloves were still standing, which turned out to be Sass. Aside from the battle royale, there were a few reasons we decided to go with Sass for the new base skin in version 5.
- Familiarity. Core contributors that started working on the new base skin were a little more experienced with Sass and simply preferred it.
- Speed. On top of allowing us to use Sass without requiring Ruby, LibSass is fast.
- Popularity. Your parents are right, not everything's a popularity contest...but it is when you want to pick between two basically equivalent* tools. We wanted to pick something that more devs would be familiar with, and that seems to be Sass. On that note, it was also requested fairly often on the issue tracker.
- Community. This goes hand in hand with popularity, but the Sass community is large and growing, with currently popular projects using it (and switching to it) and new tooling popping up every day along side industry standards such as Compass and Bourbon.
Big changes that we made during the switch that are unrelated to the tooling:
- We broke apart the source files.
- Switched to a Flexbox-based layout. "What about IE8," you say? Tables. Srsly.
- Improved support for responsive layouts.
- We simplified the amount of customization we explicitly allow in the source to encourage people to build on top of the base skin, not edit it directly.
- On the simplification note, we tried to simplify the base skin as much as possible. Our goal was to allow designers to build anything on top of the base without having to entirely start from scratch.
- And more!
* We try to avoid Super Power User Features™ for reasons that can be explained in a different post, but in practice for us, the functional differences are pretty limited.
The switch to an icon font in version 4 was a huge win for Video.js. It allowed designers to do things as basic as style component icon colors with just CSS. It simplified the code base by allowing us not not worry about things like image sprites or other image optimizations. The only recurring issue we ran into was the process around adding new icons to the set, which ultimately involved just uploading the font back to IcoMoon and re-exporting.
In version 5, we've switched everything about our icon set. First we went with a new set of icons: Google's Material Icons. This was a big step forward in terms of appearance, but we had the same issue as far as adding new icons. To fix that process we created new Font tooling for the project.
The tooling is really simple, but it allows anyone to write out a JSON configuration file pointing to any SVGs they have access to. The output of that tool is the font files themselves along with a new SCSS partial that gets imported into our Sass workflow in the core project at build.
We primarily use the Material icons, but occasionally we have to pull in a social media icon from another set, which this process greatly simplifies. See icons missing in the set that you'd like to use? Give the tool a try and let us know what you think!
5.0 comes with bit of enlightenment as we ditch our not-built-here syndrome and make a leap to post-modern development practices.
When we started work on the new version we originally planned to just use browserify and CommonJS modules, but when we took a closer look at the great work being done on Babel, it only made sense to jump again to ES6 modules and save ourselves another code transition down the road, while at the same time gaining a lot of great new JavaScript features.
Side-stepping any argument of the validity of JavaScript Classes, Video.js has always used classes for the internal UI framework. This used a custom class implementation that was of course incompatible with other custom implementations, so the move to ES6 opens the door for some interoperability with other frameworks as more people use ES6 classes specifically.
With this move to modules we've also opened the door to using more of the glorious ecosystem that is npm. We've started to toss out some of the non-core internal libraries that required us to be experts in just about everything, and replace them with other community-built modules. So far this includes libraries like lodash and raynos/xhr, and we're actively looking for opportunies where we can share more code.
Check out this video from the SF Vid Tech meetup for quick overview.
[video]
Proper support for responsive layouts has been a long time request. We've had tips and guides for how to make it work in the old version, but now it's seamlessly built into the core player. We have some easy CSS classes you can just add to the embed code.
// example css classes
Or you can set the player to a fluid layout in the options and it will automatically update to match the aspect ratio of the content., whether you set a width, height, or neither. This was very tricky to implement, but well worth the effort. Check out this example page to see all the options.
// Link to example page. Also put up the example page on the site.
(DAVID)
In version 4.0 we introduced Google's Closure Compiler into our build chain. It's advanced optimizations mode saved us 50% in filesize over UglifyJS at the time. The downsides were that it required us to write the code in very specific ways and mangled internal object properties, which made contributing, debugging, and writing plugins much more difficult. The reality today is that with gzip and improved bandwidth, video.js users are pushing us less and less to squeeze the last bit of filesize out of the library. So for 5.0 we've switched back to UglifyJS. Plugin authors rejoice!
Hey did you know? Video.js also supports the HTML5 audio tag. Try it out and let us know what you think.
Ever since we implemented localization in Video.js there's been a wave of contributions from all over the world. With 5.0 comes Danish, Bosnian, Serbian, Croatian, Finnish, and Turkish. This brings the number of lanugages supported to 25!
(GARY)
We're taking a slightly different approach with the designer now. Instead of exposing all CSS properties from the default skin, we've set up a template starter that has fewer options and allows you to get at the more common customizations more easily.
It's also using Codepen, which is a great service and much better than hosting the designer ourselves. If you make a cool skin, be sure to tweet at @videojs and let us know.
http://codepen.io/heff/pen/EarCt/left/?editors=010
Jumping right on that band wagon, we're implementing a governance model for the project that's similar to Node.js/io.js and 0MQ's C4.1. Along with some better structure around the project it comes with a lower bar for becoming an official maintainer of the project. We're aiming to have a more diverse set of people and companies representing the leadership of Video.js.
For 5.0 we have moved from Sauce Labs to BrowserStack as our browser provider for automated testing. BrowserStack is cross-browser testing tool that provides desktop and mobile browsers and are currently rolling out support for real mobile devices. We moved to BrowserStack to reduce the amount of timeout errors, build time and false positives we were seeing in our builds previously. This stability has allowed us to expand our testing coverage to include iOS, Android and all supported versions of Internet Explorer.
The CDN-hosted version of Video.js at vjs.zencdn.net is downloaded over 2 BILLION times every month, even with agressive browser-side caching. Video.js is relatively small in file size but that's still 34 TB per month. We were previously piggy-backing on Brightcove's Akamai account, but Fastly offered to host the library for free. We gave it a shot and fell in love. In full disclosure, our testing found that Fastly didn't perform quite as well as Akamai internationally, but Fastly's user interface, API, and real-time purge are things of beauty and make our CDN deploy process much simpler.
It's our community that allows Video.js to be actually decent and truly free (Apache 2 License, no fee for commerical-use), so don't be shy. Jump in and submit a bug, build a plugin, or design a skin.
In conclusion, it's been a good year of a lot of good work.