Tag Archives: Experimental Platform Features

Microsoft Edge at Build 2017

Last week, Microsoft welcomed thousands of developers from around the world to Build 2017, where we shared our vision for the future of dozens of products and services. Build featured a number of exciting sessions for developers building sites and apps with web technologies, including a peek at what’s coming to the web platform beginning with EdgeHTML 16 the Windows 10 Fall Creators Update.

In this post, you’ll find a quick review of the web developer sessions at Build 2017. If you see something you’d like to learn more about, dive into the recording to get all the details!

What’s new and what’s next for the web on Windows

In this session, Kyle Pflug and Nadia Fortini take you on a whirlwind tour of what’s new in Microsoft Edge in EdgeHTML 15, and share a roadmap for our priorities in upcoming releases of Microsoft Edge.

You’ll learn about new features like Payment Request for standardized checkout experiences, WebVR for immersive mixed reality experiences built with immersive web technologies, and dramatically improved responsiveness and battery life. We also cover upcoming APIs in development for future releases, including an updated CSS Grid implementation, Service Worker and other features that enable Progressive Web Apps, and much more.

Screen capture showing Fluent Design in Microsoft Edge. The use of materials like Acrylic allows elements of the background to influence the color and texture of the browser frame.

This session also shows an early look at upcoming changes to the design and personality of Microsoft Edge, as the new Fluent Design System begins to make to the browser beginning with the Windows 10 Fall Creators Update. Fluent Design brings depth, motion, and personality to the controls and browser frame in Microsoft Edge, allowing elements of the page and background to influence the color of the browser window.

Progressive Web Apps on Windows

In this session, Aaron Gustafson introduces Progressive Web Apps, a new vision for the future of web apps enabled by groundbreaking technologies like Service Worker, which will be coming to preview builds of Microsoft Edge for developer testing this summer.

You’ll learn how Progressive Web Apps enable world-class, cross-platform, native-like apps, build on web technologies and hosted on your own server. PWAs can work offline, update content in the background even when the browser or the app is closed, and intercept network requests to update content from a cache when the network is unavailable.

This session details how we will a first-class web app ecosystem on Windows by ingesting high-quality PWAs from across the internet, and making it easy for developers to participate in the Windows Store alongside native apps with no extra effort, using tools like Web App Manifests and PWABuilder.

WebVR: Immersive Mixed Reality powered by web technologies

In this session, David Rousset and Etienne Margraff describe how EdgeHTML 15 on the Windows 10 Creators Update enables any web developer to build an immersive mixed reality experience with Microsoft Edge, Windows Mixed Reality, and the WebVR 1.1 API.

Modern frameworks like Babylon.js and A-Frame make it easy to get started building WebVR experiences using familiar web technologies. Developers can get started today even without a headset using the Windows Mixed Reality Simulator.

Better checkout experiences with the Payment Request API

In this session, Molly Dalton, Stan Change, and Jonathan Cutler provide an in-depth look at the new Payment Request API, which allows you to build standardized, cross-browser checkout experiences on the web and in apps. Payment Request dramatically simplifies checkout by leveraging a payment app – in this case, the browser – to store and provide payment and shipping details, so your customers can enjoy less friction and a more delightful user experience.

Payment Request works in EdgeHTML 15 as well as in UWP apps, apps packaged with the Desktop Bridge, and the Microsoft Bot Framework, allowing you to build a faster and easier checkout experience across a variety of devices and platforms.

What’s new in ChakraCore

In this session, Brian Terlson gives an overview of what’s new in Chakra – the open-source JavaScript engine that powers Microsoft Edge and Windows 10.

You’ll learn about the near-native performance enabled by experimental WebAssembly support in Microsoft Edge, and exciting new emerging tools like Time Travel Debugging. You’ll also learn about Chakra’s journey to other operating systems, and the work we’ve been doing with the Node.js core project to help solve key problems like providing a stable Node API for native module developers.

Get started today

Many of these new APIs – including WebVR 1.1, Payment Request, CSS Custom Properties, and more – are available and on by default in Microsoft Edge on the Windows 10 Creators Update, which is available now. To get started with experimental features like WebAssembly, you can simply navigate to about:flags in Microsoft Edge.

To make it as easy as possible to get started, we’ve partnered with BrowserStack to provide instant, free testing of Microsoft Edge from any device. You can test the latest stable and preview releases of Microsoft Edge, and even test localhost or using WebDriver.

We look forward to sharing more about upcoming features soon as they make their way to the Windows Insider Program. In the meantime, check out the Build sessions, and let us know what you think!

Kyle Pflug, Senior Program Manager, Microsoft Edge

Improved JavaScript performance, WebAssembly, and Shared Memory in Microsoft Edge

JavaScript performance is an evergreen topic on the web. With each new release of Microsoft Edge, we look at user feedback and telemetry data to identify opportunities to improve the Chakra JavaScript engine and enable better performance on real sites.

In this post, we’ll walk you through some new features coming to Chakra with the Windows 10 Creators Update that improve the day-to-day browsing experience in Microsoft Edge, as well as some new experimental features for developers: WebAssembly, and Shared Memory and Atomics.

Under the hood: JavaScript performance improvements

Saving memory by re-deferring functions

Back in the days of Internet Explorer, Chakra introduced the ability to defer-parse functions, and more recently extended the capability to defer-parse event-handlers. For eligible functions, Chakra performs a lightweight pre-parsing phase where the engine checks for syntax errors at startup time, and delays the full parsing and bytecode generation until functions are called for the first time. While the obvious benefit is to improve page load time and avoid wasting time on redundant functions, defer-parsing also prevents memory from being allocated to store metadata such as ASTs or bytecode for those redundant functions. In the Creators Update, Microsoft Edge and Chakra further utilizes the defer-parsing mechanism and improves memory usage by allowing functions to be re-deferred.

