Re: Javascript framework performance

On May 16, 7:39 pm, Peter Michaux <petermich...@xxxxxxxxx> wrote:
On May 16, 9:47 am, David Mark <dmark.cins...@xxxxxxxxx> wrote:

On May 16, 12:55 am, Peter Michaux <petermich...@xxxxxxxxx> wrote:
I can agree that feature detection is frustrating at times. I have to
sit down and do some serious Safari feature testing soon and I'm not
looking forward to playing detective.

Testing for what?

Well, I've been using my JavaScript library, Fork, in production for a
couple years. It hasn't needed any fixes but I'd still like to update
it have a new API more to my current tastes. I'd also like to change
the way the feature testing works. The original Fork had these
isSupported functions to test if various parts of the API will work. I
think I'd rather wrap those bits of code in their feature tests so
that the bits of code are not even defined if they won't work.

Now the library is

FORK.Event.addListener = function(){};
FORK.Event.isSupported = function(){return test ? true : false;};

and a user would write

if (FORK.Event.isSupported()) {
  Fork.Event.addListener();

}

I'd rather have the library be

if (test) {
  FORK_addListener = function(){};

}

and then the user would write

if (typeof FORK_addListener == 'function') {
  FORK_addListener();

}

I've digressed a lot but if you have any thoughts on the above please
comment.

I would add a convenience function to check more than one at a time.
Something like:

if (FORK_features('addListener', 'createXhrObject')) {
...
}


What I need to test for is in the event library. Safari 2.0.3-, if I
remember correctly, had a bug where a click or double click event
could not be preventDefault'ed. You've may seen me write about this
before. I wrote about it in the appendix of one article you've read

http://peter.michaux.ca/articles/cross-browser-widgets

Yes.


// Feature test that the Safari workaround will work
// This is *not* a browser sniff! Browsers other
// than Safari will use the workaround if they
// have the necessary features. This is not a problem.
// Tested Safari 1.0, 1.2, 1.3, 2.0 and they all
// need the workaround and all return typeof 'object'
// for unset global.onclick property.

My event library worked around this using DOM0 event handlers. That is
a bunch of ugly code that I'd like to eliminate almost purely for
aesthetic reasons but actually the workaround could clobber an
existing DOM0 handler. Also having the workaround as the comment above
says requires an onunload event which messes with Firefox's caching
system, I think.

It disables fast history navigation in virtually every browser.
Libraries have been using the event for years, which boosted the
demand for Ajax. It's a backwards approach.


These old Safari browsers were auto updated and I doubt there are even
many 2.x users now anyway. Maybe less than 0.1% of web users have one
of these browsers.

I agree you should lose that workaround. As long as your design does
not break if clicks are not prevented, you don't have a problem.
Document this for history buffs and move on.


I could ignore the problem and Safari 2.x- users just get some buggy
behavior. This doesn't seem good enough.

Not even close to good enough. It's make or break at the design
stage. That's another reason I dislike general-purpose libraries as
they can only be designed once and exist to serve every conceivable
document past, present and future.

I wonder do you support IE quirks mode or XHTML or other things.
Neither makes sense to include IMO. I assume you do not support the
latter, but likely have some code to deal with the former.


You could argue that the default behavior of following the link should
be acceptable. In fact, maybe you did argue that once.

I'm sure.

I don't like
this rationalization and where my scripts are used I don't always have
complete control (over business decisions.)

What rationalization? And I don't see where this is a business
decision.

Sometimes there are
"working in groups" compromises that I have to make to move on in life
and not make enemies while belaboring a point about graceful
degradation.

Just show them what to adjust in their design, if possible. If
painted into the corner by the design, you should point out that the
next app should be designed differently. That may not be possible if
using a framework, which leads to an oft-repeated argument against
frameworks.


What I am willing to do is just put either the Safari 2.0.3- users or
even the whole Safari 2.x- users down the degradation path. For them
the event library just wouldn't be defined at all.

I wouldn't.

Ideally they would
have the same user experience as IE5 or NN4 users get: a script-free

NN4, yes. IE5, I can't see it. It doesn't even matter that virtually
nobody uses it. It's just the idea that simple HTML document
enhancements (e.g. form validation) should require IE6 or later.

user experience. (Note this is much different than what I wrote in the
previous paragraph where the Safari users would see a mostly
JavaScript enabled experience and sometimes see a broken JavaScript
experience as they would only be partly degraded and event handlers
would be firing.)

I didn't care for that scenario either.


So I need to identify either Safari 2.0.3- or Safari 2.x- browsers. I
don't think there is an acceptable direct test for the problem of a
click or double click not being preventDefault'ed. The direct test
would require simulating a click or double click and seeing if the
page refreshes. That is too disruptive. So I was thinking about using
multiple object inference for objects only old Safari browsers have
and that no one in their right mind would ever add to another browser.
Yes it is sniffing but it is the most robust kind of sniffing if
enough really exotic objects are tested that only ever existed in
Safari.

I just need to find the right set of objects to test and I've
procrastinated for a long time.

You are looking for a multiple object inference for Safari 2.x. I'm
sure you can come up with one, but I would consider other options.
.

Relevant Pages

  • Re: Javascript framework performance
    ... In the buggy Safari versions, both the popup and the window containing ... Safari 2.x- was down the degradation path completely then there would ... It's make or break at the design ... That's another reason I dislike general-purpose libraries as ...
    (comp.lang.javascript)
  • Re: Starting Safari from the command line
    ... considered a feature" when comparing Safari to other OS X bundles. ... Apple takes UI design very, very seriously, and a CLI interface like this _is_ a user interface. ... The revelation that a single argument is accepted and opened as a local file points to some minimal functionality needed to support a test of some sort. ... These are all excellent reasons to consider such functionality as a feature. ...
    (comp.sys.mac.system)
  • Re: "The Good Enough Revolution" - As it applies to js
    ... the goal should be the best quality ... I've gotten that attitude from other jQuery developers. ... strong arguments against libraries and point out their shortcomings. ... In a recent thread on the "Github" google group, a user reported "slow script" dialog box in Safari 3. ...
    (comp.lang.javascript)
  • Re: Something like "ping" for windows messages.
    ... The third-party socket libraries I know of come with source (in a couple cases it's an ... But the CMutex layer didn't allow you to change that feature ... And what does a defective design of synchronization primitives relate to the ... solution is to buy a third-party socket libary that is designed to be portable. ...
    (microsoft.public.vc.mfc)
  • Re: "Its a Safari problem"
    ... If Safari is the culprit then the best thing would be to leave the site ... I don't know enough about javascript to be able to say the site's code ... iCab 3 shows the 'AJAX wIndows' just fine, ... Serious problem with this design though: the size of the 'AJAX window' ...
    (comp.sys.mac.apps)