DEV Community: Andrew Nosenko

WPF in 2021: alive, dead or on life support?

Andrew Nosenko — Mon, 26 Jul 2021 09:39:14 +0000

Recently I've been participating in a team discussion about whether or not to choose WPF as a framework for a new "greenfield" Windows-only application. The application itself isn't expected to have a sophisticated UI, but it might be required to use WebView2 and/or some 3rd party controls for document rendering, viewing and printing.

I'm writing this post as someone with substantial .NET/WPF background, who has lots of fond memories about WPF (and some bitter ones, too). I am not trying to diminish the value of this framework, but rather to evaluate where it stands nowadays in Microsoft Desktop development roadmap.

From what I could tell, these days even Windows Forms is getting more love from Microsoft than WPF. I hope I'm wrong, but I'm observing certain signs of WPF being currently either shelved or placed into a very low-maintenance support mode:

The WPF roadmap itself (or, pretty much, the lack of it, if compared to that of WinForms). According to this document, the only ongoing effort is "incorporating .NET Framework servicing fixes into .NET Core 3.1 and .NET 5".
"Is this repo dead" issue in the WPF repo. Lots of interesting comments in that thread, particularly, this one:

The real reason was already communicated on community calls over on YouTube. The team was merged with WinUI and created from zero, apparently everyone from the original team is gone, and the new team is very resource constrained so they don't manage to deliver more than a couple of fixes. Now we can complain that instead of doing WPF, WinUI, MAUI, Blazor on Electron (what a bad idea!) they should focus on just having one UI-vnext framework, but after UWP failure, they don't seem to be able to decide what to do, each group talks differently about the "vision".

Some folks in that thread even voiced initiatives to fork WPF and maintain it independently of Microsoft.
Microsoft's Igor Velikorossov on what's new in Windows Forms:
- For .NET 5: https://devblogs.microsoft.com/dotnet/whats-new-in-windows-forms-runtime-in-net-5-0.
- For .NET 6 Preview 5: https://devblogs.microsoft.com/dotnet/whats-new-in-windows-forms-in-net-6-0-preview-5
It's great to see WinForms being actively maintained, but what about WPF? Check out the grieving readers' comments. Back then, Microsoft's PM Premalini David replied with a promise of boosting up the WPF team internal resources. Looking at the WPF repo commit history now, that doesn't seem to have been happening yet.
"What's new in WPF for .NET 5" on docs.microsoft.com. Actually, this page doesn't exist for .NET 5, it falls back to the .NET Framework 4.x content, when you choose ".NET 5". Besides some information on adding ARM CPU support, I couldn't find any details about what's new in WPF since it got ported to .NET Core 3 in 2019.

On a side note, the "what's new" section does exist for .NET 5 Windows Forms.

I expected WPF to be an ultimate container for hosting WebView2, to help modernizing the enterprise desktop WPF apps, which typically still use the legacy IE11-based WebBrowser control. As of now, this is far from being the case, either:

Rick Strahl's blog post about his titanic efforts on integrating WebView2 into his WPF-based Markdown Monster Editor:
https://weblog.west-wind.com/posts/2021/Apr/15/WebView2-Forwarding-Alt-Keys-to-a-Host-WPF-Window.
My own struggle with WPF + WebView2 keyboard and focus issues:
https://github.com/MicrosoftEdge/WebView2Feedback/issues/468#issuecomment-855810839. I believe that can't be properly resolved without making changes on the WPF side.

Overall, while there are some ongoing efforts from other teams at Microsoft to continue supporting WPF as a platform (that includes WebView2, BlazorWebView, XAML Islands, Visual Studio Designers), the WPF GitHub repo itself has been very quiet lately.

What's on Microsoft's own radar for Windows-only UI development these days? Well, the official future path appears to be WinUI 3. It was in the spotlight during Build 2021 and the recent Windows 11 presentation event. The modern Windows Terminal app — a big open-source hit enjoying a well-deserved recognition — is built with WinUI and mostly in C++.

Microsoft also seems to be big about WebView2 for the apps where HTML UI is shared between Web and Desktop. The upcoming Teams 2.0 is a good example of such approach, it's a thin WinUI host for WebView2. I ranted with more details about the new Teams 2.0 architecture (TLTR: it doesn't use .NET on the client side at all).

Apparently, Microsoft is also well invested into React Native for Windows (a very active repo) and Fluent UI framework (used by Office 365).

For .NET folks who want to stick with C# for sharing HTML UI between Web and Desktop (with little or no JavaScript/React/etc), Microsoft will be releasing WebView2-based BlazorWebView, supported on WinForms, WPF and .NET MAUI:

Using Blazor and a hybrid approach you can start decoupling your UI investments from WPF & Windows Forms. This is a great way to modernize existing desktop apps in a way that can be brought forward onto .NET MAUI or used on the web. You can use Blazor to modernize your existing Windows Forms and WPF apps while leveraging your existing .NET investments.

This sounds like a .NET version of Electron on steroids to me. At this stage, it isn't something I'd like to take for a ride with a new Desktop project, unless there is already a working Blazor SPA web app to wrap as a desktop app. I've tried BlazorWebView with a simple WinForms-based app, and currently (as of NET 6 Preview 7) it doesn't feel close to the production quality yet. Nevertheless, BlazorWebView is an impressive piece of technology, I hope it will mature and won't be abandoned.

Besides, the UI technologies Microsoft use for their own mainstream projects aren't necessarily always what they recommend to the rest of the dev world. This can be a particularly confusing domain at the moment, just check this Twitter thread by Jerry Nixon, a Microsoft engineer:

// Detect dark theme var iframe = document.getElementById('tweet-1407013885127933952-300'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1407013885127933952&theme=dark" }

I'd also highly recommend reading Nick Randolph's "The Future of Windows (and Other Platforms) Development". It's a great take at clarifying the confusion in the fragmented space of various Windows UI frameworks.

To wrap it up, there is a whole array of frameworks and meta-frameworks to choose from for Windows desktop development nowadays, including some cross-platform options (visit crossplatform.dev for a concise overview). A .NET developer can choose from:

WinForms
WPF
UWP (but be sure to read this announcement)
WinUI
Xamarin/MAUI
BlazorWebView
Windows Community Toolkit (with MVVM Toolkit)
Uno Platform
Avalonia
Comet
ReactiveUI
Chromely
EdgeSharp
Electron.NET

... and more. Back to our specific app case, I personally voted for Windows Forms, as odd as it may sound in 2021.

Some pro-WinForms points:

it is old and battle-tested but still being actively maintained (unlike WPF, presently);
has a simple, unopinionated and well-know API;
uses native Win32 UI controls under the hood and therefore …
… is easy to integrate with other native and managed controls or modernize with WebView2, BlazorWebView and/or XAML Islands. I'd expect fewer issues with the focus/keyboard interop as well, or at least, they should be easier to address, than with WPF.
can be abstracted behind something simple, like Model-View-Presenter Pattern, or something advanced, like Reactive UI;

