D
David Mark
You could have saved me considerable time by not replying in the first
place. The world didn't need a rehash of the original re-tread. We
had this same discussion three months ago.
You could have saved me considerable time by not replying in the first
place. The world didn't need a rehash of the original re-tread. We
had this same discussion three months ago.
T
timothytoe
I'm honestly trying to learn from the discussion. I've read it twice
through entirely to make sure I was understanding all the points
everyone was making. I just think that people are more convincing when
the attacks are not personal. I'm seeing otherwise bright people
undermine their credibility repeatedly.
Don't think that there are not people learning as a result of this
discussion. I, for one, am very interested, as I'm close to hiring a
couple JavaScript programmers and I have to figure out the lay of the
land. Years ago I was on the employee side of the equation. Now I'm on
the boss side and I want to make sure I don't get blindsided. I am
using jQuery for a mock-up, and I have to figure out where to go from
there when I hire. I'm glad I chose it, because using it lets me
proceed fast enough to get up and running. Having a demo come up do
speed quickly makes a big difference in getting projects moving ($$$).
I want to know best-practices all the way down to JavaScript, so I'm
still here. If I didn't care, I wouldn't be here--there are a lot of
places easier to take.
I'm curious, David, who do you see as the JavaScript "experts" (if
any) who do not participate in this group? It seems as if almost all
the JavaScript books are crap (I have many of them). Do you like PPK's
book? Crockford has a book coming out next month, I believe. Is he
considered an exert? Or has YUI soiled his reputation on clj? I know
there's a FAQ entry concerning books, but I wonder if anyone here has
been impressed by a book I may have not read, or reads with interest
(rather than scorn) any JavaScript blogs that I may be missing.
So forgive me if I seemed to be trolling. I'm just trying to figure
things out.
D
Dag Sunde
Richard Cornford said:
Then it is unfortunate indeed!
Modern society and its power-structures are buildt on the delusion that a
statement *is* worth more, more true or more significant depending on who
made it.
E
Evertjan.
Dag Sunde wrote on 19 feb 2008 in comp.lang.javascript:
But a statement is worth more to ME
if made by someone whose judgement I value,
but that does not go sofar
as to trust the statement in a scientific sense.
Doubt is the basis of science.
Therefore "proving" an argument by just quoting someone,
even if it is an "authority", should be distrusted.
Technology should be based on science.
Programming is a technology.
Playing/working with javascript is a form of programming.
So distrusting proof by authority is a healthy habit also in javascript.
I do not hold this building for true, as per the above reasons, Dag.
But a statement is worth more to ME
if made by someone whose judgement I value,
but that does not go sofar
as to trust the statement in a scientific sense.
Doubt is the basis of science.
Therefore "proving" an argument by just quoting someone,
even if it is an "authority", should be distrusted.
Technology should be based on science.
Programming is a technology.
Playing/working with javascript is a form of programming.
So distrusting proof by authority is a healthy habit also in javascript.
I do not hold this building for true, as per the above reasons, Dag.
R
Richard Cornford
That is odd, when it comes to the personal and childish Matt's "Perhaps your
favorite midget porn sites are just poorly coded?" struck me as streets
ahead of anything else that has appeared in this thread.
So you don't thing the creators of bad work have any personal responsibility
for their actions?
I have doubted that.
The lay of the land is that if you advertise for javascript programmers a
significant proportion of the applicants will have a near negligible
understanding of javascript or browser scripting. And that proportion may
get as significant as 100%. But worse than that is the fact that many of
those candidates will consider themselves experts in the subject. We do,
after all, live in a world where people who don't even have a good handle on
HTML are putting themselves up as experts on browser scripting, and writing
books to teach others what they 'know'.
I don't hold out much hope for you. You posts so far are showing a strong
tendency to presuppose the truth of many things that should be themselves be
questioned. If you start of wanting to believe that one particular picture
is the truth you will be vulnerable to those willing to reinforce that
picture.
Try to avoid making the mistake of attempting to develop a mock-up into
production code. The internal design criteria for a mock-up are create
something that demonstrates viability very quickly. Those are a very long
way form the criteria for the internal design of production code, where
reliability, maintainability and expandability are much more important. If
you (or someone with the experience in the field to have already made the
mistakes they needed to learn from) stop and do a ground up redesign before
moving on from the mock-up you will avoid the consequences of the mock-up
design criteria becoming entrained in production code and acting as an
albatross about your neck for years to come.
Getting a project moving is one thing, maximising the returns from on
ongoing project is another.
So your are here for your own benefit? You realise that is precisely why
everyone else is here too. That is why you won't see much sympathy for your
suggestions that people may be driven away by their perception of attitudes
here; that is their loss not ours.
So your are here for your own benefit? You realise that is precisely why
everyone else is here too.
That is quite a difficult question because if you don't get to openly
exchange ideas with people it is difficult to distinguish between what they
really know and what they would like to give the impression of knowing.
And the very worst are actively harmful.
I am afraid you cannot include Douglas Crockford in your list as he does
participate in this group, and has been doing so for a very long time.
Absolutely! Douglas knows javascript front to back and inside out, there is
no question of that. He has never seemed that interested in cross-browser
application of javascript, but each to their own.
YUI gets relatively little criticism here. (It has the considerable
advantage that at least one person involved really does understand
javascript, which means that you just don't see the manifestations of
fundamental misconceptions in its source code.) Indeed there is a touch of
brilliance in the ides of creating a client-side application framework for
your search engine and then getting thousands of other people to do your QA
and bug tracing for you. That must have saved a fortune.
That question always suffers a bit from the fact that the people in the best
position to judge javascript books (the ones who understand the subject) are
the least likely to see a need to buy and read them. I look at javascript
books when they come my way because it has been decided that the FAQ should
have an entry on books, and so it seems a good idea to have an informed(ish)
attitude towards what should be in it. "Impressed" has not yet been an
outcome of looking at a javascript book.
The book I go back to regularly (if it can be called a book) is ECMA 262 3rd
Ed, but that it because it can tell me the things that I know I have not
(and will not) memorised.
That is how it seems.
Then question more (yourself included).
Richard.
favorite midget porn sites are just poorly coded?" struck me as streets
ahead of anything else that has appeared in this thread.
So you don't thing the creators of bad work have any personal responsibility
for their actions?
I have doubted that.
The lay of the land is that if you advertise for javascript programmers a
significant proportion of the applicants will have a near negligible
understanding of javascript or browser scripting. And that proportion may
get as significant as 100%. But worse than that is the fact that many of
those candidates will consider themselves experts in the subject. We do,
after all, live in a world where people who don't even have a good handle on
HTML are putting themselves up as experts on browser scripting, and writing
books to teach others what they 'know'.
I don't hold out much hope for you. You posts so far are showing a strong
tendency to presuppose the truth of many things that should be themselves be
questioned. If you start of wanting to believe that one particular picture
is the truth you will be vulnerable to those willing to reinforce that
picture.
Try to avoid making the mistake of attempting to develop a mock-up into
production code. The internal design criteria for a mock-up are create
something that demonstrates viability very quickly. Those are a very long
way form the criteria for the internal design of production code, where
reliability, maintainability and expandability are much more important. If
you (or someone with the experience in the field to have already made the
mistakes they needed to learn from) stop and do a ground up redesign before
moving on from the mock-up you will avoid the consequences of the mock-up
design criteria becoming entrained in production code and acting as an
albatross about your neck for years to come.
Getting a project moving is one thing, maximising the returns from on
ongoing project is another.
So your are here for your own benefit? You realise that is precisely why
everyone else is here too. That is why you won't see much sympathy for your
suggestions that people may be driven away by their perception of attitudes
here; that is their loss not ours.
So your are here for your own benefit? You realise that is precisely why
everyone else is here too.
That is quite a difficult question because if you don't get to openly
exchange ideas with people it is difficult to distinguish between what they
really know and what they would like to give the impression of knowing.
And the very worst are actively harmful.
I am afraid you cannot include Douglas Crockford in your list as he does
participate in this group, and has been doing so for a very long time.
Absolutely! Douglas knows javascript front to back and inside out, there is
no question of that. He has never seemed that interested in cross-browser
application of javascript, but each to their own.
YUI gets relatively little criticism here. (It has the considerable
advantage that at least one person involved really does understand
javascript, which means that you just don't see the manifestations of
fundamental misconceptions in its source code.) Indeed there is a touch of
brilliance in the ides of creating a client-side application framework for
your search engine and then getting thousands of other people to do your QA
and bug tracing for you. That must have saved a fortune.
That question always suffers a bit from the fact that the people in the best
position to judge javascript books (the ones who understand the subject) are
the least likely to see a need to buy and read them. I look at javascript
books when they come my way because it has been decided that the FAQ should
have an entry on books, and so it seems a good idea to have an informed(ish)
attitude towards what should be in it. "Impressed" has not yet been an
outcome of looking at a javascript book.
The book I go back to regularly (if it can be called a book) is ECMA 262 3rd
Ed, but that it because it can tell me the things that I know I have not
(and will not) memorised.
That is how it seems.
Then question more (yourself included).
Richard.
R
Richard Cornford
Matt said:
A book purporting to teach a technical subject makes objectively false
statements about its subject and you think improper wording is the "real
problem"? You realise that book goes on to say:-
"Listing 3-12. Examples of How != and == Differ from !== and ===
// Both of these are true
null == false
0 == undefined" - John Resig: Pro JavaScript Techniques. 2006
So how do you re-word that in a way that accounts for the fact that both of
the above expressions evaluate to boolean false?
I didn't expect you would want to answer those questions.
It is not mis-worded, it is misconceived, and it is an expression of a
misconception that could have been avoided by an action as simple as
executing the code.
You always seem to listing the things you don't care about to me.
Maybe no problems yet, but these things tend to grow, and get slower as the
grow.
<snip>
Just one browser? So that would be Windows IE then.
Richard.
D
David Mark
Good strategy.
I think you will find that, depending on the part of the country, good
JavaScript help is hard to find. Finding two good JS programmers in
one city may take a miracle. Best of luck on that.
I suppose. Just don't use jQuery in your release version.
It is good that you have the fortitude to linger here. I don't know
where else you could find comparable information.
The JavaScript books *are* crap. That being said, I am not familiar
with PPK's. PPK is a certainly an expert with browser-based host
environments. I don't know anything about his level of JavaScript
expertise.
Crockford is one of the leading experts on JavaScript. Other than
Richard Cornford, I am not familiar with any bigger authorities on the
language.
And no, YUI has not soiled his reputation as an expert on the
language. YUI's primary issues, as with Prototype, jQuery, etc., are
related to its interaction with browsers (and its size of course.)
AFAIK, YUI's JavaScript code is sound (unlike Prototype.) I wonder if
it passes JSLint though. Regardless, I severely doubt that Crockford
himself wrote a significant percentage of the YUI code. Last I heard,
his title at Yahoo! was something like "JavaScript Architect", not
"YUI developer."
Really? I don't remember seeing them in there. Personally, I don't
read JavaScript books as the excerpts shared here are typically enough
to turn me away from them. But I would consider reading anything
Crockford writes on the subject.
Certainly read the various articles on Crockford's site and Richard's
as well. They aren't blogs per se, which I think is a good thing. I
don't know of any worthwhile JavaScript blogs.
And read the FAQ and accompanying notes of course!
It is a public forum, so you are free to post whatever you like. Just
be careful about making broad statements about the etiquette (or lack
thereof) of group regulars as these are the people who will (or won't)
give you the help you need.
R
Richard Cornford
David Mark wrote:
Martin Honnen? For experience and technical knowledge Martin is pretty had
to beat.
As worded that has the implication that I may be bigger authority on
javascript than Douglas Crockford. I am not very comfortable with that idea.
Partly because I am not very comfortable with the idea of authority at all;
nobody's ideas are worth any more, or any less, than the reasoning behind
them. But mostly because Douglas Crockford was genuinely an expert when I
was a complete novice and making all the amateurish mistakes that are
expected of novices.
I learnt a huge amount from Douglas Crockford as a result of our exchanges
on this group, and even more as a direct result of reading his articles and
code. It is the case, for example, that I maybe would never have pursued
closures were it not for Douglas Crockford's method for creating private
members of javascript object instances (because that more OO employment of
closures had more concrete appeal at the time for a former Java programmer
than Yann-Erwan Perio's fascinating functional programming examples).
It is difficult to understate the significance of JSON. Javascript's object
notation sat under our noses for years but it took a genius to notice that a
subset of it could be directly interchangeable with XML but more efficient,
and that genius was Douglas Crockford. JSON is here to stay, and if
inventing it were his only legacy that alone would be a significant
accolade. But if you look at every significant change in the way javascript
is coded that has happened over the last half decade or so a line of
influences traced back might branch and spider along the way but sooner or
later it would link to Douglas Crockford.
Richard.
<snip>
Martin Honnen? For experience and technical knowledge Martin is pretty had
to beat.
As worded that has the implication that I may be bigger authority on
javascript than Douglas Crockford. I am not very comfortable with that idea.
Partly because I am not very comfortable with the idea of authority at all;
nobody's ideas are worth any more, or any less, than the reasoning behind
them. But mostly because Douglas Crockford was genuinely an expert when I
was a complete novice and making all the amateurish mistakes that are
expected of novices.
I learnt a huge amount from Douglas Crockford as a result of our exchanges
on this group, and even more as a direct result of reading his articles and
code. It is the case, for example, that I maybe would never have pursued
closures were it not for Douglas Crockford's method for creating private
members of javascript object instances (because that more OO employment of
closures had more concrete appeal at the time for a former Java programmer
than Yann-Erwan Perio's fascinating functional programming examples).
It is difficult to understate the significance of JSON. Javascript's object
notation sat under our noses for years but it took a genius to notice that a
subset of it could be directly interchangeable with XML but more efficient,
and that genius was Douglas Crockford. JSON is here to stay, and if
inventing it were his only legacy that alone would be a significant
accolade. But if you look at every significant change in the way javascript
is coded that has happened over the last half decade or so a line of
influences traced back might branch and spider along the way but sooner or
later it would link to Douglas Crockford.
Richard.
D
David Mark
Yes, he always seems to know what he is talking about. And how could
I have left out Jim Ley? Then again, perhaps he is more known for
cross-browser scripting expertise (like PPK.) He got me off browser
sniffing many years back (yes, I once thought the user agent string
was source of relevant information.) What ever happened to him?
I didn't really mean to imply that. But isn't his famed "module
pattern" something you came up with first?
I had barely heard of them a year or so back. It was your article on
the subject that changed the way I write script. The various demos on
your site are what led me to use one-off feature detection/testing. I
don't know how I got by for so many years without that pattern. It
goes to show that it doesn't take a lifetime to learn advanced browser
scripting techniques if you choose the examples you follow carefully.
On the other hand, there are so many poor sources of information on
JavaScript out there that it is very easy to get lost forever.
I imagine so. I use one of his programs (JSLint) to "supervise" my
own code. It is quite humbling when somebody else's *code* knows more
about JavaScript than you do! Lately it only catches typos, but there
was a time when it would inform me of all sorts of issues that I was
otherwise unaware of. If I ran some of my 90's code through it, it
would probably tell me to find a new career.
M
Matt Kruse
I did not realize...
That is quite bad. I'm not sure how such an error could be made by
someone with much javascript experience. Nor how it could be missed by
technical editors or people reading advance copies. It certainly
should make someone question other technical answers supplied in the
book.
It's just not relevant to me. jQuery does what I need in the
environments I need it in. I like the simplicity of the API. I've
considered writing my own library with the same API as a plug-in
replacement. I choose to use jQuery in some places not because I think
it is brilliant code or because it is so technically solid, but
because it makes development easier, faster, and cheaper, has never
broken in the situations where I use it, and it enables me to put a
team of developers to work writing javascript that actually works
rather than throwing errors every time a page is loaded. In short,
it's better than my other alternatives, at least for now. It works for
me. Regardless of what ridiculous technical errors John Resig may make
in his books.
I suppose that if such misconceptions were used in jQuery and caused
errors in the code that affected how I use it, I would have dismissed
the library already. I haven't seen that happen (yet).
True, to some extent. I've run into problems a number of times where
the jquery approach of finding elements and attaching event listeners
on page load is extremely inefficient and slow. Simple solution is to
delegate the event to a common container and a single event listener.
I've had a few problems with plugins that performed poorly. I simply
re-wrote them or replaced them with core js code.
Most of the time, yes.
Matt Kruse
M
Matt Kruse
I apologize for that remark. I thought it was so outrageous that
everyone would know it was a joke.
If you knew me in the "real world" you would probably have more
appreciation for my sense of humor
Matt Kruse
A
Arnaud Diederen
David Mark said:
In my early JavaScript coding days, I found out about Matt Kruse's
Knowledge Database
<URL: http://www.javascripttoolbox.com/search/>, which is
basically just a re-dispatch of queries to google "web" and google
groups.
I spotted the "trusted" names on the query in the lower frame
(type, for example -niark niark- "Prototype.js" in the input field, to
perform a query) and raised their score in my Gnus client.
The posts of those people turned out to be, at least, most reliable!
Best,
A.
M
Matt Kruse
Yeah, I did the same test, having forgotten that the page even
existed.
I'll take a look at it and try to fix it at some point.
Matt
T
Tony
I would be very interested in speaking with you outside this group. As
your profile says emailing you may not work, would you please email
me?
R
Richard Cornford
It is quite a common misconception, and one I held myself for a month or so
in 2002. But then I had learnt enough to know that I was nowhere near
qualified to be writing books on the subject at the time.
In context that is quite bad.
Which has been one of the points being made from the outset.
I gather that the technical editor writes javascript for Google, so enough
said.
And the non-technical advice, if the evident factual errors are symptomatic
of inexperience. There are statements like:-
"Compression should be used as the final step, just before putting your code
into production, as your code will frequently become obfuscated beyond
recognition." - John Resig: Pro JavaScript Techniques. 2006
I would be sacked on the spot if I did anything so completely reckless, and
deserve it.
<snip>
But it is relevant to the larger question. If the position taken is that
JQuery has fundamental design flaws that would be expected to be the
consequence of inexperience on its author's part then that is going to be a
subjective judgment. But if you can demonstrate the author making the sorts
of technical errors that can be except to follow from inexperience after
JQuery was designed then it becomes difficult to see how the author could
apply greater experience at an earlier date.
You are describing a situation where jquery's performance is constraining
what is possible in the rest of the system. I would say that was a
performance issue, just not an insurmountable one in your case.
You work on a single browser Intranet but the browser is only IE most of the
time? That explains why don't have performance issues - the Intranet is
running on quantum computers so the web browser has become subject to the
Hinesburg uncertainty principle; it only becomes IE when someone is
observing it to be IE.
Richard.
R
Richard Cornford
I apologize for that remark. I thought it was so outrageous that
everyone would know it was a joke.
If you knew me in the "real world" you would probably have more
appreciation for my sense of humor
Ah yes, the "real world". It sounds quite the utopia. I must try and get the
time off work for a visit at some point ;-)
Richard.
R
Richard Cornford
Yes, these days if Martin gets a single technical correction here he is
having a bad year.
That is what I thought just after I switched of the computer to go to bed.
Yes, in the long rung Jim Ley's influence on browser scripting practices may
be as great as Douglas Crockford's influence of javascript code authoring.
But that will be after User Agent string browser sniffing had disappeared
for good, and unfortunately recent trends have been in the wrong direction.
Likewise, though I don't think I ever thought of the user agent string as
"relevant information". More like I had seen it used in/on books/websites,
had never seen any alternative and hadn't really thought about it at all
beyond that.
Jim is apparently working for an outfit called Joost who do video/television
distribution over the Internet.
Yes, which puts me in a very good position to make informed statements about
the chains of influences the lead up to in.
<snip>
In the four years since that article was written closures have become
mainstream in javascript. To the point were it would be difficult to take a
javascript "expert" seriously if they did not have at least a practical
understanding of closures. And you would be hard pressed to find any sizable
body of recently written javascript code that does not use closures. So if
my article is instrumental in spreading an understanding of javascript's
closures that eventually alters the way serious javascript is written then
the influences behind the article also become the influences behind the
changes.
Richard.
P
Peter Michaux
I don't know what I've read that was written by Jim himself. Are there
any particular articles?
Are you sure they are heading in the wrong direction? I don't think
that is really the case. The libraries do slowly remove sniffs when
learn about a better way. I think that many programmers want to do the
right thing but don't know how to do it.
I've gathered information about feature detection and cross-browser
scripts from members of this group over the past couple years. The
knowledge here is the best available on the Internet but I think it is
true that the responses to questions can sometimes be too blunt and/or
rude. I survived this abuse and appreciate being given straight
answers. But imagine a person who is interested in learning something
new but is slightly insecure about being seen making mistakes. I think
just one response on c.l.js may send them running. This is a shame
because they loose out, others loose out by hearing c.l.js is a bunch
of trolls and the browser scripting profession doesn't benefit from
the group. To a certain degree the group's behavior impedes one
apparent goal of improving the over all standard of browser scripting.
It doesn't mean people with bad code need to be congratulated but they
don't need to read responses about how stupid they are etc.
I'm attempting to leak some of the information I've gathered from the
group about browser scripting to the "outside world". I've posted a
couple articles on my blog and hope they have a decent number of
visitors. More articles will help spread the word. Not everyone is
going to come here for the information.
Peter
M
Matt Kruse
To be fair, though, I'm not sure it's jQuery's fault as much as the
fault of the "unobtrusive" strategy of applying scripted behavior to
an unscripted page once the DOM is loaded. In most cases this has
worked well for me, but in some cases it's just not practical. Since I
work primarily on internal web apps, I've also often resorted to using
inline event handlers, etc. Depending on the situation, different
solutions speed up IE's rendering speed considerably.
The problem with event delegation to a common container is that
objects can cancel the bubble. If you aren't in control of all parts
of the page, you never know what might prevent the event from reaching
your container. If IE would support event capturing my life would be
easier...
I don't work on an Intranet. I typically work on web applications
(whether internet or intranet, but behind a login) used by small
groups having a single standard web browser. Most of the time this is
IE. It has also been FF at times.
Schroedinger's Browser, perhaps? You can test all browsers
simultaneously until you turn on your monitor and observe it
Matt Kruse
P
Peter Michaux
That is certainly a problem. Cancel bubble is not necessary and
shouldn't be used for exactly this reason. Even if you are in control
of the entire page you may want to add an unrelated delegate listener
to do something like log "hot spots" where a user interacts with the
page. If you've relied on cancel bubble in this case then parts of
JavaScript will need to be rewritten.
Wouldn't it just.
Peter