bg*****@gmail.com wrote:
Richard Cornford wrote:
>bg*****@gmail.com wrote:
>>Jeremy wrote:
I stand by my position that prototype.js is useful, as
long as you're aware of the ramifications of using it.
>>In my mind the jury is out on javascript. I've come to
respect it from professional use and from mostly lurking
on this group but I would certainly be open to going to
something more productive for building serious web apps
if it comes along.
Javascript is an ideal language for client-side scripting
of web browsers because its dynamic nature allows it to
adapt to the environments it encounters. Trying to do what
is easy in javascript with a strongly typed and non-dynamic
language such as Java would be a nightmare (far too much
reflection and error handling). So a replacement client-side
scripting language would best be something as flexible as
javascript, and if that then why replace at all?
My argument is questioning "hand coded" (as opposed to
program-generated) javascript as a reasonable, easily
maintainable way to build web applications.
There is a 'chicken and the egg' problem with that proposition. To be in
a position to design/write good machine generated javascript the
individual responsible will have to have learnt javascript, and its
(particularly browser scripting) applications pretty well, because they
are going to have to be automatically handing all of the issues of the
general case. They will not get into that position unless they have an
extensive experience of browser scripting (and server scripting for that
matter) and that will inevitably mean a great deal of hand coding (not
to mention that actual writing of the scripts that the machine
generates).
Historically, much server-script and automatically generated javascript
has been very poor, and it doesn't take much observing to see that
people who rely upon systems that generate client-side code are utterly
lost as soon as they encounter a problem with/limitation in the system
they are using. So lost that not only do they have no idea how to
address their problems but they cannot even express their problems in
terms applicable to client-side scripting ("I have an ASP.NET control";
says nothing in the context of client-side technologies).
I have come to admire javascript as a language and
would never advocate for a replacement client-side
scripting language.
But...
AJAX just begs for a framework, IMHO.
That would be a very poor notion that would result in a
system that would try to be all things to all men, but
end up being too much for most and insufficient for
some. ..<snip>
>At its worst you are looking at a hugely complex activity,
say 'as they type' validation, look-ups/suggestions, data
retrieval, ...<snip..and all needing to be orchestrated
with the asynchronous activity of the user in a way that
does not get in their way and still makes sense.
Yes, that is what a framework would have to do and as far
as I've seen,
But that is not an AJAX framework, it is one form of web application
framework, It would be far too much for most actual uses of AJAX.
that is indeed what Ruby On Rails does and it does it well.
Not from what I have seen of Ruby on Rails.
What I hear from you, correct me if I'm wrong, is that
users
Users? To my mind the user is the person on the receiving end of web
development, the one sitting in front of a browser interacting with the
end result. The person who's behaviour I may seek to alter in this
respect is the web developer, who, if he/she is using any form of
programming code, is a programmer (no matter how much they may not want
to admit it to themselves, or fall short of the skill set necessary to
do that job well).
shouldn't use monolithic, invisible javascript code libraries,
No they should not, that style of code authoring, while completely
appropriate in other programming contexts, is out of place in browser
scripting. It is appropriate in other contexts because it doesn't matter
how general and comprehensive a code library may be because the process
of compiling any code that uses it will allow for the automatic, and
selective, inclusion of _only_ the parts that are needed by the finished
executable. While with javascript no 'compiling' could happen until the
source code has been transmitted to the client, in its entirety. And
once sent to the client all the code received will be acted upon; All of
the code will be tokenised, all will be transformed into an executable
form, all global function declarations , for example, will result in the
unconditional creation of function objects, even if in reality some
percentage of them may never be used.
A code authoring strategy that is so near to being universally
advantageous in computer programming that people will defend it as the
only conceivable approach to sensible code re-use becomes a limiting
factor when applied to browser scripting. You just cannot set about
browser scripting by including one library then another and then
another, and actually using about 10% of each. The overheads in download
time, interpretation/compilation time and actual execution performance
adds up to the point where the end result eventually becomes non-viable.
Taking that path leads to a known destination, and it is somewhere that
should be avoided. Browser scripting has to use another strategy; a
strategy where the units of re-use are smaller, independent and
task/context specific.
they should write their own libraries (reusable code).
There is nothing wrong with using code written by others, if it is the
right type of code for the task/context. But to see that code is the
right type, is suitable written and of sufficient qualify, a javascript
programmer is going to have to gain some practical experience of browser
scripting (preferably in the most demanding applicant; public Internet
programming). And in setting about gaining that experience they will
likely write a great deal of code that will serve as the basis of their
own collection of re-useable components. Plus they will get an insight
into the issues of browser script design and a familiarity with
strategies that can be applied to address them.
I don't really need to say, as a blanket injunction, that people should
not use monolithic general purpose javascript libraries, all I have to
do is convince them to set about learning to script web browsers well
and they will see that for themselves eventually. And that is why the
champions of the general javascript library concept are not to be found
among the regular contributors to this group; the people who have put in
the effort to learn the practice well have seen the pitfalls and learnt
how to set about applying the practical alternatives.
This is the direction we are moving towards in my
company. Up to this point I have thought it was a
good direction, at least a lot better than relying on
ASP or Java, But I am starting to see a big problem
with developing large amounts of "the most misunderstood
language" code. Stronger typed or more natural languages
(Ruby reads like english most of the time) don't need to be
wholly understood by the developer. Some of my coworkers
(experts at SQL and ASP) consider javascript to be magic.
Isn't the implication of that that the people who make (or swing) the
decisions about the use of client-side technologies should be the people
who don't understand them?
I am reminded of all the times I have been told, by people who had no
idea of how to go about doing so themselves, that designing truly
cross-browser systems would be so restrictively expensive that is could
not be worth even trying. It is a bit like asking a plumber for a quote
on the cost of hart bypass surgery.
The perverse aspect to this situation (particularly with respect to
Prototype.js) is that not only is it the people who don't have the
pertinent skills who want to be directing implementation approaches but
that what is proposed largely goes against the advice of the people who
do.
In this area of the world (New York CIty), people who
advertise themselves as Javascript gurus really mean
DHTML gurus.
I don't think anyone could justify describing themselves as the latter
without also being the former (but I would seriously distrust anyone who
labelled themselves a 'guru' anyway).
But I appreciate that problem very well. When I applied for the job I
currently have, which advertised for javascript experts, I was given a
'technical' text. A test so superficial, easy and obvious that I would
consider anyone who did not get 100% on it not even to be qualified to
write javascript, it certainly didn't approach being a test of
'expertise' in the area. It transpired that one of the reasons that I
was offered the job was that _none_ of the other candidates had done
better than 50% on that test. I have no idea how these people offering
themselves for the role of javascript expert imagined that they would do
the job, I am forced to conclude that they thought that 'expert' had
been tacked onto the job description with the same misguided motivation
that has employers asking for technically skilled web developers with
"Dreamweaver" (which is almost an oxymoron).
I am also seeing this in the London job market, where a city bank (who
will have to be unnamed due to a confidentiality agreement) have spent
at least the last 6 months attempting to employ a good javascript
developer. They advertise for a couple of days, so quiet for a month,
and then advertise the job again. Presumably each time they find
someone, and then take the next month discovering that they are not up
to the job and have to start again. It must be very expensive to
repeatedly go through that cycle, and I cannot see that they will be
making much headway on whatever project this individual is supposed to
be working on.
So I can completely appreciate that you may be finding it difficult to
lay your hands on someone who can significantly contribute to your
project. However, I don't think you will solve that problem by assuming
that the authors of some library or framework would have been that
person if you had managed to employ them directly.
Still, my advice would be that if you want to create a system that makes
more than a trivial use of client-side scripting you will really need to
find someone who has the (combined server-side and client-side) skills
and experience for the task. Granted you will have to think of some
strategy for distinguishing the people who actually have those skills
from the people who just think they have, and you will have to offer
remuneration suitable for a seller's market. Otherwise my final
suggestion at the end of this post may be the best approach to take.
Most of them have never peeked at this news group.
Which would be a pity as with browser scripting the main practical
subject of this group the bulk of what gets discussed is DHTML in
practice (even if many don't like that particular label for it).
This means, to me, that there will continue to be much
more bad javascript written than good javascript
While I don't doubt that is true I don't see that it follows from your
previous comments. Bad javascript is written because it can be written,
and written more easily than virtually any other form of computer code.
There is no requirement for any specialised software, IDE, etc, and
people can create something that superficially 'works' with no more than
any javascript book or a little searching on the Internet. A situation
that allows people to easily becomes ridiculously over-confident
javascript abilities, which then motivates them to start contributing to
the mass of publicly available copy-n-paste scripts on the Internet (and
in extreme cases creating entire libraries for the even less experienced
to shoot themselves in the foot with).
and I would furthur maintain that this is much truer
than of other languages due to javascript's exclusivity
in browsers.
On the whole it is a good thing that client-side scripting is (to all
practical purposes) limited to a single language.
What I said is that in my mind, the jury is still out on
javascript.
But you did not elucidate the charges you think it is facing, so there
is not a great deal that can be said in response to those implied
charges.
I like the Yahoo UI widget libary almost as much as ROR and
it is all client side javascript. It is also a framework
for handling AJAX and events and while it won't completely
handle "validation (while you type)", it certainly makes it
easier to implement things like that.
What I would like to see are more solid cross-browser
libraries like Yahoo UI
As it happens earlier in the week I had reason to take a look at the
Yahoo libraries, specifically the Event library (indeed one specific
method call in that library), and was slightly shocked to see how
many serious faults I observed in the tiny fraction of the code that
I was interested in.
For a start it includes a couple of instances of userAgent string based
browser detection. User Agent string based browser detection is such a
universally recognised bad practice that in the extensive discussion we
had here on how to advise people on the recognition of bad javascript
code it was one of only two practices that were agreed to be universally
indicative of code so poor that it should be rejected out of hand (i.e.
you do a text search of the source for 'userAgen' and if found you
reject the script in question and move on to the next). (The other
universally agreed indicator of bad code being the direct - eval -ing of
string literals.)
User Agent string based browser detection is a bad practice because:
1. RFC 2616 (HTTP 1.1) makes it clear that the UserAgent header is not a
source of information about the user agent (because it does not require
the header to contain any specific information, or even be consistent
over time) and as the navigator.userAgent property reflects the HTTP
header it must also not be a source of information.
2. Many browser use, by default, User Agent headers that are practically
indistinguishable from the headers used by (normally more common)
browsers, and discriminating is not practical when the input data is
identical. (It was Microsoft's introduction of UserAgent header spoofing
that forced the HTTP 1.1 specification to give the UserAgent header its
current status as something that is not a source of information, though
Microsoft appears to have not noticed the consequences of their actions
and themselves make the mistake of integrating UA header browser
'discrimination' into .NET)
1. User Agent headers are amenable to user modification in almost all
cases, including on browsers such as IE, and as the HTTP specification
does not require the header to be a source of information no criticism
can reasonably be levelled at users who modify the header (regardless of
how inconvenient that may seem to people who have already made the error
of mistaking the header for a source of information).
The practical upshot of this error in the Yahoo code is that the
libraries will not be cross-browser, the best they could aver achieve
would be to be multi-browser, and then only multi-browser where the
browsers in question were (in some respects) operated in their default
configurations. And here is something that speaks to maintenance, as
this error could be fixed but if it is everyone who has tied their
project to the library has to make an effort to take advantage (assuming
that they find out about it).
The reason that I had to look at the browser detection was because it
was used to branch into this function (theoretically for IE only, though
in reality only for IE's with near default UA strings and any browser
with an IE like UA string and no pageX/Y property on its event
objects):-
| _getScroll: function() {
| var dd = document.documentElement; db = document.body;
| if (dd && dd.scrollTop) {
| return [dd.scrollTop, dd.scrollLeft];
| } else if (db) {
| return [db.scrollTop, db.scrollLeft];
| } else {
| return [0, 0];
| }
| }
However, this code demonstrates either a lack of understanding of the
behaviour of IE browsers, or a shortfall in the application of logic on
the part of its author. IE 6+ can operate in one of two 'modes' (which
it knows a 'CSS1Compat' and 'BackCompat', all earlier IEs do the same is
IE 6+ in 'BackCompat' mode (as that is 'Back' referred to). The
arrangement with scrollTop/Left is that when in 'BackCompat' mode you
read the values form the document.body, and in 'CSS1Compat' you read
them form the document.documentElement (which does not exist prior to IE
5.0). Fortunately for this code, on IE whichever of these elements is
not reporting the actual scroll offsets of a page will report zero
values for scrollLeft/Top (rather than NaN or undefined values). This
allows the code to disregard the reported 'mode' of the browser (as
retrieved from - document.compatMode - on IE 6+) and instead deduce
that zero values imply a need to look elsewhere.
However, if a document is in 'CSS1Compat' mode and has been scrolled
horizontally but not vertically the - if (dd && dd.scrollTop) { - test
will return false (because dd.scrollTop is still zero), and so the
scrollTop/Left values will be read from the document.body element, where
both values will be zero because the page is in 'CSS1Compt' mode.
This fault is inherent in the logic of code, and I assume that the
author would not have written code that outputs erroneous values under
realistically possible conditions deliberately. So when I look at barely
16 line of code from this library and find a universally recognised bad
practice and implemented logic that will produce erroneous results under
realistic circumstances I am inclined to be seriously unimpressed, and
wonder to what extent these shortcomings manifest themselves elsewhere
in the code. I also wonder to what extent those using this code, and
recommending its use to others, appreciate its faults and limitations.
The author(s) obviously are not aware of what they have done here, else
they would have applied joined up logic to the situation.
Unfortunately for many the decision to use this code will be based upon
a trust in the source of the code (Yahoo's reputability) and the
recommendations of others, who may not be an any better position to
properly asses the library's actual code.
and individually coded javascript tasks using those libraries
and complimenting a server based framework like Rails or server
based technology like PHP-Mysql. Yes, and I guess .NET (though
it is not my idea of fun).
But is that solving problems or hiding from them; abdicating
responsibility for the quality of your products to third parties, and
third parties you are unlikely to be able to assess the skills of but
you have to trust to be doing their job properly, and properly testing
their creations. Your cited Yahoo library illustrates the shortcomings
of this approach, where the author did not perceive the hole in the
logic implemented and the QA testing applied did not expose it.
There is always the option of taking another course, and just leaving
client-side scripting alone. It certainly is not compulsory to use it
and may be better not used than used badly.
Richard.