sebmarkbage

I heard some points of criticism to how React deals with reactivity and it's focus on "purity". It's interesting because there are really two approaches evolving. There's a mutable + change tracking approach and there's an immutability + referential equality testing approach. It's difficult to mix and match them when you build new features on top. So that's why React has been pushing a bit harder on immutability lately to be able to build on top of it. Both have various tradeoffs but others are doing good research in other areas, so we've decided to focus on this direction and see where it leads us.

I did want to address a few points that I didn't see get enough consideration around the tradeoffs. So here's a small brain dump.

"Compiled output results in smaller apps" - E.g. Svelte apps start smaller but the compiler output is 3-4x larger per component than the equivalent VDOM approach. This is mostly due to the code that is usually shared in the VDOM "VM" needs to be inlined into each component. The tr

everdimension

Cleanup merged branches

Source: https://stackoverflow.com/a/6127884/3523645

git branch --merged | egrep -v "(^\*|master|dev)" | xargs git branch -d

Cleanup orphaned branches

Problem: If pull-request are merged into the main branch using a "squash" strategy and then the remote branches are removed,

ChaosJohn

#!/bin/sh 

DIR="$HOME/.oh-my-zsh/custom/themes"
mkdir -p $DIR
cd $DIR

sed "s/➜/→/g;s/✗/×/g" $HOME/.oh-my-zsh/themes/robbyrussell.zsh-theme > robbyrussell.zsh-theme

ryanflorence

import React, { Component } from 'react'
import logo from './logo.svg'
import './App.css'

import { Route, Link, Redirect } from './Zero'

const paths = [ 'one', 'two', 'three' ]

class App extends Component {
  render() {

acdlite

// getComponent is a function that returns a promise for a component
// It will not be called until the first mount
function asyncComponent(getComponent) {
  return class AsyncComponent extends React.Component {
    static Component = null;
    state = { Component: AsyncComponent.Component };

    componentWillMount() {
      if (!this.state.Component) {
        getComponent().then(Component => {

ALF-er

Disclaimer 1: Первую которая "про то чего мы достигли" я таки пропустил.

Disclaimer 2: Многие доклады смотрелись и отчёты писались в состоянии алкогольного опьянения.

1. Ben Alpert - What Lies Ahead

Сейчас посмотрел Ben Alpert - What Lies Ahead она про то какие идеи они имеют о дальнейшем развитии. И они делят на UX-идеи и DX-идеи. В UX у них:

justinwoo

Reposted from Qiita

For almost a year now, I've been using this "flux" architecture to organize my React applications and to work on other people's projects, and its popularity has grown quite a lot, to the point where it shows up on job listings for React and a lot of people get confused about what it is.

Why I'm tired of using and teaching flux

There are a billion explainations on the internet, so I'll skip explaining the parts. Instead, let's cut to the chase -- the main parts I hate about flux are the Dispatcher and the Store's own updating mechanism.

If you use a setup similar to the examples in facebook/flux, and you use flux.Dispatcher, you probably have this kind of flow:

couto

var webpack = require('webpack');
var HtmlWebpackPlugin = require('html-webpack-plugin');
var path = require('path');
var folders = {
    APP: path.resolve(__dirname, '../app'),
    BUILD: path.resolve(__dirname, '../build'),
    BOWER: path.resolve(__dirname, '../bower_components'),
    NPM: path.resolve(__dirname, '../node_modules')
};

octocat

# Compiled source #
###################
*.com
*.class
*.dll
*.exe
*.o
*.so

# Packages #

jlong

var parser = document.createElement('a');
parser.href = "http://example.com:3000/pathname/?search=test#hash";

parser.protocol; // => "http:"
parser.hostname; // => "example.com"
parser.port;     // => "3000"
parser.pathname; // => "/pathname/"
parser.search;   // => "?search=test"
parser.hash;     // => "#hash"
parser.host;     // => "example.com:3000"