can be deployed as a single EXE ~~(~75MB)~~ without needing admin rights, Windows Store, packaging, sideloading, tweaks to the Windows Developer settings, etc (updated: trimming no longer work in .NET 6 for WinForms/WPF):

dotnet new winforms -n app

dotnet publish app -r win-x64 -c Release --self-contained true -p:PublishSingleFile=true -p:PublishTrimmed=True -p:IncludeNativeLibrariesForSelfExtract=true -p:TrimMode=Link

dir /s app.exe

I've been using the .NET Core reincarnation of WinForms for #DevComrade, a small side project. It enables systemwide pasting without formatting by default, amongst a few other productivity improvement features. Building it with WinForms has been a very positive experience so far.

Some late updates:

Microsoft's announcement about .NET 5/6 support not coming to UWP .NET projects.
My take on the above UWP announcement.
No trimming support for WinForms and WPF projects in .NET 6.
An interesting thread on HN, discussing current the state of UI development with .NET, amongst other things.
"The roadmap is outdated" issue in WPF repo.
I learnt that WPF is still used in Microsoft's Powertoy project and in the new Visual Studio Installer (migrated from Electron), not to mention VS2022 itself (still a .NET Framework 4.x project though).
There's hope that WPF team will eventually get a much needed resource boost (although still no signs this is happening, as of Nov'21):

// Detect dark theme var iframe = document.getElementById('tweet-1454510032985346056-769'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1454510032985346056&theme=dark" }

Thanks for reading! Feel free to leave a comment below or on Twitter.

Some thoughts on the new Microsoft Teams 2.0 architecture (WebView2/ReactJS)

Andrew Nosenko — Sat, 17 Jul 2021 12:38:13 +0000

Updated on 2021/07/24, Electron.js has published a great article on comparing Electron to WebView2. It's reassuring to know an improved form of IPC (between the WV2 host and JavaScript) is coming, in form of CBOR.

If you've been following the news from the remote collaboration software industry, you've probably heard that Microsoft Teams have migrated from Electron/Angular to WebView2/React for the upcoming version 2.0, which is also a part of Windows 11. A tweet by Rish Tandon, the CVP of engineering for Teams:

// Detect dark theme var iframe = document.getElementById('tweet-1408085784016539653-81'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1408085784016539653&theme=dark" }

As a software engineer who is involved in both web conferencing tools and Windows Desktop app development, I've been curious about this move. Particularly, whether or not they may also be utilizing .NET on the Desktop now, along with WebView2 (and JavaScript interop via WebView2 IPC).

I thought, as long as they don't use Electron anymore and are being more Windows-centric now, they might as well be leveraging the power of .NET to do some media pre-processing on the client side. Similar to what Zoom is doing with WebAssembly, but potentially, in a more efficient way with some compiled .NET code?

I didn't have a chance to install any insider builds of Windows 11 yet, but with a little help from a fellow redditor, I managed to get a sneak peek into Teams 2.0 internals, using SysInternals' excellent ListDLLs tool.

Take these thoughts with a grain of salt, currently they are just mine (somewhat educated) guesses/speculations.

Teams 2.0 appears to be a Windows Store package, it's installed under "C:\Program Files\WindowsApps". Presumably, it can be listed from PowerShell with Get-AppxPackage -allusers *teams*.
I could not detect any traces of the .NET runtime DLLs in the memory space of the new Teams process. It does look like they use some Azure C++ SDK DLLs (azure-core.dll, azure-storage-blobs.dll, azure-storage-common.dll), a set of Boost C++ libraries (boost_*.dll) and SQLite (sqlite3.dll, presumably for storing the app's local state).
They use WebView2 (aka WV2) in shared "evergreen" mode ("C:\Program Files (x86)\Microsoft\EdgeWebView\Application\91.0.864.70\EBWebView\x64\EmbeddedBrowserWebView.dll").
It's now a single-instance msteams.exe process. This may look as a departure from the multi-process architecture of Electron, but of course, WV2 still runs a bunch of its own msedgewebview2.exe processes. No surprise here, as it's still a customized version of Chromium under the hood.

Is this pool of WV2 Chromium processes shared across other WV2 instances? I don't think so, but let's ask the WV2 team directly.
It's hard to tell if they just use pure WebRTC API inside WebView2, or do some custom video processing on the client, but I haven't spotted any FFmpeg-like DLLs or anything that might look like custom codecs (the Electron-based version of Teams does bundle ffmpeg.dll, although it might just be a part of Electron runtime).

Overall, Teams 2 appears to be a basic WinUI 3 Desktop C++ App, not using WinForms, WPF or any other .NET libraries, with all-HTML UI made with React and hosted in WV2. Except, perhaps, for the UI pieces like top-level menus bar, status bar and Windows native notifications.

I actually haven't seen the full UI yet, but such approach would make sense if they still aim to share the UI codebase between the Desktop app and the browser web app (at https://teams.microsoft.com). The HTML UI is most likely built with Fluent UI React, in line with the rest of Office 365.

One issue I've myself dealt with while hosting WV2 in a WPF app was with accelerator keys of native peer WPF controls and menus, when the focus is inside WV2. It'll be interesting to see if a Win UI 3 host app is also affected by this, how Teams 2.0 deals with this.

That's the whole picture I've got for now. I'd appreciate if someone who might know more could jump in and correct me. I'll be updating this post as I learn anything new about Teams 2.0 architecture.

Automation with Deno: a tiny text template processor in JavaScript

Andrew Nosenko — Fri, 04 Jun 2021 10:18:20 +0000

Basically, a three-liner:

const templateText = await Deno.readTextFile(Deno.args[0]);
const render = new Function("return `" + templateText + "`").bind(templateParams);
console.log(render());

It uses interpolated JavaScript template strings (aka template literals) to process a generic text template file. For example:

# example of a YAML template
request:
  ip: ${ this.dateTime.client_ip }
  ip_time_zone: ${ this.dateTime.abbreviation }
  server_utc_time: ${ this.dateTime.utc_datetime }
  local_time: ${ new Date() }

Here, this refers to the templateParams object we passed from the above Deno script. This text file is in fact just a multi-line template strings, with all the corresponding syntax rules you'd follow inside a JavaScript "backtick" string. Hey, it's even possible to use await inside `${...}` :)

What is this useful for?

I believe it can be useful for build automation, including certain CI/CD-related tasks.

Deno itself is a very self-cointained JavaScript/TypeScript runtime engine. It comes as a single executable file which can be used without any external dependencies. Yet it offers an extensive built-in API to deal with files, networking etc.

More so, any specific Deno version can be easily installed into a local folder without admin rights. E.g., to install Deno v1.10.3 on Windows with PowerShell:

# install Deno v1.10.3 into ./bin
$env:DENO_INSTALL = "$pwd"
$v="1.10.3"
iwr https://deno.land/x/install/install.ps1 -useb | iex

Personally, I've never been comfortably fluent with Bash, PowerShell etc., so I find Deno very handy for quick, shell-like scripting with JavaScript. With Deno, I can quickly run a one-liner like this:

