#!/bin/bash | |
# Colors | |
RED='\033[0;31m' | |
GREEN='\033[0;32m' | |
NO_COLOR='\033[0m' | |
BLUE='\033[0;34m' | |
YELLOW='\033[0;33m' | |
NO_COLOR='\033[0m' |
#/usr/bin/env bash | |
git config --global init.templatedir '~/.git-templates' && \ | |
mkdir -p ~/.git-templates/hooks && \ | |
cd ~/.git-templates/hooks | |
cat >post-checkout <<'EOL' | |
changed_files="$(git diff-tree -r --name-only --no-commit-id ORIG_HEAD HEAD)" | |
check_run() { |
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!') | |
} |
Kyle Simpson (@getify) wrote a very thoughtful post decrying optimize-js, which is a tool I wrote that exploits known optimizations in JavaScript engines to make JS bundles parse faster (especially minified bundles, due to what could be reasonably described as a bug in Uglify).
Kyle lays out a good case, but I tend to disagree with nearly all his points. So here's my rebuttal.
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
var PIXI = require('pixi.js') | |
console.log(PIXI) |
So basically FlowType doesn't know about CSS Modules, a really handy way of dealing with the plagues of CSS in codebases (global variables and dependency wackiness mainly).
What WebPack allows us to do is "require" CSS files and use their class names:
import styles from "my_styles.css";
import React from "react";
I would recommend @acdlite's redux-actions over the methods suggested in this Gist.
The methods below can break hot-reloading and don't support Promise-based actions.
Even though 'redux-actions' still uses constants, I've come to terms with the fact that constants can be good, especially in bigger projects. You can reduce boilerplate in different places, as described in the redux docs here: http://gaearon.github.io/redux/docs/recipes/ReducingBoilerplate.html