This gist is updated daily via cron job and lists stats for npm packages:
- Top 1,000 most depended-upon packages
- Top 1,000 packages with largest number of dependencies
- Top 1,000 packages with highest PageRank score
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.
elem.offsetLeft
, elem.offsetTop
, elem.offsetWidth
, elem.offsetHeight
, elem.offsetParent
// Implementation in ES6 | |
function pagination(c, m) { | |
var current = c, | |
last = m, | |
delta = 2, | |
left = current - delta, | |
right = current + delta + 1, | |
range = [], | |
rangeWithDots = [], | |
l; |
This is the follow up to a post I wrote recently called From Require.js to Webpack - Party 1 (the why) which was published in my personal blog.
In that post I talked about 3 main reasons for moving from require.js to webpack:
Here I'll instead talk about some of the technical challenges that we faced during the migration. Despite the clear benefits in developer experience (DX) the setup was fairly difficult and I'd like to cover some of the challanges we faced to make the transition a bit easier.
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
var gulp = require('gulp'); | |
var sourcemaps = require('gulp-sourcemaps'); | |
var source = require('vinyl-source-stream'); | |
var buffer = require('vinyl-buffer'); | |
var browserify = require('browserify'); | |
var watchify = require('watchify'); | |
var babel = require('babelify'); | |
function compile(watch) { | |
var bundler = watchify(browserify('./src/index.js', { debug: true }).transform(babel)); |
var Bar1 = base => class extends base { | |
componentWillMount(){ | |
super.componentWillMount(); | |
console.log('Bar1'); | |
} | |
}; | |
var Bar2 = base => class extends base { | |
componentWillMount(){ | |
super.componentWillMount(); |
function get(uri) { | |
return http(uri,'GET'); | |
} | |
function post(uri,data) { | |
if(typeof data === 'object' && !(data instanceof String || (FormData && data instanceof FormData))) { | |
var params = []; | |
for(var p in data) { | |
if(data[p] instanceof Array) { | |
for(var i = 0; i < data[p].length; i++) { | |
params.push( encodeURIComponenet(p) + '[]=' + encodeURIComponenet(data[p][i]); |
Native HTML controls are a challenge to style. You can style any element in the web platform that uses Shadow DOM with a pseudo element ::pseudo-element
or the /deep/
path selector.
video::webkit-media-controls-timeline {
background-color: lime;
}
video /deep/ input[type=range] {
I say "animated gif" but in reality I think it's irresponsible to be serving "real" GIF files to people now. You should be serving gfy's, gifv's, webm, mp4s, whatever. They're a fraction of the filesize making it easier for you to deliver high fidelity, full color animation very quickly, especially on bad mobile connections. (But I suppose if you're just doing this for small audiences (like bug reporting), then LICEcap is a good solution).