Re: JS strangeness
Hamish Campbell wrote:
The JQuery group responded to the OP's question by pointing out that the
information provided was insufficient for an answer to be given
(particularly asking to see the code). Pretty much the same reaction to
the question as received here (and unsurprising as there is a minimum of
information required in any meaningful analysis).
In the end it turned out that my suspicion that the information provided
was inaccurate at least in part, due to the contradiction between the
description of the code and the symptoms, was well founded. The issue
was caused by arbitrary character sequences being written into the
javascript source code for a string literal without appropriate
escaping. A common novice mistake that easily goes unnoticed up until
the point where someone/something introduces a character that is
forbidden or problematic in a string literal, like apostrophes
(problematic) or line terminators (forbidden).
That meant that the "run it locally under Firefox, everything works
fine" was pure misdirection, as given the same data it would have failed
as reliably locally as it failed "on the host site".
Willingness does not necessitate ability. What I don't see on the JQuery
group is any depth of expiation, or any push to enable other posters to
become better javascript programmers. It appears that everything is
geared towards getting things 'working' in some sense, with no
consideration of how stupidly coded that 'working' outcome may be. Is
that a limitation in the ability of the participants, or a desire to
keep JQuery users as 'in the dark' as possible about javascript?
There are plenty of people here who are willing to help, but the help
offered anywhere may often not be something that the person asking for
help would be happy to hear.
You see, even you think the OP has to expose the code before an answer
can be proffered.
"Old school"? What can you mean by that? Are you suggesting that there
are practices and ideas in javascript programming/browser scripting that
have been superseded by more recent developments and we ("the group")
are steadfastly using and promoting them despite the tide of progress?
So are we talking about ideas such as those relating to handling browser
differences. Where the oldest idea was User Agent string based browser
sniffing (which pre-dates javascript), followed by the more potentially
more effective strategy of object inference browser sniffing (which was
very rarely implemented to get anywhere near reaching its potential),
and eventually the more rationally justified feature detection strategy.
And all of this in the dying years of the last century.
All of the proposed alternatives are old, but if any is to be regarded
as "old school" it should have to be one of the first two. But here it
is feature detection (the most modern of those strategies) that is
promoted, and UA string sniffing is ridiculed for its lack of any
technical foundation and demonstrable inability to make the required
discriminations . While in contrast it is in libraries like JQuery that
you find heavy reliance on UA string based browser sniffing and the
people promoting the strategy are the authors of those libraries.
Language use has changed over time, in terms of style. Go back to 2001
and pretty much all large-ish scale javascript design was relentlessly
OO style aping Java. While the passage of time has seen things develop
towards exploiting the functional programming aspects of javascript.
Consider the understanding of closures as an aspect of that trend. At
the turn of the century very few javascript programmers had any idea
what a closure was (at least partly as a consequence of their having
zero coverage in books of the day) and little use for them. These days
anyone who intends putting themselves forward as an expert on javascript
is going to be expected to have a good handle on closures, and the run
of the mill programmers are expected to have a working familiarity. That
trend started right here on this group. You would be hard pressed to
find a single regular participant in this group (with the obvious
exception of VK) in the middle of 2004 who was not fully familiar with
the theory, mechanism and practical applications of closures.
Similarly the "Module Pattern" (and generally the use of inline calls to
function expressions to provided a pseudo-private scope) that came as
such a new idea to so many in mid 2007 when the famous YUI blog was
first published is old enough to be regarded as "old school". It was
first published, on this group, in April-May 2003 (various examples from
function expression calls motivated by private scooping to recognisable
"module pattern" implementations ). And it was participants in this group
who first took up the idea, developed and discussed it, teased out its
permutations and identified its appropriate uses, with sufficient rigor
and enthusiasm that the whole subject was played out here by the end of
2004.
So it is "old school" to be in at the point other people's new ideas of
the last couple of years really were genuinely new ides? To be, what
appears to be, 3 or 4 years ahead of the game?
And given 3 or 4 years head start to spend debating the issues do you
really think that the reasoning behind the "hatred" of these libraries
is not well thought out? After all, the idea of large-scale
general-purpose javascript/DOM libraries is hardly anything like a new
ides. When I started writing javascript back in 2001 libraries such as
'overlib' and (I think it was called something like) 'x-lib' had the
mass popularity. Maybe not to the level of current libraries, but that
is partly because the demand for javascript on the web was nothing like
what it is today (and I don't think anyone even considered marketing
them, and certainly not having t-shirts printed). Consider how critical
and argumentative this group is; is it credible that poor reasoning
about such an old idea would not have been torn apart by now in such an
environment?
Is that true? Do you imagine that nobody has ever attempted to enumerate
the supposed benefits of those "hated" libraries here? Granted, mostly
when you ask a 'supporter' of these libraries to enumerate the benefits
they offer, no list is forthcoming. Which always suggests to me that the
"benefits ... to real world developers" arguments are the
comprehensionle ss parroting of someone else's propaganda. And when the
response is 'they are too obvious to mention' I know full well that I am
not listening to reasoned argument (whenever something is really that
obvious it is also easy to justify/explain/enumerate).
When it comes down to it, the things that really are of benefit in these
things are not exclusive to these things, or maximised by these things.
A good few years of discussing these subjects suggests that all of the
benefits are achievable in other code authoring strategies, and that
some of those alternative strategies can significantly mitigate the
drawbacks of the "hated" libraries.
It may be the case that the debate of alternatives has not yet
crystallised into any formal strategies, and so code written by
participants in the debate still varies considerably in style and
structure, but still the direction chosen is away form the "hated"
libraries.
And of course some of the things put forward as benefits of these
libraries actually turn out to be drawbacks when critically examined.
It may be inevitable that most people will not appreciate being told
that they have taken a totally wrong direction, but that is not a good
reason for not telling them. And mostly when it comes to taking advice
about which path to take it is a good idea to get the advice from
someone familiar with the whole journey.
Richard.
Hamish Campbell wrote:
On Jul 28, 5:39 pm, jdalton <John.David.Dal ...@gmail.comwr ote:
>
I hope this helps :D
>@Pink
>>
>You might try one of the jQuery mailing
>>
>If you are on twitter.com you can message @jquery for help :)
>>
>You might try one of the jQuery mailing
> >>lists:http://docs.jquery.com/Discussion
>If you are on twitter.com you can message @jquery for help :)
>Also for fun you can read up on the various
>personalitie s here:
>>http://redwing.hutman.net/~mreed/war...ssrebutter.htm
>>
>personalitie s here:
>>http://redwing.hutman.net/~mreed/war...ssrebutter.htm
>>
>>
>- JDD
>- JDD
information provided was insufficient for an answer to be given
(particularly asking to see the code). Pretty much the same reaction to
the question as received here (and unsurprising as there is a minimum of
information required in any meaningful analysis).
In the end it turned out that my suspicion that the information provided
was inaccurate at least in part, due to the contradiction between the
description of the code and the symptoms, was well founded. The issue
was caused by arbitrary character sequences being written into the
javascript source code for a string literal without appropriate
escaping. A common novice mistake that easily goes unnoticed up until
the point where someone/something introduces a character that is
forbidden or problematic in a string literal, like apostrophes
(problematic) or line terminators (forbidden).
That meant that the "run it locally under Firefox, everything works
fine" was pure misdirection, as given the same data it would have failed
as reliably locally as it failed "on the host site".
Plenty of people there (including myself) willing to
help out.
help out.
group is any depth of expiation, or any push to enable other posters to
become better javascript programmers. It appears that everything is
geared towards getting things 'working' in some sense, with no
consideration of how stupidly coded that 'working' outcome may be. Is
that a limitation in the ability of the participants, or a desire to
keep JQuery users as 'in the dark' as possible about javascript?
There are plenty of people here who are willing to help, but the help
offered anywhere may often not be something that the person asking for
help would be happy to hear.
Try to post a link to a sample site if
possible.
possible.
can be proffered.
Unfortunately this group can be a little.. old school.
are practices and ideas in javascript programming/browser scripting that
have been superseded by more recent developments and we ("the group")
are steadfastly using and promoting them despite the tide of progress?
So are we talking about ideas such as those relating to handling browser
differences. Where the oldest idea was User Agent string based browser
sniffing (which pre-dates javascript), followed by the more potentially
more effective strategy of object inference browser sniffing (which was
very rarely implemented to get anywhere near reaching its potential),
and eventually the more rationally justified feature detection strategy.
And all of this in the dying years of the last century.
All of the proposed alternatives are old, but if any is to be regarded
as "old school" it should have to be one of the first two. But here it
is feature detection (the most modern of those strategies) that is
promoted, and UA string sniffing is ridiculed for its lack of any
technical foundation and demonstrable inability to make the required
discriminations . While in contrast it is in libraries like JQuery that
you find heavy reliance on UA string based browser sniffing and the
people promoting the strategy are the authors of those libraries.
Language use has changed over time, in terms of style. Go back to 2001
and pretty much all large-ish scale javascript design was relentlessly
OO style aping Java. While the passage of time has seen things develop
towards exploiting the functional programming aspects of javascript.
Consider the understanding of closures as an aspect of that trend. At
the turn of the century very few javascript programmers had any idea
what a closure was (at least partly as a consequence of their having
zero coverage in books of the day) and little use for them. These days
anyone who intends putting themselves forward as an expert on javascript
is going to be expected to have a good handle on closures, and the run
of the mill programmers are expected to have a working familiarity. That
trend started right here on this group. You would be hard pressed to
find a single regular participant in this group (with the obvious
exception of VK) in the middle of 2004 who was not fully familiar with
the theory, mechanism and practical applications of closures.
Similarly the "Module Pattern" (and generally the use of inline calls to
function expressions to provided a pseudo-private scope) that came as
such a new idea to so many in mid 2007 when the famous YUI blog was
first published is old enough to be regarded as "old school". It was
first published, on this group, in April-May 2003 (various examples from
function expression calls motivated by private scooping to recognisable
"module pattern" implementations ). And it was participants in this group
who first took up the idea, developed and discussed it, teased out its
permutations and identified its appropriate uses, with sufficient rigor
and enthusiasm that the whole subject was played out here by the end of
2004.
So it is "old school" to be in at the point other people's new ideas of
the last couple of years really were genuinely new ides? To be, what
appears to be, 3 or 4 years ahead of the game?
And given 3 or 4 years head start to spend debating the issues do you
really think that the reasoning behind the "hatred" of these libraries
is not well thought out? After all, the idea of large-scale
general-purpose javascript/DOM libraries is hardly anything like a new
ides. When I started writing javascript back in 2001 libraries such as
'overlib' and (I think it was called something like) 'x-lib' had the
mass popularity. Maybe not to the level of current libraries, but that
is partly because the demand for javascript on the web was nothing like
what it is today (and I don't think anyone even considered marketing
them, and certainly not having t-shirts printed). Consider how critical
and argumentative this group is; is it credible that poor reasoning
about such an old idea would not have been torn apart by now in such an
environment?
I'm pretty sure that PointedEars et. al. could
program JS with an Oscilloscope and a soldering iron
if they really tried. Unfortunately that sword has cut
both ways and they're all but blind to the benefits
that jQuery (and the other hated libraries) bring
to real world developers.
program JS with an Oscilloscope and a soldering iron
if they really tried. Unfortunately that sword has cut
both ways and they're all but blind to the benefits
that jQuery (and the other hated libraries) bring
to real world developers.
the supposed benefits of those "hated" libraries here? Granted, mostly
when you ask a 'supporter' of these libraries to enumerate the benefits
they offer, no list is forthcoming. Which always suggests to me that the
"benefits ... to real world developers" arguments are the
comprehensionle ss parroting of someone else's propaganda. And when the
response is 'they are too obvious to mention' I know full well that I am
not listening to reasoned argument (whenever something is really that
obvious it is also easy to justify/explain/enumerate).
When it comes down to it, the things that really are of benefit in these
things are not exclusive to these things, or maximised by these things.
A good few years of discussing these subjects suggests that all of the
benefits are achievable in other code authoring strategies, and that
some of those alternative strategies can significantly mitigate the
drawbacks of the "hated" libraries.
It may be the case that the debate of alternatives has not yet
crystallised into any formal strategies, and so code written by
participants in the debate still varies considerably in style and
structure, but still the direction chosen is away form the "hated"
libraries.
And of course some of the things put forward as benefits of these
libraries actually turn out to be drawbacks when critically examined.
It may be inevitable that most people will not appreciate being told
that they have taken a totally wrong direction, but that is not a good
reason for not telling them. And mostly when it comes to taking advice
about which path to take it is a good idea to get the advice from
someone familiar with the whole journey.
Richard.
Comment