The idea of re-deferring is deceptively simple – for every function that Chakra deems would no longer get executed, the engine frees the bulk of the memory the function holds to store metadata generated after pre-parsing, and effectively leaves the function in a deferred state as if it has just been pre-parsed. Imagine a function foo which gets deferred upon startup, called at some point, and re-deferred later.

Illustration showing a function foo which gets deferred upon startup, called at some point, and re-deferred later.

The tricky part about re-deferring is that Chakra cannot perform such actions too aggressively or it risks frequently re-paying the cost of full-parsing, bytecode generation, etc. Chakra checks its record of function call counts every N GC cycles, and re-defers functions that are not called over that period of time. The value of N is based on heuristics, and as a special case a smaller value is used at startup time when memory usage is more susceptible to peak. It is hard to generalize the exact saving from re-deferring as it is very subject to the content served, but in our experiment with a small sample of sites, re-deferring typically reduces the memory allocated by Chakra by 6-12%.

Bar chart showing memory allocated by Chakra for various popular sites, with and without re-deferral. With re-deferral, the memory allocated is reduced by 6-12%.

Post Creators Update, we are working on addressing an existing limitation of re-deferring to handle arrow functions, getters, setters, and functions that capture lexically-scoped variables. We expect to see further memory savings from the re-deferring feature.

Optimizing away heap arguments

The usage of arguments object is fairly common on the web. Whenever a function uses the arguments object, Chakra if necessary, creates a “heap arguments” object so that both formals and the arguments object refer to the same memory location. Allocating such object can be expensive, so the Chakra JIT optimizes away the creation of heap arguments when functions have no formal parameters.

In the Creators Update, the JIT optimization is extended to avoid the creation of heap arguments with the presence of formals as long as there’re no writes to the formals. It is no longer necessary to allocate heap arguments objects for code such as below.

// no writes to formals (a & b) therefore heap args can be optimized away
function plus(a, b) {
  if (arguments.length == 2) {
      return a + b; 
  }
}

To measure the impact of the optimization, our web crawler estimates that the optimization benefits about 95% websites and it allows the React sub-test in the Speedometer benchmark, which runs a simple todoMVC implemented with React, to speed up by about 30% in Microsoft Edge.

Better performance for minified code

Using a minifier before deploying scripts has been a common practice for web developers to reduce the download burden on the client side. However, minifiers could sometimes pose performance issues as they introduce code patterns that developers typically would not write by hand and therefore might not be optimized.

Previously, we’ve made optimizations in Chakra for code patterns observed in UglifyJS, one of the most heavily-used minifiers, and improved performance for some code patterns by 20-50%. For the Creators Update, we investigated the emit pattern of the Closure compiler, another widely used minifier in the JavaScript ecosystem, and added a series of inlining heuristics, fast paths and other optimizations according to our findings.

The changes lead to a visible speedup for code minified by Closure or other minifiers that follow the same patterns. As an experiment to measure the impact consistently in a well-defined and constrained environment, we minified some popular JavaScript benchmarks using Closure and noticed a 5~15% improvement on sub-tests with patterns we’ve optimized for.

WebAssembly

WebAssembly is an emerging portable, size- and load-time-efficient binary format for the web. It aims to achieve near-native performance and provides a viable solution for performance-critical workloads such as games, multimedia encoding/decoding, etc. As part of the WebAssembly Community Group (CG), we have been collaborating closely with Mozilla, Google, Apple and others in the CG to push the design forward.

Following the recent conclusion of WebAssembly browser preview and the consensus over the minimum viable product (MVP) format among browser vendors, we’re excited to share that Microsoft Edge now supports WebAssembly MVP behind the experimental flag in the Creators Update. Users can navigate to about:flags and check the “Enable experimental JavaScript features” box to turn on WebAssembly and other experimental features such as SharedArrayBuffer.

Under the hood, Chakra defers parsing WebAssembly functions until called, unlike other engines that parse and JIT functions at startup time. We’ve observed startup time as a major headache for large web apps and have rarely seen runtime performance being the issue from our experiences with existing WebAssembly & asm.js workloads. As a result, a WebAssembly app often loads noticeably faster in Microsoft Edge. Try out the Tanks! demo in Microsoft Edge to see it for yourself – be sure to enable the “Experimental JavaScript Features” flag in about:flags!

Beyond the Creators Update, we are tuning WebAssembly performance as well as working on the last remaining MVP features such as response APIs and structured cloning before we enable WebAssembly on by default in Microsoft Edge. Critical post-MVP features such as threads are being considered as well.

Shared Memory & Atomics

JavaScript as we know it operates in a run-to-completion single-threaded model. But with the growing complexity of web apps, there is an increasing need to fully exploit the underlying hardware and utilize multi-core parallelism to achieve better performance.

The creation of Web Workers unlocked the possibility of parallelism on the web and executing JavaScript without blocking the UI thread. Communication between the UI thread and workers was initially done via cloning data and postMessage. Transferable object was later added as a welcome change to allow transferring data to another thread without the runtime and memory overhead of cloning, and the original owner forfeits its right to access the data to avoid synchronization problems.

Soon to be ratified in ES2017, Shared Memory & Atomics is the new addition to the picture to further improve parallel programming on the web. With the release of Creators Update, we are excited to preview the feature behind the experimental JavaScript features flag in Microsoft Edge.

In Shared Memory and Atomics, SharedArrayBuffer is essentially an ArrayBuffer shareable between threads and removes the chore of transferring data back and forth. It enables workers to virtually work on the same block of memory, guaranteeing that a change on one thread on a SharedArrayBuffer will eventually be observed (at some unknown point of time) on other threads holding the same buffer. As long as workers operate on different parts of the same SharedArrayBuffer, all operations are thread-safe.

The addition of Atomics gives developers the necessary tools to safely and predictably operate on the same memory location by adding atomics operations and the ability to wait and wake in JavaScript. The new feature allows developers to build more powerful web applications. As a simple illustration of the feature, here’s the producer-consumer problem implemented with shared memory:

