Scott said:
Do you centralize all code that might need rounded corners, then?
I don't think this is a good example feature as it is hard to imagine
code that hinges on rounded-corners. But yes, depending on the
complexity of the applications, you may need to break it up into
sections and use a different gateway for each section.
If
so, how do you deal with dynamic changes to the DOM? Or do you store
a variable with the result of API,roundCorners? If it's that, how
much savings do you really get?
I don't follow. The gateways prevent entry to sections that would rely
on that feature.
Of course, but my whole post was about ways to make a static API
available that doesn't blow up or fail silently even in the absence of
features we would like.
Well, you can't really abstract a random environment with a static API
unless you are willing to allow some functions to fail silently (which
can work in some cases).
Unless I actually can note performance issues, I'm much more concerned
with clean APIs that are as easy to use as possible than I am about
bloat in the library code.
You can't get much cleaner than the method I describe. If the feature
is there, it is expected to work (and vice-versa), so all you have to do
is write an appropriate gateway (or gateways) for your app. As for the
API itself, the described technique lends itself well to one-off method
function creation, which leads to a clean and efficient set of methods.
But if performance is a concern, this can be done efficiently. It can
still be an up-front check:
API.myCoolFade = (API.opacitySupported)
? function(elt) {
// cool opacity animation here.
}
: function(elt) {
if (elt) elt.style.display = 'none';
}
But now you have an extraneous flag for each dynamically created
function. Why not just use the functions themselves as the flags? Then
there is nothing to get out of sync.
I certainly agree that a dynamic API can be more flexible; that's
practically tautological. I'm not sure I agree about the efficiency
question. To me the main question is whether the behavior of the
static API can degrade in a reasonable manner in environment that
don't support its full functionality.
It is more efficient because neither the app nor the API functions have
to continually check for features or waste time calling code that falls
through silently.
I've done that.too. It works fine. The trouble is then if there is a
simpler supported version of the functionality with fewer bells and
whistles that I can fall back on. It's nice to have the super-cool
fade fall back on a simple hide in the absence of the necessary
environmental features. Then I simply don't have to think about it
usually.
Sure, do that at the application level. If the fade effect is there,
define a hide/show function that uses it. Otherwise use the stock
hide/show function.
if (API.effects && API.effects.fade) {
myCoolShowFunction = function() { ... };
} else {
myCoolShowFunction = API.showElement;
}
Note that this is a generic example. It is not specific (but is
similar) to My Library, which actually does something like this
internally. As a matter of fact, as it sits, My Library's show/hide
functionality is less than ideal as it actually does ignore effects
options on hide/show when effects are impossible. But when only
_specific_ effects are unavailable (e.g. fade), it is up to the
applications to avoid passing those effects functions in the options.
That's something I need to rearrange down the road. For now the
incongruity is simply documented. There actually is a flag on the
affected methods indicating whether the hide/show operation will be
immediate or progressive (the latter indicating that a callback can be
used). Affected methods include setElementHtml, changeImage, as well as
showElement and a few others that can optionally use effects and/or a
callback.
The effects stuff is a bad example though as effects in general will
virtually always be possible (all they need is CSS support and
setInterval). The fade effect may be unavailable in some ancient and/or
limited browsers, but that would be rare compared to something like XHR.
And it is hard to imagine an application that would actually _need_
effects at all, so other than checking for specific effects like fade,
it is fine for most applications to remain oblivious to their presence
or absence.
Of course, when using the OO interface, it is as simple as:-
var E;
if (E && E.prototype.fadeIn) {
// OO application that _must_ be able to fade in elements
}
Well an API with thousands of methods would scare me much more than
this code. Even jQuery's large API has fewer than 250 methods in it.
Large is relative. jQuery isn't much more than a haphazard query engine
with a few basic (and broken) DOM wrappers thrown in. Where they are
starting to bloat is the ill-advised "Live" feature, which attempts to
bottle event delegation (again it is about marketing rather than
providing a sound API). Also, they combine getters and setters, which
reduces the number of methods, but makes application code virtually
unreadable (you must count the number of arguments passed to
differentiate between get and set operations).
Why don't you think this would scale to the multiple environments of
the Internet?
In short, too many flag checks in the application code. Virtually
everything would require such checks as nothing is assured on the
Internet. It's much simpler (and more efficient) to detect methods of
the API up front and be done with it.
So it looks like you have some selling to do!
You mean as far as examples of people using My Library. There are
several people building applications with it that I know of (and likely
many more that I don't know of), but it is only a couple of months in.
I think that if I continue to improve the documentation and wrap up the
last of the CSS3 selectors that everyone seems to expect these days, it
will sell itself. If something like jQuery can become wildly popular,
despite outrageous shortcomings and inefficiencies, I think it is only a
matter of time for mine to do the same.
I'm not much for selling though. As I've said repeatedly, the best bet
is to avoid general-purpose libraries altogether. But I suppose if you
are already sold on the strategy, mine has a lot of positives that
aren't found in any of the others (starting with the dynamic API and
ending with the support that I provide). Also, there is the fact that
none of the others can do much of anything without browser sniffing (in
one form or another). All but jQuery (which uses bad object inferences
and bogus feature testing) are still fixated on the UA string, which is
clearly a fatal flaw (and has been for a decade). They don't see it as
fatal as to them it is sane to swap out a huge script every time a new
browser comes out (and to ignore all that came before). But the
end-users won't buy (or even understand) that when their favorite sites
break (they'll just get new favorites).
