media-source
ECMAScript 6 compatibility table
media-source | ECMAScript 6 compatibility table | |
---|---|---|
1 | 33 | |
266 | 4,406 | |
0.4% | 0.1% | |
6.9 | 5.2 | |
about 1 month ago | 9 days ago | |
HTML | HTML | |
GNU General Public License v3.0 or later | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
media-source
-
Chrome 0day is being exploited now for CVE-2022-1096; update immediately
It depends heavily on the website we're talking about but there's generally a lot going on when streaming video on the web.
Usually what happens at the core is that JavaScript will download video, audio and subtitles progressively through small chunks of data called "segments" and push them to JS-exposed buffers called 'SourceBuffer'. Deciding which chunk to download, downloading them and pushing them already require a lot of JavaScript (for example, you need to decide which video and audio quality to download through adaptive algorithms, which tend to be quite complex, moreover there's also a lot of media events that needs reaction to, like when seeking, rebuffering, changing track etc.). You also have a lot of JavaScript there to limit risks of playback stalling and if you have DRMs, a lot of JavaScript there to be able to recuperate the right decryption keys (an operation you generally wish to finish as soon as possible as it is often the last step before playback).
On some websites, you might want to play with as low latency as possible between the broadcaster and the user. In those cases, you might want to optimize your JS code, have very small checking intervals, and you might again prefer to run as much code as possible in a worker to avoid rebuffering due to the risk of the main thread being too occupied doing other things to push media segments.
Even on non-low-latency contents, some websites which already have a lot of JavaScript running beside video playback such as at least Facebook and YouTube pushed browsers for quite some time now to be able to use the main JavaScript media streaming APIs in a worker (https://github.com/w3c/media-source/issues/175), e.g. in another thread.
You could also have complex contents (lot of audio and subtitles languages, many audio and video qualities, multiple decryption keys, long duration etc.) that may lead to big performance and memory issue when parsing them on the JS-side. Those contents are usually described through a file named "manifest" or "playlist" which in this case can take a lot of resources to process (the document can be up to a huge 15MB XML where I work), often leading either the linked JavaScript to run in a worker or to use webassembly (a solution we chosed). Even more if you consider live contents, where this document might have to be regularly refreshed.
You might also want to apply some processing on the media played, for example transmuxing mpeg-ts segments to MP4 ones so they can be played by more browsers. Those are very frequent operations that can be performance-sensitive and are also often performed in another thread.
Again it very much depends on the website and I mainly know the use cases I personally encountered. Generally, adaptive media player are very complex JavaScript beasts.
Also performance issues and poor memory management from the browser-side can lead to a lot of issues. A recurring issue at my work is bad performance leading through side-effect to a very poor quality being played (due to the high overhead in loading segments, pushing them to the buffer etc.).
All these would suffer without a powerful and featureful JS engine like we generally have today on most browsers.
ECMAScript 6 compatibility table
-
TypeScript Is Surprisingly OK for Compilers
http://kangax.github.io/compat-table/es6/
This page lists features from es6 (and newer versions linked at the top) along with compliance to the spec. First column is the current browser, second is babel+corejs polyfills.
Overall, babel gets about 70% of the way there.
- Яндекс Браузер не переводит видео про обучение украинских танкистов, хотя другие видео с канала МО Британии переводит нормально
-
Brett Slatkin: Why am I building a new functional programming language?
Case in point: Tail Call Optimization has been part of the JS spec since ES6, but remains completely unimplemented in all mainstream browsers/engines besides Safari[1]. For all but the most predictable inputs, you're pretty much forced to use loops where recursion would otherwise be preferable.
Additional case in point: async Iterables cannot be processed as a piped stream. You must use the for await construct, which is a shame considering the FP niceties that the Array type already provides for more traditional lists. Once again, you are forced to use an imperative construct unless you specifically want to defeat the purpose of using an Iterable in the first place by trying to convert it into an Array (... and potentially choking in the process, I might add!).
[1]: https://kangax.github.io/compat-table/es6/
- [AskJS] Is there a detailed comparison chart that shows what's supported in JavaScript ES5 versus ES6?
-
A single developer has been maintaining core.js with little recognition or support. Almost all modern single page apps use core.js. Millions of downloads and hardly any compensation
Eventually the browsers started racing to near-full ES6 compatibility. I remember following ES6 progress in realtime with articles and with compatibility tables http://kangax.github.io/compat-table/es6/ . But many people are acting like that either didn't happen, or like it was a one and done thing (despite the ESNext naming shift to avoid the focus on numbers). So we see people just hand-waving away the importance of polyfills like in this gem:
-
Tell HN: Firefox Is an awesome browser right now
> https://kangax.github.io/compat-table/es6/
Oh man this was a rough one both for FF and Chrome but Chrome did perform better slightly on cursory glance.
Thanks for providing these links, they're definitely a good rule of thumb benchmarks to test new browsers
-
My 1st website "Claw Man" written in javascript
Javascript / CSS language syntax: can see availability for Javascript here - https://kangax.github.io/compat-table/es6/
-
Is there any legitimate reasons for the javascript hate?
I say this as a JS user, but there is no singular JavaScript (realistically, it's not even JavaScript but instead ECMAScript). There is no one place to go that lays out all of what the language can or can't do the way PHP and Python do. The ECMAScript board makes recommendations, then the browsers and runtimes implement features of the recommendations. This site does a good job laying out which features are implemented for browsers and runtimes based on the flavor of the ECMAScript standard. This unique experience can be especially frustrating for someone learning JavaScript and coming from another language that does not have this problem.
- JS Polyfills - Part 1
-
[AskJS] Is there a JavaScript library that will test all ES features on your browser and tell you which it supports and which it doesn't?
https://kangax.github.io/compat-table/es6/ has a column for "current browser"
What are some alternatives?
V8 - The official mirror of the V8 Git repository
es6-features - ECMAScript 6: Feature Overview & Comparison
quickjs - Public repository of the QuickJS Javascript Engine.
Babel (Formerly 6to5) - 🐠 Babel is a compiler for writing next generation JavaScript.
tiny-snitch - an interactive firewall for inbound and outbound connections
Traceur compiler - Traceur is a JavaScript.next-to-JavaScript-of-today compiler
es6-cheatsheet - ES2015 [ES6] cheatsheet containing tips, tricks, best practices and code snippets
es6features - Overview of ECMAScript 6 features
Lebab - Turn your ES5 code into readable ES6. Lebab does the opposite of what Babel does.
browserslist - 🦔 Share target browsers between different front-end tools, like Autoprefixer, Stylelint and babel-preset-env
javascript-cheatsheet - All-inclusive Javascript cheatsheet
MEVN-CLI - Light speed setup for MEVN(Mongo Express Vue Node) Apps