So the language that runs everywhere goes from strength to strength allowing us to do more and more in fewer lines of code whilst maintaining the accessibility that makes JavaScript so popular.

With that in mind, I thought I'd take a look at some of the features being proposed to the TC39 committee (the guys who decide what will become part of the language) that may become part of our everyday toolkit.

Async iteration

Why would you need this? Well looking at the repo for this one two of the first code samples are:

async function* readLines(path) {
  let file = await fileOpen(path);

  try {
    while (!file.EOF) {
      yield await file.readLine();
  } finally {
    await file.close();


for await (const line of readLines(filePath)) {

So it would be pretty convenient to have an understandable and maintainable way of iterating over I.O bound operations that are by their nature asynchronous.

Whilst the above example seems contrived there is a stream of new features coming into mainstream JavaScript, the web streams standard!. See what I did there ;-).

Processing audio and video in a browser though, admittedly not something we do every day, is a possibility now and it's surely only a matter of time before all manner of libraries that to do all kinds of fantastic things in everyday browser applications appear. This feature would really make for a very readable way of dealing with large chunks of data in a non-blocking manner.

The Fetch API also brings an easy way of consuming binary data to the browser so this might also be a way we could use this.


Anyone who has used RX.js or Angular(2+) might get excited by seeing this in the repo for the observable-proposal.

interface Observable {

    constructor(subscriber : SubscriberFunction);

    // Subscribes to the sequence with an observer
    subscribe(observer : Observer) : Subscription;

    // Subscribes to the sequence with callbacks
    subscribe(onNext : Function,
              onError? : Function,
              onComplete? : Function) : Subscription;

    // Returns itself
    [Symbol.observable]() : Observable;

    // Converts items to an Observable
    static of(...items) : Observable;

    // Converts an observable or iterable to an Observable
    static from(observable) : Observable;


interface Subscription {

    // Cancels the subscription
    unsubscribe() : void;

    // A boolean value indicating whether the subscription is closed
    get closed() : Boolean;

function SubscriberFunction(observer: SubscriptionObserver) : (void => void)|Subscription;

The Promise gives us a way of receiving a push based notification about one asynchronous operation. There are so many instances, however, (browser events, timers, and web sockets) where values, data or events arrive over time and having a push based system that would allow us to deal with them as a set of values provides a powerful way of expressing dynamic behaviour as constant values, or in lay-mans terms it allows you to write code to handle a sequence of related events in one place using method chains and arrow functions.

Whilst the RX.js operators are not in the proposal, the base functionality would certainly bring several immediate benefits such the fact observables are:

  1. Lazy, they only execute if you subscribe.
  2. Easily composed/extended, hence the inclusion of the word extensions in the phrase "Reactive extensions for JavaScript" aka RxJS.
  3. Easily disposable, as they have a great way of providing a handle to cancel subscriptions, important for scalability.

Perhaps I'm getting carried away here but looking through the repo for this one I found the following in a comment:

(async _=> {
    for await (let e of mouseDrags(document.body))
        console.log(`DRAG: <${ e.x }:${ e.y }>`);

The "mouseDrags" function emits a stream of events created by combining a mousedown, mousemove and mouseup (another neat trick that observables enable!).

Perhaps if async iteration and this make it into the language then subscribing to an observable stream using async and await will be possible, making the code to consume observable streams very readable, at least in a large number of scenarios.

Obviously, we would need the async "for of" to work with the proposed "Symbol.observable" for this to work but as both these features are being proposed at the same time on can only hope, or dream.

Pattern matching

This one seems to be in fashion at the moment with the ability to perform conditional logic based on the shape of data already existing in languages like Rust, F# and most recently C#.

The dynamic nature of JavaScript makes this feature a great fit. The following is taken from the GitHub repo of this one

let getLength = vector => match (vector) {
    { x, y, z }: Math.sqrt(x ** 2 + y ** 2 + z ** 2),
    { x, y }:    Math.sqrt(x ** 2 + y ** 2),
    [...]:       vector.length,
    else: {
        throw new Error("Unknown vector type");

match (p) {
    { x, y } if x === y: true,
    else: false

This combined with arrow syntax could be a really powerful feature when dealing with unstructured/variable datasets in a functional manner so something like.

customers = => match(e){
    { x }: e.x //if an object with the property x
    [ {x}, ... ]: e[0].x // if an array with at least 1 object with x as a property 
    { x, y }: e.y //if an object that has the properties x and y

NB: the above is pseudo code based on the proposal.

This could be used to transform data from a collection of similar but slightly differing states. Strongly typed functional languages such as F# have "Discriminated Unions" that are often used in tandem with this feature, though the dynamic nature of JavaScript allows us to deal with collections of data with different values and types out of the box.

Like all new syntax, it can look a bit cryptic at first but it's quite expressive once you take your time to get your head around it.

Final thoughts

So some or all of these features may not make it through into the language but given the increasing things we can use JavaScript for as well our need to work in a nonblocking manner but still allow a human being to read our code, there are many compelling reasons for all of these proposals.

If there's a feature that you're wanting to see in the language (you can check out all the proposed features) why not leave a comment below and share your views on the topic. Anyway thanks for reading.