developit

finally-polyfill

A tiny ~150-byte polyfill for Promise.prototype.finally.

Useful for browsers that support Promise but not the .finally() method.

Usage

npm install finally-polyfill

DavidKuennen

(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 = () => {

bebraw

/*
html-webpack-plugin-lite

Usage:

new HtmlWebpackPluginLite({
  title: "Webpack demo", // Available in context
  template: ({ css, js, title }) => ... html ...
}),
 */

threepointone

A series of posts on css-in-js

0. styles as objects

First, an exercise. Can we represent all of css with plain data? Let's try.

let redText = { color: 'red' };

yyx990803

// 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 = {}

Rich-Harris

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.

What is Prepack?

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...

rsj217

package main

import (
	"database/sql"
	"strconv"
	"log"
	"net/http"
	"fmt"
	"bytes"
	"gopkg.in/gin-gonic/gin.v1"

DaBs

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!')
}

Rich-Harris

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.

ebidel

<!--
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.