// UI thread
var sab = new SharedArrayBuffer(Int32Array.BYTES_PER_ELEMENT * 1000);
var i32 = new Int32Array(sab);
producer.postMessage(i32);
consumer.postMessage(i32);

// producer.js – a worker that keeps producing non-zero data
onmessage = ev => {
  let i32 = ev.data;
  let i = 0;
  while (true) {
    let curr = Atomics.load(i32, i);             // load i32[i]
    if (curr != 0) Atomics.wait(i32, i, curr);   // wait till i32[i] != curr
    Atomics.store(i32, i, produceNonZero());     // store in i32[i]
    Atomics.wake(i32, i, 1);                     // wake 1 thread waiting on i32[i]
    i = (i + 1) % i32.length;
  }
}

// consumer.js – a worker that keeps consuming and replacing data with 0
onmessage = ev => {
  let i32 = ev.data;
  let i = 0;
  while (true) {
    Atomics.wait(i32, i, 0);                     // wait till i32[i] != 0
    consumeNonZero(Atomics.exchange(i32, i, 0)); // exchange value of i32[i] with 0
    Atomics.wake(i32, i, 1);                     // wake 1 thread waiting on i32[i]
    i = (i + 1) % i32.length;
  }
}

Shared memory will also play a key role in the upcoming WebAssembly threads.

Built with the community

We hope you enjoy the JavaScript performance update in Microsoft Edge and are as excited as we are to see the progress on WebAssembly and shared memory pushing the performance boundary of the web. We love to hear user feedback and are always on a lookout for opportunities to improve JavaScript performance on the real-world web. Help us improve and share your thoughts with us via @MSEdgeDev and @ChakraCore, or the ChakraCore repo on GitHub.

― Limin Zhu, Program Manager, Chakra Team

A peek into the WebAssembly Browser Preview

Following the introduction of asm.js, we have been working with other browser vendors including Mozilla, Google, Apple, along with the rest of the WebAssembly community group, to push the performance boundary of the web with WebAssembly. WebAssembly is a new, portable, size- and load-time-efficient binary compiler target, which promises near-native performance on the web.

As the community group comes close to consensus over the final design of the MVP (minimum viable product) release, we are pleased to share that the WebAssembly standard is in browser preview and invite the community to provide feedback on the WebAssembly design. We’re continuing to make progress towards a public preview implementation in Microsoft Edge, and today we’re excited to demonstrate WebAssembly in our internal builds.

The Browser Preview

The WebAssembly browser preview is effectively a release candidate for MVP, and includes the latest:

  • Binary format, generalized from previous AST formats to a more efficient stack machine format;  a more compact binary format generally means better loading time.
  • Equivalent human-readable text format for the purpose of reading, debugging, and occasionally handwriting WebAssembly.
  • Built-in JavaScript APIs to integrate WebAssembly modules to the web platform.
  • Up-to-date tools to produce WebAssembly modules, such as the Emscripten/Binaryen toolchain to convert C++ source to asm.js to WebAssembly, and WABT to convert between text and binary format.

To give you a taste of what WebAssembly looks like now, here is an example C++ recursive factorial function with its corresponding WebAssembly:

C++ factorial WebAssembly factorial function body
binary   | text
int factorial(int n)
{
  if (n == 0)
    return 1;
  else
    return n * fac(n-1);
}
20 00    | get_local 0
42 00    | i64.const 0
51       | i64.eq
04 7e    | if i64
42 01    |   i64.const 1
05       | else
20 00    |   get_local 0
20 00    |   get_local 0
42 01    |   i64.const 1
7d       |   i64.sub
10 00    |   call 0
7e       |   i64.mul
0b       | end

The WebAssembly factorial function is extracted from the WebAssembly spec test.

We are eager to hear feedback from the community on WebAssembly. App authors should still expect changes and recompilation of apps for the MVP release, but any feedback from developing an app during the preview will help us make a better standard.

Implementation Progress in Microsoft Edge

We’ve been hard at work developing support for WebAssembly in Microsoft Edge at the open-source ChakraCore project repo. Microsoft Edge and ChakraCore are close to shipping the browser preview, which we expect to come when the full JavaScript APIs are implemented.

To demo the current capability of ChakraCore, we are also excited to showcase the AngryBots demo (with an updated WebAssembly binary) running in an internal build of Microsoft Edge. The demo loads faster than earlier versions compiled to asm.js or older WebAssembly formats, due to a more compact binary and ChakraCore’s new ability to defer parsing WebAssembly functions.

Over the next couple of months, our team will be focused on bringing the browser preview to Microsoft Edge. We look forward to continuing to contribute to the standardization of WebAssembly with the other browser vendors and the community, and would love to hear your thoughts about WebAssembly via @MSEdgeDev and @ChakraCore, or on the ChakraCore repo.

Limin Zhu, Program Manager, Chakra

Bringing WebVR to Microsoft Edge

Today, we’re excited to announce that we’ve begun development on experimental WebVR support in Microsoft Edge! WebVR is the next frontier in web graphics, enabling developers to create a wide range of truly immersive experiences for a variety of devices.

Innovative and immersive WebVR content is already showing up on the web, and we expect to see even more coming as developers turn WebGL experiences into WebVR experiences.

Stereoscopic screen capture showing a VR scene of an astronaut exiting a base on Mars.

A stereoscopic screen capture from “Mars One” Mission, an example WebVR scene on SketchFab

We’ve been working on advancing the W3C WebVR specificationalong with Mozilla, Google, Oculus and others — to ensure that web developers have a faster, more powerful, and interoperable tool.

We look forward to sharing more software and hardware details soon as our implementation progresses. As always, we welcome your feedback as we work to land this new functionality, and we’re very much looking forward this next evolution of the web!

Frank Olivier, Principal Program Manager Lead

