Jiri Spac capaj

One thing that surprises newer programmers is that the older 8-bit microcomputers from the 70s and 80s were designed to run at the speed of random memory access to DRAM and ROM. The C64 was released in 1982 when I was born and its 6502 CPU ran at 1 MHz (give or take depending on NTSC vs PAL). It had a 2-stage pipelined design that was designed to overlap execution and instruction fetch for the current and next instruction. Cycle counting was simple to understand and master since it was based almost entirely on the number of memory accesses (1 cycle each), with a 1-cycle penalty for taken branches because of the pipelined instruction fetch for the next sequential instruction. So, the entire architecture was based on keeping the memory subsystem busy 100% of the time by issuing a read or write every cycle. One-byte instructions with no memory operands like INX still take the minimum 2 cycles per instruction and end up redundantly issuing the same memory request two cycles in a row.

The gist: by having a Promise adopt the state of a forever pending one, you can suspend its then handlers chain.

Promise.pending = Promise.race.bind(Promise, [])

let cancel

new Promise(function(fulfill, reject) {
  cancel = function() {fulfill(Promise.pending())}
  setTimeout(fulfill, 1000, 5)

Why imperative imports are slower than declarative imports

A lot of people misunderstood Top-level await is a footgun, including me. I thought the primary danger was that people would be able to put things like AJAX requests in their top-level await expressions, and that this was terrible because await strongly encourages sequential operations even though a lot of the asynchronous activity we're talking about should actually happen concurrently.

But that's not the worst of it. Imperative module loading is intrinsically bad for app startup performance, in ways that are quite subtle.

Consider an app like this:

// main.js

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

Stuff I wish I'd known sooner about service workers

I recently had several days of extremely frustrating experiences with service workers. Here are a few things I've since learned which would have made my life much easier but which isn't particularly obvious from most of the blog posts and videos I've seen.

I'll add to this list over time – suggested additions welcome in the comments or via twitter.com/rich_harris.

Use Canary for development instead of Chrome stable

~~Chrome 51 has some pretty wild behaviour related to console.log in service workers. Canary doesn't, and it has a load of really good service worker related stuff in devtools.~~

	➜ pretty-format git:(perf) ✗ npm run perf

	> [email protected] perf /Users/thejameskyle/Projects/pretty-format
	> node perf/test.js

	empty arguments:
	prettyFormat() - 662ns - 0.066249041s total (100000 runs) - "Arguments []"
	JSON.stringify() - 738ns - 0.073823264s total (100000 runs) - "{}"
	util.inspect() - 55131ns - 5.513100926s total (100000 runs) - "{ [length]: 0,\n [callee]: \n { [Function: returnArguments]\n [length]: 0,\n [name]: 'returnArguments',\n [arguments]: null,\n [caller]: null,\n [prototype]: returnArguments { [constructor]: [Circular] } },\n [Symbol(Symbol.iterator)]: \n { [Function: values]\n [length]: 0,\n [name]: 'values',\n [prototype]: values { [constructor]: [Circular] } } }"

	// 1. npm init
	// 2. npm install --save webpack webpack-dev-server babel-loader babel-preset-es2015
	// 3. mkdir dist && touch index.html
	// 4. Include `<script src="/bundle.js"></script>` inside index.html
	// 5. mkdir src && touch src/index.js
	// 6. Add some code to index.js (e.g. `console.log('Hello, World!'))
	// 7. npm start
	// 8. Browse to http://localhost:8080/dist/

	const webpack = require('webpack')

	Community Packages (43) /home/capaj/.atom/packages
	├── [email protected]
	├── [email protected]
	├── [email protected]
	├── [email protected]
	├── [email protected]
	├── [email protected]
	├── [email protected]
	├── [email protected]
	├── [email protected]

	// https://web.archive.org/web/20141119215047/http://jsperf.com/javascript-quicksort-comparisons
	// based on work from Vladimir Yaroslavskiy: https://web.archive.org/web/20151002230717/http://iaroslavski.narod.ru/quicksort/DualPivotQuicksort.pdf
	var dualPivotQuicksort = (function (Math, toString, undefined) {
	'use strict';
	function swap(arr, i, j) {
	var temp = arr[i];
	arr[i] = arr[j];
	arr[j] = temp;
	}
	function dualPivotQuicksort(arr, comp, left, right, div) {

	const toDataURL = url => fetch(url)
	.then(response => response.blob())
	.then(blob => new Promise((resolve, reject) => {
	const reader = new FileReader()
	reader.onloadend = () => resolve(reader.result)
	reader.onerror = reject
	reader.readAsDataURL(blob)
	}))