dypsilon

Frontend Development

Attention: the list was moved to

https://github.com/dypsilon/frontend-dev-bookmarks

This page is not maintained anymore, please update your bookmarks.

---

Rich-Harris

Edit — February 2019

This gist had a far larger impact than I imagined it would, and apparently people are still finding it, so a quick update:

• TC39 is currently moving forward with a slightly different version of TLA, referred to as 'variant B', in which a module with TLA doesn't block sibling execution. This vastly reduces the danger of parallelizable work happening in serial and thereby delaying startup, which was the concern that motivated me to write this gist
• In the wild, we're seeing (async main(){...}()) as a substitute for TLA. This completely eliminates the blocking problem (yay!) but it's less powerful, and harder to statically analyse (boo). In other words the lack of TLA is causing real problems
• Therefore, a version of TLA that solves the original issue is a valuable addition to the language, and I'm in full support of the current proposal, which you can read here.

I'll leave the rest of this document unedited, for archaeological

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

treshugart

import React, { Component } from 'react';
import { render } from 'react-dom';
import { props, withProps } from 'skatejs/esnext/with-props';
import { withRender } from 'skatejs/esnext/with-render';

// This is the React renderer mixin.
const withReact = Base => class extends withRender(withProps(Base || HTMLElement)) {
  get props () {
    // We override props so that we can satisfy most use
    // cases for children by using a slot.

treshugart

/** @jsx h */

// You only need custom elements for this!!!
import 'skatejs-web-components/src/native-shim';
import { Component, define, h, prop } from 'skatejs';
import ShadowNode, { scopeCss, scopeTree } from './shadow-node';

// Converts real DOM nodes into Incremental DOM nodes.
//
// This is orthogonal to this gist, but makes it so we can distribute real

treshugart

const $slotRendered = Symbol();
const Slot = (props, chren) => {
  const { changed } = props;

  function onSlotchange(e) {
    const slot = e.target;
    if (slot[$slotRendered]) {
      if (changed) {
        changed(slot);
      }

treshugart

import hify from './create-element';
import React from 'react';
import { render } from 'react-dom';

const h = hify(React.createElement.bind(React));

class Test extends HTMLElement {
  static observedAttributes = ['attr']
  attributeChangedCallback (name, oldValue, newValue) {
    this.innerHTML = `Hello, ${this.getAttribute('attr')}!`;

jexchan

Multiple SSH Keys settings for different github account

create different public key

create different ssh key according the article Mac Set-Up Git

$ ssh-keygen -t rsa -C "your_email@youremail.com"

CMCDragonkai

HTTP Streaming (or Chunked vs Store & Forward)

The standard way of understanding the HTTP protocol is via the request reply pattern. Each HTTP transaction consists of a finitely bounded HTTP request and a finitely bounded HTTP response.

However it's also possible for both parts of an HTTP 1.1 transaction to stream their possibly infinitely bounded data. The advantages is that the sender can send data that is beyond the sender's memory limit, and the receiver can act on

zsup

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

• Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
• Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
• Once documentation has been written, development should commence, and test-driven development is preferred.
• Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
• When a feature is being modified, it should be modified documentation-first.
• When documentation is modified, so should be the tests.