$ deno eval -p "await fetch('https://example.com').then(r => r.text()).then(t => t.match('example'))"

Of course, Deno is much more capable than that, but that's outside the scope of this article.

An example of templating

This example is a bit contrived, but it illustrates the purpose. Here we make a simple fetch request to https://worldtimeapi.org/api/ip and save the results, using the above YAML template:

// deno run --allow-read --allow-net nascentTextGen.js sample.yaml.template 

const templateParams = {
  dateTime: await fetch("https://worldtimeapi.org/api/ip").then(r => r.json()),
  args: Deno.args
};

const templateText = await Deno.readTextFile(Deno.args[0]);
const render = new Function("return `" + templateText + "`").bind(templateParams);
console.log(render());

Output:

# example of a YAML template
request:
  ip: a.b.c.d
  ip_time_zone: AEST
  server_utc_time: 2021-06-04T01:32:56.595373+00:00
  local_time: Fri Jun 04 2021 11:32:55 GMT+1000 (Australian Eastern Standard Time)

Code

Clone or fork this simpe demo project. Then:

to install Deno (PowerShell):

pwsh -f _installDeno.ps1

to run the sample:

pwsh -f _demo.ps1

Some more advanced general-purpose templating tools

This little project was inspired by a search for a JavaScript-based general-purpose text templating tool.

Of course, this approach may only be useful for simple, "logic-less" templates. If you need branching and looping constructs like if, for, while or function, there are a lot more powerful and actively maintained alternatives out there:

Nunjucks: https://github.com/mozilla/nunjucks (there's even a VSCode extension for Nunjucks)
Mustache: https://github.com/janl/mustache.js
EJS: https://github.com/mde/ejs
T4 (C#/.NET): https://github.com/mono/t4
and more...

Await inside JavaScript template strings

Andrew Nosenko — Wed, 02 Jun 2021 06:59:27 +0000

Did you know it is possible to use await inside interpolated JavaScript template strings (aka template literals)? I personally did not, and have just discovered that by an accident.

For example, try this with Node or Deno (runkit and gist; save the code as .mjs so it runs as an ESM module):

const delay = (ms, result) => 
  new Promise(r => setTimeout(r, ms, result));

const interpolated = `Hello, ${await delay(1000, "World!")}`; 

console.log(interpolated);

This code works in the browser console as well, verified for Chrome/Edge/Firefox.

It does require the top-level await support, or otherwise has to reside inside an async function, as it's basically just a syntactic sugar for:

const interpolated = "Hello, " + await delay(1000, "World!");

Why would this feature be useful? For one thing, I can think of a poor man's text templating engine for JavaScript, where instead of delay we might be using something like fetch, readFile or any other Promise-based APIs.

For now, I've added this to my collection of a few handy JavaScript tricks.

Updated, here's a follow-up article: Automation with Deno: a tiny text template processor in JavaScript.

Syntactic sugar: yet another async/await question for JavaScript interviews

Andrew Nosenko — Tue, 04 May 2021 11:08:55 +0000

Whenever I stumble upon "[something] is a syntactic sugar", I appreciate when it is accompanied by a good technical explanation of what exactly that particular "sugar" is translated to behind the scene. Which isn't always the case.

For instance, try googling "async await syntactic sugar". I don't think the statements like "async is a syntactic sugar for promises" are very helpful in grokking async/await. In my opinion, the concept of the finite-state machine would be very important in this context, yet I couldn't spot the phrase "state machine" in the top Google-quoted results.

So, here is one question I personally find interesting and relevant for the both sides of a JavaScript/TypeScript interview (as well as C#, F#, Python, Dart or any other programming language which has adopted the async/await syntax):

How would you go about implementing the following async function <funcName> as a simple state machine, without using the keywords async, await or yield?

I think it's a one-shot-many-kills kind of question, potentially covering the knowledge of the basic topics like promises, closures, exception handling, recursion, in addition to async/await and the state machine concepts themselves.

For a practical JavaScript example, let's take the following simple asynchronous workflow function, loopWithDelay. It runs a loop doing something useful (doWhat), with a certain minimal interval between iterations, until the stopWhen callback signals the end of the loop:

async function loopWithDelay({ doWhat, stopWhen, minInterval }) {
  while (!stopWhen()) {
    const interval = startInterval(minInterval);
    await doWhat();
    const ms = await interval();
    console.log(`resumed after ${ms}ms...`);
  }
  console.log("finished.");
}

We might be calling loopWithDelay like below (runkit). In JavaScript, anything can be awaited, so this works regardless of whether or not doWhat returns a promise:

await loopWithDelay({
  doWhat: doSomethingForMs(150), 
  stopWhen: stopAfterMs(2000), 
  minInterval: 500
});

// a higher-order helper to simulate an asynchronous task
// (for doWhat)
function doSomethingForMs(ms) {
  let count = 0;
  return async () => {
    const elapsed = startTimeLapse();
    await delay(ms); // simulate an asynchronous task 
    console.log(`done something for the ${
      ++count} time, it took ${elapsed()}ms`);
  }
}

// a higher-order helper to tell when to stop
function stopAfterMs(ms) {
  const elapsed = startTimeLapse();
  return () => elapsed() >= ms; 
}

// a simple delay helper (in every single codebase :)
function delay(ms) { 
  return new Promise(r => setTimeout(r, ms)); }

// a higher-order helper to calculate a timelapse
function startTimeLapse() {
  const startTime = Date.now();
  return () => Date.now() - startTime;
} 

// a higher-order helper for a minimal interval delay
function startInterval(ms) {
  const sinceStarted = startTimeLapse();
  return () => {
    const sinceDelayed = startTimeLapse();
    return delay(Math.max(ms - sinceStarted(), 0))
      .then(sinceDelayed);
  };
}

Of course, there are many ways to rewrite this loopWithDelay without using async/await. We don't have to stricly follow a typical state machine implementation as done by programming language compilers (which can be a bit intimidating, e.g., look at what TypeScript generates when it targets ES5. Interestingly, when targeting ES2015, TypeScript transpiles async/await using generators as an optimization).

To implement loopWithDelay manually as a state machine, we need to break down the normal flow control statements (in our case, the while loop) into individual states. These states will be transitioning to one another at the points of await. Here's one take at that, loopWithDelayNonAsync (runkit):

function loopWithDelayNonAsync({ doWhat, stopWhen, minInterval }) {
  return new Promise((resolveWorkflow, rejectWorkflow) => {
    let interval;

    // a helper to transition to the next state, 
    // when a pending promise from 
    // the previous state is fulfilled
    const transition = ({ pending, next }) => {
      // we fail the whole workflow when 
      // the pending promise is rejected or
      // when next() throws 
      pending.then(next).catch(rejectWorkflow);
    }

    // start with step1
    step1();

    // step1 will transition to step2 after completing a doWhat task
    function step1() {
      if (!stopWhen()) {
        // start the interval timing here
        interval = startInterval(minInterval);
        // doWhat may or may not return a promise, 
        // thus we wrap its result with a promise
        const pending = Promise.resolve(doWhat());
        transition({ pending, next: step2 }); 
      }
      else {
        // finish the whole workflow 
        console.log("finished.");
        resolveWorkflow();
      }
    }

    // step2 will transition to step3 after completing a delay
    function step2() {
      transition({ pending: interval(), next: step3 }); 
    }

    // step3 will transition to step1 after showing the time lapse
    function step3(prevStepResults) {
      // prevStepResults is what the pending promise 
      // from step2 has been resolved to
      console.log(`resumed after ${prevStepResults}ms...`);
      step1();
    }
  });
}

await loopWithDelayNonAsync({
  doWhat: doSomethingForMs(150), 
  stopWhen: stopAfterMs(2000), 
  minInterval: 500
});

Equipped with async/await, we should never have to write code like loopWithDelayNonAsync in real life. It still might be a useful exercise though, especially for folks who first got into JavaScript after it had received the native support for async functions.

Rather than taking async/await syntactic sugar for granted, I think it helps to understand how it works behind the scene as a state machine. It also amplifies how versatile, concise and readable the async/await syntax is.

For a deep dive into async/await under the hood in JavaScript, the V8 blog has an awesome article: "Faster async functions and promises".

A few handy JavaScript tricks

Andrew Nosenko — Tue, 01 Dec 2020 11:45:01 +0000

I'd like to document a few neat JavaScript tricks and patterns I've recently learnt from Twitter and other online resources (which I sadly haven't kept track of). All the credits go to the online JavaScript community.

class is an expression, what it extends is also an expression
this in static class methods
Invoking an IIFE without extra brackets
Invoking an async IIFE without extra brackets
Destructuring of a function argument inline
Partial destructuring of a function argument inline
Using expressions in switch
Passing a non-function object as event handler to addEventListener
Checking if a variable is of specific type
Checking if a variable is nullish (i.e., null or undefined)
Converting to primitive types with Symbol.toPrimitive
A mnemonic way of ignoring promise errors (where applicable)
Thenables can be useful side-by-side with promises
Telling which promise has settled first in Promise.race
"Promisifying" a synchronous function call to defer exception handling
Symbol.species can be useful when extending standard classes
await can be used inside string templates

`class` is an expression, what it extends is also an expression

Similar to function funcName() { ... }, class className { ... } is an expression which can be assigned to a variable or passed over as a function argument. And className here can be optional as well, like with anonymous functions. More so, the base class is also an expression. For example, the following is possible:

class Base1 {
  whatAmI() { 
    return 'Base1';
  }
}

class Base2 {
  whatAmI() { 
    return 'Base2';
  }
}

const createDerivedClass = base => class extends base {
  whatAmI() {
    return `Derived from ${super.whatAmI()}`;
  }
};

const Derived1 = createDerivedClass(Base1);
// output: Derived from Base1
console.log(new Derived1().whatAmI());

const Derived2 = createDerivedClass(Base2);
// output: Derived from Base2
console.log(new Derived2().whatAmI());

This can be useful for dynamic compositions of class inheritance trees, including mixins. I've learnt about it from Justin Fagnani's excellent "Mixins and Javascript: The Good, the Bad, and the Ugly."

Conveniently, `this` in static class methods refers to the class itself

Thus, polymorphism is possible for static methods, like with oncreate method below:

// Base
class Base {
  static create() { 
    const instance = new this();
    this.oncreate(instance);
    return instance; 
  }

  static oncreate(instance) { 
    console.log(`Something of the base class ${
      Base.name} has been created.`); 
  }
}

// Derived
class Derived extends Base {
  static oncreate(instance) { 
    console.log(`It's a new instance of ${
      Derived.name}, all right!`); 
  }
}

// output: Something of the base class Base has been created.
const base = Base.create(); 

// output: It's a new instance of Derived, all right!
const derived = Derived.create(); 
// output: true
console.log(derived instanceof Derived);

I learnt about new this() when I stumbled upon this tweet.

Invoking an IIFE (Immediately Invoked Function Expression) without extra brackets

We can use the void operator for that, where void clearly indicates we want to discard the result of an expression (which an IIFE itself is):

void function debug() {
  if (confirm('stop?')) debugger;
}();

I believe it's more readable and mnemonic than wrapping the function with brackets:

(function debug() {
  if (confirm('stop?')) debugger;
})();

If we do need the result:

const rgb = function getColor(color) {
  return { 
    red: '#FF0000',
    green: '#00FF00',
    blue: '#0000FF'
  }[color];
}(car.color);

Invoking an `async` IIFE (Immediately Invoked Function Expression)

Similarly to the above, we don't need the wrapping brackets:

await async function delay() {
  const start = performance.now();
  await new Promise(r => setTimeout(r, 1000));
  console.log(`elapsed: ${performance.now() - start}`);
}();

Destructuring of a function argument inline

function output ({firstName, lastName}) {
  console.log(firstName, lastName);
}

const person = {
  firstName: 'Jane',
  lastName: 'Doe'
};

output(person);

Partial destructuring of a function argument inline

function output ({firstName, ...rest}) {
  console.log(firstName, rest.lastName, rest.age);
}

const person = {
  firstName: 'John',
  lastName: 'Doe',
  age: 33
};

output(person);

Using expressions in `switch`

const category = function getCategory(temp) {
  // the first `case` which expression is `true` wins
  switch(true) {
    case temp < 0: return 'freezing';
    case temp < 10: return 'cold';
    case temp < 24: return 'cool';
    default: return 'unknown';
  }
}(10);

Passing a non-function object as event handler to `addEventListener`

The trick is to implement EventListener.handleEvent:

const listener = Object.freeze({
  state: { message: 'Hello' },
  handleEvent: event => {
    alert(`${event.type} : ${listener.state.message}`);
  }
});

button.addEventListener('click', listener);

Checking if a variable is of specific type

This method works for both primitive value types and their wrapper classes: String, Number, Boolean, Object.

Could you predict which console output is common for s1 and s2 snippets below?

const s1 = 's'; 
console.log(s1 instanceof String);
console.log(typeof s1);
console.log(s1.constructor === String);

const s2 = new String('s'); 
console.log(s2 instanceof String);
console.log(typeof s2);
console.log(s2.constructor === String);

I could not, so I've made a RunKit:

s1 instanceof String: false
typeof s1: string
s1.constructor === String: true
s2 instanceof String: true
typeof s2: object
s2.constructor === String: true

Interestingly, it's only s1.constructor === String and s2.constructor === String which are consistently true for both s1 (a primitive string value) and s2 (an instance of String class).

It's even more fun in TypeScript, which may feel odd for a person coming to JavaScript with C# or Java background.

So, to check if variable s represents a string, the following works equally well for primitive values and their wrapping class types:

const isString = s?.constructor === String;

We can also make it work across realms (an iframe or a popup):

const isString = s?.constructor.name === 'String';

Some may argue that we shouldn't be using class wrappers for primitive values at all. Indeed, we should not. But we have an option to make our own code behave correctly when it is called by a 3rd party, no matter if it's given a primitive value or a wrapper class object as an argument.

For example, the following works consistently for all three cases (note the use of valueOf):

takeBool(false);
takeBool(Boolean(false));
takeBool(new Boolean(false));

function takeBool(b) {
  if (b?.constructor !== Boolean) throw new TypeError();
  console.log(b.valueOf() === false? "is false": "is true");
}

Checking if a variable is `nullish` (i.e., `null` or `undefined`)

Traditionally, this is done with loose equality operator ==, for example:

if (a == null) {
  // a is either null or undefined
  console.log((a == null) && (a == undefined)); // both true 
}

This might arguably be the only meaningful use of the loose equality == operator (as opposed to the strict equality operator ===).

If however you want to avoid using == and != operators by all means, below are some alternative ways of performing the "nullish" check:

// The nullish coalescing (??) operator returns 
// its right-hand side operand when its left-hand side operand 
// is null or undefined, and otherwise returns 
// its left-hand side operand.

if ((a ?? null) === null) {
  // a is either null or undefined
}

if (Object.is(a ?? null, null)) {
  // a is either null or undefined
}

if (Object.is(a ?? undefined, undefined)) {
  // a is either null or undefined
}

// all standard or properly derived custom JavaScript objects 
// have standard properties like these:
// `constructor`, `valueOf`, `toString`.
// Note though the below doesn't work for exotic cases, 
// e.g. where a = Object.create(null):

if (a?.constructor) {
  // a is neither null nor undefined
}

if (!a?.constructor) {
  // a is either null or undefined
}

if (a?.valueOf === undefined) {
  // a is either null or undefined
}

What's nice about the optional chaining operator is that the result is unambiguously undefined when a is either null or undefined. This allows for some fancy expressions like this:

class Derived extends Base {
  constructor(numericArg) {
    // make sure the argument we pass to the base class'
    // constructor is either a Number or DEFAULT_VALUE
    super(function() {
      switch (numericArg?.constructor) {
        case undefined: return DEFAULT_VALUE;
        case Number: return numericArg.valueOf();
        default: throw new TypeError();
      }
    }());
  }
}

One notable thing about the nullish coalescing operator is that in a ?? DEFAULT_VALUE it will pick DEFAULT_VALUE when a is either null or undefined (as opposed to a || DEFAULT_VALUE, which picks DEFAULT_VALUE when a is falsy).

Converting to primitive types with `Symbol.toPrimitive`

The well-know symbol Symbol.toPrimitive defines how an object can be converted to primitive types, as in the example below. Note also the use of Symbol.toStringTag:

class Item {
  #item;

  constructor(item) {
    if (item?.constructor !== Number) throw new TypeError();
    this.#item = item.valueOf();
  }

  [Symbol.toPrimitive](hint) {
    // hint can be "number", "string", and "default" 
    switch (hint) {
      case 'number': 
        return this.#item;
      case 'string': 
      case 'default': 
        return `Item: ${this.#item}`;
      default:
        return null;
    }
  }

  get [Symbol.toStringTag]() {
    return this.constructor.name;
  }
}

const item = new Item(42);
console.log(Number(item));
console.log(String(item));
console.log(item.toString());
console.log(item);

/* Output:
42
Item: 42
[object Item]
Item {}
*/

A mnemonic way of ignoring promise errors (where applicable)

await promise.catch(e => void e);

This literally says: "void that error" and it is ESLint-friedly. I see it becoming increasingly useful, to avoid potential troubles with unhandled promise rejections in Node v15+. For example:

// • we may want to start workflow1 before workflow2
const promise1 = workflow1();
const promise2 = workflow2();
// • and we may need workflow2 results first
// • if it fails, we don't care about the results of workflow1
// • therefore, we want to prevent 
//   unwanted unhandled rejection for promise1
promise1.catch(e => void e); 
// • observe workflow2 results first
await promise2; 
// • if the above didn't throw, now observe workflow1 results
await promise1;

Thenables can be useful side-by-side with promises

I've previously blogged about thenables. In a nutshell, here's how to create a jQuery.Deferred-like thenable object that can be awaited:

function createDeferred() {
  let resolve, reject;

  const promise = new Promise((...args) => 
    [resolve, reject] = args);

  return Object.freeze({
    resolve, 
    reject,
    then: (...args) => promise.then(...args)
  });
}

const deferred = createDeferred();
// resolve the deferred in 2s 
setTimeout(deferred.resolve, 2000);
await deferred;

Telling which promise has settled first in `Promise.race`

Sometimes we need to know which promise became resolved or rejected first and thus won the race with Promise.race, similarly to Task.WhenAny in .NET. Linking my SO answer:

/**
 * When any promise is resolved or rejected, 
 * returns that promise as the result.
 * @param  {Iterable.<Promise>} iterablePromises An iterable of promises.
 * @return {{winner: Promise}} The winner promise.
 */
async function whenAny(iterablePromises) {
  let winner;

  await Promise.race(function* getRacers() {
    for (const p of iterablePromises) {
      if (!p?.then) throw new TypeError();
      const settle = () => winner = winner ?? p;
      yield p.then(settle, settle);
    }
  }());

  // return the winner promise as an object property, 
  // to prevent automatic promise "unwrapping"
  return { winner }; 
}

"Promisifying" a synchronous function call to defer exception handling

Credits: tc39-proposal-promise-try.

function ensureEven(a) {
  if (a % 2 !== 0) throw new Error('Uneven!');
  return a;
}

// • this throws:
const n = ensureEven(1);

// • this doesn't throw:
const promise = Promise.resolve().then(() => ensureEven(1));
// • until it is awaited
const n = await promise;

// • alternatively:
const promise = Promise(r => r(ensureEven(1)));

Hopefully, soon we'll be able to do:

const promise = Promise.try(() => ensureEven(1));

Until then, we can also use a polyfill like this one.

`Symbol.species` can be useful when extending standard classes

The well-know symbol Symbol.species was definitely little-known to me. MDN describes it as symbol that specifies a function-valued property that the constructor function uses to create derived objects.

What it means in reality is that sometimes JavaScript needs to create a fresh instance of an object, i.e., to reproduce an object without cloning. For example, Array.prototype.map creates a new array instance before doing any mapping:

class UltraArray extends Array {}
const a = new UltraArray(1, 2, 3);
const a2 = a.map(n => n/2);
console.log(a2 instanceof UltraArray); // true

It might be tempting to think about such kind of object reproduction this way:

const a2 = new a.constructor();

In reality though, it's done a bit differently, more like this:

const constructor = a.constructor[Symbol.species] ?? a.constructor;
const a2 = new constructor();

Thus, if we want map to use the base class Array for a new mapped instance, when map is invoked on an object of our custom class UltraArray, we can do this:

class UltraArray extends Array {
  static get [Symbol.species]() { return Array; }
}
const a = new UltraArray(1, 2, 3);
const a2 = a.map(n => n/2);
console.log(a2 instanceof UltraArray); // false
console.log(a2.constructor.name); // Array

When could this feature (seemingly not so useful) still be important? My answer would be: for deriving from and extending the standard Promise class with added functionality like DeferredPromise, AbortablePromise, etc. This probably deserves a separate blog post, which I plan to publish soon.

I hope you find these tips helpful

I plan to keep this post updated as I discover more fun JavaScript bits and pieces. Consider following me on Twitter if interested in these updates.

Grokking type conversion between TypeScript basic types, classes instances and object literals

Andrew Nosenko — Wed, 25 Nov 2020 01:22:24 +0000

Edited: I've now filed a related issue in the TypeScript repo:
A flag to make TypeScript more strict towards duck-typing classes.

A disclaimer: this post is coming from an OOP/C# person with a solid JavaScript background who's slowly learning TypeScript. If you're a TypeScript ninja, you should probably be already aware of these language specifics. I admit I should have thoroughly read the Handbook before starting coding with TypeScript, but who has time for that? :)

Let me start with a simple question, could you predict the output from the following TypeScript snippet?

let s1: String = "s"; 
console.log(s1 instanceof String)
console.log(typeof s1)
console.log(s1.constructor === String)

Here's a playground link for your convenience, and the output is:

false 
"string" 
true

So, s1 is not an instance of String (despite typed so), its typeof type is "string" but its constructor is nevertheless String. Coming from C#, this doesn't make a lot of sense 🙂

Now, try predicting this output:

let s2: String = new String("s"); 
console.log(s2 instanceof String)
console.log(typeof s2)
console.log(s2.constructor === String)

Here's a playground link, and the output is:

true 
"object" 
true

Now, s2 is an instance of String, its typeof type is now "object" but its constructor is still String.

Finally, this one (playground):

let s3: string = "s"; 
console.log(s3 instanceof String) // TypeScript error
console.log(typeof s3)
console.log(s3.constructor === String)

Output:

false 
"string" 
true

This might be confusing, but it makes sense if we recall that TypeScript doesn't have any runtime type system (unlike C#). It just emits JavaScript, using whatever nascent type system the current ECMAScript version of JavaScript has.

For example, the generated JavaScript for the first code snippet looks like this (compiled with tsc -t ESNext code.ts):

let s1 = "s";
console.log(s1 instanceof String);
console.log(typeof s1);
console.log(s1.constructor === String);

As a C# person, I might expect TypeScript to turn let s1: String = "s" into let s1 = new String("s") in JavaScript, because I declared s1 to be of a non-basic, class type String (rather than of a basic, primitive value type string).

Well, this is not how it works. Why? I asked this question on StackOverflow, and I got an excellent answer:

It is specifically a non-goal of the TypeScript language design to "add or rely on run-time type information in programs, or emit different code based on the results of the type system". So any suggestion or expectation of this sort should not be made.

To dig a bit deeper, the same relationship is true for classes and simple anonymous objects in TypeScript (playground):

interface IC {
    s: string;
}

class C implements IC {
    s: string;
    constructor(s: string) {
        this.s = s;
    }
}

const c1: C = new C("c1");
// true
console.log(c1 instanceof C); 

const c2: C = { s: "c2" };
// false
console.log(c2 instanceof C); 

const c3: IC = { s: "c3" };
// false
console.log((c3 as C) instanceof C)

This works the way it does because TypeScript is a "duck typing" language.

Note the as operator? This is a "type assertion", rather than some kind of type conversion that might affect the generated code. It will not magically turn an anonymous object into a instance of a class.

If the object is of type any or unknown, the as operator simply tells TypeScript that (to our best knowledge) the object has the expected set of properties and methods of the target type, to avoid compile-time errors. If that's not true, we'll most likely experience runtime errors.

If the object is anything other type than any or unknown, the as operator will make sure the target type is compile-time compatible.

If we want to verify this during runtime, we should be using "type guards" for that.

Thus, the lessons I've learnt are:

Reading "Advanced Types" from the Handbook is a must.
Leave your #C baggage behind the closed door. There is no added runtime type system in JavaScript code that TypeScript would emit, and it won't magically make instanceof work the way we might expect, coming from C#. A class object must be explicitly constructed with new MyClass() syntax for instanceof to work, and that's still a feature of JavaScript, not something specific to TypeScript.
Use primitive basic types (string, boolean, number, object) everywhere in TypeScript, and avoid using their class wrappers (String, Boolean, Number, Object), as a general rule.
If you really need to test whether a particular variable or a property contains a string (boolean, number), prop.constructor === String does work consistently for basic and wrapper types. When it is true, you can go one step further and check if typeof prop === "string", to tell whether it's a basic type or a wrapper class.

Note that prop.constructor === String may not work across realms (e.g., iframes), but prop.constructor.name === "String" will.

I hope the above makes sense. Feel free to leave a comment here or on my Twitter if you disagree 🙂

Thenable: how to make a JavaScript object await-friendly, and why it is useful

Andrew Nosenko — Sat, 07 Nov 2020 11:09:44 +0000

What are thenables?

This short post is to remind that we can add .then(onFulfilled, onRejected) method to any JavaScript class or object literal, to make it play well with await. It's useful when the object carries out asynchronous operations.

Many C# developers are familiar with the concept of "custom awaiters" (see "Await anything" by Stephen Toub). Interestingly, in JavaScript literally anything can be awaited as is (e.g., try (await true) === true), but the language also offers a feature similar to C# awaitables: thenable objects, or Thenables.

Thenables are not promises, but they can be meaningfully used on the right side of the await operator and are accepted by many standard JavaScript APIs, like Promose.resolve(), Promise.race(), etc. For example, we can wrap a thenable as a bona fide promise, like this:

const promise = Promise.resolve(thenable);

If you're interested in learning more about how it works behind the scene, the V8 blog got you covered: "Faster async functions and promises".

Sample use cases

As a simple example to begin with, let's create a Deffered object, inspired by jQuery Deferred and .NET TaskCompletionSource:

function createDeferred() {
  let resolve, reject;

  const promise = new Promise((...args) => 
    [resolve, reject] = args);

  return Object.freeze({
    resolve, 
    reject,
    then: promise.then.bind(promise)
  });
}

const deferred = createDeferred();
// resolve the deferred in 2s 
setTimeout(deferred.resolve, 2000);
await deferred;

For completeness, the same in TypeScript.

Now, a little contrived but hopefully a more illustrative example, which shows how a thenable can be useful for a proper resource cleanup (a timer in this case):

function createStoppableTimer(ms) {
  let cleanup = null;
  const promise = new Promise(resolve => {
    const id = setTimeout(resolve, ms);
    cleanup = () => {
      cleanup = null;
      clearTimeout(id);
      resolve(false);
    }
  });
  return Object.freeze({
    stop: () => cleanup?.(),
    then: promise.then.bind(promise) 
  });
}

const timeout1 = createStoppableTimeout(1000);
const timeout2 = createStoppableTimeout(2000);
try {
  await Promise.race([timeout1, timeout2]);
}
finally {
  timeout1.stop();
  timeout2.stop();
}

Surely, we could have just exposed promise as a property:

await Promise.race([timeout1.promise, timeout2.promise]);

That works, but I'm not a fan. I believe where asyncWorkflow represents an asynchronous operation, we should be able to await asyncWorkflow itself, rather than one of its properties. That's where implementing asyncWorkflow.then(onFulfilled, onRejected) helps.

Here is one more example of how to wait asynchronously for any arbitrary EventTarget event, while cleaning up the event handler subscription properly. Here we're waiting for a popup window to be closed within the next 2 seconds:

const eventObserver = observeEvent(
  popup, "close", event => event.type);

const timeout = createStoppableTimeout(2000);

try {
   await Promise.race([eventObserver, timeout]);
}
catch (error) {
  console.error(error);
}
finally {
  timeout.stop();
  eventObserver.close();
}

This is what the observeEvent implementation may look like (note how it returns an object with then and close methods):

function observeEvent(eventSource, eventName, onevent) { 
  let cleanup = null;

  const promise = observe();
  return Object.freeze({
    close: () => cleanup?.(),
    then: promise.then.bind(promise)
  });

  // an async helper to wait for the event
  async function observe() {
    const eventPromise = new Promise((resolve, reject) => {
      const handler = (...args) => {
        try {
          resolve(onevent?.(...args));
        }
        catch (error) {
          reject(error);
        }
        finally {
          cleanup?.();
        }
      };

      cleanup = () => {
        cleanup = null;
        eventSource.removeEventListener(handler);
      } 

      eventSource.addEventListener(
        eventName, handler, { once: true });
    });

    try {
      return await eventPromise;      
    } 
    finally {
      cleanup?.();    
    }
  }
}

I use this pattern a lot, as it helps with properly structured error handling and scoped resources management. The errors are propagated from inside the event handler (if any) by rejecting the internal promise, so await eventObserver will rethrow them.

As the current TC39 "ECMAScript Explicit Resource Management" proposal progresses, we soon should be able to do something like this:

const eventObserver = observeEvent(
  popup, "close", event => "closed!");

const timeout = createStoppableTimeout(2000);

try using (eventObserver, timeout) {
   await Promise.race([eventObserver, timeout]);
}

We will not have to call the cleanup methods explicitly.

I my future blog posts, I hope to cover this and another important TC39 proposal by Ron Buckton — ECMAScript Cancellation — in more details, including what we could use today as alternatives.

Thanks for reading! Feel free to leave a comment below or on Twitter.

Would it make sense to have "Symbol.promise" as standard JavaScript Symbol?

Andrew Nosenko — Thu, 22 Oct 2020 00:12:50 +0000

Updated: I've tried to provide a better context for this discussion with my new post: "Thenable: how to make a JavaScript object await-friendly, and why it is useful".

Asking for opinions. Would it make sense to have a standard symbol for the object's default awaitable, e.g. Symbol.promise, by analog to Symbol.asyncIterator?

I sometimes use the following pattern, in a nutshell (codepen):

class AsyncOperation {
  #promise = null;

  constructor(ms) {
    this.#promise = new Promise(r => setTimeout(r, ms));
  }

  then(resolve, reject) { 
    return this.#promise.then(resolve, reject); }
}

async function main() {
  await new AsyncOperation(1000);
  console.log("completed!")
}

This works, because we've made an instance AsyncOperation to be thenable.

If however we had Symbol.promise, it'd be less boilerplate code for AsyncOperation:

class AsyncOperation {
  #promise = null;

  constructor(ms) {
    this.#promise = new Promise(r => setTimeout(r, ms));
  }

  get [Symbol.promise]() { return this.#promise; }
}

Wouldn't Symbol.promise be useful?

Here is a less contrived snippet, adapted from some real-life code of mine:

const subscription = createSubscription(
  cancellationToken, eventSource, "eventName"); 
try {
  await subscription;
}
finally {
  subscription.close();
}

The relevant part of createSubscription code:

  // ...
  return Object.freeze({
    close: () => unsubscribe(),
    then: (resolve, reject) => promise.then(resolve, reject)
  });

I'd like to be able to do:

  // ...
  return Object.freeze({
    close: () => unsubscribe(),
    get [Symbol.promise]() { return promise; }
  });

Of course, I could as well just expose promise as a property getter (and do await subscription.promise), or as a method, similar to RxJS' toPromise().

Yet the same arguments could possibly be used for iterable objects, which nevertheless expose their iterators via [Symbol.iterator] or [Symbol.asyncIterator]. Not via something like array.iterator or array.getIterator().

IMO, it'd be convenient if await looked for [Symbol.promise] in the same way the for...of and for await...of loops look for iterators.

Given that we already can await any expression in JavaScript (not just a Promise or "thenable"), I think that would make sense.

Yet another OOP/C# person (me) trying to understand the mechanics behind React Hooks

Andrew Nosenko — Wed, 30 Sep 2020 12:13:59 +0000

I've written this article as a memo to my future self as well, and my goal was to make it short. If there is something here that isn't technically correct, a feedback would be appreciated.

What is the magic behind the simplicity of React Hooks?

Coming to React from an OOP/MVVM/C# background, for a while I was having this "how-does-it-work-behind-the-scence" syndrome about React hooks.

As they get called from what seemingly is a plain, stateless JavaScript function, and yet hooks maintain their state.

Particularly, about how multiple hooks of the same kind coexist within the same function component and persist their state across multiple renders.

For example, across multiple invocations of the following MyComponent function (try it in the CodePen):

function MyComponent() {
  const refUp = useRef(0);
  const refDown = useRef(0);

  const [countUp, setCountUp] = useState(0);
  const [countDown, setCountDown] = useState(0);

  const clicked = () => {
    setCountUp(count => count + 1);    
    setCountDown(count => count - 1);    
  };

  console.log("rendering");

  return (
    <p>
      <span>Up: {refUp.current++}</span><br/>
      <span>Down: {refDown.current--}</span><br/>
      <span>Counts: {countUp}, {countDown}</span><br/>
      <button onClick={clicked}>Count</button>
    </p>
  );
}

How is it possible that refA.current and refB.current can be mutated and still survive multiple renders, keeping their values, without relying upon something like JavaScript's this?

Especially, given they both were created with two identical invocations of useRef(0)? My guts were telling me there should be a unique name parameter, like useRef(0, "refA"), but there isn't.

The same question applies to countUp, countDown and the corresponding useState(0) calls which initialize these variables.

Something has got to maintain the state for us.

And there has to be some kind of 1:1 mapping for each hook into that state.

As it turns, there is no magic. In a nutshell, here is my understanding of how it goes:

First of all, hook calls don't work outside React function components, by design. They implicitly rely upon the calling context React provides them with, when it renders the component.
React maintains its own internal state for the life-time of the web page. While not exactly accurate, let's called it React's static state.
Each component like MyComponent above has a dedicated entry in React's static state, and that entry keeps the state of each hook used by the component between renders.
When a hook like useRef is called, React knows which component is calling it (the one currently being rendered), so React can retrieve that individual component's state entry it have previously mapped and stored in its static state. That's where the current values of hooks like useRef and useState are stored, per component.
Initially, such entry gets created and mapped when the component gets mounted (or perhaps upon the first render, I didn't dig deep into that, but it's done once).
The exact order of calls like useRef or useState within the component function matters, and it should remain the same across subsequent renders. In our case, React initially creates two entries for useRef in its internal state for MyComponent, then two entries for useState.
Upon subsequent renders (invocations of MyComponent), React knows how to access the correct state and which values to return, by the order of each useRef or useState call.
I'm not sure about exact data structure used by React to map hooks by the order of their appearance in the function component, I didn't dig into that either. But it's easy to think about the order of each hook call as of an index in the array of hooks maintained by React for the life cycle of our component.
Thus, if we mess about this order across multiple renders, our state will be broken, because the original indexing wouldn't be correct. E.g., the following made-up example will likely screw up the state of refUp and refDown very soon, because their order of useRef calls is inconsistent:
```
 // don't mess up the order of hooks like this:
 let refUp;
 let refDown;
 if (Date.now() & 1) {
   refUp = useRef(0);
   refDown = useRef(0);
 } 
 else {
   refDown = useRef(0);
   refUp = useRef(0);
 }
```

Finally, hooks are not available for class components. While in theory it might have been possible to support hooks for class components' render() method, it's React's philosophy to keep the state in the class this.state and use this.setState() to update it, for class components.

The following resources greatly helped me to understand these hook mechanics:

Why I no longer use ConfigureAwait(false)

Andrew Nosenko — Thu, 17 Sep 2020 00:37:25 +0000

This might be an unpopular opinion, but I'd like to share why I no longer use ConfigureAwait(false) in pretty much any C# code I write, including libraries, unless required by the team coding standards.

The following two points are widely seen as major benefits of calling task.ConfigureAwait(false) and awaiting the ConfiguredTaskAwaitable value it returns, rather than the original task:

Potential performance improvements
Potential remedy for deadlocks

Let's break it down.

Potential performance improvements

It might be the result of not queueing the await continuation callbacks with the original synchronization context/task scheduler, but rather continuing in-place, on the same thread where the actual asynchronous operation has completed.

In my opinion, this is much less relevant with the modern ASP.NET Core/ASP.NET 5+ backend, which simply doesn't have a synchronization context by default anymore. ConfigureAwait(false) simply becomes a no-op in that execution environment.

On the other hand, the front-end code normally does have a concept of the main UI thread, with a certain UI framework-specific synchronization context installed on it (e.g, DispatcherSynchronizationContext).

In this case, I believe that using ConfigureAwait(false) for the purpose of not continuing on a UI thread is a premature optimization, especially for small code chunks between awaits. Under particular circumstances, it may even have a negative effect, by introducing frequent yet redundant context switches. In a nutshell (contrived but illustrative):

async Task SomeAsync(Func<Task> func)
{
    var threadId = Environment.CurrentManagedThreadId;
    await func().ConfigureAwait(false);
    // false: a redundant and probably undesired thread switch here
    Debug.Assert(threadId == Environment.CurrentManagedThreadId);
}

private async void MainForm_Load(object? sender, EventArgs e)
{
    var tcs = new TaskCompletionSource();
    var task = SomeAsync(() => tcs.Task);
    tcs.SetResult();
    await task;
}

More details in my old related question on SO.

Thus, for the UI threads, I prefer to explicitly control the execution context, especially where it is a part of performance-sensitive, CPU-intensive code.

I can do that by either using Task.Run(Func<Task> asyncFunc):

await Task.Run(async () => 
{
  await RunOneWorkflowAsync();
  await RunAnotherWorkflowAsync();
});

Or, lately, with a custom implementation of TaskScheduler.SwitchTo extension, inspired by this David Fowler's initiative:

await TaskScheduler.Default.SwitchTo();
await RunOneWorkflowAsync();
await RunAnotherWorkflowAsync();

Instead of:

await RunOneWorkflowAsync().ConfigureAwait(false);
await RunAnotherWorkflowAsync();

The former two might be a bit more verbose and could incur an extra thread switch, but they clearly indicate the intent.

Moreover, I don't have to worry about any side effects the current synchronization context/task scheduler may have on RunOneWorkflowAsync, and whether or not the author of RunOneWorkflowAsync used ConfigureAwait(false) internally in their implementation.

With the second option, TaskScheduler.Default.SwitchTo is optimized to check if the current thread is already a ThreadPool thread with the default task scheduler, and complete synchronously, if so.

Potential remedy for deadlocks

In my option, using ConfigureAwait(false) as a defensive measure against deadlock may actually hide obscure bugs. I prefer detecting deadlocks early. As a last resort, I'd still use Task.Run as a wrapper for deadlock-prone code. Here is a real-life example of where I needed that.

Moreover, from debugging and unit-testing prospective, we always have an option to install a custom SynchronizationContext implementation for debugging asynchronous code, and that would also require to give up ConfigureAwait(false).

Conclusion

Microsoft's Stephen Toub in his excellent "ConfigureAwait FAQ" still recommends using ConfigureAwait(false) for general-purpose, context-agnostic libraries, even if they only target .NET Core or later. Later in the comments to that blog post, David Fowler mentions that "most of ASP.NET Core doesn't use ConfigureAwait(false) and that was an explicit decision because it was deemed unnecessary."

Use your own best judgment on whether you need it or not for a specific project. I've personally chosen to avoid ConfigureAwait(false) where possible, and control the execution context explicitly where it makes sense.

I believe the library code should behave well in any context, and I don't like the idea of using ConfigureAwait(false) as a defensive remedy for undetected deadlocks. Performance-wise, where it is critical (like with ASP.NET Core), there is already no synchronisation context in modern .NET.

As an added bonus, my C# code looks more clean without ConfigureAwait(false) all over the place :-)

Comparing process working sets of WebView-based Windows Desktop apps

Andrew Nosenko — Mon, 31 Aug 2020 13:21:12 +0000

Updated, related discussion in MicrosoftEdge Feedback repo. The source code repo with examples of each WebView-based app mentioned here is now available, too.

Let's compare the working sets of various WebView-based Windows Desktop apps. Each application simply loads the Bing homepage.

App	Working set size
Legacy IE11 WebBrowser WPF	164 MB
MSEdge WebView2 WPF	582 MB
Chromely/CefSharp	516 MB
Electron v10	570 MB

A screenshot of Process Explorer:

Updated on 2021/05/27: Prompted by this Twitter thread, I've re-verified the WPF + WebView2 memory footprint with now-GA WebView2 Runtime (v90.0.818.66), Microsoft.Web.WebView2 (v1.0.818.41) and .NET 5 (v5.0.6).

I witness an amazing improvement, ~270MB now vs ~580MB I saw back in August 2020 when WebView2 was in preview:

The source code is here. Well done @MSEdgeDev team!