Previewing H.264/AVC support for ORTC

Today we’re excited to announce preliminary support for H.264/AVC support in the real-time communications (RTC) stack in Microsoft Edge, as initially promised in our April roadmap update. You can preview this feature in Windows Insider Preview builds starting with EdgeHTML 14.14352 by navigating to about:flags and checking “Enable experimental H.264/AVC support.” This change helps enable interoperable video communications solutions across browsers for basic 1:1 calling scenarios.

This preview release adds the following for H.264/AVC support in our RTC stack:

  • Support for packetization-mode 1, per RFC 7742
  • Support for Constrained Baseline Profile with levels up to 4.2 (i.e. with profile-level-id=42c02a)
  • Support for the absolute send time header extension (abs-send-time)
  • Support for Picture Loss Indication (PLI), per RFC 4585 

H.264/AVC support is currently available through the ORTC API in Microsoft Edge.  In addition, we’re actively working with the community to enable these features via the adapter.js library as well.

These features lay the foundation for video interoperability within the Edge RTP stack, and we plan to extend this in future release by supporting additional feedback messages (e.g. Generic NACK) as well as congestion control and robustness mechanisms (e.g. RTX).

We will continue developing our RTC implementation beyond this summer’s Anniversary Update, including planned support for the WebRTC 1.0 API, and will share updates and preview builds as this work progresses.

– Shijun Sun, Principal Program Manager, Microsoft Edge
– Bernard Aboba, Principal Architect, Skype

Previewing ES6 Modules and more from ES2015, ES2016 and beyond

Chakra, the recently open-sourced JavaScript engine that powers Microsoft Edge and Universal Windows applications, has been pushing the leading edge of ECMAScript language support.  Most of ES2015 (aka ES6) language support is already available in Edge, and last week’s Windows Insider Preview build 14342 brings more ES6 capabilities including modules, default parameters, and destructuring. We’re not stopping there – Edge also supports all ES2016 (aka ES7) proposals – the exponentiation operator and Array.prototype.includes – as well as future ECMAScript proposals such as Async Functions and utility methods like Object.values/entries and String.prototype.padStart/padEnd.

ES6 Modules

Modules let you write componentized and sharable code. Without complete support from any browser, developers have already started to get a taste of ES6 modules through transpiling from tools such as TypeScript or Babel. Edge now has early support for ES6 modules behind an experimental flag.

Modules aren’t exactly new to JavaScript with formats such as Asynchronous Module Definition (AMD) and CommonJS predating ES6. The key value of having modules built in to the language is that JavaScript developers can easily consume or publish modular code under one unified module ecosystem that spans both client and server. ES6 modules feature a straightforward and imperative-style syntax, and also have a static structure that paves the way for performance optimizations and other benefits such as circular dependency support. There are times when modules need to be loaded dynamically, for example some modules might only be useful and thus loaded if certain conditions are met in execution time. For such cases, there will be a module loader which is still under discussion in the standardization committee and will be specified/ratified in the future.

ES6 Modules in Microsoft Edge

To light up ES6 modules and other experimental JavaScript features in Edge, you can navigate to about:flags and select the “Enable experimental JavaScript features” flag.

Screen capture showing the "Experimental JavaScript features" flag at about:flags

The “Experimental JavaScript features” flag at about:flags

As a first step, Edge and Chakra now support all declarative import/export syntax defined in ES6 with the exception of namespace import/export (import * as name from “module-name” and export * from “module-name”). To load modules in a page, you can use the <script type=”module”> tag. Here is an example of using a math module:

/* index.html */
...
&amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;script type='module' src='./app.js'&amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
...
/* app.js */
import { sum } from './math.js';
console.log(sum(1, 2));
/* math.js */
export function sum(a, b) { return a + b; }
export function mult(a, b) { return a * b; }

Implementation: static modules = faster lookup

One of the best aspects of ES6’s modules design is that all import and export declarations are static. The spec syntactically restricts all declarations to the global scope in the module body (no imports/exports in if-statement, nested function, eval, etc.), so all module imports and exports can be determined during parsing and will not change in execution.

From an implementation perspective, Chakra takes advantage of the static nature in several ways, but the key benefit is to optimize looking up values of import and export binding identifiers. In Microsoft Edge, after parsing the modules, Chakra knows exactly how many exports a module declares and what they are all named, Chakra can allocate the physical storage for the exports before execution. For an import, Chakra resolves the import name and create a link back to the export it refers to. The fact that Chakra is aware of the exact physical storage location for imports and exports allows it to store the location in bytecode and skip dynamically looking up the export name in execution. Chakra can bypass much of the normal property lookup and cache mechanisms and instead directly fetch the stored location to access imports or exports. The end result is that working with an imported object is faster than looking up properties in ordinary objects.

Going forward with modules

We have taken an exciting first step to support ES6 modules. As the experimental status suggests, the work towards turning ES6 modules on by default in Edge is not fully done yet. Module debugging in the F12 Developer Tools is currently supported in internal builds and will be available for public preview soon. Our team is also working on namespace import/export to have the declarative syntax fully supported and will look into module loader once its specification stabilizes. We also plan to add new JSRT APIs to support modules for Chakra embedders outside of Edge.

More ES6 Language Features

Microsoft Edge has led the way on a number of ES6 features. Chakra has most of ES6 implemented and on by default including the new syntax like let and const, classes, arrow functions, destructuring, rest and spread parameters, template literals, and generators as well as all the new built-in types including Map, Set, Promise, Symbol, and the various typed arrays.

In current preview builds, there are two areas of ES6 that are not enabled by default – well-known symbols and Proper Tail Calls. Well-known symbols need to be performance optimized before Chakra can enable them – we look forward to delivering this support in an upcoming Insider flight later this year.

The future of Proper Tail Calls, on the other hand, is somewhat in doubt – PTC requires a complex implementation which may result in performance and standards regressions in other areas. We’re continuing to evaluate this specification based on our own implementation work and ongoing discussions at TC39.

