peterc

// Open a supplied HTML file and record whatever's going on to an MP4.
//
// Usage: node recorder.cjs <path_to_html_file>
// Dependencies: npm install puppeteer fluent-ffmpeg
// (and yes, you need ffmpeg installed)
//
// It expects a <canvas> element to be on the page as it waits for
// that to load in first, but you can edit the code below if you
// don't want that.
//

kamilogorek

getify

In defense of blocks for local scopes (Part 1)

---

[EDIT: I've added a part 2 to this blog post, to address some of the feedback that has come up: https://gist.github.com/getify/706e5e10822a298375da40f9cc1fa295]

---

Recently, this article on "The JavaScript Block Statement" came out, and it received some good discussion in a reddit thread. But the general reaction seems to be against this approach. That saddens me.

thepassle

Fwiw, the past couple of weeks I've been working on supporting import assertions and CSS/JSON modules in our app at work, I thought it might be worth to share the experience and also prompted by this, maybe its helpful to someone looking into doing the same.

We currently transform our app to Systemjs. My initial thought was to start using es-module-shims, for several reasons:

• We use importmaps
• It supports CSS/JSON modules
• It would save a buildtime transformation to Systemjs

I initially thought that bundling from ESM to ESM would be at least somewhat noticeably faster than bundling from ESM to Systemjs, because of the code transform, but after running some benchmarks in our pipeline, it seemed to not make a significant difference.

karansinghgit

1. Close and Quit VSCode

2. Remove VScode from Applications (just go to Finder -> Applications and move VSCode to Bin)

3. Execute these commands in any order. The paths might be slightly different for you.

rm -fr ~/.vscode*
rm -fr ~/Library/Application\ Support/Code/

rm -fr ~/Library/Saved\ Application\ State/com.microsoft.VSCode.savedState/
rm -fr ~/Library/Preferences/com.microsoft.VSCode.helper.plist 

nikparo

// Sometimes you want to run parent effects before those of the children. E.g. when setting
// something up or binding document event listeners. By passing the effect to the first child it
// will run before any effects by later children.

export function Effect({ effect }) {
  useEffect(() => effect?.(), [effect]);
  return null;
}

//

getify

Parens And Performance

Years ago, some smart folks that worked on JS engines realized that not all JS that's loaded into a page/app initially is needed right away. They implemented JIT to optimize this situation.

JIT means Just-In-Time, which means essentially that the engine can defer processing (parsing, compiling) certain parts of a JS program until a later time, for example when the function in question is actually needed. This deferral means the engine is freer to spend the important cycles right now on the code that's going to run right now. This is a really good thing for JS performance.

Some time later, some JS engine devs realized that they needed to get some hints from the code as to which functions would run right away, and which ones wouldn't. In technical speak, these hints are called heuristics.

So they realized that one very common pattern for knowing that a function was going to run right away is if the first character before the function keyword was a (, because that usually m

Rich-Harris

Dynamic module loading done right

Follow-up to Top-level await is a footgun – maybe read that first

Here are some things I believe to be true:

1. Static module syntax is beneficial in lots of ways – code is easier to write (you get better linting etc) and easier to optimise (tree-shaking and other things that are only really possible with static syntax), and most importantly, faster to load (it's trivial for a module loader to load multiple dependencies concurrently when they're declared with a static syntax – not so with imperative statements like require(...) or await import(...)).
2. App startup time is perhaps when performance is most critical. (You already know this, I don't need to cite the studies.)
3. If you're in favour of constructs that jeopardise app startup time, you are anti-user. Top-level await is such a construct.

Rich-Harris

Edit — February 2019

This gist had a far larger impact than I imagined it would, and apparently people are still finding it, so a quick update:

• TC39 is currently moving forward with a slightly different version of TLA, referred to as 'variant B', in which a module with TLA doesn't block sibling execution. This vastly reduces the danger of parallelizable work happening in serial and thereby delaying startup, which was the concern that motivated me to write this gist
• In the wild, we're seeing (async main(){...}()) as a substitute for TLA. This completely eliminates the blocking problem (yay!) but it's less powerful, and harder to statically analyse (boo). In other words the lack of TLA is causing real problems
• Therefore, a version of TLA that solves the original issue is a valuable addition to the language, and I'm in full support of the current proposal, which you can read here.

I'll leave the rest of this document unedited, for archaeological

petsel

composable("composites.Range", function (require, global) {


  "use strict";


  require("environment_extended_introspective_core");