A tiny ~150-byte polyfill for Promise.prototype.finally
.
Useful for browsers that support Promise but not the .finally()
method.
npm install finally-polyfill
(function (context, trackingId, options) { | |
const history = context.history; | |
const doc = document; | |
const nav = navigator || {}; | |
const storage = localStorage; | |
const encode = encodeURIComponent; | |
const pushState = history.pushState; | |
const typeException = 'exception'; | |
const generateId = () => Math.random().toString(36); | |
const getId = () => { |
/* | |
html-webpack-plugin-lite | |
Usage: | |
new HtmlWebpackPluginLite({ | |
title: "Webpack demo", // Available in context | |
template: ({ css, js, title }) => ... html ... | |
}), | |
*/ |
// place this file in __mocks__ | |
let pendingAssertions | |
exports.prompt = prompts => { | |
if (!pendingAssertions) { | |
throw new Error(`inquirer was mocked and used without pending assertions: ${prompts}`) | |
} | |
const answers = {} |
Note: I'm not involved in Prepack in any way — please correct me if I say anything incorrect below!
A few people have asked me if Prepack and Svelte are similar projects with similar goals. The answer is 'no, they're not', but let's take a moment to explore why.
Prepack describes itself as a 'partial evaluator for JavaScript'. What that means is that it will run your code in a specialised interpreter that, rather than having some effect on the world (like printing a message to the console), will track the effects that would have happened and express them more directly.
So for example if you give it this code...
package main | |
import ( | |
"database/sql" | |
"strconv" | |
"log" | |
"net/http" | |
"fmt" | |
"bytes" | |
"gopkg.in/gin-gonic/gin.v1" |
var str = 'class ಠ_ಠ extends Array {constructor(j = "a", ...c) {const q = (({u: e}) => {return { [`s${c}`]: Symbol(j) };})({});super(j, q, ...c);}}' + | |
'new Promise((f) => {const a = function* (){return "\u{20BB7}".match(/./u)[0].length === 2 || true;};for (let vre of a()) {' + | |
'const [uw, as, he, re] = [new Set(), new WeakSet(), new Map(), new WeakMap()];break;}f(new Proxy({}, {get: (han, h) => h in han ? han[h] ' + | |
': "42".repeat(0o10)}));}).then(bi => new ಠ_ಠ(bi.rd));'; | |
try { | |
eval(str); | |
} catch(e) { | |
alert('Your browser does not support ES6!') | |
} |
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.
<!-- | |
This demo shows two ways to detect changes to a DOM node `.textContent`, one | |
using a `MutationObserver` and the other using an ES2015 `Proxy`. | |
From testing, a `Proxy` appears to be 6-8x faster than using a MO in Chrome 50. | |
**Update**: removing the `Proxy` altogether speeds up the MO to be inline with the Proxy. | |
This has something to do with how the browser queues/prioritizes Proxies over MO. |