ES2016 & Beyond with the New TC39 Process

TC39, the standards body that works on the ECMAScript language, has a new GitHub-driven process and yearly release cadence. This new process has been an amazing improvement so far for a number of reasons, but the biggest is that it makes it easier for implementations to begin work early for pieces of a specification that are stable and specifications are themselves much smaller. As such, Chakra got an early start on ES2016 and are now shipping a complete ES2016 implementation. ES2016 was finalized (though not ratified) recently and includes two new features: the exponentiation operator and Array.prototype.includes.

The exponentiation operator is a nice syntax for doing `Math.pow` and it uses the familiar `**` syntax as used in a number of other languages. For example, a polynomial can be written like:

let result = 5 * x ** 2 – 2 * x + 5;

Certainly a nice improvement over Math.pow, especially when more terms are present.

Chakra also supports Array.prototype.includes which is a nice ergonomic improvement over the existing Array.prototype.indexOf method. Includes returns `true` or `false` rather than an index which makes usage in Boolean contexts lots easier. `includes` also handles NaN properly, finally allowing an easy way to detect if NaN is present in an array.

Meanwhile, the ES2017 specification is already shaping up and Chakra has a good start on some of those features as well, namely Object.values and entries, String.prototype.padStart and padEnd, and SIMD. We’ve blogged about SIMD in the past, though recently Chakra has made progress in making SIMD available outside of asm.js. With the exception of Object.values and entries, these features are only available with experimental JavaScript features flag enabled.

Object.values & Object.entries are very handy partners to Object.keys. Object.keys gets you an array of keys of an object, while Object.values gives you the values and Object.entries gives you the key-value pairs. The following should illustrate the differences nicely:

let obj = { a: 1, b: 2 };
Object.keys(obj);
// [ 'a', 'b' ]
Object.values(obj);
// [1, 2]
Object.entries(obj);
// [ ['a', 1], ['b', 2] ]

String.prototype.padStart and String.prototype.padEnd are two simple string methods to pad out the left or right side of a string with spaces or other characters. Not having these built-in has had some rather dire consequences recently as a module implementing a similar capability was removed from NPM. Having these simple string padding APIs available in the standard library and avoiding the additional dependency (or bugs) will be very helpful to a lot of developers.

Chakra is also previewing SIMD, with the entire API surface area in the stage 3 SIMD proposal completed, as well as a fully-optimized SIMD implementation integrated with asm.js. We are eager to hear feedback from you on how useful these APIs are for your programs.

You can try ES2015 modules and other new ES2015, ES2016, and beyond features in Microsoft Edge, starting with the latest Windows Insider Preview and share your thoughts and feedback with us on Twitter at @MSEdgeDev and @ChakraCore or on Connect. We look forward to hearing your input!

― Taylor Woll, Software Engineer
― Limin Zhu, Program Manager
― Brian Terlson, Program Manager

Previewing ES6 Modules and more from ES2015, ES2016 and beyond

Chakra, the recently open-sourced JavaScript engine that powers Microsoft Edge and Universal Windows applications, has been pushing the leading edge of ECMAScript language support.  Most of ES2015 (aka ES6) language support is already available in Edge, and last week’s Windows Insider Preview build 14342 brings more ES6 capabilities including modules, default parameters, and destructuring. We’re not stopping there – Edge also supports all ES2016 (aka ES7) proposals – the exponentiation operator and Array.prototype.includes – as well as future ECMAScript proposals such as Async Functions and utility methods like Object.values/entries and String.prototype.padStart/padEnd.

ES6 Modules

Modules let you write componentized and sharable code. Without complete support from any browser, developers have already started to get a taste of ES6 modules through transpiling from tools such as TypeScript or Babel. Edge now has early support for ES6 modules behind an experimental flag.

Modules aren’t exactly new to JavaScript with formats such as Asynchronous Module Definition (AMD) and CommonJS predating ES6. The key value of having modules built in to the language is that JavaScript developers can easily consume or publish modular code under one unified module ecosystem that spans both client and server. ES6 modules feature a straightforward and imperative-style syntax, and also have a static structure that paves the way for performance optimizations and other benefits such as circular dependency support. There are times when modules need to be loaded dynamically, for example some modules might only be useful and thus loaded if certain conditions are met in execution time. For such cases, there will be a module loader which is still under discussion in the standardization committee and will be specified/ratified in the future.

ES6 Modules in Microsoft Edge

To light up ES6 modules and other experimental JavaScript features in Edge, you can navigate to about:flags and select the “Enable experimental JavaScript features” flag.

Screen capture showing the "Experimental JavaScript features" flag at about:flags

The “Experimental JavaScript features” flag at about:flags

As a first step, Edge and Chakra now support all declarative import/export syntax defined in ES6 with the exception of namespace import/export (import * as name from “module-name” and export * from “module-name”). To load modules in a page, you can use the <script type=”module”> tag. Here is an example of using a math module:

/* index.html */
...
&lt;script type='module' src='./app.js'&gt;
...
/* app.js */
import { sum } from './math.js';
console.log(sum(1, 2));

/* math.js */
export function sum(a, b) { return a + b; }
export function mult(a, b) { return a * b; }

Implementation: static modules = faster lookup

One of the best aspects of ES6’s modules design is that all import and export declarations are static. The spec syntactically restricts all declarations to the global scope in the module body (no imports/exports in if-statement, nested function, eval, etc.), so all module imports and exports can be determined during parsing and will not change in execution.

From an implementation perspective, Chakra takes advantage of the static nature in several ways, but the key benefit is to optimize looking up values of import and export binding identifiers. In Microsoft Edge, after parsing the modules, Chakra knows exactly how many exports a module declares and what they are all named, Chakra can allocate the physical storage for the exports before execution. For an import, Chakra resolves the import name and create a link back to the export it refers to. The fact that Chakra is aware of the exact physical storage location for imports and exports allows it to store the location in bytecode and skip dynamically looking up the export name in execution. Chakra can bypass much of the normal property lookup and cache mechanisms and instead directly fetch the stored location to access imports or exports. The end result is that working with an imported object is faster than looking up properties in ordinary objects.

