machty

/* jshint node: true */

const EmberApp = require('ember-cli/lib/broccoli/ember-app');
const generateWhitelabelIndexes = require('./generate-whitelabel-indexes');

module.exports = function(defaults) {
  const app = new EmberApp(defaults, {
    // ...all sorts of config
  });

CodeMyUI

<div class="page page-laser-to-text">
	<input id="input" type="text" maxlength="24" placeholder="I love you!">
	<canvas id="canvas"></canvas>
</div>

paulirish

A few conversations have circled around user-side structural profiling. For context, see React PR #7549: Show React events in the timeline when ReactPerf is active

One particular concern is the measurement overhead. This gist has a benchmarking script (measure.js) for evaluating overhead and initial results.

Results: performance.mark()

Runs about 0.65µs per mark() call. Naturally, that's ~= an overhead of 1ms for 1500 mark()s.

tomazzaman

import fs from 'fs';
import path, { resolve } from 'path';
import assert from 'assert';
import Module from 'module';
import jsdom from 'jsdom';
import Mocha from 'mocha';
import chokidar from 'chokidar';

// Let's import and globalize testing tools so
// there's no need to require them in each test

paulirish

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

fivetanley

(Originally taken from the Skylight "almost daily" emails, written by Tom Dale)

It was a very busy week. We spent the first three days of the week digging deep into Glimmer performance. As we've been scrambling to bring the benefits of this brand new approach to rendering to the many existing Ember apps, we inadvertently added some performance regressions while adding backwards compatibility features.

We spent many hours staring at the profiler in Chrome, trying to figure out how to optimize Glimmer's rendering performance at both the micro and macro level.

One of the biggest improvements was minimizing the number of DOM manipulations for certain cases of re-rendering an each helper in Ember. You can see more of the specific details in the commit here: https://github.com/tildeio/htmlbars/commit/64be35ef03953d80cfe4434446a01dd483bba7b0

This definitely involved busting out some rusty Computer Science skills, but it's always fun to explore algorithms and

nolanlawson

// Promise.all is good for executing many promises at once
Promise.all([
  promise1,
  promise2
]);

// Promise.resolve is good for wrapping synchronous code
Promise.resolve().then(function () {
  if (somethingIsNotRight()) {
    throw new Error("I will be rejected asynchronously!");

sebmarkbage

import { Component } from "React";

export var Enhance = ComposedComponent => class extends Component {
  constructor() {
    this.state = { data: null };
  }
  componentDidMount() {
    this.setState({ data: 'Hello' });
  }
  render() {

Genkilabs

// app/initializers/simple-auth-config.js
export default {
  name: 'simple-auth-config',
  before: 'simple-auth',
  initialize: function() {

    var tokenEndpoint = '/users/sign_in';
    MyAppnameENV['simple-auth'] = {
      authorizer: 'simple-auth-authorizer:devise',
      crossOriginWhitelist:[

rwjblue

From a terminal run the following commands:

git clone git@github.com: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):