This is purposefully ambitious and aspirational. Some concepts that are worth understanding in addition to the principles outlined here include:
Here’s a CodePen I’ll periodically update with the compiled CSS to use as a testing playground.
// declaration | |
function foo (n) { return n + 1; } | |
// expression | |
// note, fat arrow functions have very different meaning (usually what I want, though) | |
var foo = function (n) { return n + 1; }; | |
var foo = (n) => { return n + 1; }; | |
var foo = n => n + 1; | |
// object methods |
This is purposefully ambitious and aspirational. Some concepts that are worth understanding in addition to the principles outlined here include:
Here’s a CodePen I’ll periodically update with the compiled CSS to use as a testing playground.
* { | |
font-size: 12pt; | |
font-family: monospace; | |
font-weight: normal; | |
font-style: normal; | |
text-decoration: none; | |
color: black; | |
cursor: default; | |
} |
/* bling.js */ | |
window.$ = document.querySelector.bind(document); | |
window.$$ = document.querySelectorAll.bind(document); | |
Node.prototype.on = window.on = function(name, fn) { this.addEventListener(name, fn); }; | |
NodeList.prototype.__proto__ = Array.prototype; | |
NodeList.prototype.on = function(name, fn) { this.forEach((elem) => elem.on(name, fn)); }; |
NOTE I'm trying to find the most optimal fav/touch icon setup for my use-cases. Nothing new here. Read Mathias Bynens' articles on re-shortcut-icon and touch icons, a FAQ or a Cheat Sheet for all the details.
I'd like to hear how you approach this: @valuedstandards or comment on this gist.
You have to include a boatload of link
elements pointing to many different images to provide (mobile) devices with a 'favicon' or 'touch icon':
This post has moved to my personal blog: http://maximilianschmitt.me/posts/compile-es6-command-line-apps/
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
When it comes to languages that power the web, CSS is a double-edged sword. Often heralded for being quick to learn, like chess it takes awhile to master. Due to its simplicity, it is easy to get to a point where CSS files become unruly, mired by code repetition and lack of consistency.
Enter CSS pre-processors (and post-processors). Of all the CSS pre-processing approaches, Sass (Syntactically Awesome Style Sheets) is the clear front-runner.
Metaphorically, Sass is to CSS what jQuery is to JavaScript. Not only that, Sass gives CSS a seat at the table of first-class programming languages.
This is a quick guide of what you need to do to publish a react component for use by others. This guide is distilled from a conversation [0] on twitter. I will reference individual tweets, where appropriate (thereby shifting blame for incorrect advice from me to the authors :D)