Going forward with modules

We have taken an exciting first step to support ES6 modules. As the experimental status suggests, the work towards turning ES6 modules on by default in Edge is not fully done yet. Module debugging in the F12 Developer Tools is currently supported in internal builds and will be available for public preview soon. Our team is also working on namespace import/export to have the declarative syntax fully supported and will look into module loader once its specification stabilizes. We also plan to add new JSRT APIs to support modules for Chakra embedders outside of Edge.

More ES6 Language Features

Microsoft Edge has led the way on a number of ES6 features. Chakra has most of ES6 implemented and on by default including the new syntax like let and const, classes, arrow functions, destructuring, rest and spread parameters, template literals, and generators as well as all the new built-in types including Map, Set, Promise, Symbol, and the various typed arrays.

In current preview builds, there are two areas of ES6 that are not enabled by default – well-known symbols and Proper Tail Calls. Well-known symbols need to be performance optimized before Chakra can enable them – we look forward to delivering this support in an upcoming Insider flight later this year.

The future of Proper Tail Calls, on the other hand, is somewhat in doubt – PTC requires a complex implementation which may result in performance and standards regressions in other areas. We’re continuing to evaluate this specification based on our own implementation work and ongoing discussions at TC39.

ES2016 & Beyond with the New TC39 Process

TC39, the standards body that works on the ECMAScript language, has a new GitHub-driven process and yearly release cadence. This new process has been an amazing improvement so far for a number of reasons, but the biggest is that it makes it easier for implementations to begin work early for pieces of a specification that are stable and specifications are themselves much smaller. As such, Chakra got an early start on ES2016 and are now shipping a complete ES2016 implementation. ES2016 was finalized (though not ratified) recently and includes two new features: the exponentiation operator and Array.prototype.includes.

The exponentiation operator is a nice syntax for doing `Math.pow` and it uses the familiar `**` syntax as used in a number of other languages. For example, a polynomial can be written like:

let result = 5 * x ** 2 – 2 * x + 5;

Certainly a nice improvement over Math.pow, especially when more terms are present.

Chakra also supports Array.prototype.includes which is a nice ergonomic improvement over the existing Array.prototype.indexOf method. Includes returns `true` or `false` rather than an index which makes usage in Boolean contexts lots easier. `includes` also handles NaN properly, finally allowing an easy way to detect if NaN is present in an array.

Meanwhile, the ES2017 specification is already shaping up and Chakra has a good start on some of those features as well, namely Object.values and entries, String.prototype.padStart and padEnd, and SIMD. We’ve blogged about SIMD in the past, though recently Chakra has made progress in making SIMD available outside of asm.js. With the exception of Object.values and entries, these features are only available with experimental JavaScript features flag enabled.

Object.values & Object.entries are very handy partners to Object.keys. Object.keys gets you an array of keys of an object, while Object.values gives you the values and Object.entries gives you the key-value pairs. The following should illustrate the differences nicely:

let obj = { a: 1, b: 2 };
Object.keys(obj);
// [ 'a', 'b' ]
Object.values(obj);
// [1, 2]
Object.entries(obj);
// [ ['a', 1], ['b', 2] ]

String.prototype.padStart and String.prototype.padEnd are two simple string methods to pad out the left or right side of a string with spaces or other characters. Not having these built-in has had some rather dire consequences recently as a module implementing a similar capability was removed from NPM. Having these simple string padding APIs available in the standard library and avoiding the additional dependency (or bugs) will be very helpful to a lot of developers.

Chakra is also previewing SIMD, with the entire API surface area in the stage 3 SIMD proposal completed, as well as a fully-optimized SIMD implementation integrated with asm.js. We are eager to hear feedback from you on how useful these APIs are for your programs.

You can try ES2015 modules and other new ES2015, ES2016, and beyond features in Microsoft Edge, starting with the latest Windows Insider Preview and share your thoughts and feedback with us on Twitter at @MSEdgeDev and @ChakraCore or on Connect. We look forward to hearing your input!

― Taylor Woll, Software Engineer
― Limin Zhu, Program Manager
― Brian Terlson, Program Manager

Building a more accessible web platform

In February we shared our roadmap for empowering all Microsoft Edge customers through accessibility and inclusive design. Today, we’re excited to share more about Microsoft Edge’s native support for the modern UI Automation accessibility framework, coming with the Windows 10 Anniversary Update. UI Automation enables Windows applications to provide programmatic information about their user interface to assistive technology products such as screen readers, and enables a comprehensive ecosystem.

New Microsoft Edge accessibility architecture

Providing a great experience for users of all abilities requires the right architecture. Over the last year we’ve rethought our approach, and designed an accessibility system which inherently supports modern web standards including HTML5 and CSS3. Let’s take a look at the simplified browser pipeline that follows the webpage content into an accessible presentation layer:

Flowchart showing the simplified browser pipeline. Figure 1. Content transformed to the engine model is projected into visual and accessibility views that are presented either as visual or accessible presentation.

Content transformed to the engine model is projected into visual and accessibility views that are presented either as visual or accessible presentation.

In our previous architecture, accessibility objects were generated and tightly associated with the DOM tree, in fact it was a subset of the tree itself. This presented many engineering challenges to maintain and evolve.

With Microsoft Edge an accessibility view is now generated from the same engine model used for visual presentation. Our accessible view creates native accessible objects which can be mutated and invalidated with script changes, just like visual view elements.

Our new accessibility architecture is available in the latest public flight behind the “Enable experimental accessibility features” flag under about:flags, and assistive technologies can take advantage of this using the “MicrosoftEdge” UIA_FrameworkIdPropertyId.

