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


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.


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?


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.


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.


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 24

What was your win this week?

Got to all your meetings on time? Started a new project? Fixed a tricky bug?

Ben Halpern profile image
A Canadian software developer who thinks he’s funny. He/Him.