Wired Earp wiredearp

(tl;dr DOM builders like [domo][domo] trump HTML templates on the client.)

Like all web developers, I've used a lot of template engines. Like most, I've also written a few of them, some of which even [fit in a tweet][140].

The first open-source code I ever wrote was also one of the the first template engines for node.js, [a port][node-tmpl] of the mother of all JavaScript template engines, [John Resig][jresig]'s [micro-templates][tmpl]. Of course, these days you can't swing a dead cat without hitting a template engine; one in eight packages on npm ([2,220][npm templates] of 16,226 as of 10/19) involve templates.

John's implementation has since evolved and [lives on in Underscore.js][underscore], which means it's the default choice for templating in Backbone.js. And for a while, it's all I would ever use when building a client-side app.

But I can't really see the value in client-side HTML templates anymore.

WARNING

This gist is outdated! For the most up-to-date information, please see http://emberjs.com/guides/routing/!

It All Starts With Templates

An Ember application starts with its main template. Put your header, footer, and any other decorative content in application.handlebars.

<header>

tl;dr

If you must nest functions in a way that requires access to multiple this', alias outer this to something meaningful - describe the value it's holding. Treat this as the invisible first argument.

In general though, avoiding the situation (nested functions and frivolous use of this) will frequently produce clearer results.

Naming `this` in nested functions

I was accidentally included in a discussion on how to best name this in nested functions in JavaScript. +1's were given to this suggestion of using _this.

Giving style advice on naming nested this without a meaningful context isn't too helpful in my opinion. Examples below have been altered to have at least some context, although a completely contrived and stupid one.

In-Application Sandboxing with Web Workers

A design rationale.

For the past fews years, the Web has been shifting control to the client. Given the limitations of remote services, developers are now looking for ways to "unhost" static applications – that is, break the dependency on remote servers while still using the Web platform.

One untapped technology for client-side control is the Web Worker Sandbox. This API lets the Page load, execute, and destroy separate Worker threads which use their own Virtual Machines. By using Worker Sandboxes to drive behavior, the Web can give users the choice of which software they run together, shifting development from a centralized SaaS model into a distributed and free (as in freedom) script-sharing model.

Worker Sandboxes can Execute Arbitrary Code

Communicating with Workers using HTTP

A design rationale.

See first: In-Application Sandboxing with Web Workers.

Web Workers interact with their Host Pages using a messaging channel (the postMessage API). Crucially for their programming model, the messages are asyncronous. This introduces a significant challenge for implementing Page APIs within a Worker – for instance, how do you port a GUI widget from the Page (where it can access the DOM) to a Worker, where it can only send async messages?

In my experience, two categories of solutions are suggested: use code-transformations to recreate Page-native APIs in the Worker, or introduce a new interface around messaging. In this gist, I'll explain why code transformations don't address the problem fully, and present a complete messaging solution based on HTTP.

	.PHONY: compile

	time=/usr/bin/time

	compile: dart typescript coffeescript haxe jsx

	dart:
	$(time) dart2js -ooutput/dart.js source/simple.dart

	typescript:

	JSWEEKLY BINGO
	+-------------------------------+-------------------------------+-------------------------------+
	\| An atricle from someone who \| \| \|
	\| just figured out \| Baby's first functional \| How to do this one very \|
	\| prototype-based OO and thinks \| programming \| specific thing in Node.js \|
	\| everyone else needs telling \| \| \|
	+-------------------------------+-------------------------------+-------------------------------+
	\| \| \| \|
	\| A new jQuery release \| A job in San Francisco \| An introduction to an MVC \|
	\| \| \| framework \|

	/**
	* How to have floating scrollbars in Firefox (Linux, Windows & Mac).
	* Screenshot: http://i.imgur.com/bn44L.png
	* You need Firefox > 18. Just run this code in a browser-scratchpad:
	*
	* Ping me on Twitter (@paulrouget) if you run into problems.
	*
	* 1. Go to about:config - Set devtools.chrome.enabled to true
	* 2. Starts Scratchpad (Shift-F4)
	* 3. In Scratchpad's menubar, check "Environment > Browser"

	/*
	* Example of a state monad in use. This is adapted from an example on
	* the Haskell Wiki:
	* http://www.haskell.org/haskellwiki/State_Monad#Complete_and_Concrete_Example_1
	*/
	require(['state', 'qunit'], function(state, qunit) {

	/*
	* playGame() is a recursive function that given an array of moves
	* defines an algorithm for constructing a final game score. Along

	// Tested in Chrome 23, Firefox 16, and IE9 in standards mode (i.e. with <!DOCTYPE html>).
	// Converts '#f00', 'red', 'hsl(0, 100%, 50%)' and 'rgb(255,0,0)' to {r:255,g:0,b:0}.

	function cssColorToRGB(cssColor) {
	var s = document.createElement('span')
	document.body.appendChild(s)
	s.style.backgroundColor = cssColor
	var rgb = getComputedStyle(s).backgroundColor
	document.body.removeChild(s)
	var m = /^rgb\((\d+), (\d+), (\d+)\)$/.exec(rgb)