Skip to content

Instantly share code, notes, and snippets.

browserify index.js | uglifyjs | gzip -9f | wc -c

A few ideas I'd quite like to cover:

  1. Code structure in your views is important. It's easy to create a templating engine, hard to create a good one. Layouts (inheritance...) and mixins (partials, functions...) are the key to not having a messy set of views.
  2. Generators give you a fantastic opportunity to use propper control flow structures in your asynchronous programmes. They also make it easy to provide propper error bubbling behaviour.
  3. Thunks are still almost a type of promise, and in order to make them handle all the corner cases correctly you have to add just as much code as with a promise. They don't actually represent the result of an asynchronous operation, and from there all problems stem.
'use strict';
var github = require('github-basic');
var pr = require('pull-request');
var README_FILE = '';
var auth = { type: 'oauth', token: TOKEN };

Top 50 contributors to esdiscuss (all time)

db.headers.aggregate({'$group': {'_id': '$', 'count': {'$sum': 1}}}, {'$sort': {'count': -1}}, {'$limit': 50});
  "_id" : "",
  "count" : 3685

The "polyfill" package.json property

The polyfill property of package.json indicates what features need to be polyfilled in older browsers. The polyfill property should not include the polyfills required for dependencies of the given package (they should have their own polyfill property).


Many packages in npm can be used in browsers. Many of them use methods that are not available in older browsers though. Still others inline the code for the polyfills, or require large libraries like underscore instead of using the builtin methods that the language provides.

The problem with including polyfills or workarounds in the libraries is that it forces even consumers who don't wish to support older browsers to still include these polyfills. It also creates fragmentation as many different libraries may require the same functionality to be polyfilled (you don't want 10 slightly different JSON parsers in your project).

'use strict';
// run this in the packages directory of the metor repository to generate "meteor-packages.html"
var fs = require('fs');
var uglify = require('uglify-js');
function getDependenciesFromSource(str) {
var dependencies = {
summary: '',
function poll() {
ForbesLindesay /
Created August 2, 2014 03:22
This is the email I sent to to detail my concerns surrounding their recent aquisitioin of express

Dear Issac Roth,

I am writing, as per you request ( to raise my concerns about the recent handling of express.js by Strong Loop. I understand from reading everything I can find online that TJ Holowaychuk was consulted before the move and that the idea of sponsoring was raised with the maintainer (although the full extent of this move was perhaps not fully understood by everyone). However, there are a few things that still concern me:

  1. No consultation seems to have occurred with the wider community.
  2. In your post announcing the change you describe your first order of business as "is to get familiarized with the project’s practices, release processes and get started on more visible community contributions”. This does not appear to correlate well with your actions of immediately transferring ownership of the repo to a strongloop location.
  3. Pull requests are not being handled in a

Asset Key Spec

Asset key is a specification for defining a common API for all compilable languages.

compiler.compile(src, options) => Promise({body: string, type: string, dependencies: []})

Compiles a string with some options and returns a promise for an asset. This should never attempt to implement any caching internally, regardless of options passed in.

If the transform requires a filename, this method should not be implemented.