Browser support about ramda

[buzzdecafe]

yes, if we ever get a build process going, maybe we can add shims to support ancient browsers. Up until recently we could be very cavalier about ignoring anything but modern browsers. That was great.

[megawac]

Specifically with the indexOf, if an (internal) implementation with startIndex is added several functions can be significantly optimized... e.g.

    ramda.isSet = function(a) {
        return !any(a, function(item, idx) {
            return contains(a, item, idx + 1);
        });
    };

[CrossEye]

That would make a lot of sense. And honestly, I would love to be able to say that this library is compatible with ES3 implementations. A pull request would be quite welcome.

From another discussion, we're quite likely to remove at least the current implementation of deepClone, whch I believe is the only dependency on JSON, which leaves only a few things that wouldn't work, I believe in IE6+, including indexOf. It would be nice to be rid of them.

[buzzdecafe]

i knew isSet was sub-optimal; it oughta short-circuit as soon as it finds a dupe instead of just running uniq. again, until the past couple of weeks, we have not focused on perf. now that we are stuff like this will come out.

@CrossEye, i thought i did remove deepClone. did that come back??

[CrossEye]

@buzzdecafe Didn't even check. Looks like it's still gone.

So are foldl1/foldr1. But we'll see how long that lasts.

[megawac]

Regarding path*``With|By here's how I wrote it in my implementation to avoid over currying pathBy

// internal path function
function path(paths, obj) {
    var i = -1, length = paths.length, val;
    while (obj != null && ++i < length) {
        obj = val = obj[paths[i]];
    }
    return val;
}

ramda.pathWith = lodash.curry(function(fn, str, obj) {
    var paths = fn(str) || [];
    return path(paths, obj);
});
ramda.pathBy = lodash.curry(function(sep, str, obj) {
    return path(str.split(sep), obj);
});
ramda.path = ramda.pathBy('.');

[cgarciae]

I suspect support for older browsers makes it more expensive to run on newer browsers since you have to take into account rare cases. I am ideologically opposed to this and in agreement with Douglas Crockford. For supporting old things and not forcing users to update we make the present worst. Someday, in the far but sure to come future, there won't be the need for that extra penalty, what would happen then? Do we have to change all our functions?

[megawac]

I have to disagree with you from a library perspective. A library should try not to limit its browser support for trivial things to implement (consistently). IE<9 still has a decent market share (mostly corporate and second world) and I think itd be foolhardy not to support them to save 20-30 lines of code.

Moreover, because we can make some assumptions and not obligated to follow ES spec verbatim we can get away with more efficient implementations

[buzzdecafe]

i would like nothing better than to ignore legacy browsers, but I agree with @megawac on this. The intent of ramda is to be a practical functional library, and IMHO practical means support for the majority of platforms out there, esp. if it is not expensive.

[megawac]

Can one of you set up Sauce Labs testing

[buzzdecafe]

👍

and testling

[megawac]

On a similar note we should switch from chai to expect if we want to test older code

[buzzdecafe]

that's been on the wish list for a while, but it is a tedious job, so it hasn't gotten done

[buzzdecafe]

old ie has been slain.

[CrossEye]

Hip hip hooray!