Steve Chikwaya stavarotti

I'm having trouble understanding the benefit of require.js. Can you help me out? I imagine other developers have a similar interest.

From Require.js - Why AMD:

The AMD format comes from wanting a module format that was better than today's "write a bunch of script tags with implicit dependencies that you have to manually order"

I don't quite understand why this methodology is so bad. The difficult part is that you have to manually order dependencies. But the benefit is that you don't have an additional layer of abstraction.

Update 6/14/13

see https://gist.github.com/machty/5723945 for the latest API (unlikely to change from now on)
latest Ember build: https://machty.s3.amazonaws.com/ember/ember-async-routing-10.js

Router Facelift Examples

Guide to latest API enhancements router.js PR Ember PR

	<!doctype html>

	<!-- http://taylor.fausak.me/2015/01/27/ios-8-web-apps/ -->

	<html>
	<head>
	<title>iOS 8 web app</title>

	<!-- CONFIGURATION -->

	var parser = document.createElement('a');
	parser.href = "http://example.com:3000/pathname/?search=test#hash";

	parser.protocol; // => "http:"
	parser.hostname; // => "example.com"
	parser.port; // => "3000"
	parser.pathname; // => "/pathname/"
	parser.search; // => "?search=test"
	parser.hash; // => "#hash"
	parser.host; // => "example.com:3000"

	Latency Comparison Numbers (~2012)
	----------------------------------
	L1 cache reference 0.5 ns
	Branch mispredict 5 ns
	L2 cache reference 7 ns 14x L1 cache
	Mutex lock/unlock 25 ns
	Main memory reference 100 ns 20x L2 cache, 200x L1 cache
	Compress 1K bytes with Zippy 3,000 ns 3 us
	Send 1K bytes over 1 Gbps network 10,000 ns 10 us
	Read 4K randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD

	"use strict";

	// `f` is assumed to sporadically fail with `TemporaryNetworkError` instances.
	// If one of those happens, we want to retry until it doesn't.
	// If `f` fails with something else, then we should re-throw: we don't know how to handle that, and it's a
	// sign something went wrong. Since `f` is a good promise-returning function, it only ever fulfills or rejects;
	// it has no synchronous behavior (e.g. throwing).
	function dontGiveUp(f) {
	return f().then(
	undefined, // pass through success

	#!/bin/bash
	# REQUIRES SUDO
	# Benchmark runner

	repeats=20
	output_file='benchmark_results.csv'
	command_to_run='echo 1'

	run_tests() {
	# --------------------------------------------------------------------------

	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
	<plist version="1.0">
	<dict>
	<key>author</key>
	<string>Jacob Rus</string>
	<key>comment</key>
	<string>Created by Jacob Rus. Based on ‘Slate’ by Wilson Miner</string>
	<key>name</key>
	<string>Cowboy - Presentation</string>

	#!/usr/bin/python

	import sys
	from PIL import Image

	def avhash(im):
	if not isinstance(im, Image.Image):
	im = Image.open(im)
	im = im.resize((8, 8), Image.ANTIALIAS).convert('L')
	avg = reduce(lambda x, y: x + y, im.getdata()) / 64.

	/**
	Ember Data: Dependent Relationships

	This package extends Ember Data to support creating relationships
	where a model's dirty state depends not only on its own attributes
	but on the dirty state of models in dependent relationships as well.

	```javascript
	App.Thing = DS.Model.extend({
	name : DS.attr('string'),