Prev: FAQ Topic - How can I create a Date object from a String? (2010-07-27)
Next: Javascript exception control
From: RobG on 27 Jul 2010 10:00
On Jul 27, 5:59 pm, Karl Tikjøb Krukow <karl.kru...(a)gmail.com> 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/blob/4703619c7ac77be6ea3fb9d9d0fe93d9a9f5e3f1/src/nwmatcher.js#L278
>

--
Rob
From: Karl Tikjøb Krukow on 27 Jul 2010 12:05
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.
From: Karl Tikjøb Krukow on 27 Jul 2010 12:06
RobG wrote:
> On Jul 27, 5:59 pm, Karl Tikj�b Krukow <karl.kru...(a)gmail.com> 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/blob/4703619c7ac77be6ea3fb9d9d0fe93d9a9f5e3f1/src/nwmatcher.js#L278
>
> --
> Rob

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

Thanks.
Karl
From: Karl Tikjøb Krukow on 27 Jul 2010 14:46
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.
From: David Mark on 27 Jul 2010 18:01
On Jul 27, 2:46 pm, Karl Tikjøb Krukow <karl.kru...(a)gmail.com> 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.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: FAQ Topic - How can I create a Date object from a String? (2010-07-27)
Next: Javascript exception control