paulirish

/* bling.js */

window.$ = document.querySelectorAll.bind(document);

Node.prototype.on = window.on = function (name, fn) {
  this.addEventListener(name, fn);
}

NodeList.prototype.__proto__ = Array.prototype;

bishboria

These links no longer work. Springer have pulled the free plug.

Graduate texts in mathematics

duplicates = multiple editions

A Classical Introduction to Modern Number Theory, Kenneth Ireland Michael Rosen

A Classical Introduction to Modern Number Theory, Kenneth Ireland Michael Rosen

alekseykulikov

Recently CSS has got a lot of negativity. But I would like to defend it and show, that with good naming convention CSS works pretty well.

My 3 developers team has just developed React.js application with 7668 lines of CSS (and just 2 !important). During one year of development we had 0 issues with CSS. No refactoring typos, no style leaks, no performance problems, possibly, it is the most stable part of our application.

Here are main principles we use to write CSS for modern (IE11+) browsers:

• SUIT CSS naming conventions + SUIT CSS design principles;
• PostCSS + CSSNext. Future CSS syntax like variables, nesting, and autoprefixer are good enough;
• Flexbox is awesome. No need for grid framework;
• Normalize.css, base styles and variables are solid foundation for all components;

mikhailov

# Nginx+Unicorn best-practices congifuration guide. Heartbleed fixed.
# We use latest stable nginx with fresh **openssl**, **zlib** and **pcre** dependencies.
# Some extra handy modules to use: --with-http_stub_status_module --with-http_gzip_static_module
#
# Deployment structure
#
# SERVER:
#  /etc/init.d/nginx                             (1. nginx)
#  /home/app/public_html/app_production/current  (Capistrano directory)
#

PaulKinlan

(function() { 
  var CSSCriticalPath = function(w, d, opts) {
    var opt = opts || {};
    var css = {};
    var pushCSS = function(r) {
      if(!!css[r.selectorText] === false) css[r.selectorText] = {};
      var styles = r.style.cssText.split(/;(?![A-Za-z0-9])/);
      for(var i = 0; i < styles.length; i++) {
        if(!!styles[i] === false) continue;
        var pair = styles[i].split(": ");

hdragomir

<script type="text/javascript">
    (function () {
      "use strict";
      // once cached, the css file is stored on the client forever unless
      // the URL below is changed. Any change will invalidate the cache
      var css_href = './index_files/web-fonts.css';
      // a simple event handler wrapper
      function on(el, ev, callback) {
        if (el.addEventListener) {
          el.addEventListener(ev, callback, false);

dalethedeveloper

#Mobile Device Detection via User Agent RegEx

Yes, it is nearly 2012 and this exercise has been done to death in every imaginable language. For my own purposes I needed to get the majority of non-desktop devices on to a trimmed down, mobile optimized version of a site. I decided to try and chase down an up-to-date RegEx of the simplest thing that could possibly work.

I arrived at my current solution after analyzing 12 months of traffic over 30+ US based entertainment properties (5.8M+ visitors) from Jan - Dec 2011.

The numbers solidified my thoughts on the irrelevancy of including browsers/OSes such as Nokia, Samsung, Maemo, Symbian, Ipaq, Avant, Zino, Bolt, Iris, etc. The brass tacks of the matter is that you certainly could support these obscure beasts, but are you really going to test your site on them? Heck, could you even find one?! Unless the folks that pay you are die hard Treo users my guess is "No".

Interestingly enough my research shows that /Mobile/ is more efficient than **/iP(

afeld

Updated for Rails 4.0.0+

Bower

1. Set up the bower gem.

2. Follow the Bower instructions and list your dependencies in your bower.json, e.g.

   // bower.json

{

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

scottjehl

I wanted to figure out the fastest way to load non-critical CSS so that the impact on initial page drawing is minimal.

TL;DR: Here's the solution I ended up with: https://github.com/filamentgroup/loadCSS/

---

For async JavaScript file requests, we have the async attribute to make this easy, but CSS file requests have no similar standard mechanism (at least, none that will still apply the CSS after loading - here are some async CSS loading conditions that do apply when CSS is inapplicable to media: https://gist.github.com/igrigorik/2935269#file-notes-md ).

Seems there are a couple ways to load and apply a CSS file in a non-blocking manner: