A collection of links to the excellent "Composing Software" series of medium stories by Eric Elliott.
--Table | |
CREATE TABLE IF NOT EXISTS person ( | |
id integer NOT NULL, | |
person_name character varying(40) NOT NULL, | |
updated_date date, | |
CONSTRAINT person_pkey PRIMARY KEY (id) | |
); | |
--Index | |
CREATE INDEX IF NOT EXISTS idx_person_name ON person (person_name); |
/** @jsx h */ | |
// You only need custom elements for this!!! | |
import 'skatejs-web-components/src/native-shim'; | |
import { Component, define, h, prop } from 'skatejs'; | |
import ShadowNode, { scopeCss, scopeTree } from './shadow-node'; | |
// Converts real DOM nodes into Incremental DOM nodes. | |
// | |
// This is orthogonal to this gist, but makes it so we can distribute real |
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
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
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.
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.
const I = x => x | |
const K = x => y => x | |
const A = f => x => f (x) | |
const T = x => f => f (x) | |
const W = f => x => f (x) (x) | |
const C = f => y => x => f (x) (y) | |
const B = f => g => x => f (g (x)) | |
const S = f => g => x => f (x) (g (x)) | |
const S_ = f => g => x => f (g (x)) (x) | |
const S2 = f => g => h => x => f (g (x)) (h (x)) |
All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.
Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.
elem.offsetLeft
,elem.offsetTop
,elem.offsetWidth
,elem.offsetHeight
,elem.offsetParent
function toArray(args) { | |
return [].slice.call(args); | |
} | |
function autocurry(fn) { | |
var len = fn.length; | |
var args = []; | |
return function next() { | |
args = args.concat(toArray(arguments)); | |
return (args.length >= len) ? |