markdown guide

Although not in the language yet, I'm excited to see top-level await, pattern matching as well as the null coalesce operator progress and land in the language. Top-level await is already at stage 3, so that is pretty much a shoe in.

Here's the repos for those interested:

GitHub logo tc39 / proposal-top-level-await

top-level `await` proposal for ECMAScript (stage 3)

ECMAScript proposal: Top-level await

Champion: Myles Borins

Status: Stage 3


Top-level await enables modules to act as big async functions: With top-level await, ECMAScript Modules (ESM) can await resources, causing other modules who import them to wait before they start evaluating their body.


Limitations on IIAFEs

With await only available within async functions, a module can include an await in the code that executes at startup by factoring that code into an async function:

// awaiting.mjs
import { process } from "./some-module.mjs"
let output
async function main() {
  const dynamic = await import(computedModuleSpecifier)
  const data = await fetch(url);
  output = process(dynamic.default, data);
export { output };

This pattern can also be immediately invoked. You could call this an Immediately Invoked Async Function Expression (IIAFE), as a play on IIFE idiom.

// awaiting.mjs

GitHub logo tc39 / proposal-pattern-matching

Pattern matching syntax for ECMAScript

ECMAScript Pattern Matching


Stage: 1

Author: Kat Marchán (npm, @maybekatz)

Champions: Brian Terlson (Microsoft, @bterlson), Sebastian Markbåge (Facebook, @sebmarkbage), Kat Marchán (npm, @maybekatz)


This proposal adds a pattern matching expression to the language, based on the existing Destructuring Binding Patterns.

There's many proposals potentially related to this one, and other proposals might mention interaction with this. This file includes casual, example-based discussion of the proposal, and there's also a document describing the core semantics in more formal language, which will be iterated over into the final Spec-ese.

There's also a document including suggestions for other future proposals, which are dependent on this one, but do not directly affect the main behavior of the feature.

This proposal was approved for Stage 1 in the May 2018 TC39 meeting, and slides for that presentation are available.

This proposal draws…

GitHub logo tc39 / proposal-nullish-coalescing

Nullish coalescing proposal x ?? y

Nullish Coalescing for JavaScript


Current Stage:

  • Stage 2


Overview and motivation

When performing optional property access in a nested structure in conjunction with the optional chaining operator, it is often desired to provide a default value if the result of that property access is null or undefined. At present, a typical way to express this intent in JavaScript is by using the || operator.

const response = {
  settings: {
    nullValue: null
    height: 400
    animationDuration: 0
    headerText: ''
    showSplashScreen: false

const undefinedValue = response.settings?.undefinedValue || 'some other default'; // result: 'some other default'
const nullValue = response.settings?.nullValue || 'some other default'; // result:

Oh man I didn't know about the pattern matching proposal! I've been waiting for that exact feature in JS ever since I encountered it in Ruby!!! 😍


Oooo I hadn't heard of top-level await before. That's awesome!


Pattern matching is one of my favorite features of Standard ML and functional languages. Hopefully they add it to Javacript.


While this is useful, it makes the code look undecided 😃 I already see all kinds of good practices that limit the use of this


I can't speak for the broader ecosystem, as I actively avoid boarding hype-trains as they tend to have cabins full of people arguing for argument sake, and I can't sit quietly and enjoy my coffee (admittedly, an analogy stretched too far). I can, however, speak to what I find new and interesting after 20 years of JavaScript development:

  1. If you haven't checked out CoffeeScript 2 with await, you're missing out. I contributed to the death of CoffeeScript by mistake but remained a loyal fan. When version 2 came out with its brilliant interpretation of asynchronicity, I jumped all over it, and have written 3 applications using it since. The combination of "everything is an expression" + no need to declare async + Promise-based APIs means that you can write JS now that reads like PHP...which I realize may not seem like a huge plus to people, but in PHP you can read from a Database, send an email, and import a file without ever worrying about if what you're doing is synchronous or not.

  2. The industry is starting to standardize on React/Vue, which means that Web-based frontends are finally being designed using components. Right now dev teams are still figuring out the implications to this, but eventually, people will start to understand not only how to build reusable components, but also how to use reusable components. For example, many React devs don't fully understand when to use props.children, despite that being a core reuse mechanic of the framework. Over time, people will start to use async-queues to connect components (what we're starting to see with Microfrontends) as well as techniques such as declarative component locators, so that UIs can be built from JSON configurations without having to write any code at all.

  3. The implications of React Native. We have yet to have a "killer app" React Native app, but it's coming. When it does, it will tip the scales such that it will truly not make sense to build a native app over using React Native. When that happens, Apple and Google will have to respond, as they will have lost control over their app ecosystem. I am watching the news every day looking for that shift, but if it does happen, it will be the most impactful thing to happen to the JavaScript ecosystem since the death of the Java Applet.


React Native still has to essentially compile to what’s available in the native ecosystem right?

As long as the user experience is solid it doesn’t seem like something Google and Apple would be overly concerned about eh?

They’d still be gatekeepers even if the downstream implementation details change.


All true, which is why the situation is so deliciously interesting.

From a technical perspective, neither company should care. Google/Alphabet may very well not care, but there's no way Apple has invested all that is has in Swift and XCode to not be able to dictate the features that are and are not supported in iOS apps - which they inevitably lose with a robust enough React Native ecosystem. Ultimately, Apple has an extremely low amount of chill when it comes to people creating meta-frameworks for their apps, but what can they really do with React Native? Not a thing, as far as I can tell. But still, they're Apple - they're not going to allow control to be ceded to - of all people - a framework maintained primarily by Facebook.

I have my popcorn and am watching the situation play out.


svelte: it's more reactive than react and makes programming more inclusive which is my mantra ;)


I find TypeScript to be exciting right now. It seems that the community became a lot more open to it and even excited about it. It improves the way we interact with 3rd party libraries, with our own code, and makes things better and cleaner. I believe that the next steps for JavaScript / TypeScript will be, like for most other modern languages, to adapt more standards in writing clean code. We may see more things like dependency inversion and separation of concerns.

I find framework wars to be mostly distracting (e.g. recent thing between React and Svelte). They implement and reimplement the wheel, they try to solve the same problem, each time slightly differently, but they don't solve new problems, and, in the end, don't make developers that much more efficient. My hope is that people will realize this and start separating their business logic away from the frameworks rather than putting it in the components, and use frameworks as plug-in if they choose so.


electron is one area where you need to pay attention. Though personally I feel its a crap due to its super bloat and bad performance (a browser container for each app, really?), there is no denying that there are very few players in that niche (seamless OS independence).

Unless Microsoft comes up with a fully platform independent version for WinForms/WPF or Oracle steps up their game with JavaFX, electron has a very super-bright future on desktops.


Microfrontends - My twitter feed is filled with people fighting over what micro frontends are and not. Then there's Jamstack, how do we even keep up with technology?


Still waiting for decorators. Looking forward to Vue 3.


Microfrontends, lerna with tailor and cloud functions


Const thing = const {something: here}

I hope the const on the value is decided to be immut or something else. The immutable keyword for values would be a game changer.

Classic DEV Post from Jan 16

What would you like to see on your DEV profile?

If we were to rethink the DEV profile, what would you like to see on it?

Ben Halpern profile image
A Canadian software developer who thinks he’s funny. open source and it's magnificent

Sign Up