Erik Bryn ebryn

What forces layout / reflow

All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.

Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.

Element APIs

Getting box metrics

elem.offsetLeft, elem.offsetTop, elem.offsetWidth, elem.offsetHeight, elem.offsetParent

From a terminal run the following commands:

git clone [email protected]:emberjs/ember.js
cd ember.js
npm install
npm start

While that is running open another terminal and run the following (starting from the ember.js folder you cloned a moment ago):

IO streams. (Domenic is leading an effort on GitHub. This is high priority, like promises was last year.)
Asynchronous iteration (event streams?). (Database cursor, going through a directory, going through entries in storage, scanning TV channels.)
A plan around distinct Error types and detection (e.g. for APIs that can fail in multiple ways where you might want to recover from certain class of errors; think network APIs, databases)
A better way to define ES APIs than WebIDL. (Part of the problem here is lack of maintenance. So maybe it's as "simple" as finding someone.)

HTML Imports: Discussion over Async/Progressive Loading

There are concerns around HTML Imports that does sync or blocking loading as the default. I’d like to address these concerns. Especially I’d like to understand the actual use cases that “sync” loading hurts. This document aims to be a portal of that effort.

What to Block

Before discussing use cases, let’s clarify which part of page loading process HTML Imports possibly blocks. The blocking model of HTML Imports is modeled after the one for external stylesheets. There are two main bits of the blocking:

The `<script>` elements

"Model-dependent query param stickiness"

The question of whether query param controller properties are preserved/restored/reset when navigating away/back/between routes is a tricky one, but the sensible default seems to be "model-dependent stickiness", whereby query params are stick unless you're switching the model of the current or parent routes. There's more that could be said about this but here's a quick summary of my plan:

We need a dictionary to store QP state scoped to a model

Data Down / Actions Up
- http://emberjs.jsbin.com/nayaho/edit?html,js - Interdependent select boxes. No observers.
- http://ember-twiddle.com/2d7246875098d0dbb4a4 - One Way Input
Plain JSBin's
- http://rwjblue.jsbin.com/pixeki/edit?html,js,output
Ember Version Base JSBin's
- 1.0 - http://emberjs.jsbin.com/juluje/edit?html,js,output
1.1 - http://emberjs.jsbin.com/cofufo/edit?html,js,output

Web Components Resources

Specs / standardization

W3C Introduction to Web Components - explainer/overview of the technologies

	var Link = React.createClass({ /* magic */ });
	var Routed = { /* magic */ };

	var App = React.createClass({
	mixins: [Routed],

	render: function() {
	return (
	<Root path="/">
	<About path="about"/>

	var get = Ember.get, set = Ember.set, doc = document;

	var FastSelectComponent = Ember.Component.extend({
	items: null,
	valuePath: 'value',
	labelPath: 'label',
	value: null,
	selected: null,

	tagName: 'select',