dmitriid

/*
 * TypeScript runs separately, not through loader, and outputs compiled files to
 *    .build_cache
 */


var path                        = require('path')
var webpack                     = require('webpack')
var HtmlWebpackPlugin           = require('html-webpack-plugin')
var InlineManifestWebpackPlugin = require('inline-manifest-webpack-plugin')

dmitriid

let deferreds       = {} as { [key : string] : any[] }
let deferred_timers = {} as { [key : string] : number }

/*
 * If you're waiting wor a `window.something`, and are not sure when it
 * will appear (for example, you defer async load it), you can do the following:
 *
 *       defer('something', (something) => ...)
 *
 *  You can also check nested props:

dmitriid

type any = Js.t {.};

type key =
  | String string
  | Int int;

type hero = {id: string};

type attach_data = Js.t {. placeholder : option any, real : option string}; /* TODO */

dmitriid

<div class="toast toast-success" id='status-color'>
  <button class="btn btn-clear float-right" id='start-stop-button'>START!</button>
  <span id='status-text'>Retrieving status...</span>
</div>

dmitriid

{
  "devDependencies": {
    "@types/jasmine": "2.5.43",
    "@types/jquery": "2.0.40",
    "@types/react": "15.0.12",
    "@types/react-dom": "0.14.23",
    "@types/router5": "0.0.28",
    "autoprefixer-stylus": "0.13.0",
    "babel-core": "6.23.1",
    "babel-loader": "6.2.10",

dmitriid

var path                        = require('path');
var webpack                     = require('webpack');
var HtmlWebpackPlugin           = require('html-webpack-plugin');
var InlineManifestWebpackPlugin = require('inline-manifest-webpack-plugin');
// var BabiliPlugin                = require('babili-webpack-plugin');

var paths = {
  src:   path.join(__dirname, '.build_cache'),
  entry: path.join(__dirname, '.build_cache', 'app', 'index.js'),
  profile: path.join(__dirname, '.build_cache', 'app', 'profile.js'),

dmitriid

Lose-lose situation with Web Components.

Polymer is the leading implementation of Web Components and functionality on top of Web Components.

If this is Web Components spec, it's horrible. Lose

<template>
 [[name.first]] [[name.last]]

dmitriid

package com.dmitriid;

import com.amazonaws.auth.AWSCredentials;
import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.services.s3.AmazonS3;
import com.amazonaws.services.s3.AmazonS3Client;
import com.amazonaws.services.s3.model.CannedAccessControlList;
import com.amazonaws.services.s3.model.ObjectMetadata;
import com.amazonaws.services.s3.model.PutObjectRequest;
import com.amazonaws.util.Base32;

dmitriid

/*
 * No hyperscript helpers
 */


import { h } from '../../snabbdom.wrapper'
import UserStore from '../../stores/UserStore'
import Link from '../components/Link'
import Form from '../components/Form'

dmitriid

The question

tl;dr: Closure compiler makes little to no sense outside of Google's ecosystem.

Nolan Lawson conducted a very nice research on how various Javasctip tools bundle/compile Javascript. I highly recommend it: The cost of small modules.

This article has made several rounds on Twitter and many people have asked: Why aren't more people using Closure? There are many reasons for that.

Considering the dire state of Javascript tools today, Google's Closure compiler is yet another cryptic, badly configured, half-baked tool to throw into the ever-groing pile of twigs and sticks called Javascript infrastructure.