I think the first thing to notice about this is:
ua = navigator.userAgent.toLowerCase(), (24, glow.js)
and the env object created that uses this.
This library is fully dependent on browser sniffing.
Yeah, that is for sure. The mitigating goal is that it follows the
"BBC standard [that] exists so as to produce web pages that can be
viewed (as consistently as can reasonably be achieved) by the greatest
number of people possible,"
Whether pages are "consistent" between browsers is irrelevant, the
point is whether they are functional or not. Doing that should not be
left to javascript, or browser sniffing.
If widest possible access is a goal, using an XHTML DOCTYPE is not a
good tactic. As usual, to compensate pages are served as text/html.
meaning afaics all browsers/versions
achievable within a single generation:
Employing a strategy based on capability detection and falling back to
basic functionality obviates the requirement for any list of
"supported" browsers. Sites can then be made compatible with any UA
implementing HTML 4, with additional features for those also
supporting various W3C DOM standards and perhaps vendor enhancements
and extensions.
[...]
Given the goal, browser sniffing seems to me a must-have.
Quite the opposite. Browser sniffing leads to never-ending maintenance
as new browsers come into use. It may also prevent access by otherwise
capable user agents because of a misinterpreted sequence of characters
in their UA string.
I am awfully impressed by the library's overall design,
Which particular design features stand out as being better than other
libraries?
I had a quick look at glow.js, I'm underwhelmed.
glow.lang.trim() references a blog entry that investigation trim
functions in 2 browsers, then doesn't use the one recommended as
"probably the best all-around approach". The one chosen was fastest in
IE, very much slowest in Firefox and requires support for the greedy
operator. Further, it is dependent on the vaguaries of \s, which has
been shown to be inconsistent across browsers and to not match all
possible whitespace.
How is this consistent with the goal of a consistent cross-browser
experience? If they can screw up something so simple in the name of
cross-browser support, what hope for more complex tasks?
glow.lang.hasOwnProperty() will always return true for browsers where
{}.hasOwnProperty and {}.__proto__ are falsey, so even that basic
attempt at feature detection is a failure.
How about glow.lang.toArray():
toArray: function(aArrayLike) {
if (aArrayLike.constructor == Array) {
return aArrayLike;
}
//use array.slice if not IE? Could be faster
var r = [], i=0, len = aArrayLike.length;
for (; i < len; i++) {
r
= aArrayLike;
}
return r;
},
So if you pass it an array (or at least something where
obj.constructor == Array, which will likley fail across frames), it
returns the same array. If you pass it something else, it returns a
new array. A fairly crass attempt that will likely result in some very
hard to find bugs.
Consider glow.lang.apply(). Given the native
Function.prototype.apply() method, you might expect it to do something
similar - you'd be wrong. It copies properties from one object to
another. It doesn't use any filtering of inherited properties, so
what's the point of glow.lang.hasOwnProperty()?
That's enough for me to decide it's not worth further investigation.
Such as?
Which are?
The core is 70kB minified, hardly concise.