msmfsd

// Async/Await requirements: Latest Chrome/FF browser or Babel: https://babeljs.io/docs/plugins/transform-async-to-generator/
// Fetch requirements: Latest Chrome/FF browser or Github fetch polyfill: https://github.com/github/fetch

// async function
async function fetchAsync () {
  // await response of fetch call
  let response = await fetch('https://api.github.com');
  // only proceed once promise is resolved
  let data = await response.json();
  // only proceed once second promise is resolved

ramiroaznar

select * from table t1
where (select count(*) from table t2
where t1.field = t2.field) > 1
order by field

robotnealan

server {
    listen 80;
    listen [::]:80;

    server_name robertnealan.com;
    root /var/www/ghost/system/nginx-root;

    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

tracker1

import {createAction} from 'redux-actions'
import {
  SOMETHING_STARTED,
  SOMETHING_SUCCESS,
  SOMETHING_ERROR
} from './constants';

export const somethingStarted = createAction(SOMETHING_STARTED);
export const somethingSucceeded = createAction(SOMETHING_SUCCESS);
export const somethingFailed= createAction(SOMETHING_ERROR);

amcdnl

Why I hate TypeScript

Warning: These views are highly oppinated and might have some slightly incorrect facts. My experience with typescript was about 2 weeks in Node and a week in angular2.

Not Standard

TypeScript is implementing their own take on JavaScript. Some of the things they are writing will likely never make it in an official ES* spec either.

Technologies that have competing spec / community driven development have a history of failing; take: Flash, SilverLight, CoffeeScript, the list goes on. If you have a large code base, picking TypeScript is something your going to be living with for a long time. I can take a bet in 3 years JavaScript will still be around without a doubt.

Its also worth noting that they have built some things like module system and as soon as the spec came out they ditched it and started using that. Have fun updating!

eliot-akira

==========================
How Software Companies Die
==========================
 - Orson Scott Card

The environment that nurtures creative programmers kills management and
marketing types - and vice versa.

Programming is the Great Game. It consumes you, body and soul. When
you're caught up in it, nothing else matters. When you emerge into

varmais

var getPosition = function (options) {
  return new Promise(function (resolve, reject) {
    navigator.geolocation.getCurrentPosition(resolve, reject, options);
  });
}

getPosition()
  .then((position) => {
    console.log(position);
  })

watson

Low-level modules

• airplay-mdns-server - Advertise an AirPlay server on the network
• raop-mdns-server - Advertise a RAOP server on the network
• raop-stub - Create a fake RAOP server on the network
• rtsp-stream - Parse RTSP streams
• rtsp-server - A low level module for creating RTSP servers
• raop-server - A low level module for creating RAOP servers (WIP - for now, see raop-rtsp-server or rtsp-server instead)
• airplay-server - A low level module for creating AirPlay servers
• airplay-txt - WIP

chantastic

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

tracker1

Directory structure for JavaScript/Node Projects

While the following structure is not an absolute requirement or enforced by the tools, it is a recommendation based on what the JavaScript and in particular Node community at large have been following by convention.

Beyond a suggested structure, no tooling recommendations, or sub-module structure is outlined here.

Directories

• lib/ is intended for code that can run as-is
• src/ is intended for code that needs to be manipulated before it can be used