##UPDATE
I've now moved this stuff into it's own repo and added an executable checker, and some nifty diagrams of the stream state transitions state diagrams
This gist is no longer being maintained. goto dominictarr/stream-spec
function introspect(source, alias) { | |
return reducible(function(next, initial) { | |
return reduce(source, function(value, result) { | |
if (value === end) console.log(alias, "<<", value) | |
if (isError(value)) console.log(alias, "\u26A1", value) | |
result = next(value, result) | |
if (isReduced(result)) console.log(alias, "\u2702", result.value) | |
return result | |
}, intial) | |
}) |
##UPDATE
I've now moved this stuff into it's own repo and added an executable checker, and some nifty diagrams of the stream state transitions state diagrams
This gist is no longer being maintained. goto dominictarr/stream-spec
The following features of ES5 cannot be shimmed.
Using Object.defineProperty
if you define a non-enumerable property on an object then for..in
loops over that object will behave correctly in modern browsers but enumerate over that property in legacy browsers.
This means that code that works in modern browsers, breaks in legacy browsers.
Shims allow you to work without a browser compliance or without a browser abstraction library. Modern browsers have enough native and host APIs that you do not need any third party libraries for these features, you just need shims as your legacy browser compliance strategy.
Host objects defined in the WHATWG and W3C specifications are standard APIs. They are well known, readable and maintainable. They are highly optimised and efficient.
Consider getElementsByClassName
, you can either use it and have a shim for non-compliant browsers. This gives you maximum performance for compliant browsers, good performance for non-compliant browsers.
var slice = Array.prototype.slice | |
function iterativelyWalk(nodes, cb) { | |
nodes = slice.call(nodes) | |
while(nodes.length) { | |
var node = nodes.shift(), | |
ret = cb(node) | |
if (ret) { |
var Parent = { | |
constructor: function constructor(magic) { | |
this.isMagic = magic | |
return this | |
}, | |
method: function method() { } | |
} | |
var Mixin = { | |
mixinMethod: function () { } |
Related: [Why you don't need jQuery as an abstraction][2]
$
itself is a god object. Everything goes on it. The standard plugin / extension architecture that is recommended is to just bolt more methods on $
itself!
Surely this is bad. An example would be how we have both $.load
which is overloaded to do completely different things. If they were on two separate sensibly named objects $Container.load
and $EventTarget.load
. Personally I would deprecate the latter in favour of .on('load'
The animation should be it's own little modular thing, not bolted onto $
. Ajax should be it's own little modular thing, not bolted onto $