Athæryn Anderson athaeryn

CSS Layout Debugger

A tweet-sized debugger for visualizing your CSS layouts. Outlines every DOM element on your page a random (valid) CSS hex color.

One-line version to paste in your DevTools

Use $$ if your browser aliases it:

~ 108 byte version

react-arduino

React has revolutionized the way we write user interfaces. It brings an extremely simple mental model to the authoring of UIs. React-native, react-canvas, and other projects have shown us that this model extends beyond the browser DOM.

I believe that this functional, predictable approach can also revolutionize how we build real-world user interfaces.

Hi Nicholas,

I saw you tweet about JSX yesterday. It seemed like the discussion devolved pretty quickly but I wanted to share our experience over the last year. I understand your concerns. I've made similar remarks about JSX. When we started using it Planning Center, I led the charge to write React without it. I don't imagine I'd have much to say that you haven't considered but, if it's helpful, here's a pattern that changed my opinion:

The idea that "React is the V in MVC" is disingenuous. It's a good pitch but, for many of us, it feels like in invitation to repeat our history of coupled views. In practice, React is the V and the C. Dan Abramov describes the division as Smart and Dumb Components. At our office, we call them stateless and container components (view-controllers if we're Flux). The idea is pretty simple: components can't

Descartes, Berkeley and Functional Reactive Programming

By @dmvaldman

Functional Reactive Programming (FRP) is generating buzz as an alternative to Object Oriented Programming (OOP) for certain use cases. However, an internet search quickly leads a curious and optimistic reader into the rabbit-hole of monads, functors, and other technical jargon. I’ve since emerged from this dark and lonely place with the realization that these words are mere implementation details, and that the core concepts are far more universal. In fact, the groundwork was laid down many centuries before the first computer, and has more to do with interpretations of reality, than structuring programs. Allow me to explain.

There’s an old thought experiment that goes like this:

Notes from @wesbos's talk:

Our frontend workflow is changing quickly and for good reasons. Tooling for tooling sake is a waste, but don't overlook the utility of modern dev tooling workflows - these are great, useful tools that are letting us improve our workflows in standards-based, forward-looking ways.

Trend: Frontend developers are moving to using package managers (npm) for client-side code (CSS and JS), much like we have been for managing our build tooling itself. I can attest to this being hugely helpful at Filament Group on client-side code, especially now that so many of our projects are on npm (https://www.npmjs.com/~filamentgroup ).

Yay, another talk that recommends loadCSS for performance. Nice to hear :)

Gulp tasks to use:

This document has moved!

It's now here, in The Programmer's Compendium. The content is the same as before, but being part of the compendium means that it's actively maintained.

	const getAllPropertyNames = require('./get_all_property_names'),
	Mutex = require('./mutex')

	function actor(object) {
	let methods = getAllPropertyNames(object),
	mutex = new Mutex(),
	wrapper = {}

	for (let method of methods) {
	if (typeof object[method] !== 'function') continue


	module StringContext =
	Context.MakePair({
	type t = string;
	let defaultValue = "Awesome";
	});

	let component = ReasonReact.statelessComponent("Tree");

	let make = _children => {

	/** Schema for translations, with @genType for TS/JS usage */
	[@genType]
	type translations = {
	helloMessage: string,
	helloMessageWithVariable: (~name: string) => string,
	};

	/** English translations */
	[@genType]
	let translationsEN = {