Try it today and let us know what you think!

Navigating web content faster with document structure and landmark roles

To transform content, styles and attributes into accessible objects browsers use HTML and Core Accessibility API mapping specifications. These define how semantic HTML elements gain ARIA roles and are transformed into accessibility entities, such as UI Automation objects.

Using semantic elements, developers can greatly improve the content navigation experience. Microsoft Edge and Narrator now support document structure and landmark role elements in heading, paragraph and landmark navigation modes.

For example, using the <main> elementdevelopers can provide a hint to assistive technology indicating where the primary content is. This makes it easier for their users to get to this content quickly from anywhere on the page. This experience will light up in Microsoft Edge and Narrator, and in other browsers, with assistive technologies supporting those roles.

Getting more information with accessible names and descriptions

Site authors commonly use ARIA attributes and well known patterns and techniques to enhance presentation of the elements on the page. Browsers then take the available information on that element, including contextual elements nearby, and compute accessible name and description. Microsoft Edge now supports the computation algorithm, providing users access to the full information available in the markup.

Better user experience with forms, controls and new semantic elements

Form data entry is a core scenario on the web, and based on user feedback we’ve greatly improved the form entry experience including:

  • Improved accessibility of the error validity states
  • Made <datalist> element accessibile
  • Improved accessibility of all the controls that support lists, including <select>
  • Improved keyboard experience for input types, including Up and Down keys to change the input type=number value
  • Implemented input type=color, which stores the value in computer readable form, and which now presents the information in human readable percentages of Red, Green and Blue.

Code: <input type="color" value="#ff0000" />

Result: UIA Value: “100% Red 0% Green 0% Blue”

Improved web legibility in high contrast

Microsoft Edge provides full support for the Windows high contrast themes, including custom user themes. Many modern web sites use background images as foreground content, which doesn’t provide a great experience for users who need increased contrast.

Screen capture showing xbox.com in IE's high contrast mode. The main foreground content is entirely blacked out with only a heading and secondary content elements visible.

Xbox.com in the legacy high contrast mode.

After working closely with visually impaired users and prototyping different solutions, we decided to try something different for high contrast mode in this release. Microsoft Edge will no longer remove background images, and instead will render an opaque layer behind text to improve legibility while maintaining the site design.

These improvements speak for themselves:

Screen capture showing Xbox.com in the updated high contrast mode. Only the area immediately surrounding each text block is blacked out, allowing the page structure and imagery to show through without impairing readability.

Xbox.com in the redesigned high contrast mode.

Along with the changes we have retained full developer control over browser implicit enhancements with -ms-high-contrast media feature and -ms-high-contrast-adjust property.

These high contrast improvements are available in current Windows Insider releases, enabled by default. Users can disable the “Render backgrounds in high contrast” feature under about:flags to get the previous behavior.

More improvements and platform features

Alongside these platform, user experience, and legibility improvements, we’ve had a chance to add a few user experience features and fixes:

  • Implemented the Web Speech Synthesis API
  • Improved caret browsing on Windows Phone with external keyboards
  • Improved Microsoft Edge frame-to-content focus transitions

Journey towards a more accessible web platform

As we finalize these features on the road to the Windows 10 Anniversary Update, we’ve also begun work on a few additional areas targeting a future release. Below are some of the features we’re currently considering:

  • Improving the UIA TextPattern reading experience based on user feedback
  • Enabling the web platform to take into account the “Text size” slider, available in Ease of access > More options on Windows 10 Mobile
  • Improvements to input controls and scrollbars in high contrast mode
  • Improvements to the text contrast ratios of controls
  • Improvements to touch and keyboard experience with Narrator on the web for desktop and mobile
  • Tweaks to the focus outlines to make finding and tracking elements in the browser easier

In upcoming posts we’ll have more to share about our user experience improvements as measured by HTML5Accessibility.com, as well as our approach to automate accessibility testing for the web.

We’re excited to share the current improvements and look forward to building an even more accessible web with you! As always, we welcome your feedback.

– Bogdan Brinza, Program Management Lead, Microsoft Edge
– Rossen Atanassov, Software Development Lead, Microsoft Edge

WebM, VP9 and Opus Support in Microsoft Edge

Starting with EdgeHTML 14.14291, the open-source WebM container format and the VP9 video and Opus audio codecs are supported in Microsoft Edge. These are available to websites that use Media Source Extensions (MSE) to adaptively stream video content. Windows Web Apps (built on the same Edge APIs) will also be able to use WebM streams containing VP9 and Opus. This change will be available in stable releases starting with the Windows 10 Anniversary Update.

VP9 is an efficient open source video codec developed as part of the WebM Project by Google. The VP9 and WebM project team recently joined the Alliance for Open Media effort where their work on VP9 is expected to be a significant contribution to the next generation of open-source, royalty-free video codecs.

Opus was developed by the Xiph Foundation to support both bandwidth-efficient speech/RTC applications as well as high-quality media playback – all within one codec. Opus is the primary audio codec paired with VP9 in the WebM specification.

We are adding support for these formats to simplify building interoperable websites, and to provide an alternative format for compressing 4K video content. To try them in Microsoft Edge, please install the most recent Windows 10 Insider Build.

Background

Microsoft has been providing support for Media Source Extensions (MSE) since Windows 8.1, initially through support for ISO-Base Media File Format (ISO-BMFF) content that uses fragmented MP4 containers with H.264/AVC video and AAC audio. More recently, we added support within MP4 for H.265/HEVC video and Dolby Digital multi-channel audio, formats targeted at high-performance media.

The WebM Byte Stream Format has existed for some time. It defines the specifics of using VP9 and Opus with MSE. VP9 is an open source video codec that has efficient compression well suited to HD and 4K streaming. Opus, similarly, is a very efficient open source audio codec. They are used together by some prominent websites – notably YouTube – that value them for this efficiency, especially on content with greater than 1080p resolution. Adding WebM, VP9 and Opus to Microsoft Edge means the full experience on these websites will be possible in the Edge browser.

