Can there be any doubt at this point that queries were a bad idea?

Discussion in 'Javascript' started by David Mark, Mar 3, 2010.

  1. David Mark

    David Mark Guest

    Perhaps in some way queries could be considered a nice idea. Too bad
    the implementation was so completely botched (over the course of roughly
    five years).

    http://groups.google.com/group/my-library-general-discussion/browse_thread/thread/b0963750135d884d

    I don't think I need to add much to that. As an aside, I'll mention
    that SlickSpeed's error handling is bullshit (at least for YUI3 which
    managed to slip one past the goalie in IE--hell of a shock to see
    something like that).

    I'll have to see if there is a new MooTools available. As mentioned, I
    removed both versions (1.2.4 was the newest IIRC) due to infinite loop
    problems on some of the position-based queries.

    I'm surrounded by incompetence, but will break out before long. :)

    Executive summary for the cited article: do not use queries.
     
    David Mark, Mar 3, 2010
    #1
    1. Advertisements

  2. David Mark

    Scott Sauyet Guest

    If I were to make the following (entirely factual) post, there would
    be good reason for complaint:

    | I've just posted another update of my version of the Slickspeed
    | framework. You can see it here:
    |
    | http://scott.sauyet.com/Javascript/Test/slickspeed/2010-03-03a/
    |
    | There are a number of new selectors, as proposed by David Marks.
    |
    | You can see the result of one of my recent runs in Firefox 3.6 at
    |
    | http://tinyurl.com/ylyhzu5
    |
    | jQuery is the clear-cut winner here, followed by YUI, Dojo, and
    | Prototype. My Library is pulling up the rear. My Library
    | errors out on seventeen different selectors, gets twelve others
    | wrong, and is the slowest on thirty-four additional ones.
    | Clearly My Library has some catching up to do.

    Of course the most obvious complaint is that this only discusses the
    results in one browser, and a very recent one at that. But that is
    not the worst of it.

    The main thing is that I included a six-week old version of My
    Library. And many of the tests that you've since added to your
    Slickspeed version don't work in that older one. You've cried foul
    before on my testing My Library against selectors it doesn't claim to
    support, even though those were the selectors that have been included
    with Slickspeed since the beginning. But you're adding all sorts of
    new selectors and pointing out the failure of other libraries to
    already have them working. You still include jQuery 1.2.1, well over
    two years old, in your comparison; I'll bet they didn't claim at that
    time to include all the selectors you've added recently. At the very
    best, this is hypocrisy.

    The main issue is that tools like Slickspeed are great for minor
    bragging rights about speed. They are useful to fix a minimal list of
    expected behavior from libraries. When you add selectors like this,
    you're obviously trying to use it in a very different manner:

    td[title='test1" # . > ~ + test2[1]']

    The article you link to starts

    | Added :root pseudo and finished up the positional selectors. Lots
    of
    | new tests added to the SlickSpeed page:-
    |
    | http://www.cinsoft.net/slickspeed.html
    |
    | I had a feeling that this would create a lot more black cells in the
    | results table (in anything West of the last two columns of course).
    | Did it ever. :(

    Can you re-read that and not see it as simply self-aggrandizement?

    I've started to play with My Library a bit, and in many ways I like
    it. But the attitude you present with posts like that is more than
    off-putting. In most environments I've worked, I wouldn't be able to
    even *try* to suggest that the client consider using MyLib, not when
    it's presented in such an arrogant fashion.

    And I'm not complaining just about style here. You're adding all
    sorts of new selectors, you're changing the underlying test document,
    you're mixing and matching all sorts of library versions, and you're
    presenting the results as if they prove much more than they actually
    do.

    It's really a shame that a pretty solid piece of work is being buried
    in this nonsense.

    -- Scott
     
    Scott Sauyet, Mar 3, 2010
    #2
    1. Advertisements

  3. David Mark

    Matt Kruse Guest

    Oh I don't know, I use them quite a bit and they work great and result
    in much shorter code that is easier to read and way less work to
    write.

    Perhaps you should qualify your over-generalized conclusion.

    Queries FTW!

    Matt Kruse
     
    Matt Kruse, Mar 3, 2010
    #3
  4. *the* implementation of what?

    Leaving the planet?

    What do you mean by "do not use queries"? What constitutes a "query"?
    Are document.getElementsByTagName or document.getElementById bad in
    your books?

    Peter
     
    Peter Michaux, Mar 3, 2010
    #4
  5. David Mark

    David Mark Guest

    New selectors? Not really.
    Or they can just run it in FF3.6. :)
    As mentioned below, this is all made-up BS. You were testing an old
    version without the QSA adapter against libraries that were just handing
    the queries off to the browsers (using QSA). And you disingenuously did
    not include the latest versions (with or without QSA adapters) that do
    support more of your tested selectors. It was a stupid comparison then
    and even more so now.
    Who are you complaining about?
    Well, how lame. Many of the selectors weren't even _present_ in the
    library then. You do understand that I'm only adding them because
    that's what people seem to want (and continue to run tests that use
    them, hence making it look like mine is "broken"). And then you post
    tests that use a rendition posted six weeks ago (before I started adding
    the bulk of the "standard" selectors). What are you trying to prove?
    What does that mean? Why are you testing a version of My Library that
    (as documented), didn't support all of the selectors. It doesn't make a
    lot of sense as there were appropriate tests for that one at the time. (?)
    Just one. The :not pseudo selector, which I will add shortly, along
    with the of-type stuff, which was never on the "standard" SlickSpeed
    test (quotes indicate there are myriad versions of that test). Again,
    you don't really know what you are talking about.
    You should re-read my test page. There are maybe two or three rows that
    do not have the same old selectors (e.g. :root and :lang). And notice
    that the other libraries appear to work in QSA-enabled environments, but
    then fail when that crutch is not present. That's no good. They either
    support the selectors or they don't. And even variations of ones they
    ostensibly support are botched beyond belief. You don't have to use the
    specific selectors that were on whatever SlickSpeed page you first
    encountered. Feel free to riff on them as that is how you test if
    things work in more than a superficial manner. :)
    Huh? The old version of jQuery is there for a very good reason. If you
    would stop and use your head, you'd know what it is (hint: it is the
    last non-QSA-assisted version). You need to be able to see what their
    slow lane will look like compared to mine as not all browsers have QSA
    and not all queries even work with QSA. We've had this discussion before.
    Don't be juvenile. It's a stress test. I added it primarily to make
    sure that _my_ parsing was working as expected. You are acting like
    this is some sort of contest. Well, there are no prizes and the other
    libraries have supposedly had a multi-year-head start on most of this stuff.
    So what? I had a feeling that they would foul up the positional stuff
    and many of them did (one so bad it had to be cut).
    It's simply facts. Unlike the BS you opened with about "catching up". :)
    So don't use it. Did you read the rest of the post? And did you get
    the main point? Queries were a very _bad_ idea. Don't use them. No
    need to thank me for (hopefully) driving that point home. And if I
    broke some eggs making that omelet, too bad.
    Your client is unlikely to read technical posts in my forum.
    NO, I haven't. You don't know what you are talking about. Re-read it.
    So what! I had to add some stuff to the bottom so that I could test
    something other than DIV's (e.g. form controls). And you tested with a
    completely different document. What the hell is wrong with testing with
    different documents?
    They are all clearly documented. The latest of each is included and
    each is labeled as to whether it supports QSA. What is your problem?
    In clear (perhaps even technical) terms, please. Mixing and matching,
    indeed. :(
    In what way did I present them? The primary points were:-

    1. No compatibility between browsers
    2. No portability between libraries
    3. How did this simplify things?

    And they spent years trying to get it right. It didn't work, did it?
    It's true whether I had taken the time to add more selectors to My
    Library (or even written a library).
    My thoughts exactly. What a nonsensical bunch of hyperbole.
     
    David Mark, Mar 4, 2010
    #5
  6. David Mark

    David Mark Guest

    Is that supposed to be funny?
    Perhaps you should read the article and accompanying test results.
     
    David Mark, Mar 4, 2010
    #6
  7. David Mark

    David Mark Guest

    CSS selector queries (the thing that is discussed in the cited article).
    Obviously not. Those standard DOM methods are what queries attempted to
    stamp out, despite the fact that they are virtually 100% reliable and
    work in almost every browser (certainly anything that has come out of late).
     
    David Mark, Mar 4, 2010
    #7
  8. David Mark

    David Mark Guest

    And BTW, there really is no "if" about it. You actually went to the
    time and trouble to create and post it. That's a lot of effort to look
    stupid. ;)
    And, just as those are not "new selectors" (did you think "2n+1" and
    "2n" were the extent of the positionals?), my name is not "Marks."

    Gee, look at this, QSA can handle lots of "new selectors" and a library
    that never _claimed_ to support them can't. Personally, I think I'd
    post a follow-up that claims an intruder broke in an used my PC to post
    that stuff. It would be just as credible. :)
     
    David Mark, Mar 4, 2010
    #8
  9. David Mark

    David Mark Guest

    And BTW, there really is no "if" about it. You actually went to the
    time and trouble to create and post it. That's a lot of effort to look
    stupid. ;)
    And, just as those are not "new selectors" (did you think "2n+1" and
    "2n" were the extent of the positionals?), my name is not "Marks."

    Gee, look at this, QSA can handle lots of "new selectors" and a library
    that never _claimed_ to support them can't. Personally, I think I'd
    post a follow-up that claims an intruder broke in an used my PC to post
    that stuff. It would be just as credible. :)
     
    David Mark, Mar 4, 2010
    #9
  10. There isn't *one* implementation.


    What you are writing is confused. You are suggesting that using the
    DOM methods is ok but writing functions that use the DOM methods is
    not ok.

    Peter
     
    Peter Michaux, Mar 4, 2010
    #10
  11. David Mark

    David Mark Guest

    That's not what you asked.
    To you perhaps.
    Depends on what those functions do, doesn't it? See above for the
    specific types I am referring to.
     
    David Mark, Mar 4, 2010
    #11
  12. There is still not one implementation.


    You haven't written anything worthwhile in this thread and I have no
    idea what your point is or why you think your logic leads to your
    conclusion.

    Clearly being able to find elements in a document is a worthwhile
    feature for browser scripting. The DOM methods allow that. Those
    methods can be combined to make more complex query functions. Those
    new functions are reusable which is a primary goal of good software
    engineering. Using a domain specific language (i.e. CSS selectors) to
    specify the desired elements provides a compact, declarative API is a
    good idea. CSS has shown it to be a good idea. I've used simple
    selectors and a selector function in JavaScript and looking back it
    was a good idea.

    So although your initial post in this thread was very vague, with the
    extra details you've provided, the answer to your question...
    There is definitely doubt. In fact, it is more than just doubt. The
    opposite is true. Using CSS selectors for finding elements in a page
    (aka queries) is, at the very least, not a bad idea.

    Peter
     
    Peter Michaux, Mar 4, 2010
    #12
  13. No it hasn't *proven* to be a bad idea. Being able to find elements in
    a document is important. Building reusable functions to do that is not
    a bad idea.

    Peter
     
    Peter Michaux, Mar 4, 2010
    #13
  14. David Mark

    Scott Sauyet Guest

    Do you *really* need to ask that question when you proceed to make
    complaints about it?
    The post you referenced to start this thread, begins, "Added :root
    pseudo and finished up the positional selectors. Lots of new tests
    added to the SlickSpeed page"

    Six weeks ago, you posted your version of Slickspeed with 28
    selectors, down from the original 40 that are usually found in
    Slickspeed. When I commented on your reducing the number by 30% you
    said that it couldn't be that high; for the record 12 is exactly 30%
    of 40. I posted a copy of Slickspeed with different libraries but
    with the same set of selectors at

    http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22b/

    In this thread, you now have 81 selectors. As your page keeps
    changing, my version, with your selectors is here:

    http://scott.sauyet.com/Javascript/Test/slickspeed/2010-03-03a/

    And as mentioned before I even posted it. The whole point was that
    posting misleading tests is BS. If you still can't see how that
    applies to your own post, your blindness is rather stunning.

    I'm not sure what "then" you are using here. This was a brand new
    version of Slickspeed posted today using the set of selectors you
    promoted.

    I'm explaining what was wrong with my hypothetical post. By
    comparison, you might see some of what's wrong with yours.

    So, your six-week old version can't handle many of the tests thrown at
    it, but you think it's perfectly legitimate to compare it to a 130-
    week old version of jQuery. Hmmm.

    The whole point is that I wouldn't actually post such misleading
    claptrap, and I really wish you would stop doing so yourself.

    And yet you continually bemoan how the so-called major libraries
    constantly are being updated without stable releases...

    Well, testing that six week old library against your new list, there
    were 17 errors and 12 additional wrong answers in FF. On the original
    forty Slickspeed selectors, there were 5 errors and 10 additional
    wrong answers as can still be seen here:

    http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22a/
    Of course you don't have to use the ones you found. You can alter the
    document. You can replace the list of selectors. You can even change
    how the timing is determined. As long as it seems clear that the
    intent is not to simply make one's own library look better, any of
    this is fair game. However, if I were to post a version that included
    only those queries at which dojo is fastest, and then tried to use it
    to demonstrates the superiority of dojo, others would understandably
    object. That is what it seems you are doing.

    So, is including QSA an appropriate thing to do or not? Not for the
    other libraries, for yours? If it is, fine. If it's not, fine. The
    other libraries have made their choices (subject as always to the
    vagaries of changing design.) If it's most appropriate to use QSA
    with My Library, then stop whining about others including it, and just
    use it. If it's not, then live with the fact that others libraries
    will probably be faster for a great number of queries, although they
    might get things entirely wrong when the native QSA fails. That's
    just the way it goes.

    What's a head start in something that's not a contest?

    Don't be disingenuous. You are promoting My Library unabashedly
    here. I wouldn't have bothered to respond if it hadn't been for your
    saying, "I had a feeling that this would create a lot more black cells
    in the results table (in anything West of the last two columns of
    course). Did it ever." You are treating this as a contest.

    Yes, it looks like MooTools can't handle nth-*: an + b where a is
    negative.

    No, they are equally BS. That was the point.

    I have nothing to add to Peter Michaud's excellent argument in favor
    of CSS-selector queries as a DOM-selection mechanism.

    But have you thought about the overall logic of your post at all? The
    argument seems to be, "Queries suck. Don't use them. But I'm going
    to spend the effort to add them to My Library, so that it's better
    than all the other libraries. Just remember not to actually use
    them."

    Many clients want to see the mechanisms for getting help with the
    tools I suggest for them. When I point out the helpful community
    around Wicket (a Java Web framework) they are much more likely to
    accept it as an alternative to the more well-known frameworks. With
    My Library, I would have to actively steer them away from your rants
    if I ever wanted them to accept it.

    David, as much as you may find this hard to believe, I'm one of the
    ones who wants to help I don't think the ecosystem of JS libraries is
    anywhere near rich enough. I really want to see more innovation. But
    the style in which you present your library makes it next to
    impossible to even give it a chance.

    -- Scott
     
    Scott Sauyet, Mar 4, 2010
    #14
  15. David Mark

    Scott Sauyet Guest

    Well, I learned from the master.

    Actually, posting a new version of the slickspeed test takes me only a
    few minutes. The only reason this one took as much as ten minutes was
    because the slickspeed framework didn't properly handle selectors with
    single-quote characters in them, and I had to fix that.
    I understand the distinction you are making. But it is I think not
    the common usage of "selector". It is certainly not how I use it.
    "div" and "p" are distinct selectors to me, as are ":nth-child(2n +
    3)" and ":nth-child(2n -1)".

    I apologize.

    I wish your post had a credible excuse.

    -- Scott
     
    Scott Sauyet, Mar 4, 2010
    #15
  16. David Mark

    David Mark Guest

    You are still playing dumb. What's the point?
     
    David Mark, Mar 4, 2010
    #16
  17. David Mark

    RobG Guest

    I think the basis of David's argument is that they are a bad idea
    because of the differences in implementations. Because various
    libraries introduce an additional set of inconsistencies, the range of
    possible outcomes is greatly increased.

    I think simple CSS queries can be very helpful, but most of those can
    be easily replaced with simple ad hoc functions. Complex selectors can
    be harmful, not only for performance, but they more tightly bind
    programming logic to document layout so that a small change may cause
    a script to fail or enhancements to become unreliable.

    I also suspect that complex selectors are more likely to have
    inconsistent results, but don't have any proof.

    As for David's hyperbole, I took it as just that. Scale it back to
    half-throttle and you get "[CSS] queries can lead to problems", which
    is true. It wasn't that long ago that it was standard practice to
    ensure sites worked without scripting and that script only enhanced
    usability. Lately there has been a trend to sites that are
    dysfunctional without scripting. I expect that within a few years,
    browsers that do not have efficient built-in query selector support
    will find the web quite unfriendly. That will lead to problems for
    less capable browsers and platforms.

    Incidentally, I tried surfing with Safari 1.0.3 recently - very few
    sites were functional, including apple.com. Considering it's younger
    than IE 6 (2004 vs. 2001), it is clear that if IE 6 didn't have the
    market share it has, developers would have stopped coding around its
    quirks many years ago and it would be dead by now. Imagine a web where
    most browsers were DOM and CSS 3 compliant and HTML5 was mostly
    implemented, then javascript libraries could focus on efficient
    delivery of high-level functionality, not smoothing over browser
    quirks.

    And this thread would be irrelevant.
     
    RobG, Mar 4, 2010
    #17
  18. David Mark

    David Mark Guest

    New tests, not new selectors. CSS3 has been around for years, as have
    the claims of support for them by makes of selector engines. What you
    meant to say was that I added variations of the same old CSS3 selectors
    (e.g. mth-child(4n+3) as opposed to the usual nth-child(2n+1)). Somehow
    , you see this as "cheating", which indicates you don't really
    understand what these tests are for.
    You are wildly mistaken. I posted that roughly two years ago. And it
    was perfectly appropriate to remove the tests for selectors I did not
    support when I first wrote the library. In fact, there was a disclaimer
    that the top that point it out.
    Um, don't break your arm patting yourself on the back for accuracy. I
    didn't count them at all. So what? Is that supposed to make up for all
    of this newly posted and misleading nonsense?
    Yes, we've been over that. You didn't understand at the time about QSA.
    We finally got past that (or so I thought). Anyway, so what?
    Yes, adding additional test cases is a good thing.

    Yes, adding non-DIV's to test is a good thing too. Testing DIV's
    exclusively is inherently limited (for reasons that should be obvious).
    I find myself asking you this a lot, but what's the point in all of
    this? It's like you go on and on about nothing and hope that the sheer
    weight of it will make naive readers think there is something to it.

    No, as I explained. You are blind to the fact that 98% (go calculate it
    and tell me it is really 97) of the additions are variations of
    selectors that are ostensibly supported by the "competition". Do you
    not understand that you have to test variations to get anything more
    than the same superficial results that have been deluding you (and the
    library authors) into thinking all is well?
    The "then" was when you compared QSA to non-QSA and proclaimed that QSA
    was faster. :)

    ISTM you are doing something similar now, proclaiming (admittedly
    disingenuously) that an old rendition of mine, which predates any
    support for the newly added CSS3 selectors is "broken", "miscounting",
    etc. and that the others are "faster", when in fact, the others are
    simply handing the queries off to the browsers (using QSA) and have been
    demonstrated to screw up lots of them when that crutch is taken away (as
    it often is in the wild).
    ^^^^^^^^^^^^

    FYI, That's spelled h-y-p-o-c-r-i-t-i-c-a-l. It's like making an
    obnoxious joke and qualifying it with something like "if I were a real
    jackass, I would have said..." You said it. You also posted bogus
    tests. :(
    No, that was your qualification that was supposed to make you look
    gallant and restrained rather than disingenuous and obnoxious.
    You really need to get a grip. There are _three_ versions of jQuery on
    that page. They are all clearly labeled. It is up to you to interpret
    what the results mean to you. Seeing the history of these things has
    been a real eye-opener for those who can think straight. It's not a
    conspiracy to make jQuery 1.21 look lousy. But then, jQuery 1.21
    claimed to support virtually all of the selectors on the page.

    And, as for my six-week-old version, it handled exactly what I claimed
    it would handle and I listed exactly what was _not implemented at all_
    six weeks back. See the difference now? I never even wanted to add all
    of these silly selectors, but as there have been requests and tests
    posted that made it look broken due to the fact that it didn't support
    some "standard" set of selectors...

    Again, what are you trying to say?
    But you did. That's one of my points. The other is that much of what
    you say and do with regard to these SlickSpeed tests is laughably inept
    and demonstrates a severe misunderstanding about JS libraries, their
    claims, history and how all of this paints a picture of enduring abject
    incompetence. The fact that I never wanted to follow in their
    footsteps, hadn't really done so six weeks back, did trample them of
    late, etc. is irrelevant. Look at the big picture and imagine if I had
    never even wrote a library. ;)
    So what? I've never released mine at all. In fact, it sat on the shelf
    for over two years, with me telling anyone who would listen not to use
    any GP library (including mine). During that time, despite numerous
    mistakes on my part, it survived the releases of several major browsers,
    including IE8 without my lifting a finger. That demonstrated how the
    feature testing beat the hell out of the browser sniffing that was
    popular at the time. A month or two back, I started working on it
    again, tested all the way back to the late 90's browsers, patched some
    holes in the feature detection as a result and will release it when I
    feel like it. So what?

    And how is adding support for additional selectors the same as endlessly
    twiddling with browser sniffing, epiphanies about IE that should have
    occurred years ago, etc.? It's not as if I am fixing bugs in my
    non-existent release version, am I? As a matter of fact, I'm not fixing
    bugs at all. I'm adding features by request (notably from you).

    And remember, one of the biggest selling points of those "major"
    libraries is that they are so well-tested because they have so many
    vigilant users and developers. LOL.
    Um, once again, you were testing selectors that I explicitly did not
    support, which was plainly documented at the top of the page. I never
    claimed (two years ago) to support all forty of those "standard"
    selectors (quotes indicate there are lots of variations of this test out
    there). So how stupid is it to keep parroting about these imagined
    failures? You can't have a failure without an assertion, can you? ;)
    And what sort of fool wouldn't? The original set of selectors was all
    DIV's (as was 99% of the document). How stupid was that?
    And obviously adding (4n+3) and (-2n+1) next to (2n+1) is necessary to
    verify that your positional selectors are working properly. What sort
    of fools (besides the authors of the original test page) wouldn't do
    that? FYI, as mentioned, the primary purpose of that page is to _test_
    my engine. Embarrassing the other efforts is just a highly unexpected
    bonus. :)
    You are completely full of shit. How is adding lots of additional
    positional tests going to make mine appear faster? I can't even fathom
    what you are saying. Do you think I studied the ins and outs of all of
    the others and determined that this area (which was coincidentally
    lacking in the original list) was the perfect place to add more tests to
    make mine look faster?! And perhaps adding lots of attribute variations
    (which preceded these latest additions) would also make mine look faster
    too. Or maybe, just maybe, I want to create as stressful a set of tests
    as I can and never mind the impact on speed (an area where I have never
    been exactly lacking?) Think about it.
    Depends on what you are trying to compare, doesn't it?
    Huh? AFAIK, the others don't give you any option. That's why you have
    to look at their old versions side by side to compare with both of mine
    (meaning with and without the QSA add-on). I really hope these concepts
    are starting to congeal at this point.
    Whining?! I've always included both versions on my tests. End of
    story. What you do is really of no consequence, except that it often
    exposes your lack of understanding for what your tests are comparing.
    Why not compare both and let the users decide what they want. That's
    what I did. ;)
    I clearly was referring to your use of the word "contest". But call
    them efforts as it is more appropriate.
    Over using YUI or Dojo or jQuery? You bet. And I hope it is clear at
    this point that you really shouldn't use CSS selector queries,
    regardless of the library.
    No, it is a chart of results. Nothing more. My assertion was that they
    would have lots of errors (and miscounts) for these less-than-trivial
    additions and they did. So what?
    Yes. It sends them into an infinite loop, which doesn't speak well of
    their QA. Again, the "well tested by many eyes" argument turns out to
    be bunk.
    Don't write wrong answers on the blackboard as somebody is likely to
    copy them down. ;)
    Oh Christ, take me now. He had no argument at all. It was the same
    generalized BS over and over. It was like he was posting from a coma.
    Actually, that is what I am saying and it is quite logical. Nobody will
    even consider a library if it doesn't have CSS3 selector queries.
    That's a fact of life. I say don't even include that crap in the build
    (and have always said that). And if I am going to honor requests for
    more selectors, I'm going to make sure that they work in as many
    browsers and configurations as I can before announcing that they are
    available for user. Logical?
    Java?! So what?
    Don't be ridiculous. Even my harshest critics have acknowledged that my
    support (particularly in that forum) is grade-A. I don't think your
    client would care what I said about the other libraries, particularly as
    it is all true.
    It's been on the brink of bankruptcy for years.
    For God's sake, if you want me to make progress (on the code) cut out
    these marathon responses.
     
    David Mark, Mar 4, 2010
    #18
  19. David Mark

    David Mark Guest

    Throwaway lines don't really change the score.
    I suppose. I don't remember having that problem. I test both single
    and doubles.
    Okay, fair enough. In that sense, I added "new selectors", but how is
    that being sneaky or disingenuous? I think it is just being thorough.
    Now, if I added lots of rows of the of-each stuff (coming tomorrow
    likely, but with a disclaimer of course), which the others (mostly) do
    not support...

    And I'll have you know that I'll be adding NWMatcher whenever I have a
    chance. AFAIK, it is as (or more) robust than mine in most respects and
    perhaps faster too (at least in the slow lanes in some browsers).
    NP on that one.
    I think you are making way too much out of what was a couple of
    paragraphs in my own forum (and a few asides here).
     
    David Mark, Mar 4, 2010
    #19
  20. I think that doesn't necessarily make the idea bad but the
    implementations could be judged as bad. Original compilers (e.g.
    Fortran) were complex and challenging to build and presumably buggy
    but compilers weren't a bad idea.

    I agree. Actually my selector function can only handle simple
    selectors with any combination of tag, id, and class values.

    I've written a couple complex selector engines and they are
    significantly more difficult to implement than simple selector
    engines.

    I work on such web apps. The implementation overlap between a no-
    JavaScript version and a JavaScript version is so little that business
    says they don't care to pay for the no-JavaScript version.

    By that time canvas and HTML video may be significant players also and
    be incentive for people to upgrade.

    I think the JavaScript libraries will always smooth over browser
    quirks for the most recent set of browser features. When IE7 dies, XHR
    libraries will be only a thin layer of sugar. If IE ever implements
    the DOM2 event model then that wrapper library can go away. But new
    things like canvas and video will probably have various browser bugs
    to work around and so the JavaScript libraries will live on for them.

    In some ways. The popularity of the query selectors implemented in
    JavaScript were the motivation for the built-in query selectors.
    History often repeats itself and I wouldn't be surprised if similar
    developments for a different browser scripting topic happens again.

    Peter
     
    Peter Michaux, Mar 4, 2010
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.