SlexAxton

Before I watched this, if someone would have asked about why Pointer Events wasn't getting into Chrome, I'd have pointed at Safari. I don't love that reason, but it makes sense with their current dominance on mobile. However, I don't necessarily agree, I think if every other browser implemented them, they'd come around. That's tended to be true on the web for the last 20 years (Old IEs, webgl, innerHTML, video codecs when hardware is present, etc)

As far as the main issues brought up here, which I hopefully have fairly summarized (in one sentence each, lol, sry) below, I don't see them as entirely compelling for dropping PE altogether, especially since so many real-world folks (jQuery, Dojo, IE-y people) like the unification quite a bit.

1. Hit tests (with or without capture) are expensive and bad for performance

From what I can read from the previous calls and conversations[0] about this, it's less of an issue than it seems. From those conversations, it seemed like hit tests weren't cached, and Chrome at

paulirish

Just some early draft thoughts

Increased modularity is a long-standing request of jQuery. 3.0 should deliver on that. Many authors will use jQuery 3.0 in ES6 codebases, and often alongside frameworks that have overlap in functionality.

That said, a majority of developers will use a monolithic build. jQuery 3.0 must aggressively remove API surface area and functionality from this core build to protect developers from performance footguns. The jQuery team has reasonably voiced concern that removing modules means it's less likely for people to upgrade. While some users do attempt jQuery version upgrades, many freeze their version and never revisit it. I'd like to get more data on this phenomenon as I think we're optimizing API deprecation policy for a small audience.

Lastly, it's 2015 and the gap between JavaScript developers and jQuery developers has never been bigger. Let's bridge that gap. We should encourage the developer to use modern DOM APIs (that don't suck) and polyfill as neccessary.

Rem

simonhearne

var SPA="none";

if (typeof(app)=="object") SPA = "unknown";

if (window.hasOwnProperty('require')) {
  if(window.require.hasOwnProperty('defined')){
    if(window.require.defined('troopjs-compose/decorator')) SPA = "troop";
    if(window.require.defined('flight/lib/component')) SPA = "flight";
  }
}

gshackles

const schedule = [...document.querySelectorAll("#tablepress-6 tbody tr")]
    .map(row => ({
        room: row.children[0].innerHTML,
        time: row.children[1].innerHTML,
        speaker: row.children[2].innerHTML,
        title: row.children[3].innerHTML,
        level: row.children[4].innerHTML,
        abstract: row.children[5].innerHTML
    }))
    .reduce((slots, session) => Object.assign({}, slots, { 

PaulKinlan

const applyTemplate = (templateElement, data) => {
  const element = templateElement.content.cloneNode(true);    
  const treeWalker = document.createTreeWalker(element, NodeFilter.SHOW_ELEMENT, () => NodeFilter.FILTER_ACCEPT);

  while(treeWalker.nextNode()) {
    const node = treeWalker.currentNode;
    for(let bindAttr in node.dataset) {
      let isBindableAttr = (bindAttr.indexOf('bind_') == 0) ? true : false;
      if(isBindableAttr) {
        let dataKeyString = node.dataset[bindAttr];

getify

Parens And Performance

Years ago, some smart folks that worked on JS engines realized that not all JS that's loaded into a page/app initially is needed right away. They implemented JIT to optimize this situation.

JIT means Just-In-Time, which means essentially that the engine can defer processing (parsing, compiling) certain parts of a JS program until a later time, for example when the function in question is actually needed. This deferral means the engine is freer to spend the important cycles right now on the code that's going to run right now. This is a really good thing for JS performance.

Some time later, some JS engine devs realized that they needed to get some hints from the code as to which functions would run right away, and which ones wouldn't. In technical speak, these hints are called heuristics.

So they realized that one very common pattern for knowing that a function was going to run right away is if the first character before the function keyword was a (, because that usually m

yorkxin

Amazon S3 Redirect Rules Generator

A Ruby script to generate simple Amazon S3 Redirection Rules XML file.

Update: There is an app for that now! Use Amazon S3 Redirector (Web app) and you can generate the XML without any knowledge about Ruby. Thanks to @rainforestapp. BTW, It's open source too.

Dependencies

• Nokogiri

thensg

/**
 * MIT No Attribution
 *
 * Copyright 2015 Giovanni Thenstead
 *
 * Permission is hereby granted, free of charge, to any person obtaining a copy
 * of this software and associated documentation files (the "Software"), to deal
 * in the Software without restriction, including without limitation the rights
 * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 * copies of the Software, and to permit persons to whom the Software is

PaulKinlan

<!DOCTYPE html>
<html>
<head>
<meta charset=utf-8 />
<title>JS Bin</title>
</head>
<body>
  <h2>Original CSS</h2>
  <style style="display: block; white-space: pre; font-family: monospace">
h2 { margin:0; }    

prasidhda

0%
0% risk
777
99%
99.9%
100%
100% more
#1
$$$
100% free