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

ericelliott

Essential JavaScript Links

I no longer mantain this list. There are lots of other very comprehensive JavaScript link lists out there. Please see those, instead (Google "awesome JavaScript" for a start).

shfx

window.onerror = function(message, url, linenumber) {
  try{
    _gaq.push(['_trackEvent', 'Error', 'JS', JSON.stringify({'refurl': document.location.href, 'url': url.replace(/\?\d+$/, ''), 'line': linenumber, 'message': message})]);
  } catch (e) {}
  return true;
};

briankung

A Pragmatic Philosophy

I read the first two chapters of [The Pragmatic Programmer: From Journeyman to Master][pragprog], which are entitled "A Pragmatic Philosophy" and "A Pragmatic Approach," respectively. I'll go through and summarize my thoughts "A Pragmatic Philosophy" first:

The preface of The Pragmatic Programmer begins by explaining the meaning of the word 'pragmatic,' which comes from the greek word pragmaticus, or "skilled in business." I get the feeling that this is the central pivot point around which the rest of the book hinges. Skill and craftsmanship are emphasized from the get-go.

Business needs are also a key element, though I get the feeling that it has less in terms of doing whatever the "business person" says and more to do with contextualizing the job of programming within the context of the greater problem at hand.

The sections in the chapter were broken down as seen below. These are the guiding principles behind the rest of the book.

nodesocket

/* Flatten das boostrap */
.well, .navbar-inner, .popover, .btn, .tooltip, input, select, textarea, pre, .progress, .modal, .add-on, .alert, .table-bordered, .nav>.active>a, .dropdown-menu, .tooltip-inner, .badge, .label, .img-polaroid {
 	-moz-box-shadow: none !important;
	-webkit-box-shadow: none !important;
	box-shadow: none !important;
	-webkit-border-radius: 0px !important;
	-moz-border-radius: 0px !important;
	border-radius: 0px !important;
	border-collapse: collapse !important;
	background-image: none !important;

rjz

# A class-based template for jQuery plugins in Coffeescript
#
#     $('.target').myPlugin({ paramA: 'not-foo' });
#     $('.target').myPlugin('myMethod', 'Hello, world');
#
# Check out Alan Hogan's original jQuery plugin template:
# https://github.com/alanhogan/Coffeescript-jQuery-Plugin-Template
#
(($, window) ->

yorkxin

Avoid jQuery When Possible

jQuery does good jobs when you're dealing with browser compatibility. But we're living in an age that fewer and fewer people use old-school browsers such as IE <= 7. With the growing of DOM APIs in modern browsers (including IE 8), most functions that jQuery provides are built-in natively.

When targeting only modern browsers, it is better to avoid using jQuery's backward-compatible features. Instead, use the native DOM API, which will make your web page run much faster than you might think (native C / C++ implementaion v.s. JavaScript).

If you're making a web page for iOS (e.g. UIWebView), you should use native DOM APIs because mobile Safari is not that old-school web browser; it supports lots of native DOM APIs.

If you're making a Chrome Extension, you should always use native APIs, not only because Chrome has almost the latest DOM APIs available, but this can also avoid performance issue and unnecessary memory occupation (each jQuery-driven extension needs a separate

liamcurry

Moving from jQuery

Events

// jQuery
$(document).ready(function() {
  // code
})

ziadoz

Awesome PHP

Awesome PHP has been relocated permanently to its own Github repository. No further updates will made to this gist.

Please open an issue for any new suggestions.

dfurber

# These are my notes from the PragProg book on CoffeeScript of things that either 
# aren't in the main CS language reference or I didn't pick them up there. I wrote 
# them down before I forgot, and put it here for others but mainly as a reference for 
# myself.

# assign arguments in constructor to properties of the same name:
class Thingie
    constructor: (@name, @url) ->

# is the same as: