clj in course material

Discussion in 'Javascript' started by Karl Tikjøb Krukow, Jul 27, 2010.

  1. I am preparing an introductory course on JavaScript for the place I work
    at. As part of the course, I would like present some of the common
    knowledge and generally accepted advice of this group, since it is not
    commonly known and it should guide them in the right direction.

    (A small) part of this is on general purpose libraries. I've exported
    the slides as a set of html documents which can be found here:

    <http://higher-order.net/courses/05-js-libraries.html>

    I would appreciate feedback from the group. Remember that this is an
    introductory course to it should be kept to basics and generally
    accepted statements.

    - is it accurate (enough for an introductory course)?

    - are the examples OK?

    - is something important missing?


    Additional questions on attribution:

    - Did Cornford or Crockford invent the module pattern?

    - Who created the initial "clone/object/beget/Object.create": Cornford,
    Crockford or Reichstein Nielsen?

    Thanks for your time
    /Karl
    Karl Tikjøb Krukow, Jul 27, 2010
    #1
    1. Advertising

  2. Am 2010-07-27 09:59, Karl Tikjøb Krukow meinte:
    > I am preparing an introductory course on JavaScript for the place I work
    > at. As part of the course, I would like present some of the common
    > knowledge and generally accepted advice of this group, since it is not
    > commonly known and it should guide them in the right direction.
    >
    > (A small) part of this is on general purpose libraries. I've exported
    > the slides as a set of html documents which can be found here:
    >
    > <http://higher-order.net/courses/05-js-libraries.html>
    >
    > I would appreciate feedback from the group. Remember that this is an
    > introductory course to it should be kept to basics and generally
    > accepted statements.


    Some things I noticed when quickly browsing through some slides:

    "Normalization: DOM Nodes - Some libraries provide their own types"
    Libraries can't provide their own (read: custom) *DOM* nodes. Perhaps
    some node-lookalikes.

    "Be vary of augmented HTML*Elements" - better: "Be wary of augmented
    host objects"

    "Element types"? I'd call it "Wrapped DOM elements".

    Gregor


    --
    http://vxjs.gregorkofler.com
    Gregor Kofler, Jul 27, 2010
    #2
    1. Advertising

  3. Gregor Kofler wrote:
    > Am 2010-07-27 09:59, Karl Tikjøb Krukow meinte:
    >> I am preparing an introductory course on JavaScript for the place I work
    >> at. As part of the course, I would like present some of the common
    >> knowledge and generally accepted advice of this group, since it is not
    >> commonly known and it should guide them in the right direction.
    >>
    >> (A small) part of this is on general purpose libraries. I've exported
    >> the slides as a set of html documents which can be found here:
    >>
    >> <http://higher-order.net/courses/05-js-libraries.html>
    >>
    >> I would appreciate feedback from the group. Remember that this is an
    >> introductory course to it should be kept to basics and generally
    >> accepted statements.

    >
    > Some things I noticed when quickly browsing through some slides:
    >
    > "Normalization: DOM Nodes - Some libraries provide their own types"
    > Libraries can't provide their own (read: custom) *DOM* nodes. Perhaps
    > some node-lookalikes.
    >
    > "Be vary of augmented HTML*Elements" - better: "Be wary of augmented
    > host objects"
    >
    > "Element types"? I'd call it "Wrapped DOM elements".
    >
    > Gregor
    >


    Thanks for taking the time, Gregor. I'll make the suggested changes.

    /Karl
    Karl Tikjøb Krukow, Jul 27, 2010
    #3
  4. Karl Tikjøb Krukow

    RobG Guest

    On Jul 27, 5:59 pm, Karl Tikjøb Krukow <> wrote:
    > I am preparing an introductory course on JavaScript for the place I work
    > at. As part of the course, I would like present some of the common
    > knowledge and generally accepted advice of this group, since it is not
    > commonly known and it should guide them in the right direction.

    [...]
    > Additional questions on attribution:
    >
    > - Did Cornford or Crockford invent the module pattern?


    Its history in this group is summarised by Richard Cornford here:

    FAQ Topic - How do I format a date with javascript? (2009-02-26)
    <URL: http://groups.google.com.au/group/comp.lang.javascript/msg/4947717f130ca6e5?hl=en
    >


    He claims credit (probably quite rightly) for building on the early
    work of Yann-Erwan Perio and Gosha Bine to develop the pattern that is
    in current use as the module pattern.


    > - Who created the initial "clone/object/beget/Object.create": Cornford,
    > Crockford or Reichstein Nielsen?


    I believe the pattern that Crockford popularised with beget was
    originally proposed here by Lasse Reichstein Nielsen:

    Using setInterval inside an object
    <URL: http://groups.google.com/group/comp.lang.javascript/msg/5d06e72e55d5bf11?pli=1
    >



    <FAQENTRY>
    Perhaps some of the above can be inclued in a "history of javscript"
    section of the FAQ so that such things aren't lost.
    </FAQENTRY>


    --
    Rob
    RobG, Jul 27, 2010
    #4
  5. On Jul 27, 8:59 am, Karl Tikjøb Krukow wrote:
    > I am preparing an introductory course on JavaScript for the place I work
    > at. As part of the course, I would like present some of the common
    > knowledge and generally accepted advice of this group, since it is not
    > commonly known and it should guide them in the right direction.
    >
    > (A small) part of this is on general purpose libraries. I've exported
    > the slides as a set of html documents which can be found here:
    >
    > <http://higher-order.net/courses/05-js-libraries.html>
    >
    > I would appreciate feedback from the group. Remember that this
    > is an introductory course to it should be kept to basics and
    > generally accepted statements.


    Slide img2.html

    "The goal for JavaScript libraries is to present an API which

    - us uniform and more high-level, yet efficient.
    - works around known bugs
    - supports a wide range of user agents."

    The "supports a wide range of user agents" is demonstrably false in
    almost all cases. Most javascript libraries aim to support a fixed set
    of user agents, and quite a restricted set at that.

    slide img3.html

    "Most libraries provide
    * ... , Keyboard normalization ..."

    Mostly they don't. Keyboard normalisation (so between event models and
    key event behaviour, Hardware variations, OSs (which must include non-
    desktop OSs) and language related keyboard layout) is complex subject
    that is rarely more than superficially addressed in library code.

    Slide img5.html

    "Be vary of augmenting HTML Elements" probably contains a typo.

    Slide img7.html

    "Least common denominator, e.g., event capture"

    Shouldn't that be event bubbling, as its capturing that IE doesn't do?

    Slide img8.html

    "This is considered bad practice, a hack, by many.
    - Unreliable
    - Restricted accessibility
    - Maintenance"

    I don't think that "accessibility" has much direct relevance to
    browser sniffing. It can be restricted as much without it as with it.

    As this related to UA string based browser sniffing why doesn't the
    list of reasons for considering it "bad practice, a hack" (which is a
    considerable understatement in many cases) include the observation
    that it has no technical foundations (i.e. that there are no technical
    grounds for believing that it should be possible to determine browser
    type or version from any User Agent header/string). Given that the
    pertinent standard (the HTTP 1.1 standard) does not even require that
    a user agent send the same sequence of characters in its User Agent
    header for two consecutive requests (let alone that it should contain
    anything specific, let alone specific to the browser or its version).

    The relevance of this is highlighted by 'arguments' in favour of
    browser sniffing such as:-

    <URL: http://blog.davglass.com/2009/01/browser-sniffing-vs-object-detection/
    >


    | That would be like me changing the information on my license
    | plates and then telling the officer: "You should have checked
    | the VIN instead of the license plate, I didn’t like what it
    | said so I changed it".

    - where that analogy implies some sort of 'law' being broken. While
    the applicable 'law' actually says the UA string can be anything
    anyone wants, and doesn't even have to be the same thing from one
    occasion to the next. The real automobile analogy for the UA header/
    string is not with a licence plate, but rather with something like a
    bumper sticker; if you don't like it you may change it at your own
    discretion, and no "officer" has any reason to question you about it
    (at least assuming it is not offensive, an incitement to violence/
    crime, etc.).

    The observations that there is no technical basis for the belief that
    you can discriminate between web browsers/browser versions using the
    User Agent header/string, that web browser default User Agent headers
    have been observed as being indistinguishable from those of other
    browsers, and that User Agent headers can, in some circumstances, be
    modified by users (and third party software) should be enough to
    convince the rational that "bad practice, a hack" is an extremely mild
    label to attach to the folly of browser sniffing.

    Slide img10.html

    The - typeof el.childNodes // 'function' - example for Safari is
    probably inappropriate in context as the childNodes collection can be
    called in that environment and so is a function, making the behaviour
    fully conforming with the ECMAScript behaviour for a native function.

    Slide img15.html

    The "Potential cons" list:-

    - Does not mention that the libraries are rarely actually cross-
    browser (but merely support a limited set of brewers, so are actually
    little more than an elaboration of the "both browsers" scripts from
    the end of the last century).

    - Does not mention that any 'community' is no more than the sum of the
    people who participate in it, and that if the users of a library are
    doing so because they don't know enough to do anything else (or
    better) then their potential to offer help may be severely
    constrained. (For example, while it existed the JQuery 'community' on
    Google groups did not even answer between a quarter and a third of the
    questions asked there, which was of zero 'help' to the people asking
    those questions)

    - Does not mention that the quality of library documentation can be
    very poor, especially when the authors of the documentation either do
    not understand what their code actually does, (and/)or believe that
    what it does is obvious.

    (There is a general documentation dilemma where the people who
    understand cannot easily think themselves into the position of those
    that don't, and so cannot see all of what needs to be put across, and
    the people who don't understand can see what they would need to be
    told, but cannot tell it.)

    > - is it accurate (enough for an introductory course)?


    It would be very difficult to tell without the actual text.

    > - are the examples OK?


    I didn't like any of the feature test examples. There didn't seem to
    be a statement of the basic feature testing principle that wherever
    possible you design a test that has the closest possible relationship
    with the thing that you need to know; preferably a one to one
    relationship. Rather than demonstrating this principle in action some
    of the tests were pushing object inference.

    > - is something important missing?
    >
    > Additional questions on attribution:
    >
    > - Did Cornford or Crockford invent the module pattern?


    Invent (which, in principle, many people may do independently), invent
    first, or publish first?

    Dougless Crockford has never claimed to have invented the "module
    pattern" (and has sufficed intellectual integrity that he never will).
    All attributions to him are indirect, third party, and not based on
    any actual knowledge.

    To the best of my knowledge, I published the first example of the
    archetypal "module pattern" (the specific example from the YUI blog
    article), having previously published numerous variations on the
    theme, most of which would generally be agreed to be examples of the
    'module pattern' in the wider sense (though many of them were things
    that others have since re-invented and given other names to as
    derivatives of the "module pattern").

    It is possible that one of the other people developing/expanding on
    previous examples of mine actually hit the archetypal "module pattern"
    first. Finding out would probably take working thorough the entire
    archive for the group between May and August 2003.

    > - Who created the initial "clone/object/beget/Object.create":
    > Cornford, Crockford or Reichstein Nielsen?


    If you mean a pattern where an object is assigned to the - prototype -
    property of an empty function and then that function is used to
    construct a new object as a 'clone' of the original object, then
    Reichstein Nielsen published the first example that I noticed.

    Richard.
    Richard Cornford, Jul 27, 2010
    #5
  6. Karl Tikjøb Krukow

    RobG Guest

    On Jul 27, 5:59 pm, Karl Tikjøb Krukow <> wrote:
    > I am preparing an introductory course on JavaScript for the place I work
    > at. As part of the course, I would like present some of the common
    > knowledge and generally accepted advice of this group, since it is not
    > commonly known and it should guide them in the right direction.
    >
    > (A small) part of this is on general purpose libraries. I've exported
    > the slides as a set of html documents which can be found here:
    >
    > <http://higher-order.net/courses/05-js-libraries.html>
    >
    > I would appreciate feedback from the group.


    Slide 12:

    The example code doesn't appear at the quoted link, it seems to have
    been replaced by a new function. Perhaps you should quote the version
    of the code or the date when it was quoted.

    <URL: http://github.com/dperini/nwmatcher...a3fb9d9d0fe93d9a9f5e3f1/src/nwmatcher.js#L278
    >


    --
    Rob
    RobG, Jul 27, 2010
    #6
  7. Richard Cornford wrote:
    [snip..]

    > Slide img2.html
    >
    > "The goal for JavaScript libraries is to present an API which
    >
    > - us uniform and more high-level, yet efficient.
    > - works around known bugs
    > - supports a wide range of user agents."
    >
    > The "supports a wide range of user agents" is demonstrably false in
    > almost all cases. Most javascript libraries aim to support a fixed set
    > of user agents, and quite a restricted set at that.


    Agreed, there is a difference between an ideal library and what most
    libraries do in practice.

    I will rephrase it as ".. support several popular user agents".


    > slide img3.html
    >
    > "Most libraries provide
    > * ... , Keyboard normalization ..."
    >
    > Mostly they don't. Keyboard normalisation (so between event models and
    > key event behaviour, Hardware variations, OSs (which must include non-
    > desktop OSs) and language related keyboard layout) is complex subject
    > that is rarely more than superficially addressed in library code.
    >


    Agreed - I'll remove that and explain this point in the "potential cons"
    slide.

    > Slide img5.html
    >
    > "Be vary of augmenting HTML Elements" probably contains a typo.


    That is now "host objects" taking Gregor's comment into account.

    > Slide img7.html
    >
    > "Least common denominator, e.g., event capture"
    >
    > Shouldn't that be event bubbling, as its capturing that IE doesn't do?


    That bullet is poorly phrased, event capture was meant as an example of
    a feature that is unsupported.

    > Slide img8.html
    >
    > "This is considered bad practice, a hack, by many.
    > - Unreliable
    > - Restricted accessibility
    > - Maintenance"
    >
    > I don't think that "accessibility" has much direct relevance to
    > browser sniffing. It can be restricted as much without it as with it.
    >


    Again, I've used an incorrect word. I mean accessibility to many user
    agents - not users. I will rephrase (though I haven't got a concise word
    now...)

    > As this related to UA string based browser sniffing why doesn't the
    > list of reasons for considering it "bad practice, a hack" (which is a
    > considerable understatement in many cases) include the observation
    > that it has no technical foundations (i.e. that there are no technical

    [snip..]

    Good point. I will move it to a separate slide to make room, and I will
    elaborate on this and the corresponding misconception.

    > Slide img10.html
    >
    > The - typeof el.childNodes // 'function' - example for Safari is
    > probably inappropriate in context as the childNodes collection can be
    > called in that environment and so is a function, making the behaviour
    > fully conforming with the ECMAScript behaviour for a native function.


    Ok, the IE example should suffice to prove the point.

    > Slide img15.html
    >
    > The "Potential cons" list:-
    >
    > - Does not mention that the libraries are rarely actually cross-
    > browser (but merely support a limited set of brewers, so are actually
    > little more than an elaboration of the "both browsers" scripts from
    > the end of the last century).


    Ok, I've added a bullet "Rarely supports more than a handfull of browsers"


    > - Does not mention that any 'community' is no more than the sum of the
    > people who participate in it, and that if the users of a library are


    [snip..]

    > - Does not mention that the quality of library documentation can be
    > very poor, especially when the authors of the documentation either do
    > not understand what their code actually does, (and/)or believe that
    > what it does is obvious.

    [snip..]

    I'll combine these two into the advice to consider the quality of
    documentation and community/commercial support options.

    >
    >> - is it accurate (enough for an introductory course)?

    >
    > It would be very difficult to tell without the actual text.


    Fair enough. A hope that, at least on the superficial level of
    "bullets", it is accurate enough.

    >> - are the examples OK?

    >
    > I didn't like any of the feature test examples. There didn't seem to
    > be a statement of the basic feature testing principle that wherever
    > possible you design a test that has the closest possible relationship
    > with the thing that you need to know; preferably a one to one
    > relationship. Rather than demonstrating this principle in action some
    > of the tests were pushing object inference.


    Ah, this is important to me. First, I will include a description of the
    principle - do you mind if I quote you on the above in the slides?

    Second, Example 1 (taken from Peter's blog) was included because it is
    fairly simple to understand. Do you have a reference to an example you
    would consider more appropriate as a simple example?

    Examples 2 and 3 are there to show that more advanced tests can be
    devised (event support and testing for bugs). Although the test on event
    support doesn't not directly test what I want to know (since simulating
    e.g. mouse movement, is hard as discussed by kangax on his blog), it is
    an example of not having to "give up" and do browser detection.

    Of course, even more illustrative examples are welcome :)

    >> - is something important missing?
    >>
    >> Additional questions on attribution:
    >>
    >> - Did Cornford or Crockford invent the module pattern?

    >
    > Invent (which, in principle, many people may do independently), invent
    > first, or publish first?


    I did mean publish first.

    >
    > Dougless Crockford has never claimed to have invented the "module
    > pattern" (and has sufficed intellectual integrity that he never will).
    > All attributions to him are indirect, third party, and not based on
    > any actual knowledge.
    >
    > To the best of my knowledge, I published the first example of the
    > archetypal "module pattern" (the specific example from the YUI blog
    > article), having previously published numerous variations on the
    > theme, most of which would generally be agreed to be examples of the
    > 'module pattern' in the wider sense (though many of them were things
    > that others have since re-invented and given other names to as
    > derivatives of the "module pattern").
    >
    > It is possible that one of the other people developing/expanding on
    > previous examples of mine actually hit the archetypal "module pattern"
    > first. Finding out would probably take working thorough the entire
    > archive for the group between May and August 2003.
    >
    >> - Who created the initial "clone/object/beget/Object.create":
    >> Cornford, Crockford or Reichstein Nielsen?

    >
    > If you mean a pattern where an object is assigned to the - prototype -
    > property of an empty function and then that function is used to
    > construct a new object as a 'clone' of the original object, then
    > Reichstein Nielsen published the first example that I noticed.
    >
    > Richard.


    Thanks for the clarifications.

    Kind Regards,
    Karl.
    Karl Tikjøb Krukow, Jul 27, 2010
    #7
  8. RobG wrote:
    > On Jul 27, 5:59 pm, Karl Tikjøb Krukow <> wrote:
    >> I am preparing an introductory course on JavaScript for the place I work
    >> at. As part of the course, I would like present some of the common
    >> knowledge and generally accepted advice of this group, since it is not
    >> commonly known and it should guide them in the right direction.
    >>
    >> (A small) part of this is on general purpose libraries. I've exported
    >> the slides as a set of html documents which can be found here:
    >>
    >> <http://higher-order.net/courses/05-js-libraries.html>
    >>
    >> I would appreciate feedback from the group.

    >
    > Slide 12:
    >
    > The example code doesn't appear at the quoted link, it seems to have
    > been replaced by a new function. Perhaps you should quote the version
    > of the code or the date when it was quoted.
    >
    > <URL: http://github.com/dperini/nwmatcher...a3fb9d9d0fe93d9a9f5e3f1/src/nwmatcher.js#L278
    >
    > --
    > Rob


    Yes, valid point. I modified the code - that should be pointed out.

    Thanks.
    Karl
    Karl Tikjøb Krukow, Jul 27, 2010
    #8
  9. Karl Tikjøb Krukow wrote:
    > Richard Cornford wrote:

    [snip]
    >> The "Potential cons" list:-
    >>
    >> - Does not mention that the libraries are rarely actually cross-
    >> browser (but merely support a limited set of brewers, so are actually
    >> little more than an elaboration of the "both browsers" scripts from
    >> the end of the last century).

    >
    > Ok, I've added a bullet "Rarely supports more than a handfull of browsers"

    [snip]

    Trade-off: if and what library to use
    Potential pros:
    - Responsibility of handling most cross-browser concerns are pushed to
    the library developers

    - Common utility functions and reusable components

    - One place to go for documentation, and a single community

    Potential cons:
    - You may not be happy with all the solutions that library developers
    have chosen, nor consistency of all APIs

    - Rarely supports more than a handfull of browsers

    - Varying quality of documentation and support

    - Browser detection requires continous maintainance/upgrades

    - Monolithic/non-modular libraries will inevitably contain many features
    that you won't use

    - Libraries will inevitably not contain all you need. Extensibility is
    useful.



    Advice on libraries

    * Consider your context
    - General web vs. intranet.
    - Accessibility requirements?
    - Constrained devices? Unknown devices?
    - App-in-a-page or hyper-text document? In between?

    * Be aware of the costs and benefits of using a particular library or not
    - Make an informed decision
    - Don't include a library “by default”
    - If you choose to use one, consider which one to use based on
    context: Don't decide by “what is hot” or “what I know”


    Karl.
    Karl Tikjøb Krukow, Jul 27, 2010
    #9
  10. Karl Tikjøb Krukow

    David Mark Guest

    On Jul 27, 2:46 pm, Karl Tikjøb Krukow <> wrote:
    > Karl Tikjøb Krukow wrote:
    > > Richard Cornford wrote:

    > [snip]
    > >> The "Potential cons" list:-

    >
    > >> - Does not mention that the libraries are rarely actually cross-
    > >> browser (but merely support a limited set of brewers, so are actually
    > >> little more than an elaboration of the "both browsers" scripts from
    > >> the end of the last century).

    >
    > > Ok, I've added a bullet "Rarely supports more than a handfull of browsers"

    >
    > [snip]
    >
    > Trade-off: if and what library to use
    > Potential pros:
    > - Responsibility of handling most cross-browser concerns are pushed to
    > the library developers


    That's virtually never a pro. Experienced developers know that
    complicated, monolithic do-everything-for-everybody scripts are
    inappropriate for a language that must be downloaded, runs in a single
    thread and must face many disparate environments. It's generally
    folly to try and the inexperienced are typically the ones who do.

    General-purpose JS libraries and frameworks are also the most
    challenging of browser scripting projects, so combined with mostly B
    Team contributors, the results are predictably disastrous.

    Furthermore, none of the "majors" is capable of supporting progressive
    enhancement in any meaningful way. The calling applications have no
    idea which methods will work and which will fall on their face. This
    precludes any possibility of graceful degradation in hostile or
    limited environments.

    AFAIK, there is but one (comprehensive) GP library that has come close
    to delivering a truly cross-browser (and largely maintenance-free)
    experience, while supporting progressive enhancement.

    http://www.cinsoft.net/

    That being said, I don't recommend telling your students to use it.
    They need to learn how to write browser scripts before they start
    trying to borrow code from others.

    >
    > - Common utility functions and reusable components
    >
    > - One place to go for documentation, and a single community


    That's not necessarily a pro either. There are lots of places to go
    to find information about JS and browser scripting in general (granted
    most of them are very bad). There is but one jQuery documentation
    site.

    As for community. As Richard noted, the "support" communities are
    mostly the blind leading the blind.

    Furthermore, it's not always true that there is a single point of
    contact. Many of these efforts get fragmented over the years (see
    Dojo and Ext JS), even so much as to break their Google search results
    by changing domain names (Ext JS and Dojo each did that *twice* at
    least).

    >
    > Potential cons:
    > - You may not be happy with all the solutions that library developers
    > have chosen, nor consistency of all APIs


    That's an understatement of a disclaimer.

    >
    > - Rarely supports more than a handfull of browsers


    ....in their default configurations. Remember that as the developers
    typically lack understanding (due to inexperience), they are often
    reduced to programming by feel (observing each browser and fiddling
    with the code until it appears to work). A familiar refrain when
    confronted with incorrect or dubious logic is "show me where it
    fails". Clearly that's not programming but pattern arrangement.

    >
    > - Varying quality of documentation and support


    Mostly (and predictably) bad.

    >
    > - Browser detection requires continous maintainance/upgrades


    And it may well fail *today* (in environments unknown to or unobserved
    by) the developers. Furthermore, the "upgrades" invariably break
    yesterday's browsers, leading them to be lopped off the "supported"
    list. Of course, end-users don't read such lists and cannot be
    expected to upgrade their browsers in perfect step with the library
    developers.

    >
    > - Monolithic/non-modular libraries will inevitably contain many features
    > that you won't use


    And must be "upgraded" in one go, requiring a reboot of regression
    testing. It's a nightmare in practice (again Dojo, Ext JS and the
    like are the most extreme examples).

    >
    > - Libraries will inevitably not contain all you need.


    No question there. JQuery has never featured anything that I need
    (and likely never will). In fact, it could be argued that a 70K CSS
    selector query engine that disagrees with its own QSA shim is a pig in
    a poke for anybody these days. There really are no valid arguments
    for it. All I ever hear are generalizations like "I use it as a
    tool".

    > Extensibility is
    > useful.


    Extensibility for JS libraries typically involves augmenting
    "namespace" objects. You can add properties to objects in any script,
    so any script can be considered extensible in this way. Granted, some
    take it a step further with additional syntactic sugar, but rarely to
    any real positive effect. If anything, it encourages "plug-in"
    authors who really shouldn't be writing JS in the first place (let
    alone extensions for widely used libraries).

    >
    > Advice on libraries
    >
    > * Consider your context
    >     - General web vs. intranet.
    >     - Accessibility requirements?
    >     - Constrained devices? Unknown devices?
    >     - App-in-a-page or hyper-text document? In between?
    >
    > * Be aware of the costs and benefits of using a particular library or not
    >     - Make an informed decision
    >     - Don't include a library “by default”
    >     - If you choose to use one, consider which one to use based on
    > context: Don't decide by “what is hot” or “what I know”
    >


    Those are good points, but you need more.
    David Mark, Jul 27, 2010
    #10
  11. Karl Tikjøb Krukow

    RobG Guest

    On Jul 28, 2:05 am, Karl Tikjøb Krukow <> wrote:
    > Richard Cornford wrote:

    [...]
    > > "This is considered bad practice, a hack, by many.
    > >    - Unreliable
    > >    - Restricted accessibility
    > >    - Maintenance"

    >
    > > I don't think that "accessibility" has much direct relevance to
    > > browser sniffing. It can be restricted as much without it as with it.

    >
    > Again, I've used an incorrect word. I mean accessibility to many user
    > agents - not users. I will rephrase (though I haven't got a concise word
    > now...)


    The use of the term "accessibility" to mean the quality of user
    interaction is a misnomer, it should never have come into popular use.
    What is meant is usability: that is, how well users can use a site.
    The phrase you are looking for is "restricted usability", with the
    implication that it is due to dysfunctional, inoperable or unavailable
    user interface features that prevent suitable access to the data.

    Consider a blind user whose screen reader is befuddled by text loaded
    by XHR that is positioned in an appropriate spatial location in a
    page, but does not sit in a logical place in the DOM. The screen
    reader may well read it out of sequence so it is heard in the wrong
    context. The user has accessed the data just fine, but they have
    difficulty comprehending it because of awkard or inappropriate
    presentation (i.e. the interface sucks).

    In another case, a user might access the correct URI but because theu
    are unable to cause an appropriate event to occur (say initiate a
    hover event when using a touch interface or a click if using a
    keyboard) in order to make information appear on the screen, then they
    have a usability issue. They may have accessed the data, or at least
    the correct URI, they just can't get it to display the information.

    If, on the other hand, they access the URI but their internet
    connection is too slow and the page times out, they have an
    accessibility issue - they can't *get* to the information (or it can't
    get to them).

    However, I think I'm pissing in the wind on this one. :-(

    [...]
    > > Slide img10.html

    >
    > > The - typeof el.childNodes // 'function' - example for Safari is
    > > probably inappropriate in context as the childNodes collection can be
    > > called in that environment and so is a function, making the behaviour
    > > fully conforming with the ECMAScript behaviour for a native function.

    >
    > Ok, the IE example should suffice to prove the point.


    The Safari example shows that host objects can be infuriatingly
    inconsistent even in browsers that claim to be more standards
    compliant than the others (it just depends on what standard you happen
    to be using for which behaviour).


    --
    Rob
    RobG, Jul 28, 2010
    #11
  12. On 28/07/10 05.23, RobG wrote:
    > On Jul 28, 2:05 am, Karl Tikjøb Krukow<> wrote:

    [snip]
    >> Ok, the IE example should suffice to prove the point.

    >
    > The Safari example shows that host objects can be infuriatingly
    > inconsistent even in browsers that claim to be more standards
    > compliant than the others (it just depends on what standard you happen
    > to be using for which behaviour).
    >
    >
    > --
    > Rob


    Agreed, there is value in known that it's not "just IE".

    I'll keep the document.all Safari example.

    Thanks,
    Karl.
    Karl Tikjøb Krukow, Jul 28, 2010
    #12
  13. On 28/07/10 00.01, David Mark wrote:
    > On Jul 27, 2:46 pm, Karl Tikjøb Krukow<> wrote:
    >> Karl Tikjøb Krukow wrote:
    >>> Richard Cornford wrote:

    >> [snip]
    >>>> The "Potential cons" list:-

    >>
    >>>> - Does not mention that the libraries are rarely actually cross-
    >>>> browser (but merely support a limited set of brewers, so are actually
    >>>> little more than an elaboration of the "both browsers" scripts from
    >>>> the end of the last century).

    >>
    >>> Ok, I've added a bullet "Rarely supports more than a handfull of browsers"

    >>
    >> [snip]
    >>
    >> Trade-off: if and what library to use
    >> Potential pros:
    >> - Responsibility of handling most cross-browser concerns are pushed to
    >> the library developers

    >
    > That's virtually never a pro. Experienced developers know that
    > complicated, monolithic do-everything-for-everybody scripts are
    > inappropriate for a language that must be downloaded, runs in a single
    > thread and must face many disparate environments. It's generally
    > folly to try and the inexperienced are typically the ones who do.
    >
    > General-purpose JS libraries and frameworks are also the most
    > challenging of browser scripting projects, so combined with mostly B
    > Team contributors, the results are predictably disastrous.
    >
    > Furthermore, none of the "majors" is capable of supporting progressive
    > enhancement in any meaningful way. The calling applications have no
    > idea which methods will work and which will fall on their face. This
    > precludes any possibility of graceful degradation in hostile or
    > limited environments.


    It was written as a "potential pro" :)

    In an ideal scenario, pushing this responsibility to an experienced
    cross-browser developer would be a pro. Obviously, when it is not
    handled appropriately, it becomes a con: "You may not be happy with all
    the solutions that library developers have chosen, nor consistency of
    all APIs".


    >
    > AFAIK, there is but one (comprehensive) GP library that has come close
    > to delivering a truly cross-browser (and largely maintenance-free)
    > experience, while supporting progressive enhancement.
    >
    > http://www.cinsoft.net/
    >
    > That being said, I don't recommend telling your students to use it.
    > They need to learn how to write browser scripts before they start
    > trying to borrow code from others.


    Yes, I mention "My Library" as a notable exception (a long with Fork and
    APE, but they don't look as comprehensive nor maintained).

    Hopefully, by the end of the course they will be able to comprehend why
    code such as "My Library" is written as it is. Hopefully they will
    understand the general principles and techniques, albeit they will not
    have extensive knowledge of various bugs and quirks of particular
    browsers. I won't recommend any particular library: hopefully they will
    be able to make an informed decision on their own.

    At least that is the goal.

    >>
    >> - Common utility functions and reusable components
    >>
    >> - One place to go for documentation, and a single community

    >
    > That's not necessarily a pro either. There are lots of places to go
    > to find information about JS and browser scripting in general (granted
    > most of them are very bad). There is but one jQuery documentation
    > site.
    >
    > As for community. As Richard noted, the "support" communities are
    > mostly the blind leading the blind.


    Again, a "potential" pro. At the course, I will discuss the warning that
    Richard and yourself are giving.

    > Furthermore, it's not always true that there is a single point of
    > contact. Many of these efforts get fragmented over the years (see
    > Dojo and Ext JS), even so much as to break their Google search results
    > by changing domain names (Ext JS and Dojo each did that *twice* at
    > least).
    >


    While I agree that it is not always true, usually it is a single (or a
    few) points of contact. I think I will keep this bullet.

    >>
    >> Potential cons:
    >> - You may not be happy with all the solutions that library developers
    >> have chosen, nor consistency of all APIs

    >
    > That's an understatement of a disclaimer.


    Yes, I am deliberately not using too strong statements in this
    presentation.

    [snip]

    >> - Browser detection requires continous maintainance/upgrades

    >
    > And it may well fail *today* (in environments unknown to or unobserved
    > by) the developers. Furthermore, the "upgrades" invariably break
    > yesterday's browsers, leading them to be lopped off the "supported"
    > list. Of course, end-users don't read such lists and cannot be
    > expected to upgrade their browsers in perfect step with the library
    > developers.


    I will include this point explicitly.

    >>
    >> - Monolithic/non-modular libraries will inevitably contain many features
    >> that you won't use

    >
    > And must be "upgraded" in one go, requiring a reboot of regression
    > testing. It's a nightmare in practice (again Dojo, Ext JS and the
    > like are the most extreme examples).


    Do you mean as opposed to a modular library where you would be able to
    upgrade a particular module, keeping other modules in an older version?

    That is a good point.

    >>
    >> - Libraries will inevitably not contain all you need.

    >
    > No question there. JQuery has never featured anything that I need
    > (and likely never will). In fact, it could be argued that a 70K CSS
    > selector query engine that disagrees with its own QSA shim is a pig in
    > a poke for anybody these days. There really are no valid arguments
    > for it. All I ever hear are generalizations like "I use it as a
    > tool".
    >
    >> Extensibility is
    >> useful.

    >
    > Extensibility for JS libraries typically involves augmenting
    > "namespace" objects. You can add properties to objects in any script,
    > so any script can be considered extensible in this way. Granted, some
    > take it a step further with additional syntactic sugar, but rarely to
    > any real positive effect. If anything, it encourages "plug-in"
    > authors who really shouldn't be writing JS in the first place (let
    > alone extensions for widely used libraries).
    >


    I guess extensibility and customization is only relevant for "widget"
    libraries.

    The notion of extensibility that you consider is a property of the
    language itself. It is often not sufficient to be practical: I think the
    widgets should be designed with the mindset that the user should be able
    to easily change certain properties, provided that they still satisfy
    the same contract of the widget API.

    But I guess it is really just a question of how well-designed it is: if
    well designed, extensibility and customization will probably follow.

    >> Advice on libraries
    >>
    >> * Consider your context
    >> - General web vs. intranet.
    >> - Accessibility requirements?
    >> - Constrained devices? Unknown devices?
    >> - App-in-a-page or hyper-text document? In between?
    >>
    >> * Be aware of the costs and benefits of using a particular library or not
    >> - Make an informed decision
    >> - Don't include a library “by default”
    >> - If you choose to use one, consider which one to use based on
    >> context: Don't decide by “what is hot” or “what I know”
    >>

    >
    > Those are good points, but you need more.


    Would you mind helping me with what additional points I need? (unless
    you mean the points discussed in the present post).

    Thanks for taking the time.
    Karl.
    Karl Tikjøb Krukow, Jul 28, 2010
    #13
  14. On 28/07/10 00.01, David Mark wrote:
    > On Jul 27, 2:46 pm, Karl Tikjøb Krukow<> wrote:
    >> Karl Tikjøb Krukow wrote:

    [snip]
    >> - Libraries will inevitably not contain all you need.

    >
    > No question there. JQuery has never featured anything that I need
    > (and likely never will). In fact, it could be argued that a 70K CSS
    > selector query engine that disagrees with its own QSA shim is a pig in
    > a poke for anybody these days. There really are no valid arguments
    > for it. All I ever hear are generalizations like "I use it as a
    > tool".
    >


    OT: Well, you need jQuery to add numbers

    http://www.doxdesk.com/img/updates/20091116-so-large.gif

    :)

    Karl.
    Karl Tikjøb Krukow, Jul 28, 2010
    #14
  15. Karl Tikjøb Krukow

    David Mark Guest

    On Jul 28, 1:10 am, Karl Tikjøb Krukow <> wrote:
    > On 28/07/10 00.01, David Mark wrote:
    >
    >
    >
    >
    >
    > > On Jul 27, 2:46 pm, Karl Tikjøb Krukow<>  wrote:
    > >> Karl Tikjøb Krukow wrote:
    > >>> Richard Cornford wrote:
    > >> [snip]
    > >>>> The "Potential cons" list:-

    >
    > >>>> - Does not mention that the libraries are rarely actually cross-
    > >>>> browser (but merely support a limited set of brewers, so are actually
    > >>>> little more than an elaboration of the "both browsers" scripts from
    > >>>> the end of the last century).

    >
    > >>> Ok, I've added a bullet "Rarely supports more than a handfull of browsers"

    >
    > >> [snip]

    >
    > >> Trade-off: if and what library to use
    > >> Potential pros:
    > >> - Responsibility of handling most cross-browser concerns are pushed to
    > >> the library developers

    >
    > > That's virtually never a pro.  Experienced developers know that
    > > complicated, monolithic do-everything-for-everybody scripts are
    > > inappropriate for a language that must be downloaded, runs in a single
    > > thread and must face many disparate environments.  It's generally
    > > folly to try and the inexperienced are typically the ones who do.

    >
    > > General-purpose JS libraries and frameworks are also the most
    > > challenging of browser scripting projects, so combined with mostly B
    > > Team contributors, the results are predictably disastrous.

    >
    > > Furthermore, none of the "majors" is capable of supporting progressive
    > > enhancement in any meaningful way.  The calling applications have no
    > > idea which methods will work and which will fall on their face.  This
    > > precludes any possibility of graceful degradation in hostile or
    > > limited environments.

    >
    > It was written as a "potential pro" :)


    Fair enough. :)

    >
    > In an ideal scenario, pushing this responsibility to an experienced
    > cross-browser developer would be a pro.


    Absolutely, but as Richard mentioned, the "majors" are not cross-
    browser in any sense of the term. I'd be careful with the term "pro"
    as well. Just because somebody somewhere may have paid for the
    services of a library author, doesn't make them proficient (only
    professional).

    > Obviously, when it is not
    > handled appropriately, it becomes a con:


    And, the sad story is that it has not been handled appropriately by
    the "pros" on the other end as they haven't really done what they set
    out to do.

    "You may not be happy with all
    > the solutions that library developers have chosen, nor consistency of
    > all APIs".


    True enough. Of course, they may not be experienced enough to make
    wise judgements in such matters. In other words, they may be happy as
    clams with something like jQuery and not realize that they are
    standing on the shoulders of midgets.

    >
    >
    >
    > > AFAIK, there is but one (comprehensive) GP library that has come close
    > > to delivering a truly cross-browser (and largely maintenance-free)
    > > experience, while supporting progressive enhancement.

    >
    > >http://www.cinsoft.net/

    >
    > > That being said, I don't recommend telling your students to use it.
    > > They need to learn how to write browser scripts before they start
    > > trying to borrow code from others.

    >
    > Yes, I mention "My Library" as a notable exception (a long with Fork and
    > APE, but they don't look as comprehensive nor maintained).


    Yes, I think Fork "died" years ago (though may well still work as it
    is a cross-browser script). APE has never amounted to much AFAIK.

    >
    > Hopefully, by the end of the course they will be able to comprehend why
    > code such as "My Library" is written as it is.


    That would be helpful.

    > Hopefully they will
    > understand the general principles and techniques, albeit they will not
    > have extensive knowledge of various bugs and quirks of particular
    > browsers.


    Here's the most important point: it doesn't require vast knowledge of
    browser quirks to be successful. After all, how could I have known
    what IE8 or IE9 would look like back in 2007? ;)

    It's about understanding the underlying abstractions, proper feature
    detection and testing patterns and solving problems. Memorization (or
    prognostication) rarely enter into it.

    Granted, when attempting to solve every problem related to browser
    scripting for everybody, there will be times when observation of
    quirks is required. But it is what you do with those observations is
    what determines how far you will go in this business.

    > I won't recommend any particular library: hopefully they will
    > be able to make an informed decision on their own.


    Be sure to mention the possibility of *not* using a GP library.
    That's also an important concept (and is not tantamount to "writing
    everything from scratch"). ;)

    >
    > At least that is the goal.


    Hey, I salute you for your efforts. The world needs more competent JS
    developers. It starts with the kids.

    >
    >
    >
    > >> - Common utility functions and reusable components

    >
    > >> - One place to go for documentation, and a single community

    >
    > > That's not necessarily a pro either.  There are lots of places to go
    > > to find information about JS and browser scripting in general (granted
    > > most of them are very bad).  There is but one jQuery documentation
    > > site.

    >
    > > As for community.  As Richard noted, the "support" communities are
    > > mostly the blind leading the blind.

    >
    > Again, a "potential" pro. At the course, I will discuss the warning that
    > Richard and yourself are giving.


    Good deal.

    >
    > > Furthermore, it's not always true that there is a single point of
    > > contact.  Many of these efforts get fragmented over the years (see
    > > Dojo and Ext JS), even so much as to break their Google search results
    > > by changing domain names (Ext JS and Dojo each did that *twice* at
    > > least).

    >
    > While I agree that it is not always true, usually it is a single (or a
    > few) points of contact. I think I will keep this bullet.


    Yes, but more importantly, who are they contacting? Programmers or
    pattern arrangers?

    >
    >
    >
    > >> Potential cons:
    > >> - You may not be happy with all the solutions that library developers
    > >> have chosen, nor consistency of all APIs

    >
    > > That's an understatement of a disclaimer.

    >
    > Yes, I am deliberately not using too strong statements in this
    > presentation.


    Fair enough.

    >
    > [snip]
    >
    > >> - Browser detection requires continous maintainance/upgrades

    >
    > > And it may well fail *today* (in environments unknown to or unobserved
    > > by) the developers.  Furthermore, the "upgrades" invariably break
    > > yesterday's browsers, leading them to be lopped off the "supported"
    > > list.  Of course, end-users don't read such lists and cannot be
    > > expected to upgrade their browsers in perfect step with the library
    > > developers.

    >
    > I will include this point explicitly.


    Glad to hear it. :)

    >
    >
    >
    > >> - Monolithic/non-modular libraries will inevitably contain many features
    > >> that you won't use

    >
    > > And must be "upgraded" in one go, requiring a reboot of regression
    > > testing.  It's a nightmare in practice (again Dojo, Ext JS and the
    > > like are the most extreme examples).

    >
    > Do you mean as opposed to a modular library where you would be able to
    > upgrade a particular module, keeping other modules in an older version?
    >
    > That is a good point.


    Yes. And it is important to realize that they all claim to be
    modular, but (particularly in the case of Dojo and Ext JS) it's
    usually all smoke due to interdependencies. For example, Dojo's XHR
    module requires its (highly dubious) query module. What does XHR have
    to do with CSS selector queries?

    >
    >
    >
    >
    >
    > >> - Libraries will inevitably not contain all you need.

    >
    > > No question there.  JQuery has never featured anything that I need
    > > (and likely never will).  In fact, it could be argued that a 70K CSS
    > > selector query engine that disagrees with its own QSA shim is a pig in
    > > a poke for anybody these days.  There really are no valid arguments
    > > for it.  All I ever hear are generalizations like "I use it as a
    > > tool".

    >
    > >> Extensibility is
    > >> useful.

    >
    > > Extensibility for JS libraries typically involves augmenting
    > > "namespace" objects.  You can add properties to objects in any script,
    > > so any script can be considered extensible in this way.  Granted, some
    > > take it a step further with additional syntactic sugar, but rarely to
    > > any real positive effect.  If anything, it encourages "plug-in"
    > > authors who really shouldn't be writing JS in the first place (let
    > > alone extensions for widely used libraries).

    >
    > I guess extensibility and customization is only relevant for "widget"
    > libraries.


    Yes, it's more relevant for those. And note that the "widget"
    frameworks are often castles built on top of swamps. In other words,
    they are the results of developers getting way ahead of themselves. I
    can't name one such framework that is not completely execrable. Dojo,
    YUI, Ext JS, Cappuccino, SproutCore, qooxdoo, etc. are all ill-advised
    and unsuccessful attempts to make every control look the same in every
    browser and chop off the browser's built-in layout mechanisms to be
    replaced slowly and painfully with single-threaded scripts that fail
    miserably (when compared with what they sought to replace) even in
    their "supported" browsers. See Richard's comments about qooxdoo's
    layout and widget scripts in a recent thread.

    >
    > The notion of extensibility that you consider is a property of the
    > language itself. It is often not sufficient to be practical: I think the
    > widgets should be designed with the mindset that the user should be able
    > to easily change certain properties, provided that they still satisfy
    > the same contract of the widget API.


    Certainly. Unfortunately, the majors all go way too far with this,
    often requiring a half-dozen levels of inheritance and tons of nested
    DIV's to create the simplest of controls. As a result, they are slow,
    bloated and inaccessible in numerous ways (when compared with what
    they sought to replace) And whenever HTML5 finally gets here (and is
    widely implemented), all of that crap will end up on history's scrap
    heap anyway.

    >
    > But I guess it is really just a question of how well-designed it is: if
    > well designed, extensibility and customization will probably follow.


    Well, even a poor design can allow for massive customization.

    >
    >
    >
    >
    >
    > >> Advice on libraries

    >
    > >> * Consider your context
    > >>      - General web vs. intranet.
    > >>      - Accessibility requirements?
    > >>      - Constrained devices? Unknown devices?
    > >>      - App-in-a-page or hyper-text document? In between?

    >
    > >> * Be aware of the costs and benefits of using a particular library or not
    > >>      - Make an informed decision
    > >>      - Don't include a library “by default”
    > >>      - If you choose to use one, consider which one to use basedon
    > >> context: Don't decide by “what is hot” or “what I know”

    >
    > > Those are good points, but you need more.

    >
    > Would you mind helping me with what additional points I need?


    I wouldn't mind at all. Perhaps tomorrow.

    (unless you mean the points discussed in the present post).

    I mean those, but certainly there are more.
    David Mark, Jul 28, 2010
    #15
  16. Karl Tikjøb Krukow

    David Mark Guest

    On Jul 28, 1:39 am, Karl Tikjøb Krukow <> wrote:
    > On 28/07/10 00.01, David Mark wrote:
    >
    > > On Jul 27, 2:46 pm, Karl Tikjøb Krukow<>  wrote:
    > >> Karl Tikjøb Krukow wrote:

    > [snip]
    > >> - Libraries will inevitably not contain all you need.

    >
    > > No question there.  JQuery has never featured anything that I need
    > > (and likely never will).  In fact, it could be argued that a 70K CSS
    > > selector query engine that disagrees with its own QSA shim is a pig in
    > > a poke for anybody these days.  There really are no valid arguments
    > > for it.  All I ever hear are generalizations like "I use it as a
    > > tool".

    >
    > OT: Well, you need jQuery to add numbers
    >
    > http://www.doxdesk.com/img/updates/20091116-so-large.gif
    >
    > :)
    >


    Good one, Karl. :)
    David Mark, Jul 28, 2010
    #16
  17. Karl Tikjøb Krukow

    Ry Nohryb Guest

    On Jul 27, 9:59 am, Karl Tikjøb Krukow <> wrote:
    >
    > Additional questions on attribution:
    >
    > - Did Cornford or Crockford invent the module pattern?


    I used to doubt it before, but when you dig into the c.l.js. archive
    starting @ the beginning of 2003 you see that he's been -certainly- a
    pioneer of that pattern. He posted quite often and a bunch of
    variations on the topic, and it's obvious that he had the feeling and
    excitement of whom is inventing/discovering something different, like
    a new and unknown piece of JS programming.
    --
    Jorge.
    Ry Nohryb, Jul 28, 2010
    #17
  18. On 28/07/10 07.59, David Mark wrote:
    > On Jul 28, 1:10 am, Karl Tikjøb Krukow<> wrote:
    >> On 28/07/10 00.01, David Mark wrote:
    >>> On Jul 27, 2:46 pm, Karl Tikjøb Krukow<> wrote:

    [snip]
    >> In an ideal scenario, pushing this responsibility to an experienced
    >> cross-browser developer would be a pro.

    >
    > Absolutely, but as Richard mentioned, the "majors" are not cross-
    > browser in any sense of the term. I'd be careful with the term "pro"
    > as well. Just because somebody somewhere may have paid for the
    > services of a library author, doesn't make them proficient (only
    > professional).


    Oh, I didn't mean "pro" as in professional, I meant as "a point in favor
    of" :)

    Anyway, I agree.

    >> Obviously, when it is not
    >> handled appropriately, it becomes a con:

    >
    > And, the sad story is that it has not been handled appropriately by
    > the "pros" on the other end as they haven't really done what they set
    > out to do.
    >
    > "You may not be happy with all
    >> the solutions that library developers have chosen, nor consistency of
    >> all APIs".

    >
    > True enough. Of course, they may not be experienced enough to make
    > wise judgements in such matters. In other words, they may be happy as
    > clams with something like jQuery and not realize that they are
    > standing on the shoulders of midgets.


    Yes, in this case, the problem is hard. Hopefully with the course they
    will get at least some degree of knowledge and experience.

    >>
    >>
    >>> AFAIK, there is but one (comprehensive) GP library that has come close
    >>> to delivering a truly cross-browser (and largely maintenance-free)
    >>> experience, while supporting progressive enhancement.

    >>
    >>> http://www.cinsoft.net/

    >>
    >>> That being said, I don't recommend telling your students to use it.
    >>> They need to learn how to write browser scripts before they start
    >>> trying to borrow code from others.

    >>
    >> Yes, I mention "My Library" as a notable exception (a long with Fork and
    >> APE, but they don't look as comprehensive nor maintained).

    >
    > Yes, I think Fork "died" years ago (though may well still work as it
    > is a cross-browser script). APE has never amounted to much AFAIK.


    At least http://forkjavascript.org/ still "works" :)


    >>
    >> Hopefully, by the end of the course they will be able to comprehend why
    >> code such as "My Library" is written as it is.

    >
    > That would be helpful.
    >
    >> Hopefully they will
    >> understand the general principles and techniques, albeit they will not
    >> have extensive knowledge of various bugs and quirks of particular
    >> browsers.

    >
    > Here's the most important point: it doesn't require vast knowledge of
    > browser quirks to be successful. After all, how could I have known
    > what IE8 or IE9 would look like back in 2007? ;)
    >
    > It's about understanding the underlying abstractions, proper feature
    > detection and testing patterns and solving problems. Memorization (or
    > prognostication) rarely enter into it.
    >
    > Granted, when attempting to solve every problem related to browser
    > scripting for everybody, there will be times when observation of
    > quirks is required. But it is what you do with those observations is
    > what determines how far you will go in this business.
    >
    >> I won't recommend any particular library: hopefully they will
    >> be able to make an informed decision on their own.

    >
    > Be sure to mention the possibility of *not* using a GP library.
    > That's also an important concept (and is not tantamount to "writing
    > everything from scratch"). ;)


    Yes, this is will be an important point. The problem is that getting a
    GP library is easy, dropping it in your page is easy; not doing that
    takes more work (either you do write part of it from scratch, or you
    find a number of good reusable modules suitable for your context).

    And, getting a number of reusable modules for the particular context
    isn't that easy - i.e. there is no good-reusable-js-modules.org.

    More often than not most people go for the "easy" solution. The problem
    being that it appears to work on all the browsers you have installed
    (yes, in their default configuration :).

    Another point is that of widgets: with a GP library there is always the
    chance that it comes with (almost) just that widget you want, or someone
    has written that widget as a "plugin". Again it appears to work just
    fine (in all the browsers you have installed, yes, in their default
    configuration) - you may not consider "accessibility" (or usability, Rob
    :), use of keyboard.

    In this case, the alternative often is writing it from scratch...
    Still looking for quality-js-widgets.org

    Anyway, I want to convey the message that using a GP library is not an
    automatic default: it comes with a cost. Sometimes that cost is too high.

    >
    >>
    >> At least that is the goal.

    >
    > Hey, I salute you for your efforts. The world needs more competent JS
    > developers. It starts with the kids.
    >


    Thanks :) At least this should not be "the blind leading the blind", as
    you say.

    I may not see all that well, but at least I can steer away from the abyss...

    [snip]
    >>> Furthermore, it's not always true that there is a single point of
    >>> contact. Many of these efforts get fragmented over the years (see
    >>> Dojo and Ext JS), even so much as to break their Google search results
    >>> by changing domain names (Ext JS and Dojo each did that *twice* at
    >>> least).

    >>
    >> While I agree that it is not always true, usually it is a single (or a
    >> few) points of contact. I think I will keep this bullet.

    >
    > Yes, but more importantly, who are they contacting? Programmers or
    > pattern arrangers?
    >


    Yes, that is important.
    [snip]

    >>>> - Monolithic/non-modular libraries will inevitably contain many features
    >>>> that you won't use

    >>
    >>> And must be "upgraded" in one go, requiring a reboot of regression
    >>> testing. It's a nightmare in practice (again Dojo, Ext JS and the
    >>> like are the most extreme examples).

    >>
    >> Do you mean as opposed to a modular library where you would be able to
    >> upgrade a particular module, keeping other modules in an older version?
    >>
    >> That is a good point.

    >
    > Yes. And it is important to realize that they all claim to be
    > modular, but (particularly in the case of Dojo and Ext JS) it's
    > usually all smoke due to interdependencies. For example, Dojo's XHR
    > module requires its (highly dubious) query module. What does XHR have
    > to do with CSS selector queries?


    Yes, part of the course is actually teaching the client the basics of
    Ext JS which is used to build "app-in-a-page" things on their intranet
    (where they use only IE7+ and FF3+ on windows).

    I tried to use the Ext JS "builder" to create a version of the library
    that only included the parts we were using: it included almost
    everything :( so much for modularity...
    [snip]
    >> I guess extensibility and customization is only relevant for "widget"
    >> libraries.

    >
    > Yes, it's more relevant for those. And note that the "widget"
    > frameworks are often castles built on top of swamps. In other words,
    > they are the results of developers getting way ahead of themselves. I
    > can't name one such framework that is not completely execrable. Dojo,
    > YUI, Ext JS, Cappuccino, SproutCore, qooxdoo, etc. are all ill-advised
    > and unsuccessful attempts to make every control look the same in every
    > browser and chop off the browser's built-in layout mechanisms to be
    > replaced slowly and painfully with single-threaded scripts that fail
    > miserably (when compared with what they sought to replace) even in
    > their "supported" browsers.


    But I still have hopes that it will be possible to build those castles
    on a better foundation, some day. The client wants castles in browsers.

    > See Richard's comments about qooxdoo's
    > layout and widget scripts in a recent thread.
    >


    I will.

    >>
    >> The notion of extensibility that you consider is a property of the
    >> language itself. It is often not sufficient to be practical: I think the
    >> widgets should be designed with the mindset that the user should be able
    >> to easily change certain properties, provided that they still satisfy
    >> the same contract of the widget API.

    >
    > Certainly. Unfortunately, the majors all go way too far with this,
    > often requiring a half-dozen levels of inheritance and tons of nested
    > DIV's to create the simplest of controls. As a result, they are slow,
    > bloated and inaccessible in numerous ways (when compared with what
    > they sought to replace) And whenever HTML5 finally gets here (and is
    > widely implemented), all of that crap will end up on history's scrap
    > heap anyway.
    >


    You are speaking about Ext JS again, aren't you? :)

    Yes, HTML5 would remove the need for many, but probably not all, of
    those "widgets". And I guess canvas would help too.

    >>
    >> But I guess it is really just a question of how well-designed it is: if
    >> well designed, extensibility and customization will probably follow.

    >
    > Well, even a poor design can allow for massive customization.


    Yes, I meant the other implication: a good design would imply at least
    some degree of customization.

    >>
    >>
    >>
    >>
    >>
    >>>> Advice on libraries

    >>
    >>>> * Consider your context
    >>>> - General web vs. intranet.
    >>>> - Accessibility requirements?
    >>>> - Constrained devices? Unknown devices?
    >>>> - App-in-a-page or hyper-text document? In between?

    >>
    >>>> * Be aware of the costs and benefits of using a particular library or not
    >>>> - Make an informed decision
    >>>> - Don't include a library “by default”
    >>>> - If you choose to use one, consider which one to use based on
    >>>> context: Don't decide by “what is hot” or “what I know”

    >>
    >>> Those are good points, but you need more.

    >>
    >> Would you mind helping me with what additional points I need?

    >
    > I wouldn't mind at all. Perhaps tomorrow.


    Thanks. Looking forward to it.

    Karl.
    Karl Tikjøb Krukow, Jul 29, 2010
    #18
  19. On 27/07/10 09.59, Karl Tikjøb Krukow wrote:
    > I am preparing an introductory course on JavaScript for the place I work
    > at. As part of the course, I would like present some of the common
    > knowledge and generally accepted advice of this group, since it is not
    > commonly known and it should guide them in the right direction.
    >
    > (A small) part of this is on general purpose libraries. I've exported
    > the slides as a set of html documents which can be found here:
    >
    > <http://higher-order.net/courses/05-js-libraries.html>
    >
    > I would appreciate feedback from the group. Remember that this is an
    > introductory course to it should be kept to basics and generally
    > accepted statements.
    >


    I've had so much interesting feedback that I've chosen to publish also
    the slides on the "basic language constructs" hoping for interest and
    advice.

    <http://higher-order.net/courses/02/02_basic_language_constructs.html>


    Karl.
    Karl Tikjøb Krukow, Jul 29, 2010
    #19
  20. On 29/07/10 07.04, Karl Tikjøb Krukow wrote:
    [snip]

    > I've had so much interesting feedback that I've chosen to publish
    > also the slides on the "basic language constructs" hoping for
    > interest and advice.


    OT: do you see my lines wrapping at 72 chars? I've just upgraded to the
    newest thunderbird (from the 2.x branch to 3.x) and it seems to have
    dropped support for wrapping lines :(

    Karl.
    Karl Tikjøb Krukow, Jul 29, 2010
    #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. Dr John Stockton

    CLJ newsgroup FAQ

    Dr John Stockton, Jul 18, 2006, in forum: Javascript
    Replies:
    19
    Views:
    121
    Bart Van der Donck
    Jul 25, 2006
  2. Bart Van der Donck

    Code clj FAQ automation

    Bart Van der Donck, Jul 31, 2006, in forum: Javascript
    Replies:
    2
    Views:
    129
    Bart Van der Donck
    Aug 1, 2006
  3. FAQ server

    FAQ - What questions are off-topic for clj?

    FAQ server, Jul 31, 2006, in forum: Javascript
    Replies:
    3
    Views:
    138
    Bart Van der Donck
    Aug 1, 2006
  4. FAQ server
    Replies:
    2
    Views:
    77
    Bart Van der Donck
    Aug 3, 2006
  5. FAQ server
    Replies:
    2
    Views:
    71
    Dr John Stockton
    Sep 30, 2006
Loading...

Share This Page