VP9 and Opus Performance

Our implementation of VP9 will support software decoding and, when supported by the device, hardware decoding via the DXVA interface. Video decoding is computationally complex, so the best experience will be seen on computers that have VP9 hardware acceleration which is optimized for 4K decoding support, a feature which will start to become common on devices later this year. Software decoding can yield good performance, but will work best on more powerful desktop or laptop computers.

There’s a side effect of high computing load on software decode:  system power consumption is elevated. The elevation is highest on 4K content because the computing load correlates closely with video resolution. If we compare software decode to hardware accelerated decode, software decode may consume 20% more total power when viewing a 1080p video, and up to 80% more power viewing 2160p. The following charts compare hardware video decode to software video decode at different resolutions on a mid-level laptop computer:

Bar chart comparing software decode power consumption versus hardware decode power consumption. Software decode uses 80% more power at 2k resolutions, and 20% more power at 1080p resolutions.

This difference in power consumption is important because hardware acceleration is common for H.264, but not yet for VP9. If websites see VP9 is supported, they may prioritize using it and users will experience an unexplained reduction in battery life.

Bar chart showing extrapolated battery life estimates based on power consumption. When playing back 2k video, software accelerated playback could result in up to four hours less battery life.

Ideally, there would be a way for apps to confirm hardware acceleration itself is supported. Current web specifications don’t allow for this. For this reason, we’ve put VP9 behind an experimental flag in Microsoft Edge, and have provided a default setting for it that automatically enables VP9 when hardware acceleration is detected. VP9 is not supported on Windows mobile SKUs at this time.

Audio codecs, Opus included, don’t have the same power concern and are usually decoded in software. We have, however, elected to put Opus behind an experimental flag as well. Opus is supported on Windows mobile and desktop SKUs.

Managing Experimental Flags

You can manage the settings for VP9 and Opus by navigating to about:flags in the address bar.

Screen capture showing the Media Source Extensions section of the about:flags interface in Microsoft Edge.

Flags may be used to change the default settings for VP9 and Opus. These default settings are:

  • Opus: Enabled
  • VP9: Automatic

The “Automatic” setting for VP9 enables VP9 if hardware acceleration is supported on the device. We did this for the power reason previously discussed as well as the potential on less powerful computers to experience frame drops when doing software decode on higher resolution streams. The full set of VP9 flag settings and their meaning are:

  • Automatic: VP9 is enabled if hardware-accelerated VP9 decoding is supported
  • Enabled: VP9 is always enabled and available for use
  • Disabled: VP9 is always disabled

These settings allow users to have VP9 always enabled or disabled, in addition to our default setting. We encourage experimenting with these settings and look forward to your feedback.

The “Enabled” default setting for Opus means the Opus codec will be enabled and available for website use, and will show up in the MSE MediaSource.isTypeSupported capabilities query. It’s possible to disable Opus using this flag, which would make it unavailable for playback and show as unsupported via isTypeSupported().

VP8 video and Opus audio are important formats for WebRTC support, and have different considerations regarding hardware acceleration. The Edge WebRTC implementation supports VP8 and Opus regardless of the flag settings. See Roadmap update for Real Time Communications in Microsoft Edge for more information.

Integration

VP9 and Opus support can be queried by websites. With VP9 and Opus enabled, the following Media Source Extension capability checks will return “true”:

  • isTypeSupported ('video/webm; codecs="vp9"')
  • isTypeSupported ('video/webm; codecs="vp9, opus"')
  • isTypeSupported ('video/webm; codecs="opus"')
  • isTypeSupported ('audio/webm; codecs="opus"')

And these will return “false”:

  • isTypeSupported ('video/webm')
  • isTypeSupported ('audio/webm')

If VP9 is on “Automatic”, it will show up as supported on systems that have VP9 hardware acceleration, and won’t on systems that don’t.

MediaElement.canPlayType() is used to check capabilities for file-based playback. Edge will respond to any WebM canPlayType() calls with an empty string (the defined response for “not supported”) since we are only supporting WebM on MSE right now.

Microsoft has an ongoing effort to expand codec offerings in Windows. WebM, VP9, and Opus are our latest format additions. We continue to evaluate other formats and look forward to receiving feedback as we work on implementing them.

Please send us your feedback so we can further improve our media support in Microsoft Edge!

– Andy Glass, Principal Program Manager, Silicon, Graphics & Media (VP9 video)
– Neil Hinnant, Program Manager, Silicon, Graphics & Media (Opus audio)
– Jerry Smith, Senior Program Manager, Microsoft Edge (Media)

Edge Web Summit 2016 is streaming live tomorrow at 8:30 AM PT

Our second annual Microsoft Edge Web Summit begins tomorrow morning in San Francisco, and we couldn’t be more excited to host developers from around the world for a tour of our plans for the Edge platform in the year ahead. We have a few exciting new tools to share with the developer community and lots of in-depth content on what’s new and what’s coming next.

Sessions include an overview of our new extensions platform (now available for Windows Insiders to preview) and our roadmap for extension APIs, more details on eliminating passwords by building Windows Hello into your site with the FIDO 2.0 APIs, and ongoing improvements to Microsoft Edge that make it the most secure browser we’ve ever shipped. The full schedule is available on Channel 9.

We’ll be streaming on Channel 9 starting at 8:30 AM PT – you can join the livestream to watch from home or check out the recorded sessions shortly after the event concludes. At 6:00 PM, we’ll wrap up the day with a live Q&A from the audience and Twitter – tweet your questions to @MSEdgeDev with the hashtag #AskMSEdge throughout the day, and we’ll get to as many as we can!

See you on the livestream!

― Kyle Pflug, Program Manager, Microsoft Edge