Prototype - Good/Bad/Why?

Discussion in 'Javascript' started by ashore, Feb 15, 2008.

  1. ashore

    ashore Guest

    Guys, I see a fair bit of negativity around re subject package. Can
    someone share your views, either way?

    Thanks,

    AS
    ashore, Feb 15, 2008
    #1
    1. Advertising

  2. ashore

    David Mark Guest

    On Feb 15, 4:53 pm, ashore <> wrote:
    > Guys, I see a fair bit of negativity around re subject package.  Can
    > someone share your views, either way?
    >
    > Thanks,
    >
    > AS


    Prototype - very bad.

    It relies on browser sniffing in lieu of proper feature detection and
    testing.

    It works (sort of) in a limited set of modern browsers.

    It is too large and the design isn't modular.

    It is horribly inefficient. Even the lowest level code is tangled up
    in syntactic sugar.

    It augments host objects, most notably in the (unfortunately named) $
    function.

    It fails to leverage the inherent power of the JS language, instead
    trying to force it to work like a class-based language.

    Search the group for more details. Alternatively, read the comments
    in the Rails Trac or related blogs.
    David Mark, Feb 15, 2008
    #2
    1. Advertising

  3. ashore

    dhtml Guest

    On Feb 15, 2:36 pm, David Mark <> wrote:
    > On Feb 15, 4:53 pm, ashore <> wrote:
    >
    > > Guys, I see a fair bit of negativity around re subject package.  Can
    > > someone share your views, either way?

    >
    > > Thanks,

    >
    > > AS

    >
    > Prototype - very bad.
    >
    > It relies on browser sniffing in lieu of proper feature detection and
    > testing.
    >
    > It works (sort of) in a limited set of modern browsers.
    >
    > It is too large and the design isn't modular.
    >
    > It is horribly inefficient.  Even the lowest level code is tangled up
    > in syntactic sugar.
    >
    > It augments host objects, most notably in the (unfortunately named) $
    > function.
    >
    > It fails to leverage the inherent power of the JS language, instead
    > trying to force it to work like a class-based language.
    >
    > Search the group for more details.  Alternatively, read the comments
    > in the Rails Trac or related blogs.


    What goes on behind the scenes in Prototype? Some of the syntactic
    sugaring is inefficient. It also makes code that uses prototype
    require all of prototype, which is now a lot of code. Object Oriented
    and non-modular.

    The $super approach caused problems with compressors:
    http://www5.sys-con.com/read/464826.htm

    In fact, YUI compressor has apparently some logic to account for this.
    (according to the README).

    What do YOU think?
    dhtml, Feb 16, 2008
    #3
  4. ashore

    David Mark Guest

    On Feb 15, 9:36 pm, dhtml <> wrote:
    > On Feb 15, 2:36 pm, David Mark <> wrote:
    >
    >
    >
    >
    >
    > > On Feb 15, 4:53 pm, ashore <> wrote:

    >
    > > > Guys, I see a fair bit of negativity around re subject package.  Can
    > > > someone share your views, either way?

    >
    > > > Thanks,

    >
    > > > AS

    >
    > > Prototype - very bad.

    >
    > > It relies on browser sniffing in lieu of proper feature detection and
    > > testing.

    >
    > > It works (sort of) in a limited set of modern browsers.

    >
    > > It is too large and the design isn't modular.

    >
    > > It is horribly inefficient.  Even the lowest level code is tangled up
    > > in syntactic sugar.

    >
    > > It augments host objects, most notably in the (unfortunately named) $
    > > function.

    >
    > > It fails to leverage the inherent power of the JS language, instead
    > > trying to force it to work like a class-based language.

    >
    > > Search the group for more details.  Alternatively, read the comments
    > > in the Rails Trac or related blogs.

    >
    > What goes on behind the scenes in Prototype? Some of the syntactic


    From what I have read of it, nothing good. Like other (currently)
    popular libraries, much of its decision-making is based on browser
    sniffing and particularly susceptible to the myriad IE imitators out
    there. Treating a non-IE agent as IE is clearly a recipe for
    disaster. The authors of such libraries live in a dream world where
    such agents don't exist.

    I recently stumbled across the change log for the event handling code
    and was amused to see that it cannot handle mousewheel events for the
    handful of browsers it claims to support without several sniff-and-
    branch operations. Such profound incompetence is on display
    throughout the code. The accompanying comments to the seemingly
    constant changes indicate that the developers haven't got a clue what
    they are doing. How long until the maze of browser sniffing logic
    outweighs the code that does actual work?

    > sugaring is inefficient. It also makes code that uses prototype
    > require all of prototype, which is now a lot of code. Object Oriented
    > and non-modular.


    Exactly. It is all-or-nothing. Developers are advised to choose
    nothing.

    >
    > The $super approach caused problems with compressors:http://www5.sys-con.com/read/464826.htm


    I wasn't aware of that one. One of the benefits of not using
    Prototype (or the like) is that you don't have to keep up with the bug
    reports.

    >
    > In fact, YUI compressor has apparently some logic to account for this.
    > (according to the README).


    I highly recommend the YUI "compressor" (misnomer), but certainly not
    YUI itself. It is a better script than Prototype, but shares many of
    the same problems (e.g. browser sniffing, too much sugar, etc.) Then
    there is that ridiculous "namespace."

    >
    > What do YOU think?


    ME? I think I have made that abundantly clear. The only thing worse
    than Prototype is jQuery. YUI is slightly better, but still well
    south of competent. Using any of these libraries (or God forbid
    combinations of them) is a bad idea. The average Web developer can
    achieve lousy results on their own, so what is the benefit of adding
    100K of third-party incompetence to the mix?
    David Mark, Feb 16, 2008
    #4
  5. ashore

    David Mark Guest

    On Feb 16, 12:50 am, Randy Webb <> wrote:
    > David Mark said the following on 2/15/2008 10:42 PM:
    >
    > <snip>
    >
    > > The average Web developer can achieve lousy results on
    > > their own, so what is the benefit of adding 100K of
    > > third-party incompetence to the mix?

    >
    > Incompetence and peer pressure. Not knowing better and because
    > "everybody" is using it.
    >


    It sometimes seems like "everybody" is doing it. What I can't
    understand is why huge corporations would put their faith in trash
    like Prototripe/Craptaculous (typically to add a few nifty fade
    effects.) Can't they afford to pay competent developers? On the
    server side, most appear to believe that .NET is the answer. If so,
    what was the question?

    From what I have read about IE8 (specifically the new versioning meta
    tag), all of the libraries that rely on IE-sniffing are in for a rude
    awakening. Will the authors finally see the folly of their ways or
    will they add more branching based on the content of the meta tag?
    David Mark, Feb 16, 2008
    #5
  6. On Feb 15, 1:53 pm, ashore <> wrote:
    > Guys, I see a fair bit of negativity around re subject package. Can
    > someone share your views, either way?


    <FAQENTRY>

    Shouldn't something about Prototype be in the FAQ? It comes up very
    frequently.

    Peter
    Peter Michaux, Feb 16, 2008
    #6
  7. ashore

    David Mark Guest

    On Feb 16, 1:23 am, Peter Michaux <> wrote:
    > On Feb 15, 1:53 pm, ashore <> wrote:
    >
    > > Guys, I see a fair bit of negativity around re subject package.  Can
    > > someone share your views, either way?

    >
    > <FAQENTRY>
    >
    > Shouldn't something about Prototype be in the FAQ? It comes up very
    > frequently.
    >
    > Peter


    I propose a two word entry: mostly harmful.
    And for jQuery: completely worthless.
    David Mark, Feb 16, 2008
    #7
  8. ashore

    dhtml Guest

    On Feb 15, 7:42 pm, David Mark <> wrote:
    > On Feb 15, 9:36 pm, dhtml <> wrote:
    >
    >
    >
    > > On Feb 15, 2:36 pm, David Mark <> wrote:

    >
    > > > On Feb 15, 4:53 pm, ashore <> wrote:

    >



    > I highly recommend the YUI "compressor" (misnomer), but certainly not
    > YUI itself.

    Me too. But why 'misnomer'? It reduces the file size pretty well.

     It is a better script than Prototype, but shares many of
    > the same problems (e.g. browser sniffing, too much sugar, etc.)  Then
    > there is that ridiculous "namespace."
    >

    Namespacing seemed stupid to me, at first. I mean, these aren't
    "packages", they're just objects.

    In fact, it confused the junior devs. Check out this example:

    YAHOO.namespace("YAHOO.mst.scheduler");

    YAHOO.mst.scheduler = function() { ... }

    It's entirely possible to do this; to reassing a "package" to a
    function (or any value, or delete it). It's not safe. But neither are
    prototypes.

    extend(Sub, Super);
    Sub.prototype = { }; // <- Developer Mistake, just reassinged
    prototype.

    extend(Sub, Super, mixin); // <- corrected.

    On the other hand, enforcing namespacing has made my code more
    modular. Keeping the global namespace clean is just a small benefit.

    If I didn't use packages and a build system, unit testing would be a
    lot harder.

    Writing a library is a lot of work. I want to write a better one. This
    includes:
    modular desing.
    minimal framework.
    building things as simple as possible, but not any simpler.
    unit testing.
    code review.

    Now that last one, I could probably use a lot of help on.

    >
    >
    > > What do YOU think?

    >

    That was meant for the OP. I'm not sure why this thread was brought up
    even. If s/he's really considering Prototype, he could have done a web
    search, or searched this group. (but I can't search Groups in FF
    again; it's only FF now).


    > ME?  I think I have made that abundantly clear.  


    You have.
    The only thing worse
    > than Prototype is jQuery.  YUI is slightly better, but still well
    > south of competent.  Using any of these libraries (or God forbid
    > combinations of them) is a bad idea.  The average Web developer can
    > achieve lousy results on their own, so what is the benefit of adding
    > 100K of third-party incompetence to the mix?


    Most of the F/E jobs here in the bay area want someone who has one of
    the following:
    Prototype, YUI, Dojo, Scriptaculous, jQuery. If you can do that (of
    fake it good enough), you can make decent money.
    dhtml, Feb 16, 2008
    #8
  9. Randy Webb wrote:
    > ashore said the following on 2/15/2008 4:53 PM:
    >> Guys, I see a fair bit of negativity around re subject
    >> package. Can someone share your views, either way?

    >
    > Richard Cornford said it better than anybody else I have
    > ever seen write it and Thomas Lahn uses it in a signature:
    >
    > Prototype.js was written by people who don't know javascript
    > for people who don't know javascript. People who don't know
    > javascript are not the best source of advice on designing
    > systems that use javascript.
    > -- Richard Cornford, cljs, ...

    <snip>

    To be fair, I did not write that as a criticism of Prototype.js as such. I
    wrote it as a comment on the worth of taking the advice of people who use
    Prototype.js (advice which is usually that others should also use
    Prototype.js).

    Of course the comment was justified, and I certainly demonstrated technical
    justification of my "by people who don't know javascript" in the thread with
    the subject "Why should I eschew prototype.js?" (which started with
    Message-ID: < >).

    Richard.
    --
    "Since valid HTML is simply a subset of XML, having an efficient way to
    parse and browser DOM documents is an absolutely essential for making
    JavaScript development easier." - John Resig: Pro JavaScript Techniques.
    2006
    Richard Cornford, Feb 16, 2008
    #9
  10. dhtml wrote:
    > On Feb 15, 7:42 pm, David Mark wrote:
    >> On Feb 15, 9:36 pm, dhtml wrote:
    >>> On Feb 15, 2:36 pm, David Mark wrote:
    >>>> On Feb 15, 4:53 pm, ashore wrote:

    <snip>
    > It's entirely possible to do this; to reassing a "package"
    > to a function (or any value, or delete it). It's not safe.
    > But neither are prototypes.


    Javascript is a dynamic language where it is possible to write code that
    will 'mess up' pretty much any other code. Nothing is "safe", there are just
    varying degrees to which it is easy for programmer to break an existing
    system. In the end it is the programmer's responsibility not to be doing
    things wrongly, and that is going to be best achieved by understanding the
    task in hand, the system it is to be done in/with and the environment(s) in
    which it will operate.

    <snip>
    > On the other hand, enforcing namespacing has made my code
    > more modular. Keeping the global namespace clean is just
    > a small benefit.


    If 'namespacing' were the only way of making code modular then that would
    act as a justification for them, but they are not. Which leaves the only
    relevant namspace-modularity relationship being a demonstration that they
    may be either 'the best method' for achieving modularity or a 'good' method
    in some sense or under some circumstances.

    <snip>
    > Writing a library is a lot of work.
    > I want to write a better one.


    Remember to decide what precisely your library if for before even starting
    to design it. Browser scripting has many contexts of application and trying
    to create something that attempts to be all things to all people is pretty
    much guaranteed to have a result that falls short of all.

    > This includes:
    > modular desing.
    > minimal framework.
    > building things as simple as possible, but not any simpler.
    > unit testing.
    > code review.
    >
    > Now that last one, I could probably use a lot of help on.


    It is still probably the easiest because all you have to do is post code
    here in a readable/understandable form (along with an explanation of what it
    is for) and its shortcomings will be pointed out.

    My thoughts on the majority of current libraries is that they have been
    bought into existence while their authors were experiencing the first flush
    of superficial success in browser scripting (the stage where you start to be
    able to create things that will work on more than two browsers and then gain
    the false impression that you have the problem cracked) and then rushed
    before a public hungry for such things. This has the effect of pretty much
    freezing the libraries API (and its approach and the implied code authoring
    style). The problem being that the authors don't see (because they don't
    have the experience to see) that they have made fundamentally flawed design
    decisions, and then the freezing of the API that follows from its being used
    in the wider world removes any future hope of the overall design being
    corrected (even if the authors are willing/ capable of recognising their
    mistakes (and the current set seems to include many who have personalities
    that are extremely resistant to the very idea that they may have done
    anything wrong)).

    Generally people who can recognise and learn from their mistakes will do
    things better a second time and better yet a third.

    <snip>
    > Most of the F/E jobs here in the bay area want someone who has
    > one of the following:
    > Prototype, YUI, Dojo, Scriptaculous, jQuery. If you can do that
    > (of fake it good enough), you can make decent money.


    This is also the trend in job advertisements in the UK, but not for the jobs
    with the "decent money" (though our perceptions of "decent money" may
    differ). It probably should not be taken too seriously, as the people doing
    the recruiting don't tend to know what they need but have to write
    something. It is like all the web development jobs where knowing Dreamweaver
    was part of the requirement, regardless of the fact that the odds would be
    that someone who knew Dreamweaver well would then not have any actual
    technical understanding of web development at all.

    Richard.
    --
    "Even if you're not completely familiar with XML, you will get great
    satisfaction knowing that all HTML documents (which are, in the eyes of the
    browser, XML documents) have a DOM representation that is ready to use." -
    John Resig: Pro JavaScript Techniques. 2006
    Richard Cornford, Feb 16, 2008
    #10
  11. ashore

    dhtml Guest

    On Feb 16, 6:10 am, "Richard Cornford" <>
    wrote:
    > dhtml wrote:
    > > On Feb 15, 7:42 pm, David Mark wrote:
    > >> On Feb 15, 9:36 pm, dhtml wrote:
    > >>> On Feb 15, 2:36 pm, David Mark wrote:
    > >>>> On Feb 15, 4:53 pm, ashore wrote:

    > <snip>
    > > It's entirely possible to do this; to reassing a "package"
    > > to a function (or any value, or delete it). It's not safe.
    > > But neither are prototypes.

    >
    > Javascript is a dynamic language where it is possible to write code that
    > will 'mess up' pretty much any other code. Nothing is "safe", there are just
    > varying degrees to which it is easy for programmer to break an existing
    > system. In the end it is the programmer's responsibility not to be doing
    > things wrongly, and that is going to be best achieved by understanding the
    > task in hand, the system it is to be done in/with and the environment(s) in
    > which it will operate.
    >

    Yep.
    [snip]

    > <snip>
    >
    > > On the other hand, enforcing namespacing has made my code
    > > more modular. Keeping the global namespace clean is just
    > > a small benefit.

    >

    [sip]

    > > code review.

    >
    > > Now that last one, I could probably use a lot of help on.

    >
    > It is still probably the easiest because all you have to do is post code
    > here in a readable/understandable form (along with an explanation of what it
    > is for) and its shortcomings will be pointed out.
    >

    Thread coming.

    > My thoughts on the majority of current libraries is that they have been
    > bought into existence while their authors were experiencing the first flush
    > of superficial success in browser scripting (the stage where you start to be
    > able to create things that will work on more than two browsers and then gain
    > the false impression that you have the problem cracked) and then rushed
    > before a public hungry for such things.


    Well there;s plenty of mistakes to learn from, then.

    This has the effect of pretty much
    > freezing the libraries API (and its approach and the implied code authoring
    > style).

    That's what I see with YAHOO. They can't change some broken core parts
    of the library, like YAHOO.hasOwnProperty, augmentObject, et c.

    With so many dependencies, how can they change?


    The problem being that the authors don't see (because they don't
    > have the experience to see) that they have made fundamentally flawed design
    > decisions, and then the freezing of the API that follows from its being used
    > in the wider world removes any future hope of the overall design being
    > corrected (even if the authors are willing/ capable of recognising their
    > mistakes (and the current set seems to include many who have personalities
    > that are extremely resistant to the very idea that they may have done
    > anything wrong)).
    >
    > Generally people who can recognise and learn from their mistakes will do
    > things better a second time and better yet a third.
    >
    > <snip>
    >
    > > Most of the F/E jobs here in the bay area want someone who has
    > > one of the following:
    > > Prototype, YUI, Dojo, Scriptaculous, jQuery. If you can do that
    > > (of fake it good enough), you can make decent money.

    >
    > This is also the trend in job advertisements in the UK, but not for the jobs
    > with the "decent money" (though our perceptions of "decent money" may
    > differ). It probably should not be taken too seriously, as the people doing
    > the recruiting don't tend to know what they need but have to write
    > something. It is like all the web development jobs where knowing Dreamweaver
    > was part of the requirement, regardless of the fact that the odds would be
    > that someone who knew Dreamweaver well would then not have any actual
    > technical understanding of web development at all.
    >


    It's not just recruiters. Not many javascript experts out there.

    One case is the company adopts a library. Often, they're B/E devs (or
    tech leads w/o F/E experience). They want a library that's easy to
    understand and does what they need.

    Another case is a F/E dev will promote the library he likes to his
    company, or the team will pick a library. As the team grows, they hire
    other developers who know the same tools.

    Hype can be a big influence.

    Contract jobs such as these vay in pay range, depending on desparation
    (Urgent: Must get 'Ajax' guru). They pay from USD 40-90+/hr. or 70-150k
    +/yr. (in the Bay area).

    Garrett

    > Richard.
    dhtml, Feb 16, 2008
    #11
  12. ashore

    timothytoe Guest

    Until a clj Nazi codes a "correct" library with the capabilities of
    jQuery or Prototype or YUI, those libraries will be continue to be
    used to make websites. And probably to an acccelerating degree.

    I agree that browser-sniffing is about as appealing as anus-sniffing,
    but programmers in the real-world sometimes need to actually get
    things done. A smart programmer (as opposed to a perfection-seeking
    zealot} will go with the flow and be able to throw together a website
    quickly as a result. Sure, the website will be brittle, and users with
    obscure browsers will whine, but that's not a bad way for programmers
    to ensure future work.

    If my site is cobbled together in jQuery, guess what I'm going to look
    for on a FE resume. I need another guy who knows jQuery, so he can
    read and debug the crappy code I wrote, and create new crappy code
    that I can read and debug. I want someone who knows the jQuery plug-
    ins, not some guy that'll come in and write a bunch of new untested
    tab systems, tablesorters, Canvas charting systems, modal dialogs, and
    tool-tips. If my new programmer quits because he hates the music I
    play, or because we have a dangerous-looking homeless guy outside who
    regularly threatens his life and throws half-eaten mayonnaise-and-
    cheese sandwiches at him every time he walks to his car at night, I'm
    going to look for <i>another</i> jQuery programmer to replace him.

    And don't underestimate the impact of these libraries on the makers of
    browsers. As jQuery shows up in more and more sites, will Microsoft
    really want to be seen as releasing an IE8 that is "broken" and
    "sucks?" I predict that Microsoft will endeavor to not break jQuery,
    Prototype, and YUI sites. Already, people are starting to base their
    ideas of "browser speed" on the CSS and XPath selector timings from
    various libraries, and upon Javascript performance. It's not just the
    speed of layout that counts now. I bet Microsoft will actually
    accommodate these libraries so that IE has a little bit less
    embarrassing showing in the benchmarks. Do you think it's coincidence
    that Microsoft is trying to pass acid tests?

    By all means, point out the flaws in the libraries. But if you know
    how to write a better library, perhaps spend some of your time
    building a better mousetrap and a little less time flapping your
    mouthtrap.

    It's all changed out from under you. The libraries are THE major force
    in Web 2.0 development now. jQuery is in (I believe) Rails now, and
    Drupal, and AIR. You may have disdain for them, but it's a quixotic
    (and mildly pathetically humorous) jihad you wage against them.

    I'm not saying there is not a place for a by-the-books JS programmer
    out there--there certainly is. But I think there are already more
    places for a library-slinger and every month will bring more. It's
    more helpful to council people of how to deal with the libraries than
    avoid them.
    timothytoe, Feb 16, 2008
    #12
  13. timothytoe <> writes:

    > It's all changed out from under you. The libraries are THE major force
    > in Web 2.0 development now. jQuery is in (I believe) Rails now, and
    > Drupal, and AIR. You may have disdain for them, but it's a quixotic
    > (and mildly pathetically humorous) jihad you wage against them.


    It's expected behavior. DHTML+AJAX is a disruptive technology, and so
    are the libraries that enable its use to mortals. The responses to it
    fall neatly into the two expected categories: worship and disgust.

    Sure, the libraries are not perfect, but they "get the job done" -
    delivering results that are "good enough", and that get better with
    every iteration.

    Personally I would rather use GWT, but I like statically typed
    languages :)
    /L
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
    Lasse Reichstein Nielsen, Feb 16, 2008
    #13
  14. ashore

    timothytoe Guest

    >>It's expected behavior. DHTML+AJAX is a disruptive technology, and so are the libraries that enable its use to mortals. The responses to it fall neatly into the two expected categories: worship and disgust.

    I see three: worship, disgust, and pragmatism.

    I fall into the third category. I just can't bring myself to be either
    worshipful of or disgusted by a tool that people use to get things
    done. I reserve my worship for Jimi Hendrix and Picasso and my disgust
    for tubgirl and goatse.
    timothytoe, Feb 16, 2008
    #14
  15. On Feb 16, 12:47 pm, Lasse Reichstein Nielsen <> wrote:
    > timothytoe <> writes:
    > > It's all changed out from under you. The libraries are THE major force
    > > in Web 2.0 development now. jQuery is in (I believe) Rails now, and
    > > Drupal, and AIR. You may have disdain for them, but it's a quixotic
    > > (and mildly pathetically humorous) jihad you wage against them.

    >
    > It's expected behavior. DHTML+AJAX is a disruptive technology, and so
    > are the libraries that enable its use to mortals. The responses to it
    > fall neatly into the two expected categories: worship and disgust.


    I think the worshipers are the people who are glad to have someone
    else worry about browser bugs. Then they can defer responsibility when
    the boss questions about the support complaints.


    > Sure, the libraries are not perfect, but they "get the job done" -
    > delivering results that are "good enough", and that get better with
    > every iteration.


    But why do they get better so slowly when so many people are using
    them and apparently reading the code? Browser scripting topics like
    feature detection have been known for a long time and there are many
    well known tests; however, the mainstream libraries opt for
    navigator.userAgent frequently.

    Peter
    Peter Michaux, Feb 16, 2008
    #15
  16. ashore

    timothytoe Guest

    >>But why do they get better so slowly when so many people are using
    >>them and apparently reading the code? Browser scripting topics like
    >>feature detection have been known for a long time and there are many
    >>well known tests; however, the mainstream libraries opt for
    >>navigator.userAgent frequently.


    You'd have to hunt one of them down and make them answer to know, but
    my assumption is not yours. You appear to assume that they are simply
    sniffing to detect features. I assume they are sniffing to get around
    browser JS or CSS bugs, or perhaps in some cases to improve
    performance or to reduce the size of their often-transmitted
    functions. In other words, they probably have reasons that have to do
    with real-world trade-offs.
    timothytoe, Feb 16, 2008
    #16
  17. ashore

    dhtml Guest

    On Feb 15, 10:23 pm, Peter Michaux <> wrote:
    > On Feb 15, 1:53 pm, ashore <> wrote:
    >
    > > Guys, I see a fair bit of negativity around re subject package. Can
    > > someone share your views, either way?

    >
    > <FAQENTRY>
    >


    There shuold be an article about javascript API design. It should
    ideally include an interview or forward by Brendan (long or brief).
    This could be discussed by library authors and users of libraries.

    > Shouldn't something about Prototype be in the FAQ? It comes up very
    > frequently.


    An FAQ Entry should be unbiased and informative. There could be a link
    to some Prototype JS forums. This topic does come up a lot.

    >
    > Peter
    dhtml, Feb 16, 2008
    #17
  18. ashore

    timothytoe Guest

    >>An FAQ Entry should be unbiased and informative...

    Now that's a provocative idea!
    timothytoe, Feb 16, 2008
    #18
  19. ashore

    dhtml Guest

    On Feb 16, 11:29 am, timothytoe <> wrote:
    > Until a clj Nazi codes a "correct" library with the capabilities of
    > jQuery or Prototype or YUI, those libraries will be continue to be
    > used to make websites. And probably to an acccelerating degree.
    >

    <snip blah>

    > And don't underestimate the impact of these libraries


    They do damage. They do this by relying on browser bugs, sniffing the
    userAgent, and then patching it with a hack. What happens if the
    browser is to fix the bug? Chris Wilson takes about IE trying to "not
    break the web".


    <snip blah>
    dhtml, Feb 16, 2008
    #19
  20. On Feb 16, 1:32 pm, dhtml <> wrote:
    > On Feb 16, 11:29 am, timothytoe <> wrote:> Until a clj Nazi codes a "correct" library with the capabilities of
    > > jQuery or Prototype or YUI, those libraries will be continue to be
    > > used to make websites. And probably to an acccelerating degree.

    >
    > <snip blah>
    >
    > > And don't underestimate the impact of these libraries

    >
    > They do damage. They do this by relying on browser bugs, sniffing the
    > userAgent, and then patching it with a hack. What happens if the
    > browser is to fix the bug? Chris Wilson takes about IE trying to "not
    > break the web".


    That right there is the most solid argument I've seen against hacking.
    That is worth having in your sig line.

    Peter
    Peter Michaux, Feb 16, 2008
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,679
    Smokey Grindel
    Dec 2, 2006
  2. June Lee
    Replies:
    2
    Views:
    778
    Jim Cobban
    Apr 13, 2008
  3. rantingrick
    Replies:
    44
    Views:
    1,146
    Peter Pearson
    Jul 13, 2010
  4. Replies:
    9
    Views:
    165
    Thomas 'PointedEars' Lahn
    May 26, 2006
  5. Replies:
    3
    Views:
    252
Loading...

Share This Page