http://www.JavascriptToolbox.com/bestpractices/
I started writing this up as a guide for some people who were looking for
general tips on how to do things the 'right way' with Javascript. Their code
was littered with document.all and eval, for example, and I wanted to create
a practical list of best practices that they could easily put to use.
The above URL is version 1.0 (draft) that resulted. IMO, it is not a
replacement for the FAQ, but a more practical guide for fixing some of the
problems that commonly get pushed into web sites.
Any comments?
PS: Ignore the formatting. It's ugly, for now ;)
PPS: I know that there are exceptions to many of the 'best practices' in
very specific situations when approached by an experienced author, but the
goal of this document is to help the average joe developer fix common
problems and write more acceptable code.
--
Matt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com
Oct 11 '05
136  9186 
Randy Webb a écrit : Gérard Talbot said the following on 10/14/2005 10:15 PM:
Randy Webb a écrit :
That depends on how the <a> is coded.
<a href="somePage.html" onclick="return someFunction()">Some Page</a>
If the function someFunction() either displays the contents of
somePage.html in the current window, opens a new window, or toggles
display on a div tag that contains the data in somePage.html
I am not sure I understand that part: "toggles display on a div tag that
contains the data in somePage.html"
Wouldn't an <iframe src="foo.html" ...> or <object data="foo.html"
type="text/html" ...> be semantically better?
I believe the part of the document titled "Using onClick in <A> tags" is
a bit abstract and would benefit from having a concrete example or some
references.
then if JS is disabled the end user still gets the same content, but via a
different mechanism.
And when an a tag is used to invoke a function, and it is coded
correctly, then it degrades gracefully in the absence of JS.
How is that bad coding?
I don't know. I can't say. It depends. I see no full page example. No
concrete code. No url. Just doSomething(). Or someFunction(). And a
general description.
Gérard
--
remove blah to email me
Randy Webb a écrit : Gérard Talbot said the following on 10/14/2005 10:15 PM:
Randy Webb a écrit :
I replied a code to the situation where JS was disabled. Basically the
same code could have been provided for a badly semantically coded <a>
link (instead of a <button>).
That depends on how the <a> is coded.
<a href="somePage.html" onclick="return someFunction()">Some Page</a>
If the function someFunction() either displays the contents of
somePage.html in the current window, opens a new window, or toggles
display on a div tag that contains the data in somePage.html then if JS
is disabled the end user still gets the same content, but via a
different mechanism.
And when an a tag is used to invoke a function, and it is coded
correctly, then it degrades gracefully in the absence of JS.
How is that bad coding?
It's kinda difficult to maintain a long discussion on several sharp
topics while having doSomething() function and long reading to do. IMO,
a full-page example would certainly bring some light, would refresh this
long thread.
In this thread, I believe I've tried to bring up chunks of code,
references, more complete examples trying to substantiate my claims.
And I have presented my thoughts and nothing more.
(1) Some refer to browsers/browser versions released after 2001. Some
others refer to 5th generation browsers. Some others to browsers being
js-capable of modifying its DOM tree. In all cases, MSIE 4 does not
meet any of the above conditions.
If a "modern browser" is a "5th Generation Browser" then where does that
leave Firefox 1.0.xx?
"5th Generation Browser" is as ambiguous a term as "modern browser".
I agree with you that such expressions would need to be defined explicitly.
My goal is to support as many browsers as I can (modern or not) that do
not require a lot of extra effort. And including a snippet of code that
allows a lot of JS to be execute in IE4 without a document.all branch in
every place I want to do something, then I do it. Even if it is just 1%,
the cost of doing it is neglible. With proper server-side scripting,
With proper server-side scripting.
it is a simple matter of an include statement
Include statement.
in a template document and then the work to accomodate IE4 is zero.
No real live webpage example.
The problem I have with IE4 support now is not with document.all itself.
When I gave the URL to the emulation that is in the FAQ it was not as
outdated as it is now. To /properly/ support IE4 now with the gEBI
emulation,
gEBI emulation. No code. No url. No concrete reference.
you would have to prototype everything that a gEBI browser supports that IE4 doesn't. It is *that* requirement that makes IE4 not
worth supporting.
Anyway. Whatever. I promise never to get into a discussion on supporting
IE4 ever again.
Gérard
--
remove blah to email me
Michael Winter a écrit : On 14/10/2005 21:13, Gérard Talbot wrote:
[snip]
<form name="myform" action="[url]">
<p><input type="text" name="val1" value="1">
<input type="text" name="val2" value="2"></p>
</form>
will not trigger a validation error.
True, but since when have INPUT elements been part of a paragraph? A DIV
or FIELDSET element is more appropriate.
Mike
This semantic issue all depends on your whole page design actually. How
many inputs you have. How are they organized. etc.. A page division
might be better. A paragraph might be correct. Or sufficient. It all
depends on the whole page. A fieldset is certainly ok too.
Now, let's try to find an example somewhere.
<FORM action="http://somesite.com/prog/adduser" method="post">
<P>
First name: <INPUT type="text" name="firstname"><BR>
Last name: <INPUT type="text" name="lastname"><BR>
email: <INPUT type="text" name="email"><BR>
<INPUT type="radio" name="sex" value="Male"> Male<BR>
<INPUT type="radio" name="sex" value="Female"> Female<BR>
<INPUT type="submit" value="Send"> <INPUT type="reset">
</P>
</FORM>
or maybe better
<FORM action="http://somesite.com/prog/adduser" method="post">
<P>
<LABEL for="firstname">First name: </LABEL>
<INPUT type="text" id="firstname"><BR>
<LABEL for="lastname">Last name: </LABEL>
<INPUT type="text" id="lastname"><BR>
<LABEL for="email">email: </LABEL>
<INPUT type="text" id="email"><BR>
<INPUT type="radio" name="sex" value="Male"> Male<BR>
<INPUT type="radio" name="sex" value="Female"> Female<BR>
<INPUT type="submit" value="Send"> <INPUT type="reset">
</P>
</FORM>
or even
<FORM action="http://server.dom/cgi/handle"
enctype="multipart/form-data"
method="post">
<P>
What is your name? <INPUT type="text" name="name_of_sender">
What files are you sending? <INPUT type="file" name="name_of_files">
</P>
</FORM>
and what about
<FORM action="http://somesite.com/prog/adduser" method="post">
<P>
First name: <INPUT type="text" name="firstname"><BR>
Last name: <INPUT type="text" name="lastname"><BR>
email: <INPUT type="text" name="email"><BR>
<INPUT type="radio" name="sex" value="Male"> Male<BR>
<INPUT type="radio" name="sex" value="Female"> Female<BR>
<BUTTON name="submit" value="submit" type="submit">
Send<IMG src="/icons/wow.gif" alt="wow"></BUTTON>
<BUTTON name="reset" type="reset">
Reset<IMG src="/icons/oops.gif" alt="oops"></BUTTON>
</P>
</FORM>
These examples all come from the HTML 4.01 specification.
Gérard
--
remove blah to email me
On 15/10/2005 22:08, Gérard Talbot wrote:
[Paragraphs in forms] This semantic issue all depends on your whole page design actually.
It depends upon what's inside the paragraph. If an INPUT element is
actually part of a paragraph of text, then fine, "but since when have
INPUT elements been part of a paragraph?"
[snip]
These examples all come from the HTML 4.01 specification.
The document also contains:
<FORM action="..." method="post">
<P>
<INPUT type="button" value="Click Me" onclick="verify()">
</FORM>
and there's no way that you can say a single button with the text,
"Click Me", constitutes a paragraph.
In fact, I'm convinced that they simply followed all of their FORM
opening tags with paragraphs for simplicity. Even the FIELDSET example
includes one:
<FORM action="..." method="post">
<P>
<FIELDSET>
<LEGEND>Personal Information</LEGEND>
despite the fact that the paragraph is superfluous, and would be
immediately closed and empty (something the specification recommends
against doing).
The examples in the specification are just examples and they are not
perfect.
Mike
--
Michael Winter
Prefix subject with [News] before replying by e-mail.
On 15/10/2005 21:19, Gérard Talbot wrote: Michael Winter a écrit :
[snip]
Telling a user to upgrade is hardly a reasonable thing for a Web
developer to be doing. That's similar to thinking that one can tell
a user to enable client-side scripting; the user must be backwards
if they don't.
Well, I def. disagree. I know I'm not the only one thinking that IE 4
and NS 4 users should be invited to upgrade.
Whether a user should upgrade or not is irrelevant. It isn't your place,
nor any other developer's, to make an issue of it.
Given that any critical system should be functional with any browser
that implements HTML and HTTP reasonably well, it shouldn't matter
whether users do use something antiquated like IE4. The script won't
execute, won't cause any errors, and will gracefully degrade back to
support provided by the server (if necessary), just like users that have
scripting disabled entirely.
I can only think of two reasons why people still use NN4 and the like.
1) They made a concious choice to use an old browser.
2) They have no option but to use an old browser.
That a user would be unaware /many/ years later that there are new
versions is very unlikely.
In either of the two cases above, telling the user to upgrade is futile,
and arrogant at best; insulting at worst.
[snip]
I've never had to use getElementsByTagName() myself before or ...
maybe once I did. I certainly never used getElementsByTagName("*").
What's your point?
[snip]
document.all is mostly used in webpages (and seen in webpages as) to
access single nodes.
And most of these scripts will be badly written. When did I write that
the all collection /should/ be used to access single nodes?
So I still do not see a single reason to resort to document.all.
Evidentially.
[snip]
Mike
--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Matt Kruse wrote: Richard Cornford wrote:
<snip> In my experience with many web developers, Javascript
is this piece-of-crap scripting language that they have
to deal with and struggle with.
As soon someone accepts that they have to deal with javascript (and they
don't have to deal with it if they don't want to) then they are
accepting that their best interests lie in understanding how to use it.
And people who find themselves having to "struggle with" it have the
choice of learning what they are doing, and only struggling with the
code design issues they would have to address in any programming
context, or they can remain ignorant and continue to struggle with
javascript itself. The latter choice is self-inflicted and does not
deserve any sympathy.
It gets in the way of what they want to do, but they
have to use it.
How can it "get in the way of what they want to do"? It is either
facilitating what they want to do or they don't need to use it at all.
Many have no interest in learning the language or its
quirks, nor do they want to spend hours learning best
practices of FAQs.
And that is an attitude appropriate for anyone who never has to use
javascript at all. Anyone expecting the be paid for using javascript is
seriously misguided if they believe they should not be expected to
understand what they are doing.
My approach is to cater to those people and others who
have no interest in becoming javascript experts. I realize
and accept that they will not read the FAQ or a book on
the topic, nor will they experiment with browser quirks or
other js-related topics. The question is, if you're working
with these people, do you continue to let them make common
easily-corrected mistakes, or do you identify the "low
hanging fruit" and help them fix the most common problems
quickly and easily, so you can at least get some immediate
benefit?
I work with lots of web developers who don't understand javascript, are
not interested in learning it and will not be reading books or FAQs on
the subject. We deal with that situation by never asking them write
javascript, but instead to use the technologies (server-side and
database) that they do know how to use.
Do you tell them to 'write their own' calendar popups
and tree structures because they need to know the
inner-workings, only to see that their end result is
horrible and goes into production because of the
deadline?
If a project needs something like a date picker, and it does not already
exist, then the task goes to a javascript programmer. And a javascript
programmer who cannot already write a date picker for themselves is not
going to be offered a job with us.
Or do you offer a generalized library that might have
some 'bloat' but accomplishes the task way better than
they would have written themselves?
As it happens there was a requirement to add a date picker to the
client-side code for the web application that I am currently working on,
and I was given the task of writing it. And because I am writing in a
system that employs a layered design based on self-contained low level
components and already contains reliable and well tested components for
all of the GUI and date manipulation required by a date picker the task
only involved writing about 150 line of date picker specific logic
(about 3k, fully formatted and commented).
Not everyone wants to be a javascript expert. You do.
That's nice. But don't pigeon-hole everyone into your
mindset.
I am not asking anyone to write javascript if they don't want to, all I
am doing is proposing that people who do write javascript will benefit
from understanding what they are doing. And, to some extent, promoting
that understanding.
What you characterise as a "little extra" code bloat
is not necessarily that little. Every time one of your
libraries satisfies a demand for a less common facility
you increase the download for everyone who has no use
or interest in that facility.
The point is - who cares?
Everyone cares, to the extent that everyone wants everything to be
delivered as soon as they want it.
If it's an extra 5k or even 10k, that is
often way over-shadowed by graphics sizes, flash, etc.
Graphics can be a considerable source of needless bloat on the web. My
observations of web graphics have revealed common graphic bloat of up to
a factor of 60, with a factor of 10 being normal. Again this is a
consequence of people not really understanding what they are doing,
though in this case the culprits tend to be designers rather than
programmers.
We have HTML bloat, we have graphic bloat and we have script bloat. It
is the script authors who are responsible for the script bloat, and
falling down in that area is not justified by others falling down in
their area.
If your goal is to create tight, compact pages, then
fine - don't use libs. But that is _NOT_ a requirement
for most people.
Have you ever heard someone saying "it works fine but we would rather it
was a bit slower"? It doesn't happen. If there is a quibble about
performance the problem is always that something is not fast enough. It
may never be an explicitly stated requirement that a software product be
sufficiently fast but that expectation is implied anyway.
The convenience of using a lib with a little code bloat
is more important than the extra few k of text that is
downloaded.
Convenience? Do you imagine that it was not convenient for me to be able
to add a date picker to a system with no more than 150 lines of code?
Convenience without the bloat.
And every time more than one library is used the
odds are good that entire chunks of more or less
identical functionality are being reproduced in
each one.
Not if used correctly.
Very funny. You declare that you are in the business of catering for an
"average web developer" who does not know enough to decide what sort of
property accessor they should be using and then expect them to satisfy
some criteria of "use correctly" when deploying libraries that they have
chosen to use in order to avoid learning how to understand the code they
contain. You don't get to have it both ways, if they are incapable of
doing any more than stuffing a complete library file into a page then
they can only add facilities by stuffing another complete library file
into a page. And so there will be considerable redundancy in the
totality of the resulting code.
But what do you imagine "correctly" would be? Dissecting the libraries
to identify the commonalties behind then and then re-writing either or
both libraries so that they can each use the same code for any specific
requirement they share? That certainly is not going to be practical
without an understanding of javascript, and if "used correctly" implies
removing common features of multiple libraries and re-writing them as
lower level components that can be shared between the libraries then
doesn't it now make more sense to approach code re-use in the way I have
been suggesting and build the final script up form low level components
designed to be shared by all code that requires their facilities?
Yet I benefitted by being able to deliver more
advanced functionality in a shorter timeline.
And the relevance of Java authoring to browser scripting is?
Same concept, different language/environment.
And it is the difference between the language and environments that
modifies the appropriateness of the concept.
Develop a solution to a general problem and package
it up with an interface. People can then use your
solution to the problem in their work, even if your
solution contains much more functionality than they
actually need.
While in javascript you can address a general problem while forcing the
download of much redundant code to support unwanted functionality you
can also address the specific problem in the real context and do nothing
else, and you can employ re-useable code in doing so.
Without a vested interest my expectation would be that
individuals would be interested in identifying the best
possible approaches towards achieving their goals. And
willing to engage in, and be swayed by, reasoned debate
about the possible approaches, even to experiment with
the possibilities to better assess their relative merits.
I'd say that I definitely fall into that categorization.
That is not apparent in your words or actions. If you had, for example,
experimented with designs based on low-level re-usable self-contained
components providing consistent interfaces to various aspects of web
browser environments you would either have realised that they are a
fast, convenient and efficient approach to browser scripting, or you
would have found some tangible reason for not using them and would not
have to keep supporting your maintaining your status quo with appeals to
the stupidity of the "average web developer".
The point of providing a justification for any
recommendation is precisely so that the reader can
disagree with the recommendation.
The target audience for my recommendations (which should
be clear by the content) are generally people who may not
even have enough knowledge to decide for themselves whether
the justification is reasonable or not.
Your vision of a world of web developers who are incapable of
comprehending reasoned argument is extremely depressing. Are things
really that bad in the United States? How does anyone mange to decide
anything?
I just don't see it though. I have encountered many web developers for
whom idleness and/or arrogance get in the way of their learning anything
new, but I have never encountered one for whom the lack of intelligence
was the problem. On the whole web developers, even web designers, seem
to be of above average intelligence. If I didn't believe that I would
not spend so much of my time explaining how things work to them.
Or they may not even care. They just want their stuff to
work.
Isn't it obvious that just wanting ones stuff to work will never be
enough, on its own, to get ones stuff to work?
A "developer who doesn't know enough to decide for
themselves" which type of property accessor to use
in any given context? A vision of web development as
a bunch of headless chickens careering about in the
dark continuously bumping into each other and bouncing
off walls. The pity is that that does appear to describe
the reality in some organisations, but it does no good
to be pandering to the notion that this would be an
acceptable situation.
It describes the reality in _many_ organizations, and
_many_ individuals.
If it is a reality does that make it a good thing?
You don't see regularly how many people _DESPISE_
javascript?
I do regularly see that, and observe that most of the justifications
that accompany that attitude have nothing to do with javascript as such,
but are the result of what people attempt to do with javascript when
they don't really understand what they are doing.
I see absolutely horrible javascript practices so often that
even suggesting the most basic of 'best practices' would add
value to many people. And that is my goal.
You like to talk of "adding value", to people, to web pages, to scripts.
Does it really mean anything or is it just a turn of phrase that just
sounds positive? What is a person to whom "value" has been added? Who
perceives this value, who benefits?
Given that your reader is apparently a heedless chicken, incapable of
comprehending the reason for adopting one of your "Best Practices", and
is doing so apparently on the basis of your authority alone, the change
that represents this added "value" must be nearly negligible. They don't
actually know or understand any more than they did before.
On the contrary, I've received great feedback so far from
many others who said they immediately benefitted from it.
Marvellous, you demonstrate utter contempt for the intellectual
potential of the "average web developer" and then cite their
opinion as in some way significant to an assessment of your
page.
No, my point is, there are many who have a very basic
understanding of javascript, and a document like this is
short, practical, and adds immediate value to their development.
Would that be more or less "value" than would result form them acquiring
a less basic understanding?
But then you cannot learn javascript in a lunch break, or
24 hours, or a couple of weeks, and expecting to be able
to do so is totally unrealistic.
And yet your expectation is that every web developer in the world
should devote this much time to learning it and using it correctly.
That expectation is highly absurd.
Why? How long did you take learning to write Java? How long would you
expect to spend learning C++, .NET, PHP, CSS and so on. Nothing is
instant, even the designers who hide from the real technologies by using
Dreamweaver should have no expectation of being able to use it well
without at least a few weeks devoted to learning how it works.
It takes time to learn to do things, and cross-browser scripting is
inherently difficult because of the variations in execution
environments, so it cannot be learnt instantly.
My point is, people don't have to invest that much time to
do many of the tasks which they want to accomplish. If all
they want is a date picker on their page, they can have one
in 10 minutes. They don't need to spend weeks learning
Javascript to implement one.
No, people do not have to spend time learning to write javascript to do
something like that. There are plenty of copy-and-paste script
collections offering scripts that can be stuffed into web pages without
a moment's thought.
The problem with doing that in utter ignorance of the technology being
used is the consequence of doing so. A moments unconsidered
copy-and-paste can transform a fully interoperable system into something
that will only work on one browser, with potentially significant
consequences for the client who is paying them to do this. And then
there are the consequences for things like site maintenance when the
people who are responsible for undertaking that maintenance do not
understand the technologies that they have chosen to use.
So yes people can stuff any script they like into a web page, but when
they do it in ignorance then the odds are good that the are doing a
serious disservice to however is employing them when they do.
Yet your 'elitist' approach would say they are not worthy
of one if they aren't willing to invest the time. That's
completely unrealistic.
If an unwillingness to invest time in learning to use a technology
results in inconvenience and extra work for colleagues, unnecessary
expanse for employers and inconvenience to end users then that
unwillingness to learn is a manifestation of unprofessionalism.
Late last year I was involved in the process of creating
a javascript authoring standards document for the software
house for which I work.
...
The resulting document is 50 sides of A4 and does no
more than lay down rules that will be followed.
Such a document would be completely worthless to most web
developers.
Did I propose that that document would be of any use to most web
developers? The document is intended to make sub-contractors create code
that is consistent with code produced internally. The sub-contractors
either follow the document or they don't get paid, so it doesn't have to
include any justification for the rules it lays down.
The result is not a screen full of text, it is probably
about the size of a largish chapter in a book. So is it
surprising that I have not created such a document, given
the amount of work involved?
There is value in partially solving a problem.
It has become clear in the past that we attach very different meanings
to the words 'solving' and 'solution'. I don't believe that there is
such a thing as a "partial solution", I would regard the creation of
such as resulting in a different problem, and never regard the process
of going from one problem to another as qualifying as a solution.
If you can add value in a specific area, even without
solving the entire problem, that is a good thing.
The vague addition of "value" again? So; 'it doesn't work, but it
doesn't not work as badly as it did before' is a good thing?
A 'Best Practices' document doesn't need to cover
everything. IMO.
Maybe, and it is unlikely that anything written by one individual could
cover everything, but the more comprehensive such a document is the more
useful it is likely to be. Of course individual practices, proposed as
qualifying as "best" are often discussed on this group (indeed this very
thread discusses at least two such proposals), so the group's archives
may serve as a resource for researching the subject item by item.
That is a fundamental difference between us. I will not be satisfied
to publish anything less than a document that allows its readers to
make informed decisions about the adoption of best practices (and so
also make informed decisions about when it might be expedient to
disregarded them), and you see your best interests in pandering to a
flock of headless chickens.
I'm realistic. You're idealistic.
I'm practical. You're a perfectionist.
That is only a meaningful distinction if the prefect and ideal strategy
towards javascript development for a web browser environment wasn't
realistic and practical. But if not practical and realistic first then
they could never qualify as prefect or ideal. The pursuit of perfection
(even if never achieved, or achievable) produces practical benefits
along the way.
I cater to the masses.
Well, above it read more like 'patronise' but you can call it 'cater' if
you want.
You cater to those you deem worthy.
I 'cater' to the people who pay me. Whatever I make available for free
is on a take it or leave it bases, their choice not mine.
I understand the problems of the average developer.
You have just been telling me that the problem of the average web
developer is apparently that they are incapable of using thought to
direct their actions.
You tell them to RTFM.
Yep, if it is a technical subject RTFM. I have no problem with that.
Richard Cornford wrote: Many have no interest in learning the language or its
quirks, nor do they want to spend hours learning best
practices of FAQs. And that is an attitude appropriate for anyone who never has to use
javascript at all. Anyone expecting the be paid for using javascript
is seriously misguided if they believe they should not be expected to
understand what they are doing.
No one can be an expert in everything.
Rather than considering yourself and your job position, consider a one-man
'webmaster' for a small company who must run the web server, the external
web site, the internal intranet, code in HTML and PHP, do some database
work, write some javascript, create some images, etc. Very few people in the
real world would be an expert in all of those areas, or have anywhere close
to enough time to study each area in-depth. For many, the best hope is to
keep things working and _slowly_ advance knowledge in each of those areas.
I work with lots of web developers who don't understand javascript,
are not interested in learning it and will not be reading books or
FAQs on the subject. We deal with that situation by never asking them
write javascript, but instead to use the technologies (server-side and
database) that they do know how to use.
I'd like to know more about your work environment.
It sounds very different from any that I have worked in or worked with.
If a project needs something like a date picker, and it does not
already exist, then the task goes to a javascript programmer.
In the places I have worked or worked with, and the people I've known, I've
never yet seen someone who was simply a "javascript programmer". In almost
every case I've witnessed, javascript has been an 'add-on' technology that
web developers are expected to use, but that employers almost never devote
any time or training towards.
Again, I think your current work environment - whatever it is - does not
represent the norm for many, many developers out there. Certainly not for
those developers who aren't even _in_ a work environment.
And a
javascript programmer who cannot already write a date picker for
themselves is not going to be offered a job with us.
Good for you. You can be picky. Not every company can.
Hell, many web sites are made by _volunteers_! It could be for their church,
their local charity, their boy scout troop, or whatever. These people may
not even be programmers. If they want some cool javascript functionality on
their site, you would probably tell them "too bad, you can't. You don't know
enough." Whereas I would tell them, "sure, you can do that. Download X and Y
and put Z in your HTML, and it will work."
Whose approach do you think _they_ prefer?
As it happens there was a requirement to add a date picker to the
client-side code for the web application that I am currently working
on, and I was given the task of writing it.
... the task only involved writing about 150 line of date
picker specific logic (about 3k, fully formatted and commented).
That's great, if it solves your specific problem. But is it general enough
to be used by thousands of other people around the world? If not, then
you've solved 1 problem when you could have solved 1,000 problems with a
little more work.
you increase the download for everyone who has no use
or interest in that facility.
The point is - who cares?
Everyone cares, to the extent that everyone wants everything to be
delivered as soon as they want it.
A few extra k doesn't matter in most cases.
I'm never convinced by theoretical savings, whether it be reducing code from
10k to 9k, or by speeding up a code block by 5ms.
There comes a point where the "savings" do not justify the time invested to
achieve them.
We have HTML bloat, we have graphic bloat and we have script bloat. It
is the script authors who are responsible for the script bloat, and
falling down in that area is not justified by others falling down in
their area.
Code bloat only matters if people care.
If you have 200k of javascript, I agree, people might actually care.
If you have a 30k lib that is cached and used repeatedly on a site, I think
you would have a hard time finding anyone who realistically cared.
The convenience of using a lib with a little code bloat
is more important than the extra few k of text that is
downloaded.
Convenience? Do you imagine that it was not convenient for me to be
able to add a date picker to a system with no more than 150 lines of
code? Convenience without the bloat.
a) Not everyone has the skill to develop low-level reusable functions such
as you have done.
b) People such as yourself who write these functions often refuse to
document and share them.
c) Therefore, people without the time or skill to write those functions
cannot use your approach.
If I were you - someone repeatedly advocating reusable low-level functions
being combined to achieve a larger task - then I would certainly be
documenting those functions and making them available to other
lesser-skilled javascript developers, so that everyone could benefit from my
approach. Why don't you?
That is not apparent in your words or actions. If you had, for
example, experimented with designs based on low-level re-usable
self-contained components providing consistent interfaces to various
aspects of web browser environments you would either have realised
that they are a fast, convenient and efficient approach to browser
scripting, or you would have found some tangible reason for not using
them and would not have to keep supporting your maintaining your
status quo with appeals to the stupidity of the "average web
developer".
It's not so black and white.
I do have my own low-level reusable components for various tasks. Many work
very well, some could use some more tweaking. My libraries use these
reusable components and package them into usable form for developers. If
they want to break it down and write things on their own using the low-level
components, that's fine. My approach is to package them up in usable form so
they don't _need_ to do all that work.
I am constantly looking for the best low-level reusable functions to perform
very specific tasks. In fact, I've asked for assistance several times in
this group in writing some very specific, reusable low-level functions, and
people aren't really interested in the topic. I would think that the
regulars here would _love_ to work together to find the best way to solve
specific, low-level tasks and document them in a repository of reusable
code.
People such as yourself - who _ADVOCATE_ such a method of development - do
not share your solutions so that others may benefit. I don't see the logic
in your methods. You have the best way to develop (in your opinion), you
have great low-level components (in your opinion), and you think everyone
could benefit from developing like you - and yet you refuse to share your
work? I don't get it. At least all my stuff - good or bad - is out there for
everyone to look at, use, and criticize. Some of it is out of date and
doesn't even represent my preferred way of solving some problems anymore
(having a wife, dogs, kid, and baby on the way doesn't leave much spare time
to update web sites) but I do the best I can to put stuff up there that
others can actually benefit from.
On the whole web developers, even web
designers, seem to be of above average intelligence. If I didn't
believe that I would not spend so much of my time explaining how
things work to them.
The point is, many people making web sites and apps don't even do it for a
living. They do it in their free time. They may be assembling cars at their
job, then come home and work on a web site for their softball team. They are
not unintelligent people. They just lack the education, experience, time,
and knowledge that someone such as yourself might have. So you can talk all
you want about how they _should_ be doing things, but the fact is that
they're not even listening to you because you're so far off from what they
need.
You like to talk of "adding value", to people, to web pages, to
scripts. Does it really mean anything or is it just a turn of phrase
that just sounds positive?
It's a phrase whose meaning should be obvious.
If you've added value to something, you've increased a positive trait or
reduced a negative one. The end result is worth more, or is superior to the
original state. Maybe you increased productivity, made something more
robust, made something easier to maintain, saved money, etc, etc. And yet your expectation is that every web developer in the world
should devote this much time to learning it and using it correctly.
That expectation is highly absurd.
Why?
Because not everyone is like you, Richard.
Is that a hard concept to understand? There is value in partially solving a problem.
It has become clear in the past that we attach very different meanings
to the words 'solving' and 'solution'. I don't believe that there is
such a thing as a "partial solution"
You don't?
Let's take an easy example - medicine. If I have an incurable disease, I
sure would appreciate having medicine to fight the side-effects, and to
delay the inevitable results of the disease. The problem of the disease is
not solved. But it has been partially solved - I will be more comfortable,
and I will live longer than if I didn't take the medicine. I sure would
appreciate such a partial solution to the problem. :) I'm realistic. You're idealistic.
I'm practical. You're a perfectionist.
That is only a meaningful distinction if the prefect and ideal
strategy towards javascript development for a web browser environment
wasn't realistic and practical.
If you believe that your approach is perfect and ideal (or at least closer
than mine) for most people, then I think you are wrong. Sure, it may be
realistic and practical for some, but certainly not most. IMO.
Go find a high school student who is learning web development to make a
school band web site and wants to use some javascript. Ask them if it's
realistic and practical to invest weeks of learning and testing to figure
out how browser scripting works, then spend weeks writing their own
low-level reusable functions, then spend time combining them to perform the
specific task they wanted to achieve on their site. Ask if that approach is
realistic and practical for them, when they could have downloaded a solution
with 10k of 'code bloat' and had it working in their page in less than an
hour. Ask them which approach is more realistic and practical. You tell them to RTFM.
Yep, if it is a technical subject RTFM. I have no problem with that.
I had so many responses to this line that I couldn't even decide which one
to use. Luck you ;)
--
Matt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com
Richard Cornford said the following on 10/15/2005 10:47 PM: Matt Kruse wrote:
Richard Cornford wrote:
You tell them to RTFM.
Yep, if it is a technical subject RTFM. I have no problem with that.
Too bad the Manual for Javascript is next to useless.
It's a good theory (ECMAScript) but is so far away from reality in some
situations that it makes it useless.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
In article <vq**************@merlyn.demon.co.uk>, Dr John Stockton
<jr*@merlyn.demon.co.uk> writes JRS: In article <Sz**************@jgharris.demon.co.uk>, dated Fri, 14
Oct 2005 19:41:23, seen in news:comp.lang.javascript, John G Harris
<jo**@nospam.demon.co.uk> posted :In article <TF**************@merlyn.demon.co.uk>, Dr John Stockton
<jr*@merlyn.demon.co.uk> writesJRS: In article <3r************@uni-berlin.de>, dated Wed, 12 Oct 2005
19:30:42, seen in news:comp.lang.javascript, Gérard Talbot
<ne***********@gtalbot.org> posted :
<snip>IMO, tricks based on + and -0 can not be the best recommendable way to
convert a string to a number. parseInt or parseFloat should be used instead.
Then you are wrong; and sentences should start with a capital letter.
<snip>
Not funny. This newsgroup is read by beginners; we mustn't trick them
into writing ParseInt (with a capital P).
Agreed. The solution is to recast the sentence so that parseInt does
not come first. Putting "Function " before it is generally
satisfactory.
What a very silly thing to say. mW powers your torch.
MW melts scrap metal.
Neither makes a good start for a sentence.
What is the symbol for milliwatts? mW. Thanks.
John
--
John Harris
Matt Kruse wrote: Had everyone stuck to the rules that purists have about when to use
tables, the web would have been much uglier for much longer.
Rubbish. Your thinking seems to base on a static medium which the Web
certainly is not and has never been.
I still use tables for layout. Why? Because it works consistently across
browsers, it's much easier to accomplish nice layouts that equivalent CSS
layout, it degrades more consistently than CSS, and it's easier. I don't
care if it's "semantically" wrong. It works. Better than the alternatives
in most cases.
No, it certainly does not, and to state such can only be based on shallow
or no insight, and bad examples of the otherwise very viable alternatives
to layout tables.
A table is a table is a table. [psf 3.8]
You (and, alas, many others) seem to still perceive the Internet including
the Web as a screen-only medium for non-handicapped people. However, that
is no longer the case. The Internet, especially the Web, has moved far
beyond the desktop application it once was and more and more users,
including handicapped ones, trying to have access to it. A competent Web
author has to take this into account, and, fortunately and consequently,
current Web standards provide means to do so.
But, as Michael said correctly, this belongs to another newsgroup.
PointedEars
Thomas 'PointedEars' Lahn wrote: I still use tables for layout. Why? Because it works consistently
across browsers, it's much easier to accomplish nice layouts that
equivalent CSS layout, it degrades more consistently than CSS, and
it's easier. I don't care if it's "semantically" wrong. It works.
Better than the alternatives in most cases. No, it certainly does not, and to state such can only be based on
shallow or no insight, and bad examples of the otherwise very viable
alternatives to layout tables.
I disagree.
(And for the record, I've been doing this for 12 years, and I'm quite
informed on the topic.)
A table-based layout renders more consistently across browsers than a
CSS-based layout, in my experience. Except for very basic layouts. With a
table-based layout, I can have my content look mostly the same even in very
old browsers. With CSS-based layout, older browsers see either a very plain
or a broken layout.
I'm very familiar with (although, admittedly not an expert in) CSS-based
designs and layouts. I use CSS extensively myself, and I often use it for
positioning and layout. But some things are very difficult to do
consistently with pure CSS. In many cases, using a CSS approach is _much_
more work than a simple table layout which will work consistently in every
browser you can test in. The reasons for dumping tables in favor of pure CSS
are often unconvincing to me. As soon as a simple 3-column layout becomes
easier and more consistent to do in CSS than with tables, let me know. Until
then, I'll probably stick with a big table for the overall layout and CSS
for the rest. That's just MO.
I love the concept of CSS and CSS-based layouts. Unfortunately, it just
hasn't evolved fully yet. Abusing CSS for page layout is just as bad as
abusing tables for it, IMO. CSS is good for positioning and styling. It's
not so good for layout. And browser support (or lack thereof) certainly
makes it more difficult to use it for layout.
You (and, alas, many others) seem to still perceive the Internet
including the Web as a screen-only medium for non-handicapped people.
I don't perceive things that way at all. I realize the reality of how the
web is accessed and who is using it.
In most cases, I agree that web authors need to consider all these factors.
In some cases, it doesn't matter. And in some cases, it should be the screen
readers and other accessibility devices that should be improved to cater to
the current state of the web.
--
Matt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com
Gérard Talbot said the following on 10/15/2005 4:54 PM: Randy Webb a écrit :
Gérard Talbot said the following on 10/14/2005 10:15 PM:
Randy Webb a écrit :
I replied a code to the situation where JS was disabled. Basically
the same code could have been provided for a badly semantically coded
<a> link (instead of a <button>).
That depends on how the <a> is coded.
<a href="somePage.html" onclick="return someFunction()">Some Page</a>
If the function someFunction() either displays the contents of
somePage.html in the current window, opens a new window, or toggles
display on a div tag that contains the data in somePage.html then if
JS is disabled the end user still gets the same content, but via a
different mechanism.
And when an a tag is used to invoke a function, and it is coded
correctly, then it degrades gracefully in the absence of JS.
How is that bad coding?
It's kinda difficult to maintain a long discussion on several sharp
topics while having doSomething() function and long reading to do. IMO,
a full-page example would certainly bring some light, would refresh this
long thread.
That is part of the problem. You are wanting specific examples in light
of a general page. someFunction() can do anything you want. As long as
it returns true/false, what it does (with regards to this thread) is
irrelevant.
My goal is to support as many browsers as I can (modern or not) that
do not require a lot of extra effort. And including a snippet of code
that allows a lot of JS to be execute in IE4 without a document.all
branch in every place I want to do something, then I do it. Even if it
is just 1%, the cost of doing it is neglible. With proper server-side
scripting,
With proper server-side scripting.
it
is a simple matter of an include statement
Include statement.
I am not sure how much of the above is a result of your quoting, or, if
it is an intended correction.
in a template document and
then the work to accomodate IE4 is zero.
No real live webpage example.
Again, you are wanting a specific example to a general question.
But, before *anybody* tries to do a gEBI emulation in IE4 they have to
understand, at a minimum, what the impact is. There are some things that
gEBI does that document.all does differently. The problem I have with IE4 support now is not with document.all
itself. When I gave the URL to the emulation that is in the FAQ it was
not as outdated as it is now. To /properly/ support IE4 now with the
gEBI emulation,
gEBI emulation. No code. No url. No concrete reference.
There is a gEBI emulation in the FAQ in the DynWrite area. The basics of
it came from the metallusions site. But again, you are wanting specific
answers to a general discussion.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Thomas 'PointedEars' Lahn said the following on 10/16/2005 5:02 PM: Matt Kruse wrote:
Had everyone stuck to the rules that purists have about when to use
tables, the web would have been much uglier for much longer.
Rubbish. Your thinking seems to base on a static medium which the Web
certainly is not and has never been.
The web, with it's sites, was *very* static when it began. Simply
because there was no way to make it dynamic.
I still use tables for layout. Why? Because it works consistently across
browsers, it's much easier to accomplish nice layouts that equivalent CSS
layout, it degrades more consistently than CSS, and it's easier. I don't
care if it's "semantically" wrong. It works. Better than the alternatives
in most cases.
No, it certainly does not, and to state such can only be based on shallow
or no insight, and bad examples of the otherwise very viable alternatives
to layout tables.
The web browser that is in my cell phone has *NO* support of CSS
positional layout. It does support tables though.
And don't tell me to upgrade it, it is the latest/updated browser
available for it.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Matt Kruse a écrit : Thomas 'PointedEars' Lahn wrote:
I still use tables for layout. Why? Because it works consistently
across browsers, it's much easier to accomplish nice layouts that
equivalent CSS layout, it degrades more consistently than CSS, and
it's easier. I don't care if it's "semantically" wrong. It works.
Better than the alternatives in most cases.
No, it certainly does not, and to state such can only be based on
shallow or no insight, and bad examples of the otherwise very viable
alternatives to layout tables.
I disagree.
(And for the record, I've been doing this for 12 years, and I'm quite
informed on the topic.)
A table-based layout renders more consistently across browsers than a
CSS-based layout, in my experience.
If you code with a given lowest common denominator, then for the sake of
this discussion, you should objectivize this info. If you absolutely
want to create roughly the same page layout in NS4, IE4, Opera 8.50 and
Safari 2.01, then a table-based design for your page will meet such
requirements.
But if you code according to web standards and acknowledged web design
principles, then table-based layout shouldn't be used [for non-tabular
data].
Except for very basic layouts. With a table-based layout, I can have my content look mostly the same even in very
old browsers.
How old is "very old browsers"? To me, IE 4 and NS 4 are very old,
1997-ish browsers, designed and developed in 1996. To me, MSIE 5.01 is a
very old browser too.
To others, MSIE 6 is a very old browser: MSIE 6 beta 1 was released more
than 4½ years ago, you know.
With CSS-based layout, older browsers see either a very plain or a broken layout.
I'm very familiar with (although, admittedly not an expert in) CSS-based
designs and layouts. I use CSS extensively myself, and I often use it for
positioning and layout. But some things are very difficult to do
consistently with pure CSS.
Consistently. What do you mean with consistently? Do you mean consistent
visual layout across different browsers? Do you mean pixel-perfect
rendering for a webpage designed with pixel-perfect ambitions?
Again, I'm afraid we're talking in general terms, in abstract terms,
regarding non-defined, non-concrete webpage situation.
In many cases, using a CSS approach is _much_ more work than a simple table layout which will work consistently in every
browser you can test in.
"will work consistently in every browser": is that realistic? is that a
sane goal? When you say every browser, you mean MSIE 4, NS 4 or older
than those? Even those who have zero support for CSS?
HTML was never designed to be a layout language. It is perfectly normal
that HTML can be rendered differently in different media, softwares,
etc. and this regardless of CSS support.
As far as accessibility (and accessibility groups, guidelines,
checkpoints, directives, norms, etc..) is concerned, what matters is
that content of a page is/remains accessible and that navigation in a
site is/remains functional. How a webpage will look in a tableless
browser or in a CSS-less browser or.. etc.. is not really the most
important issue: access to content and functional navigation are.
The reasons for dumping tables in favor of pure CSS are often unconvincing to me.
You don't believe in writing markup code without validation errors in
your website to begin with. You don't believe in using a doctype which
will trigger standards compliant rendering mode in modern browsers to
begin with.
You believe in deprecated markup. And then you want pure CSS to work in
your pages?
As soon as a simple 3-column layout becomes easier and more consistent to do in CSS than with tables, let me know.
Well, they are available. It all depends on your requirements in terms of
- lowest common denominator browser/requirement,
- how consistent and accurately consistent the layout should be for
browsers like, say, IE4, IE5.x, etc.
- if the 3-column layout must be based on floats and/or abs. pos.,
- if the layout must be fluid or rigid,
- if the layout must be scalable or not,
- if the layout must be controled by js,
- etc...
It all depends on how much constraints, requirements you may have. But I
assure you that a "simple" 3-column layout has been around/available for
many years.
Until then, I'll probably stick with a big table for the overall layout and CSS
for the rest. That's just MO.
I love the concept of CSS and CSS-based layouts. Unfortunately, it just
hasn't evolved fully yet. Abusing CSS for page layout is just as bad as
abusing tables for it, IMO. CSS is good for positioning and styling. It's
not so good for layout.
Zen Garden: th beauty of CSS design http://www.csszengarden.com/
Go ahead and send an email to the creators of that site stating that CSS
is "not so good for layout" and you'll get replies for sure.
regards
Gérard
--
remove blah to email me
Gérard Talbot wrote: If you
absolutely want to create roughly the same page layout in NS4, IE4,
Opera 8.50 and Safari 2.01, then a table-based design for your page
will meet such requirements.
Thank you. That was my point.
You don't believe in writing markup code without validation errors in
your website to begin with.
As I continue to work on the design and content of
www.JavascriptToolbox.com, I am validating it (The url still points to my
old site, but I am trying to get time to put up the new content). I see
value in validating, but if something doesn't validate and I have a reason
for it to be so, I don't mind at all.
You don't believe in using a doctype which
will trigger standards compliant rendering mode in modern browsers to
begin with.
On the contrary, I do. In fact, every page on my new site will have
user-selectable doctype links at the top so that scripts can be tested in
whichever doctype the user happens to be using.
Zen Garden: th beauty of CSS design
http://www.csszengarden.com/
Go ahead and send an email to the creators of that site stating that
CSS is "not so good for layout" and you'll get replies for sure.
If you look at some of the stylesheets created for the site, you quickly
realize that CSS is not good for layout.
--
Matt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com
On 17/10/2005 04:48, Gérard Talbot wrote:
[snip] http://www.csszengarden.com/
Go ahead and send an email to the creators of that site stating that CSS
is "not so good for layout" and you'll get replies for sure.
CSS Zen Garden is an exhibition of good graphical design (exquisite, in
some cases). It demonstrates that attractive layouts can be achieved
with CSS. However, neither the markup nor many of the sample layouts can
be considered good Web design.
The markup is bloated so that there are plenty of hooks for the
different style sheets (this is even acknowledged in the markup). Many
of the style sheets are inappropriate because they produce inflexible
and potentially fragile designs, as well as exhibiting bad practices
(pixel-defined fonts and text containers, dependency upon background
images, etc.).
The site shows what /can/ be done, but doesn't necessarily demonstrate
/how/ to go about doing it.
Mike
--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Matt Kruse a écrit : Gérard Talbot wrote:
If you
absolutely want to create roughly the same page layout in NS4, IE4,
Opera 8.50 and Safari 2.01, then a table-based design for your page
will meet such requirements.
Thank you. That was my point.
You don't believe in writing markup code without validation errors in
your website to begin with.
As I continue to work on the design and content of
www.JavascriptToolbox.com, I am validating it (The url still points to my
old site, but I am trying to get time to put up the new content).
I was referring to your whole site. I was not referring to the
javascript section. I have not find a single page on your whole website
using a strict DTD. Nowhere do I see a doctype decl. in any of your
webpages. So you never trigger standards compliant rendering mode in
modern browsers.
I see value in validating, but if something doesn't validate and I have a reason
for it to be so, I don't mind at all.
You won't mind validation errors if you do not find compelling reason to
fix these either. Browsers and browser versions don't just consult
*_you_* before rendering a page, you know. Unless you actually test your
webpages with all available browsers and browser versions and web-aware
softwares, you can't just dismiss validation errors on a gut/random
feeling just like that... in particular if layout consistency across
browser is something you highly value.
There is no formal error condition in HTML. That is why it is much more
important to validate the markup code. Furthermore if consistent layout
(as consistent it may be) is a goal in itself for a web developer.
You don't believe in using a doctype which
will trigger standards compliant rendering mode in modern browsers to
begin with.
On the contrary, I do.
I have not found a single webpage on your whole website which uses a
doctype triggering web standards compliant rendering mode in modern
browsers. And the thing is that so far you have demonstrated a high
consideration layout consistency across browsers.
I see contradictions in some of your posts on this precise issue.
In fact, every page on my new site will have user-selectable doctype links at the top so that scripts can be tested in
whichever doctype the user happens to be using.
Zen Garden: th beauty of CSS design
http://www.csszengarden.com/
Go ahead and send an email to the creators of that site stating that
CSS is "not so good for layout" and you'll get replies for sure.
You said word for word that CSS is not so good for layout. I am quoting
you fair and square here. You somehow "blame" CSS for not producing as
accurate and consistent layout as tables can but
- you want to support old browsers like NS4, IE4 and other browsers
which have buggy and incomplete support for CSS
- it seems you want pixel-accurate layout for every/all browsers
- you have not defined the configuration of your 3 columns layout
"needs" in terms fluid/fixed design, scalability, float vs abs. pos.,
css hacks or no, etc. There are plenty of 3 columns layout available and
free out there.
If you look at some of the stylesheets created for the site, you quickly
realize that CSS is not good for layout.
I don't follow you. I don't understand you at all on this. I thought
your site was http://www.mattkruse.com/
which starts exactly as follows:
<HTML>
<HEAD>
<TITLE>Matt Kruse's Site</TITLE>
<style>
BODY {
scrollbar-face-color:#006666;
scrollbar-arrow-color:#ffffff;
scrollbar-track-color:#66aaaa;
scrollbar-shadow-color:#006666;
scrollbar-highlight-color:#ffffff;
scrollbar-3dlight-color:#66aaaa;
scrollbar-darkshadow-Color:black;
}
..SPONSOR {
color:#006666;
}
</style>
</HEAD>
<BODY BGCOLOR="#FFFFFF" LINK="#006666" VLINK="#004444">
<center>
<table width=99% border=0 cellpadding=0 cellspacing=0>
(...)
Gérard
--
remove blah to email me
Gérard Talbot wrote: I was referring to your whole site. I was not referring to the
javascript section. I have not find a single page on your whole
website using a strict DTD. Nowhere do I see a doctype decl. in any
of your webpages.
My personal site is a whole different matter. It's evolved (or in many cases
hasn't changed at all) over the last _TWELVE YEARS_. It is certainly no
representation of my knowledge or skills. It's a personal site, and I don't
care if it validates or looks ugly to some people. I have a family and a
job, and updating my personal web site is certainly a very, very, very low
priority in my life ;)
You're welcome to view the source at http://www.ajaxtoolbox.com/ which does
in fact use a strict doctype and probably looks more like what you'd like to
see.
- you want to support old browsers like NS4, IE4 and other browsers
which have buggy and incomplete support for CSS
If I can with a table layout, but not with a CSS layout, why should I use a
CSS layout?
- it seems you want pixel-accurate layout for every/all browsers
Nope, not at all.
- you have not defined the configuration of your 3 columns layout
"needs" in terms fluid/fixed design, scalability, float vs abs. pos.,
css hacks or no, etc. There are plenty of 3 columns layout available
and free out there.
Take for example the layout at http://www.ajaxtoolbox.com/
If you can duplicate that layout with pure CSS and it:
a) Is simpler to code
b) Is fairly consistent across browsers, even older ones
c) Looks just like what I have
then I'll consider the alternative. If you look at some of the stylesheets created for the site, you
quickly realize that CSS is not good for layout.
I don't follow you. I don't understand you at all on this. I thought
your site was...
My site has nothing to do with csszengarden. I stated that in order to
ahieve the impressive layouts that you see on _that_ site, you quickly
realize why CSS is not good layout. The resulting code using CSS is often
quite a disaster.
But really, this discussion is *way* off from javascript, and I don't see
what your goal is...
--
Matt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com
Matt Kruse wrote (2005:10:16): Richard Cornford wrote: Many have no interest in learning the language or its
quirks, nor do they want to spend hours learning best
practices of FAQs. And that is an attitude appropriate for anyone who never has
to use javascript at all. Anyone expecting the be paid for
using javascript is seriously misguided if they believe they
should not be expected to understand what they are doing.
No one can be an expert in everything.
It is not necessary to be an expert in order to understand browser
scripting.
Rather than considering yourself and your job position, consider
a one-man 'webmaster' for a small company who must run the web
server, the external web site, the internal intranet, code in
HTML and PHP, do some database work, write some javascript,
create some images, etc.
You are describing someone in an extremely responsible position.
Responsible for web site, database and network security (in relation to
external connections/access), responsible for a public face, and
consequent credibility, of the organisation, potentially responsible for
a significant revenue source, etc.
You are also describing someone who does not need to use javascript at
all, it is not compulsory.
Very few people in the real world would be an expert in all
of those areas,
And most of them will realise that they are not qualified to do that job
and so not apply for it.
or have anywhere close to enough time to study each
area in-depth.
In a responsible position, where the potential to do harm exceeds the
individuals wages, not having the skills to do the job effectively is
seriously unprofessional. And in the event of finding ones self
manoeuvred into that position without the skills it is seriously
unprofessional not to make the time to learn the required skills. But
even so, those skills do not necessarily need to include javascript at
all, as a web site can get by without it easily enough.
For many, the best hope is to keep things working
and _slowly_ advance knowledge in each of those areas.
To admit that advancing knowledge in each area is advantageous is to
question the rational of necessarily doing so slowly.
I work with lots of web developers who don't understand javascript,
are not interested in learning it and will not be reading books or
FAQs on the subject. We deal with that situation by never asking them
write javascript, but instead to use the technologies (server-side
and database) that they do know how to use.
I'd like to know more about your work environment.
It sounds very different from any that I have worked in or
worked with.
So nobody manages the use of the available resources to take best
advantage of the skills they have?
If a project needs something like a date picker, and it does not
already exist, then the task goes to a javascript programmer.
In the places I have worked or worked with, and the people I've
known, I've never yet seen someone who was simply a "javascript
programmer".
Officially I am a Java and javascript programmer, but I have not written
a single line of Java in the last year, and am unlikely to be able to do
so in the next year.
In almost every case I've witnessed, javascript has been
an 'add-on' technology that web developers are expected to
use, but that employers almost never devote any time or
training towards.
It is fairly obvious form job adverts that many organisations have
little idea of which skills, technical and otherwise, they should expect
to hire in one individual. When someone advertises for a 'web designer
with DHTML' they are asking for a graphic designer and a programmer, two
skills that would rarely be available in equal measure in the same
individual.
Again, I think your current work environment - whatever it
is - does not represent the norm for many, many developers
out there.
That may well be true, I have always programmed for software houses
(mostly working on e-commerce web sites and web applications, as I
presently am). Software houses are, however, very interested in the
efficient and cost-effective creation of reliable and easily maintained
software.
An organisation such as a web design agency may be very differently
managed, but when they find themselves in the business of writing
software maybe they should be looking at how the business of writing
software is practiced professionally.
Certainly not for those developers who aren't even _in_
a work environment.
The degree to which the attitudes and behave of individual amateur
developers may be regarded as professional is not that important.
And a javascript programmer who cannot
already write a date picker for
themselves is not going to be offered a job with us.
Good for you. You can be picky.
It is not a question of being "picky", hiring someone to white browser
scripts who cannot write browser script would be an expensive mistake.
Not every company can.
Companies cannot verify that the people they hire possess the skills
they purport to have? I think you will find that they can.
Hell, many web sites are made by _volunteers_! It could be
for their church, their local charity, their boy scout troop,
or whatever. These people may not even be programmers. If
they want some cool javascript functionality on their site,
you would probably tell them "too bad, you can't.
Would I? As I recall I have put considerable effort into demonstrating
that much of what your are calling "cool javascript functionality" can
be achieved without introducing a javascript dependency, and so without
having a negative impact on the viability of any site that uses them.
You don't know enough."
I may in practice make it evened that any given individual doesn't know
enough to handle the issues involved in using javascript on a web site,
but I tend to suggest that the answer to that problem is acquiring the
knowledge.
Whereas I would tell them, "sure, you can do that.
Download X and Y and put Z in your HTML, and it will
work."
And you use a definition of 'work' that falls short. You introduce
dependencies and penalties without properly explaining them, and then
deny their significance when others raise the issues. In short, you give
someone who might be capable of doing better the ability to do harm
without necessarily being aware that they are doing so.
Whose approach do you think _they_ prefer?
When people are doing harm, to their employer, or their employer's
clients, or their own clients, or just some organisation that they have
volunteered to 'help', then they are usually happier to be unaware that
they are doing harm (assuming some personal moral integrity).
As it happens there was a requirement to add a date picker
to the client-side code for the web application that I am
currently working on, and I was given the task of writing it.
... the task only involved writing about 150 line of date
picker specific logic (about 3k, fully formatted and commented).
That's great, if it solves your specific problem. But is it
general enough to be used by thousands of other people around
the world?
No, of course not. It is general enough to be re-used in any context
within the application that may require a date picker.
If not, then you've solved 1 problem when you could have
solved 1,000 problems with a little more work.
I solved the problem in the context of the problem. Any additional work
solving other people's problems would represent a dishonest use of my
employer's resources.
you increase the download for everyone who has no use
or interest in that facility.
The point is - who cares?
Everyone cares, to the extent that everyone wants everything to be
delivered as soon as they want it.
A few extra k doesn't matter in most cases.
I'm never convinced by theoretical savings, whether it be
reducing code from 10k to 9k, or by speeding up a code block
by 5ms. There comes a point where the "savings" do not justify
the time invested to achieve them.
A large part of the point of the code design/implementation strategy I
have been promoting is that there is no extra time involved in
implementing it. Indeed, because code re-use is maximised the time spent
actually writing code is minimised.
We have HTML bloat, we have graphic bloat and we have
script bloat. It is the script authors who are responsible
for the script bloat, and falling down in that area is not
justified by others falling down in their area.
Code bloat only matters if people care.
People care.
If you have 200k of javascript, I agree, people might actually
care. If you have a 30k lib that is cached and used repeatedly
on a site,
And as soon as you have 10 libraries providing separate functionality
you have 10 opportunities for essentially the same code to be appearing
in more than one of them.
I think you would have a hard time finding anyone who
realistically cared.
My CEO maintains that fast web applications sell better, and because he
cares all of the management cares. So, no I don't have to look far to
find someone who cares.
The convenience of using a lib with a little code bloat
is more important than the extra few k of text that is
downloaded.
Convenience? Do you imagine that it was not convenient for me
to be able to add a date picker to a system with no more than
150 lines of code? Convenience without the bloat.
a) Not everyone has the skill to develop low-level reusable
functions such as you have done.
But do the people who don't have the skill also not have the potential
to acquire that skill?
b) People such as yourself who write these functions often
refuse to document and share them.
A layered design based on low-level re-usable components is a design
pattern not a collection of specific code.
c) Therefore, people without the time or skill to write those
functions cannot use your approach.
They can once they have acquired the knowledge to do so.
If I were you - someone repeatedly advocating reusable
low-level functions being combined to achieve a larger
task - then I would certainly be documenting those
functions and making them available to other lesser-skilled
javascript developers, so that everyone could benefit from
my approach. Why don't you?
Because I understand that a code design strategy is independent of
actual code, and that the actual components are amenable to may styles
of implementation with no good reason to believe that any individual
implementation would be automatically superior to one in another style.
What developers need in order to exploit the pattern is an understanding
of the idea and some examples of individual components.
<snip> I do have my own low-level reusable components for various
tasks. Many work very well, some could use some more
tweaking. My libraries use these reusable components and
package them into usable form for developers. If they want
to break it down and write things on their own using the
low-level components, that's fine. My approach is to package
them up in usable form so they don't _need_ to do all that
work.
Which is exactly what I have been saying. As soon as you put two such
libraries together any such code they both employ is needlessly
repeated, with the problem increasing as any individual libraries are
added.
I am constantly looking for the best low-level reusable
functions to perform very specific tasks. In fact, I've
asked for assistance several times in this group in writing
some very specific, reusable low-level functions, and people
aren't really interested in the topic.
You are mistaking not being interested in the topic with not being
interested in helping you. You have to remember that everyone knows what
you are going to be doing with any information/examples you are given.
It is not surprising that people should be reluctant to aid you in
making the Internet worse that it could be.
I would think that the regulars here would _love_ to work
together to find the best way to solve specific, low-level
tasks and document them in a repository of reusable code.
You haven't noticed the Usenet archives then?
People such as yourself - who _ADVOCATE_ such a method of
development - do not share your solutions so that others
may benefit.
I put them in a public place, if you don't care to look that is your
choice.
<snip> You like to talk of "adding value", to people, to web pages,
to scripts. Does it really mean anything or is it just a
turn of phrase that just sounds positive?
It's a phrase whose meaning should be obvious.
It reads like marketing-speak and so would be assumed to have no real
meaning.
If you've added value to something, you've increased a
positive trait or reduced a negative one. The end result
is worth more, or is superior to the original state. Maybe
you increased productivity, made something more robust, made
something easier to maintain, saved
money, etc, etc.
You used added "value" in the context of someone adopting one of your
"Best Practices" without understanding what the purpose of the "Best
Practice" is, or understanding why they were adopting it. And, as I
pointed out in the paragraph that you edited from your quoted response
(without marking the edit), the change in state that represents this
added "value" would consequently be negligible. As someone working with
a technology of which they are largely ignorant has the capacity to do
enormous damage without being aware that they are doing so describing
this negligible change of state as adding "value" is like characterising
the swatting of a mosquito as adding value to the fight against malaria.
It might sound good but it really doesn't mean much.
And yet your expectation is that every web developer in
the world should devote this much time to learning it and
using it correctly. That expectation is highly absurd.
Why?
Because not everyone is like you, Richard.
Is that a hard concept to understand?
Editing out the paragraph following the question "why?" without any
indication that you have done so is seriously disingenuous. That
paragraph whent on to ask how long it took you to acquire the skills you
have, and how long you would expect to take learning skills you do not
have. You may be right in your implication and there may actually be
people who are capable of acquiring skills instantaneously, but the
majority are like me in that they will have to devote time to learning
anything new.
There is value in partially solving a problem.
It has become clear in the past that we attach very different
meanings to the words 'solving' and 'solution'. I don't believe
that there is such a thing as a "partial solution"
You don't?
No I don't. If the outcome of a problem solving process is acceptable
then it is a solution to the problem. If that acceptable outcome is not
actually a solution to the stated problem then the initial problem was
incorrectly stated/analysed.
Let's take an easy example - medicine.
Interesting choice. You have been arguing here for a tolerance of
individuals working in a professional capacity without a working
understanding of the technology they are using. How well does that
notion translate into medicine? May the general practitioner be excused
for not finding the time to gain an understanding of skin diseases, or
the surgeon for attempting brain surgery prior to gaining some expertise
in the subject? And is the pharmacist rational in his expectation to be
allowed to work as a surgeon?
The situation is more extreme because the consequences of the
harm that can be done in the field of medicine are potentially lethal,
while in web development they are mostly fiscal.
If I have an incurable disease, I sure would appreciate
having medicine to fight the side-effects, and to delay
the inevitable results of the disease. The problem of the
disease is not solved. But it has been partially solved -
I will be more comfortable, and I will live longer than
if I didn't take the medicine. I sure would appreciate
such a partial solution to the problem. :)
The "problem of the disease" is a poor analyse of the situation. The
problems may be 1. finding a cure for the decease, 2. finding a
prevention for the decease, and 3. finding a palliative for the symptoms
of the decease. Your proposal is a full solution to the problem of
finding a palliative, not a partial solution to either of the other
problems. Indeed it does not even address either of the other problems,
though a solution to either of the other problems would eventually
negate the need for a palliative.
I'm realistic. You're idealistic.
I'm practical. You're a perfectionist.
That is only a meaningful distinction if the prefect and ideal
strategy towards javascript development for a web browser
environment wasn't realistic and practical.
If you believe that your approach is perfect and ideal (or at least
closer than mine) for most people, then I think you are wrong. Sure,
it may be realistic and practical for some, but certainly not most.
IMO.
Go find a high school student who is learning web development
to make a school band web site and wants to use some javascript.
So the criteria for web development "Best Practices" are to be governed
by absolute beginners making amateur web sites?
Ask them if it's realistic and practical to invest weeks of
learning and testing to figure out how browser scripting works,
then spend weeks writing their own low-level reusable functions,
then spend time combining them to perform the specific task
they wanted to achieve on their site. Ask if that approach is
realistic and practical for them,
You have proposed someone who is "learning web development", and so time
spent learning the technologies involved will be valuable, and should be
expected to take time.
when they could have downloaded a solution with 10k of
'code bloat' and had it working in their page in less than an
hour.
You question doesn't make it clear whether it is "learning web
development" or "to make a school bad web site" that is the point of the
exercise. In the latter case you proposal may contribute to the outcome
in a way that does not require any learning of web development. If
learning something is the point of the exercise then learning to deploy
a third party library without understanding it (or the possible
consequences) is barely a contribution at all.
Ask them which approach is more realistic and practical.
<snip>
The judgement of someone who has no understanding of a subject as to
what would be practical and realistic in relation to that subject is of
little value. You would just be asking someone whether they would prefer
not to spend time learning how to go about doing something that they
want to do. It is an appeal to innate idleness in humans, and yes we
would all prefer not to have to spend time learning how to do what we
want to be able to do. However, if pressed, even you high school student
would have to admit that it is not a very realistic desire.
Richard.
Richard Cornford said the following on 10/23/2005 11:04 AM: Matt Kruse wrote (2005:10:16):
Richard Cornford wrote:
Many have no interest in learning the language or its
quirks, nor do they want to spend hours learning best
practices of FAQs.
And that is an attitude appropriate for anyone who never has
to use javascript at all. Anyone expecting the be paid for
using javascript is seriously misguided if they believe they
should not be expected to understand what they are doing.
No one can be an expert in everything.
It is not necessary to be an expert in order to understand browser
scripting.
Rather than considering yourself and your job position, consider
a one-man 'webmaster' for a small company who must run the web
server, the external web site, the internal intranet, code in
HTML and PHP, do some database work, write some javascript,
create some images, etc.
You are describing someone in an extremely responsible position.
Responsible for web site, database and network security (in relation to
external connections/access), responsible for a public face, and
consequent credibility, of the organisation, potentially responsible for
a significant revenue source, etc.
You are also describing someone who does not need to use javascript at
all, it is not compulsory.
Very few people in the real world would be an expert in all
of those areas,
And most of them will realise that they are not qualified to do that job
and so not apply for it.
Theory: Every Javascript Programmer should have at least a 99%
understanding of the language.
Reality: Less than perhaps 1% do.
Theory: Every webmaster should have a very proficient understanding of
the technologies they are using.
Reality: Very few do.
Theory: Every person who isn't qualified 100% to do a job shouldn't apply.
Reality: If that were true, 99% of the world would be unemployed.
Theory: Every webpage should be totally, 100%, accessible and degrade
gracefully.
Reality: Less than 1% do (if that many).
The Theory/Reality list can go on for pages.
You are an awesome Theorist Richard. But Theory, the Web and Reality are
a disaster in the making when you try to force Theory onto the Web and
Reality. The difference is night and day.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Richard Cornford wrote: It is not necessary to be an expert in order to understand browser
scripting.
It does require extensive learning, trial-and-error, and personal
experience. A reference document is not enough. One needs to experiment with
browsers and quirks in order to build something that is useable, in many
cases.
Rather than considering yourself and your job position, consider
a one-man 'webmaster' for a small company...
You are also describing someone who does not need to use javascript at
all, it is not compulsory.
Obviously. _Nothing_ is required. You could write plain text and not learn
HTML, too.
The point is, sometimes some more advanced functionality is desired, and not
everyone can fulfill your 'requirements' to be able to accomplish that
functionality.
Officially I am a Java and javascript programmer, but I have not
written a single line of Java in the last year, and am unlikely to be
able to do so in the next year.
I believe your position makes you _highly_ biased, and I question your
ability to identify with the needs and conditions that a more typical web
developer is faced with. You seem to be unable to grasp that not everyone is
capable of being in the position you are, either in terms of work
environment or ability to learn skills. Your solution for someone who is not
like you seems to be to become more like you. Which is highly unrealistic,
and perhaps not even desireable.
If you were an average web developer without much experience, put into a
position where you needed to develop some javascript functionality, I think
you would be like a deer in headlights. You wouldn't know what to do. Your
only recommendation would be to spend weeks or months learning the skills
required to implement things from scratch, which is a naive and completely
impractical suggestion for most.
Certainly not for those developers who aren't even _in_
a work environment.
The degree to which the attitudes and behave of individual amateur
developers may be regarded as professional is not that important.
You missed the point entirely.
Many people learn and practice web development and javascript outside of a
work environment. The idea of spending many hours learning a programming
language is not at all practical.
And as soon as you have 10 libraries providing separate functionality
you have 10 opportunities for essentially the same code to be
appearing in more than one of them.
Is that a problem? Even code you've posted yourself has code duplication,
such as multiple instances of a returnFalse() function, etc.
Having the same code appear multiple times is not ideal, but it's only bad
if it has a negative effect on performance or some other factor.
a) Not everyone has the skill to develop low-level reusable
functions such as you have done.
But do the people who don't have the skill also not have the potential
to acquire that skill?
Sometimes they don't, no.
Often employers don't have the free time to devote to properly training
people or giving them the opportunity to learn.
In cases where peoeple are volunteering their time or learning outside of
work, they may have families and other things which prevent them from
devoting the required time to learn.
And finally, some people just aren't programmers at all, and have no
interest in learning the particulars of something that they can download and
use without a big learning curve.
b) People such as yourself who write these functions often
refuse to document and share them.
A layered design based on low-level re-usable components is a design
pattern not a collection of specific code.
I realize this.
But if you have solved the problem of, for example, finding the position or
size of an object in a way that works in as many browsers as possible and as
many specific cases as possible, that code can be reused by others rather
than them writing it from scratch and discovering all the quirks which need
to be adjusted for between browsers.
c) Therefore, people without the time or skill to write those
functions cannot use your approach.
They can once they have acquired the knowledge to do so.
This prerequisite of yours has already been shown to be unrealistic and
impractical for many people.
You are mistaking not being interested in the topic with not being
interested in helping you. You have to remember that everyone knows
what you are going to be doing with any information/examples you are
given. It is not surprising that people should be reluctant to aid
you in making the Internet worse that it could be.
And you know the term used for such people? Elitist assholes. They're the
people no one likes in person and no one invites to parties. I'm sure you
understand ;)
The fact is, as I am redesigning my javascript site, I am putting in a
section for low-level solutions to specific problems. If you want to do X,
then here is a function Y which solves that very specific problem.
My libraries will of course make use of the low-level functionality, but the
goal is to have those available separately also, so that if someone wants to
find just a specific piece of functionality which they can include in their
work, it is there. Since some functionality can be difficult to develop for
in a browser-neutral way, such low-level functions are best developed with
the advice and suggestions of several people, IMO. A single author can
rarely accomplish the same level of detail and thorougness that several can. I would think that the regulars here would _love_ to work
together to find the best way to solve specific, low-level
tasks and document them in a repository of reusable code.
You haven't noticed the Usenet archives then?
You think that usenet archives are a better repository than a single web
site with contents that reflect the concensus of a number of expert
developers? You like to talk of "adding value"... It reads like marketing-speak and so would be assumed to have no real
meaning.
Like most of the novels you write in this group ;)
Go find a high school student who is learning web development
to make a school band web site and wants to use some javascript.
So the criteria for web development "Best Practices" are to be
governed by absolute beginners making amateur web sites?
Perhaps.
Expert developers rarely need to consult 'best practices' documents.
--
Matt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com
Randy Webb wrote: You are an awesome Theorist Richard. But Theory, the Web and Reality
are a disaster in the making when you try to force Theory onto the
Web and Reality. The difference is night and day.
Yeah. What he said, much better than I ever do ;)
Theory is great. But it doesn't necessarily do any good in many real-world,
every-day problems.
I think theory is interesting (and great for more advanced developers), but
I much prefer to deal in reality. It doesn't matter if you think people
OUGHT to spend hours learning javascript and write code from scratch using
their own reusable low-level functions.
IT AINT GONNA HAPPEN!
You can either shield your eyes from this reality and continue with the same
old mantra which doesn't actually help anyone, or you can accept the reality
and develop solutions, guides, suggestions, and libraries which help people
in real-world situations.
I'm not saying I take the absolute best approach possible. My code needs
improvements (many of which I've already developed, but documenting things,
creating a web site with examples, and supporting them is extremely
time-consuming), but I do believe that I'm doing more of a service to the
web community than Mr. Cornford, Mr. Stockton, et al, who continue to
complain about my approach, and also refuse to make any real constructive
criticisms of my code. They can talk theory all they want, but in reality
I'm not sure they really help many people. *shrug*
--
Matt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com
Michael Winter wrote: This might also be a good time to follow on and dispel the idea about
hash 'arrays'.
It's going to be more difficult than this spring because besides
Microsoft
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/jsobjdictionary.asp>
I now got the Mozilla Foundation support:
<http://www.mozilla.org/projects/xpcom/hashtable-guide.html>
Good luck though, my pen is still ready ;-)
frames and form elements addressing
Academically very right, but supposed to deal with some abstract ideal
browser implementation. As there is no such, should we mention
particular issues of earthy rivals (IE & FF at least).
<http://www.geocities.com/schools_ring/ArrayAndHash.html#HTMLCollection>
has some inspirational cases linked.
eval() is evil
But runtime code generation can be very effective (or even the only
option). Should we mention new Function(args, body) method as a legal
alternative to eval() ?
"VK" <sc**********@yahoo.com> writes: Michael Winter wrote:
This might also be a good time to follow on and dispel the idea about
hash 'arrays'.
It's going to be more difficult than this spring because besides
Microsoft
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/jsobjdictionary.asp>
.... which show an example of a dictionary, which is a mapping from keys
to values, and not a Javascript array ...
I now got the Mozilla Foundation support:
<http://www.mozilla.org/projects/xpcom/hashtable-guide.html>
.... which show an implementation of a hashtable, and states that it is
different from an array (and how it is different).
But runtime code generation can be very effective (or even the only
option). Should we mention new Function(args, body) method as a legal
alternative to eval() ?
No, that's evil too :)
Runtime code generation is rarely, if ever, needed. In the few, highly
specialized, cases where it is, it will hopefully be an experienced
developer who is doing it. Working with code as stings is extremely
unsafe and should be avoided if at all possible.
I have still to see a case of runtime code generation where it's not a
testing utility that executes user entered Javascript (which isn't really
generating) or a re-implementation of a newer feature for older browsers
(like apply). Modern browsers don't need code generation.
/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
> Detecting Browser Versions
.... and related scripts.
I think that really best practice for object/method detection should be
the usage of "in" operator. It's nice that JavaScript converts
undefined and null into boolean false for us, but it seems a bit durty
and may hurt you when moving on strictly typed languages.
So instead of
if ( (someObject) && (someObject.someMethod) )
we should use:
if ( (someObject in objectContainer) && (someMethod in someObject) )
As objectContainer nearly always is window, the most common case would
be:
if ( (someObject in self) && (someMethod in someObject) )
// using "self" reference to the *current* window is more reliable
// than simply "window" because "window" may be contectually
// ambiguous in some very rare but possible cases.
VK said the following on 10/26/2005 2:42 PM: Detecting Browser Versions
.... and related scripts.
I think that really best practice for object/method detection should be
the usage of "in" operator. It's nice that JavaScript converts
undefined and null into boolean false for us, but it seems a bit durty
and may hurt you when moving on strictly typed languages.
So instead of
if ( (someObject) && (someObject.someMethod) )
we should use:
if ( (someObject in objectContainer) && (someMethod in someObject) )
Test case where it is better? It would seem to be slower but may not be.
As objectContainer nearly always is window, the most common case would
be:
if ( (someObject in self) && (someMethod in someObject) )
// using "self" reference to the *current* window is more reliable
// than simply "window" because "window" may be contectually
// ambiguous in some very rare but possible cases.
How is using self to point to the window object less error prone than
using window? Without giving it a lot of though, window.property would
seem to be less error-prone than self.property for no other reason than
scope issues.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
On 26/10/2005 19:42, VK wrote:
[snip] I think that really best practice for object/method detection should
be the usage of "in" operator.
Why? That will throw a syntax exception in several browsers.
It's nice that JavaScript converts undefined and null into boolean
false for us,
Yes, it is. If you don't like that, then use the typeof operator. Just
be aware that IE considers host object methods as objects, not functions.
but it seems a bit durty and may hurt you when moving on strictly
typed languages.
What on Earth does that have to do with /anything/?
[snip]
Mike
--
Michael Winter
Prefix subject with [News] before replying by e-mail.
VK wrote: Detecting Browser Versions
... and related scripts.
I think that really best practice for object/method detection should be
the usage of "in" operator.
Why should a not far enough downwards compatible feature be considered
"best practice"? typeof ... != "undefined" is sufficient in most cases
and downwards compatible to JavaScript 1.1, JScript 1, ECMAScript 1.
If really an ECMAScript 3 compliant approach would be taken, it would not be
the "in" operator but the hasProperty() method which can much more easily
be tested for than the former. Besides, "in" would seldom suffice as
before calling a method you would need to make sure that it *is* a method
and not a non-function property.
Your assumption that `window' "nearly always" refers to the Global Object
is wrong, by the way. There is a low probability that it does not within
a HTML document context, but JS can be used in other contexts. And `self'
is merely a property of `window', if existent, not of the Global Object;
using it (untested) is only making bad things worse.
PointedEars
Thomas 'PointedEars' Lahn wrote: VK wrote:
Detecting Browser Versions ... and related scripts.
I think that really best practice for object/method detection should be
the usage of "in" operator.
Why should a not far enough downwards compatible feature be considered
"best practice"?
By "not far enough" you mean NN 2.x - NN 4.x ? IE supports it since
3.02
If some other browser still doesn't have it implemented properly, the
primary task would be to see such browser disappeared from the human
memory as quick as possible, rather than support it an any way.
The most important is that if (someObject) method fails easily in too
many curcumstances appeared after prototypes and constructors
introduction. Check this sample:
<html>
<head>
<title>Testcase</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
<script type="text/javascript">
function test() {
self.abort = undefined;
// Bad practice
// if (someObject.someMethod){...) method
// fails on prototype change
if (abort) {
alert('I still know it was originally here');
}
else {
alert('Oops, I\'ve been easily cheated');
}
// Good practice:
// if (someObject in objectContainer) {...} method
// works reliably on prototype change
// As one cannot use delete() on default property,
// you cannot be mislead in any situation
if('abort' in self) {
alert('Do not try to cheat me!');
}
else {
alert('Oops, I\'ve been cheated too');
}
}
alert(self.hasProperty)
</script>
</head>
<body bgcolor="#FFFFFF">
<form method="post" action="">
<input type="button" name="Button01" value="Test" onclick="test()">
</form>
</body>
</html>
If really an ECMAScript 3 compliant approach would be taken, it would not be
the "in" operator but the hasProperty() method which can much more easily
be tested for than the former.
Where did you get method? You mean HasProperty moniker from .Net
framework? It has no relation with the discussion.
Besides, "in" would seldom suffice as
before calling a method you would need to make sure that it *is* a method
and not a non-function property.
Why in the name you need to check the type of property in question?
What can it prove? Even if it's indeed a method (so it's typeof
"function"), what proof do you have that this is *that* method and not
some bogus? And even if it's indeed *that* method, what proof do you
have that it was implemented as documented? You can only protect
yourselve from initial "Object expected error" by doing
if ( (neededObject in self) && (neededStuff in neededObject) ) {...}
The rest remains in the hands of the Lord and browser makers.
Your assumption that `window' "nearly always" refers to the Global Object
is wrong, by the way. There is a low probability that it does not within
a HTML document context, but JS can be used in other contexts. And `self'
is merely a property of `window', if existent, not of the Global Object;
using it (untested) is only making bad things worse.
"self" has the only context to be. Unless you've created a "self"
variable and did your whole script dizzy:
....
self = something;
// var self = something ?
// window.self = something ?
....
As "self" is one of so-called "tasty words" for identifiers, I see this
happens here and there and should be each time pointed.
Thomas 'PointedEars' Lahn wrote: VK wrote:
Detecting Browser Versions ... and related scripts.
I think that really best practice for object/method detection should be
the usage of "in" operator.
Why should a not far enough downwards compatible feature be considered
"best practice"?
By "not far enough" you mean NN 2.x - NN 4.x ? IE supports it since
3.02
If some other browser still doesn't have it implemented properly, the
primary task would be to see such browser disappeared from the human
memory as quick as possible, rather than support it an any way.
The most important is that if (someObject) method fails easily in too
many curcumstances appeared after prototypes and constructors
introduction. Check this sample:
<html>
<head>
<title>Testcase</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
<script type="text/javascript">
function test() {
self.abort = undefined;
// Bad practice
// if (someObject.someMethod){...) method
// fails on prototype change
if (abort) {
alert('I still know it was originally here');
}
else {
alert('Oops, I\'ve been easily cheated');
}
// Good practice:
// if (someObject in objectContainer) {...} method
// works reliably on prototype change
// As one cannot use delete() on default property,
// you cannot be mislead in any situation
if('abort' in self) {
alert('Do not try to cheat me!');
}
else {
alert('Oops, I\'ve been cheated too');
}
}
alert(self.hasProperty)
</script>
</head>
<body bgcolor="#FFFFFF">
<form method="post" action="">
<input type="button" name="Button01" value="Test" onclick="test()">
</form>
</body>
</html>
If really an ECMAScript 3 compliant approach would be taken, it would not be
the "in" operator but the hasProperty() method which can much more easily
be tested for than the former.
Where did you get method? You mean HasProperty moniker from .Net
framework? It has no relation with the discussion.
Besides, "in" would seldom suffice as
before calling a method you would need to make sure that it *is* a method
and not a non-function property.
Why in the name you need to check the type of property in question?
What can it prove? Even if it's indeed a method (so it's typeof
"function"), what proof do you have that this is *that* method and not
some bogus? And even if it's indeed *that* method, what proof do you
have that it was implemented as documented? You can only protect
yourselve from initial "Object expected error" by doing
if ( (neededObject in self) && (neededStuff in neededObject) ) {...}
The rest remains in the hands of the Lord and browser makers.
Your assumption that `window' "nearly always" refers to the Global Object
is wrong, by the way. There is a low probability that it does not within
a HTML document context, but JS can be used in other contexts. And `self'
is merely a property of `window', if existent, not of the Global Object;
using it (untested) is only making bad things worse.
"self" has the only context to be. Unless you've created a "self"
variable and did your whole script dizzy:
....
self = something;
// var self = something ?
// window.self = something ?
....
As "self" is one of so-called "tasty words" for identifiers, I see this
happens here and there and should be each time pointed.
.... I hate groups.google
Sorry for double posting
VK wrote: Thomas 'PointedEars' Lahn wrote: VK wrote: >> Detecting Browser Versions
> ... and related scripts.
>
> I think that really best practice for object/method detection should be
> the usage of "in" operator.
Why should a not far enough downwards compatible feature be considered
"best practice"?
By "not far enough" you mean NN 2.x - NN 4.x ?
Not only, but they are included. At least NN 4.x definitely is.
IE supports it since 3.02
So? IE is probably the widest distributed, but not the only user agent
around. And the `in' operator has AFAIS not been specified in ECMAScript
before Edition 3.
If some other browser still doesn't have it implemented properly, the
primary task would be to see such browser disappeared from the human
memory as quick as possible, rather than support it an any way.
Let's just say your perception of reality appears to me to be somewhat
strange.
The most important is that if (someObject) method fails easily in too
many curcumstances appeared after prototypes and constructors
introduction.
Nobody unconditionally recommended `if (someObject)', instead you
used it as vessel for your "argumentation". You are confused, yes?
Check this
(... not Valid ...)
sample:
<html>
<head>
<title>Testcase</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
<script type="text/javascript">
function test() {
self.abort = undefined;
So you had to construct a less-than-probable case to prove
your otherwise unfounded assumption. You made my day.
// Good practice:
No, it is not. The "in" operator is certainly a viable approach, but since
it lacks wide support, it cannot be considered best practice or even good
practice. But then you have seldom, if ever, bothered with such details.
Your experience in JS programming is still (despite several attempts of
explanation by experts to you) questionable at best. Since this is not
the first time, I strongly advise you read more before you post further
such bold statements here.
alert(self.hasProperty)
Your point being?
If really an ECMAScript 3 compliant approach would be taken, it would not
be the "in" operator but the hasProperty() method which can much more
easily be tested for than the former.
Where did you get method? You mean HasProperty moniker from .Net
framework? It has no relation with the discussion.
No, I mean(t) Object.prototype.hasOwnProperty() as specified in
ECMAScript 3 and implemented in JavaScript 1.5+, JScript 5.6+.
Since I seldom have to use it, I remembered the identifier wrong.
Besides, "in" would seldom suffice as
before calling a method you would need to make sure that it *is* a method
and not a non-function property.
Why in the name you need to check the type of property in question?
Because that is the most viable approach to check it exists in the
sense that it refers to useful value.
What can it prove?
It can prove that it is not undefined, i.e. that it was not defined or
assigned undefined. It also can prove that the call operator may be
applied to it (see below).
Even if it's indeed a method (so it's typeof "function"),
.... or typeof ... == "object", for IE's DOM objects
what proof do you have that this is *that* method and not
some bogus?
I don't have. However, it has proven to be a viable approach to expect
methods that are named as documented to do what is documented, with only
a few exceptions in the implementation of the W3C DOM in IE.
I know when I mess with those methods in my included scripts and I know
who to blame then if it does not work. And since JS's object model is
dynamic, if either the UA's vendor or the user decide to cripple its
client-side script support or DOM, there is nothing a JS developer can
do about it. As JS/ECMAScript developer you always have to cope with the
host environment it runs in. So I simply don't need to bother with it.
For example if a property called `document.getElementsByTagName' exists
and it is a method, I have to assume that it can be called and returns
either `null', a HTMLCollection or not a HTMLCollection. Of course I
have to check its return value in some way before referring to it.
And even if it's indeed *that* method, what proof do you
have that it was implemented as documented? You can only protect
yourselve from initial "Object expected error" by doing
if ( (neededObject in self) && (neededStuff in neededObject) ) {...}
Rubbish. There cannot be such an error produced (and it can only in IE)
unless the call operator is applied to a non-undefined property or the
object model the host environment is completely broken. However, I
consider implementations that return something other than "function" or
"object" for a method to be badly broken, and so I do not support them.
The rest remains in the hands of the Lord and browser makers.
No, there are certain standards specified to adhere to, and UA vendors
state in the documentation what standards they support. Most of the time,
those statements have proven to be correct.
Your assumption that `window' "nearly always" refers to the Global Object
is wrong, by the way. There is a low probability that it does not within
a HTML document context, but JS can be used in other contexts. And
`self' is merely a property of `window', if existent, not of the Global
Object; using it (untested) is only making bad things worse.
"self" has the only context to be.
You are talking nonsense. `self' has been and it is still a property of
Window objects, not by definition of the Global Object. Get yourself
informed, please.
Unless you've created a "self" variable and did your whole script dizzy:
self = something;
// var self = something ?
// window.self = something ?
...
That proves or disproves which one of my arguments? Again you are virtually
*constructing* something to try and fail to prove one of your arguments.
As "self" is one of so-called "tasty words" for identifiers, I see this
happens here and there and should be each time pointed.
Pardon? You are the one who suggested using `self' in the first place.
Unfortunately, I more and more get the impression that you do not really
know what you are talking about nor, more important, do you have any idea
what you are argueing against/for. Maybe a pillowful of decent sleep will
help you. Goodnight.
PointedEars
Thomas 'PointedEars' Lahn wrote: VK wrote: And even if it's indeed *that* method, what proof do you
have that it was implemented as documented? You can only protect
yourselve from initial "Object expected error" by doing
if ( (neededObject in self) && (neededStuff in neededObject) ) {...}
Rubbish. There cannot be such an error produced (and it can only in IE)
unless the call operator is applied to a non-undefined property [...]
It should read "unless ... to an undefined property", of course.
>> VK wrote: self.abort = undefined;
Thomas 'PointedEars' Lahn wrote: So you had to construct a less-than-probable case
to prove your otherwise unfounded assumption.
You made my day.
And to make your evening also take a look at the title of this thread.
If say method X works in 98% of cases and method Y works in 99% of
cases then given all other issues being equal (simplicity, code
readability etc.), then method Y is a better practice.
In the "IN vs. UNDEFINED" case I don't see "other issues" equal
neither. They are definitely benifiting to "IN":
[1]
if ('someProperty' in someObject) {...}
follows the human language structure so it's easy to understand and
remember even for a non-experienced programmer: "if [there is]
someProperty in someObject". It's not a requirement of cource in the
programming languages but it's a suggested part of the common
programming culture.
[2]
if ('someProperty' in someObject) {...}
contains only one operation (hash LOOKUP)
while
if (someObject.someProperty) {...} has two operations:
1) resolve someObject.someProperty (hash LOOKUP)
2) do background casting to false/true
so the same for
if (typeof(someObject) == 'function')
1) get someObject typeof
2) compare with string
On double check
if ('someProperty1' in someObject) && ('someProperty2' in
someProperty1) {...}
we save on two unnecessary operation avoided.
The "in" operator is certainly a viable approach, but since
it lacks wide support,...
Do not get redicilous now. You mean that 99's ECMA lacks wide support?
Something like: "Behold: Pan 0.13.0 - The Whole Remains Beautiful just
failed to execute my script" ?
As we are talking about cross-platform scripting here then terms like
"some browsers" should be sctrictly avoided in the discussion.
Otherwise it's just a hidden way to say "I simply don't like it/you".
There are not "some browsers". There is IE 3.x - 7.x, Netscape 2.x -
8.x, Firefox 1.0.x, Pan 0.x and so on and so on. You think that a
particular method will fail in some environment? So tell us where
exactly including brends and major/minor versions. In many cases the
issue will desappear by itself just because you'll not be willing to
get funny on public by showing *what* browser you're hiding you
personal preferences behind of.
I mean(t) Object.prototype.hasOwnProperty() as specified in
ECMAScript 3 and implemented in JavaScript 1.5+, JScript 5.6+.
Since I seldom have to use it, I remembered the identifier wrong.
hasOwnProperty() method deals with script objects *only* and it doesn't
work for DOM interface check, which we are discussing now (try
hasOwnProperty on window). IN method covers both cases.
But I'm still glad to see that despite some luck of experience you're
showing more theoretical knowledge as it was demonstrated before. KOK
(Kick On Kick)
VK wrote:
[Please learn how to quote, see the FAQ. Quotation levels corrected here.] Thomas 'PointedEars' Lahn wrote: VK wrote:
self.abort = undefined;
So you had to construct a less-than-probable case
to prove your otherwise unfounded assumption.
You made my day.
And to make your evening also take a look at the title of this thread.
Ahh, yes. Quite bold of you to give it v1.0; it's more like v0.1.
If say method X works in 98% of cases and method Y works in 99% of
cases then given all other issues being equal (simplicity, code
readability etc.), then method Y is a better practice.
Which exactly is why "in" is not.
In the "IN vs. UNDEFINED" case I don't see "other issues" equal
neither. They are definitely benifiting to "IN":
^^^^^^^^^^
(May I say that even as a person with English as foreign language myself
I am quite astonished by the overall "style" of your pos(t)ings?)
[1]
if ('someProperty' in someObject) {...}
follows the human language structure so it's easy to understand [...]
You are completely missing the point again. This feature of the operand
identifier was not debated. What was debated and is still debatable was
the extend of the support of the operand as a feature of the programming
language implementation(s).
[2]
if ('someProperty' in someObject) {...}
contains only one operation (hash LOOKUP)
No, if you had bothered to read ECMAScript 3 (as suggested to you
several times before), section 11.8.7., you would have known that
the "in" operation requires 8 steps total. If all subalgorithms
are considered, it takes even more steps:
| The production
|
| RelationalExpression :
| RelationalExpression in ShiftExpression
|
| is evaluated as follows:
|
| 1. Evaluate RelationalExpression.
| RelationalExpression :
| ShiftExpression
| RelationalExpression < ShiftExpression
| RelationalExpression > ShiftExpression
| RelationalExpression <= ShiftExpression
| RelationalExpression >= ShiftExpression
| RelationalExpression instanceof ShiftExpression
| RelationalExpression in ShiftExpression
|
| (I save you the details of that here, read for yourself)
|
| 2. Call GetValue(Result(1)).
| 1. If Type(V) is not Reference, return V.
| 2. Call GetBase(V).
| GetBase(V). Returns the base object component of the reference
| V.
| 3. If Result(2) is null, throw a ReferenceError exception.
| 4. Call the [[Get]] method of Result(2), passing GetPropertyName(V)
| for the property name.
| GetPropertyName(V). Returns the property name component of the
| reference V.
| 5. Return Result(4).
|
| 3. Evaluate ShiftExpression.
|
| ShiftExpression :
| AdditiveExpression
| ShiftExpression << AdditiveExpression
| ShiftExpression >> AdditiveExpression
| ShiftExpression >>> AdditiveExpression
|
| (again, no more details here)
|
| 4. Call GetValue(Result(3)).
| 1. If Type(V) is not Reference, return V.
| 2. Call GetBase(V).
| 3. If Result(2) is null, throw a ReferenceError exception.
| 4. Call the [[Get]] method of Result(2), passing GetPropertyName(V)
| for the property name.
| 5. Return Result(4).
|
| 5. If Result(4) is not an object, throw a TypeError exception.
| 6. Call ToString(Result(2)).
See section "9.8 ToString" for details.
|
| 7. Call the [[HasProperty]] method of Result(4) with parameter Result(6).
| 8. Return Result(7)
while
if (someObject.someProperty) {...} has two operations:
1) resolve someObject.someProperty (hash LOOKUP)
2) do background casting to false/true
Actually, it's
| 1. Evaluate MemberExpression.
| 2. Call GetValue(Result(1)).
| 3. Evaluate Expression.
| 4. Call GetValue(Result(3)).
| 5. Call ToObject(Result(2)).
See section "9.9 ToObject" for details.
| 6. Call ToString(Result(4)).
See section "9.8 ToString" for details.
| 7. Return a value of type Reference whose base object
| is Result(5) and whose property name is Result(6).
and then type-cast the return value to Boolean.
so the same for
if (typeof(someObject) == 'function')
typeof is an operator, not a function. The parentheses are unnecessary.
1) get someObject typeof
2) compare with string
That's actually
| 1. Evaluate UnaryExpression.
| 2. If Type(Result(1)) is not Reference, go to step 4.
| 3. If GetBase(Result(1)) is null, return "undefined".
| 4. Call GetValue(Result(1)).
| 5. Return a string determined by Type(Result(4)) according to the
| following table: [see "11.4.3 The typeof Operator" for more]
and then compare the return value with the string value.
On double check
if ('someProperty1' in someObject) && ('someProperty2' in
someProperty1) {...}
we save on two unnecessary operation avoided.
See above. What looks simple in the source code is not at all simple
or efficient in the implementation. This could be considered rule of
thumb since complexity does not simply vanish because of convenience.
BTW: You do know that the former throws a TypeError exception if
`someObject' does not refer to an object, too?
The "in" operator is certainly a viable approach, but since
it lacks wide support,...
Do not get redicilous now.
^^^^^^^^^^
What?
You mean that 99's ECMA lacks wide support?
The specification is called ECMAScript or ECMA-262. ECMA is the
standardization body that publishes it. ECMAScript Edition 3 Final
is dated March 24, 2000.
Most features of ECMAScript 3 are implemented as (and extended by)
JScript 5.6 (IE 6), JavaScript 1.5 (Mozilla/5.0) and by the scripting
engine of newer Opera versions.
As we are talking about cross-platform scripting here then terms like
"some browsers" should be sctrictly avoided in the discussion.
Pardon? "some browsers" and interoperability is the whole point of
cross-platform scripting!
Otherwise it's just a hidden way to say "I simply don't like it/you".
You are talking nonsense again. More important, you are fighting your
own argument. If "I simply don't like you" is not what you want, then
insisting on having a not supported feature to be called best practice
is a step towards the wrong direction by 180°.
There are not "some browsers".
There are.
There is IE 3.x - 7.x, Netscape 2.x - 8.x, Firefox 1.0.x, Pan 0.x and
so on and so on.
Obviously you gave last part not enough thought.
You think that a particular method will fail in some environment?
I *know* that it will fail in some environments just because environments
are different. The probability that "in" will fail is higher than the
probability that "typeof" will fail, just because the former came last.
So tell us
That's cute of you talking the "we" although replies indicated that
your humble opinion is definitely not shared by everyone interested.
where exactly including brends and major/minor versions.
I fail to catch the meaning of this sentence. Probably you mean I have to
prove something here. Well, I don't. I did anyway on occasion here in the
hope you might learn from that.
In many cases the issue will desappear by itself just because you'll not
be willing to get funny on public by showing *what* browser you're hiding
you personal preferences behind of.
You express yourselves to the degree you appear to be able to understand the
matters discussed here.
I mean(t) Object.prototype.hasOwnProperty() as specified in
ECMAScript 3 and implemented in JavaScript 1.5+, JScript 5.6+.
Since I seldom have to use it, I remembered the identifier wrong.
hasOwnProperty() method deals with script objects *only*
What exactly are you calling a "script object"?
and it doesn't work for DOM interface check,
That depends on what DOM we are talking about.
which we are discussing now
Ohh, thank you very much for telling me what we were *really* discussing.
IYVHO.
(try hasOwnProperty on window).
this.hasOwnProperty('window') in global context yields `true' here
[Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922
Firefox/1.0.7 (Debian package 1.0.7-1) Mnenhy/0.7.2.0].
Since `window' is a property of the Global Object in almost all
HTML DOMs including the Gecko DOM, that result is correct.
The same goes for window.hasOwnProperty("document").
It does not for document.hasOwnProperty("images") and other
HTMLCollections.
IN method covers both cases.
It does, but you are still missing the point.
PointedEars
On 26/10/2005 22:33, VK wrote:
[The in operator] IE supports it since 3.02
That's odd. IE5.0 errors out, here. Just me?
[snip]
Mike
--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Michael Winter wrote: On 26/10/2005 22:33, VK wrote:
[The in operator] IE supports it since 3.02
That's odd. IE5.0 errors out, here. Just me?
Dunno, I have no IE here. Either that or the MSDN Library is
again not as correct as it should be (nothing new, though.)
PointedEars
Thomas 'PointedEars' Lahn said the following on 10/27/2005 3:12 PM: VK wrote:
[Please learn how to quote, see the FAQ. Quotation levels corrected here.]
Thomas 'PointedEars' Lahn wrote:
VK wrote:
self.abort = undefined;
So you had to construct a less-than-probable case
to prove your otherwise unfounded assumption.
You made my day.
And to make your evening also take a look at the title of this thread.
Ahh, yes. Quite bold of you to give it v1.0; it's more like v0.1.
Perhaps you should go back and look at who started this thread, who
created that document, and gave it a version number. It was *not* VK
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Matt Kruse wrote: Richard Cornford wrote: It is not necessary to be an expert in order to understand
browser scripting.
It does require extensive learning, trial-and-error, and
personal experience. A reference document is not enough.
One needs to experiment with browsers and quirks in order
to build something that is useable, in many cases.
And a similar statement can be made about any other learnt skill.
Rather than considering yourself and your job position,
consider a one-man 'webmaster' for a small company...
You are also describing someone who does not need to
use javascript at all, it is not compulsory.
Obviously. _Nothing_ is required. You could write plain
text and not learn HTML, too.
Yes, the skills you are willing to acquire should be expected to limit
what you can achieve.
The point is, sometimes some more advanced functionality is
desired, and not everyone can fulfill your 'requirements'
to be able to accomplish that functionality.
Why should a desire to do something excuse the consequences of someone
who only knows enough to do it badly doing so anyway? A desire to be a
surgeon will never be enough on its own to justify having a go at it,
and a desire to use javascript will not be enough on its own to avoid
attempting to use it from doing harm.
Officially I am a Java and javascript programmer, but I have not
written a single line of Java in the last year, and am unlikely to be
able to do so in the next year.
I believe your position makes you _highly_ biased, and I
question your ability to identify with the needs and
conditions that a more typical web developer is faced with.
You seem to be unable to grasp that not everyone is capable
of being in the position you are, either in terms
of work environment or ability to learn skills.
I don't expect everyone to be capable of being in the piston I am in,
and I don't expect the vast majority of everyone particularly wants to.
But I do believe that anyone capable of effectively functioning as a web
developer is capable of learning everything that I have learnt (and much
that I haven't) in exchange for trying.
I can see your belief that the average web developer is an intellectual
jelly would suggest otherwise.
Your solution for someone who is not like you seems to be
to become more like you.
My "solution"? Solution to what exactly? If someone expresses a desire
to understand javascript I am likely to propose that they learn
javascript. It is not really a solution, as it is really too obvious.
Which is highly unrealistic, and perhaps not even desireable.
If you were an average web developer
I am an average web developer.
without much experience,
And as I am older than the web there inevitably was a time when I had no
experience of it.
put into a position where you needed to develop some
javascript functionality,
How exactly do you imagine that I started writing javascript?
I think you would be like a deer in headlights.
You wouldn't know what to do.
Throughout my time programming there has been a continuous sequence of
new challenges. My experience is that the best way of handling these has
been to put some effort into understanding the pertinent subject, which
is why I will continue to recommend that strategy to others.
Your only recommendation would be to spend weeks or months
learning the skills required to implement things from
scratch, which is a naive and completely impractical suggestion
for most.
So your would imagine that I learnt JSP by writing a Java Application
server?
Certainly not for those developers who aren't even _in_
a work environment.
The degree to which the attitudes and behave of individual amateur
developers may be regarded as professional is not that important.
You missed the point entirely.
Many people learn and practice web development and javascript
outside of a work environment.
And if they never clam to be capable of being professional web
developers it doesn't really matter (and isn't particularly surprising)
if they are not very good at. They are also not going to be in a
position to allow their lack of skills to do harm to others.
The idea of spending many hours learning a
programming language is not at all practical.
Was that the "point" I missed? If the idea of spending many hours
learning a programming language is not practical then the fact that it
takes many hours learning any programming language would man that there
are no programmers.
<snip> a) Not everyone has the skill to develop low-level reusable
functions such as you have done.
But do the people who don't have the skill also not have the
potential to acquire that skill?
Sometimes they don't, no.
This would be your "average web developer" again?
<snip> b) People such as yourself who write these functions often
refuse to document and share them.
A layered design based on low-level re-usable components is
a design pattern not a collection of specific code.
I realize this.
But if you have solved the problem of, for example, finding
the position or size of an object in a way that works in
as many browsers as possible and as many specific cases as
possible, ...
A large part of the point of the exercise is not to address as many
specific cases as possible, but instead to only implement the component
versions for the specific cases actually encountered, as and when the
are encountered. Avoiding writing specific code until it is needed, and
still creating easily re-useable code, is one of the characteristics
that makes the strategy efficient.
<snip> c) Therefore, people without the time or skill to write
those functions cannot use your approach.
They can once they have acquired the knowledge to do so.
This prerequisite of yours has already been shown to be
unrealistic and impractical for many people.
I don't know about 'shown', we only have your word for it that the
average web developer is intellectually incapable. You are mistaking not being interested in the topic with
not being interested in helping you. You have to remember
that everyone knows what you are going to be doing with any
information/examples you are given. It is not surprising that
people should be reluctant to aid you in making the Internet
worse that it could be.
And you know the term used for such people? Elitist assholes.
<snip>
It is ironic that you should describe others as "Elitist assholes" when
your characterisation of "the average web developer" as incapable of
achieving even your level of understanding of the subject carries the
implication that you consider yourself their innate superior.
On the other hand, your attitude toward the "average web developer" may
explain why you have never yet posted a single technical explanation of
anything to this group.
Richard.
VK wrote: Detecting Browser Versions ... and related scripts.
I think that really best practice for object/method detection
should be the usage of "in" operator.
The applicable 'Best Practice' is to perform feature detection tests to
verify support for and behaviour of, features of the environment (and
suspect features of the language) prior to using them. The nature of
those tests should not be considered subject to any arbitrary rules. A
test is intended to provide a discriminating answer to a question. So
you start choosing a test by deciding what it is you want to know, and
having done that you determine which formulations of code will provide a
discriminating answer. And only in the event that there is more than one
possible test formulation do you need to even start considering which
formulation is the best to use in the applicable context.
The - in - operator has the significant problem that - in - is a late
addition to the language and produces a syntax error when not supported.
Syntax errors may result in an error dialog being shown to the user (the
biggest indicator of author incompetence possible) and they cannot be
recovered from, so they preclude controlled paths of failure. And
language features that cause syntax errors when not supported are among
the most difficult aspects of the language to apply reliable feature
detection test to.
It's nice that JavaScript converts undefined and null
into boolean false for us, but it seems a bit durty
and may hurt you when moving on strictly typed languages.
Loosely typed languages are very much in the minority, so it is much
more likely that someone would come to javascript with preconceptions
acquired from a strongly typed language rather then the other way
around. However, using a loosely typed language demands a appreciation
of the way in which type-conversion happens and hiding form
type-conversion would just be seriously tying your own hands and require
a much better justification than some vague perception of disapproval.
Knowing that an object has a property is not the same as knowing that
the value of that property type-converts to true, and knowing that the
value type-converts to true is not the same as knowing which string that
value does (or does not) produce when the - typeof - operator is applied
to it. First decide what it is that you need to know, and then decide
which text will best tell you the answer.
So instead of
if ( (someObject) && (someObject.someMethod) )
The implication of this test is that "someObject" is an existing
property name of an object on the current scope chain, that its value
type-converts to true (is an Object of some sort, or boolean true, a
non-empty string or a non-zero and non-NaN number). If the first
expression does type-convert to true then the second expression is safe,
as any of the 'true' primitive values will be type-converted to their
corresponding object (Boolean, String or Number objects) and none of
those objects has a 'someMethod' property[1], so the second expression
will evaluate to false. Only if the first expression actually is an
Object (of some sort) could the second expression evaluate to true. So
you know that - someObject - is an Object reference and that its -
someMehtod - property type-converts to true.
The only possible exception-throwing condition is when 'someObject' is
not an existing named property of some object on the scope chain. Once
that is know to be the case the following code will not error-out under
any circumstances.
[1] This assumes that the prototypes of Boolean, String and Number have
not been augmented with a 'someMethod' property, but that should be a
known condition in the environment as the script author is the one who
would be augmenting their prototypes.
we should use:
if ( (someObject in objectContainer) && (someMethod in someObject) )
Correcting the above to the much more rational:-
if ( ('someObject' in objectContainer) &&
('someMethod' in objectContainer.someObject) )
This also starts with the assumption that 'objectContainer' is a named
property of an object on the scope chain, which can never be true of a
reference to the Activation/Variable object itself. It also assumes that
that property is a reference to an object (as the ShiftExpression is not
subject to type-conversion), all primitive values will cause exceptions
to be thrown. The first - in - expression is true whenever the -
objectContainer - object (or any object on its prototype chain) has a
property with the name represented by the type-converted to string,
value of - 'someObject' -. The actual value of that property is not
tested and so could be a non-Object value, which would cause the
second - in - expression to throw an exception when evaluated.
So, you have precluded the possibility of testing local variables, and
the passing of the first - in - expression does not guarantee that the
second will successfully execute. While the restriction form the
type-converting test, that the first unqualified Identifier, refer to an
existing named property of an object on the scope chain, applies just as
much to this test.
But if this test is necessary it should be a test that will not
error-out. And so not only is the - in - test dubious because of
language support, it is dubious because it is pretty much necessarily to
be certain of values of the properties prior to verifying that they
exist, which is a bit of a contradiction. But otherwise you have no
guarantee that execution will even get to the end of test, let alone be
able to act upon the result.
As objectContainer nearly always is window, the most common
case would be:
if ( (someObject in self) && (someMethod in someObject) )
// using "self" reference to the *current* window is more reliable
// than simply "window" because "window" may be contectually
// ambiguous in some very rare but possible cases.
If that was true it would be possible to create a test case that
demonstrates the phenomenon. As the - window - and - self - properties
are non-specified but traditional properties of the window object in web
browsers they have effectively equal status and are likely to be subject
to equivalent handling in browser environments. So each would be as
reliable as the other.
Without a demonstration of the phenomenon your assertion deserves to be
dismissed as just another manifestation of your misconception of browser
scripting.
Richard.
Richard Cornford wrote: If someone expresses a desire to understand javascript I am
likely to propose that they learn javascript.
The point you missed: Not everyone wants to understand javascript. Some just
want to take advantage of its features by implementing packaged solutions.
If the idea of spending many hours
learning a programming language is not practical then the fact that it
takes many hours learning any programming language would man that
there are no programmers.
Your statement is as ridiculous as saying that if it weren't practical for
people to learn to repair their own cars, we wouldn't have auto mechanics.
It's not, in fact, practical for many people. I didn't say it was not
practical for anyone.
A large part of the point of the exercise is not to address as many
specific cases as possible, but instead to only implement the
component versions for the specific cases actually encountered, as
and when the are encountered. Avoiding writing specific code until
it is needed, and still creating easily re-useable code, is one of
the characteristics that makes the strategy efficient.
I disagree.
You are solving the specific case each time a new one comes up. I find it to
be more challenging, rewarding, and beneficial to try to solve the general
case (as much as possible) and then apply it to the specific case at hand.
If someone asks, "how do I find the position of my object on the page?" and
you supply the simplest solution which will work on their example page, you
may not be helping as much as you could. Tomorrow, if they introduce
scrollable areas into their page, change their layout with CSS, or put some
browsers into standards mode, your solution may break. And the person will
once again have no idea to fix it, because you gave them a very
limited-scope solution which can't be applied in varied situations.
Instead, you can solve the general case which also happens to solve their
specific example. Then, when their page changes, they don't need to change
their code, because the general solution already considers it correctly. The
few extra k of code which is not actually executed in each case is easily
offset by the fact that you don't need to go back and re-visit the code to
solve the new specific case, or change the code used every time your layout
changes.
The obvious fact to me is that most people prefer the approach taken by me
and many others. You may not, and that's fine, because obviously you have
the time and talent to do things your own way. But I see many people every
day downloading and using my solutions and thanking me for them. I don't see
you converting anyone to your approach with your postings on this group or
your web site examples. I do hear _lots_ of people say "wow, I found this
packaged solution, implemented it in 10 minutes, and got exactly what I
wanted". I don't hear anyone saying, "Thank god I didn't implement a
packaged solution, but instead spent the last 3 months learning and
experimenting with javascript so I could build up my own low-level function
library and solve the specific requirement that I had 3 months ago!"
Compare it to some every-day examples:
When you buy a new TV, do you learn electronics from scratch and build your
own to only have the features you want? Or do you buy one that costs a
little more and has more than you need, but gives you a TV right away and
gives you options in the future?
When you want a new computer, do you research and buy all the parts
separately and spend time assembling them to get the maximum possible
performance? Or you do buy a pre-packaged computer that may not match your
needs exactly but is certainly more convenient than building your own from
scratch?
When you choose an OS, do you build it from scratch and make it consist of
the fewest possible features that you need to use, in order to optimize
performance? Or do you use a packaged solution with lots more functionality
than you'll ever need, which uses more disk space and CPU, but makes your
life easier and more convenient?
Using a pre-packaged, generalized solution to a given problem is not lazy or
a cop-out as you seem to suggest. It's a realistic approach to take when you
consider all the factors involved and decide that building your own from
scratch just isn't advantageous. Why you object to it as a concept continues
to baffle me. I can only assume that you either have no understanding of the
real problems and priorities faced by many developers in the world, or that
you must dismiss generalized solutions in order to justify your own work to
yourself.
It is ironic that you should describe others as "Elitist assholes"
when your characterisation of "the average web developer" as
incapable of achieving even your level of understanding of the
subject carries the implication that you consider yourself their
innate superior.
Incorrect.
Many people can achieve the level of understanding that I, you, or anyone
else has. I understand that many people don't _want_ to, and many people
don't have _time_ to, and many people have higher priorities. I'm not
superior, and they aren't stupid. They just aren't focused on the same
things as I am, and I see no reason to tell them that they need to be (as
you do).
--
Matt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com
Matt Kruse wrote: The obvious fact to me is that most people prefer the approach taken by me
and many others. You may not, and that's fine, because obviously you have
the time and talent to do things your own way. But I see many people every
day downloading and using my solutions and thanking me for them. I don't
see you converting anyone to your approach with your postings on this
group or your web site examples. I do hear _lots_ of people say "wow, I
found this packaged solution, implemented it in 10 minutes, and got
exactly what I wanted". I don't hear anyone saying, "Thank god I didn't
implement a packaged solution, but instead spent the last 3 months
learning and experimenting with javascript so I could build up my own
low-level function library and solve the specific requirement that I had 3
months ago!"
Giving people what they want is not always the best approach. Most people
do not know what they really want. One has to consider what they probably
*really* *need*.
Compare it to some every-day examples:
When you buy a new TV, do you learn electronics from scratch and build
your own to only have the features you want? Or do you buy one that costs
a little more and has more than you need, but gives you a TV right away
and gives you options in the future?
No, because the effort necessary on my part would not justify the result
to be expected. This is of course natural laziness in some way intrinsic
to the psyche of all living beings. What makes them thrive and evolve is
need. What throws them back again is the urge to satisfy that need with
the least effort possible.
If you deny that you have not looked into it deep enough and you deny
yourself. Because you (and I) then would not have build libraries but
write that code from scratch every time. But, may I say, both of us are
professionals who wrote the code ourselves, who have come to understand
the basics needed for that. Others are in most cases merely consumers
of that code which puts them into a completely different position. They
have to be guided on how to use that work of ours properly which includes,
but not ends with, proper documentation.
When you want a new computer, do you research and buy all the parts
separately and spend time assembling them to get the maximum possible
performance?
Actually, I did, about four years ago. And I have not regretted it
to date, even though I have had some hardware and software upgrades.
Or you do buy a pre-packaged computer that may not match your
needs exactly but is certainly more convenient than building your own from
scratch?
The convenience of a pre-packaged solution is almost always balanced by
the problems that arise later because it does not fit special needs.
For example, pre-packaged solutions often contain bulk or low-performance
components to make the solution cheaper and easier to use. The components
are certainly able to do their basic tasks, but when it comes to getting
more of the average out of them they not only inevitably fail to do so but
cause problems when trying to enhance the particular performance level.
Think about a on-board graphics card often part of such hardware solutions
which is not good enough for your brand-new 3D game but interferes with the
new graphics card you just bought to counteract that, even though the
former is disabled in the BIOS Setup.
When you choose an OS, do you build it from scratch and make it consist of
the fewest possible features that you need to use, in order to optimize
performance? Or do you use a packaged solution with lots more
functionality than you'll ever need, which uses more disk space and CPU,
but makes your life easier and more convenient?
I use GNU/Linux, where I have downloaded the Debian distribution from
<http://debian.org/> and the Linux source from <http://kernel.org/>.
I compile my kernels to be suited to my computer (aided by sophisticated
configuration menu and make scripts), because not only their overall
performance then is better than the pre-packaged solution (which exists
anyway) but it also saves me trouble disabling things (kernel options,
including modules) I seldom or never want or need but which will
potentially and are known to interfere with the things I do need.
That does not mean I have to build the OS from scratch.
On the other hand, I use Debian packages for GNU whenever possible and
viable (up-to-date) because I have come to love the apt-get tools and
their efficient child's-play way to maintain the rest of the operating
system.
It's a not a black-and-white universe but one with many colors and shades.
Using a pre-packaged, generalized solution to a given problem is not lazy
or a cop-out as you seem to suggest. It's a realistic approach to take
when you consider all the factors involved and decide that building your
own from scratch just isn't advantageous.
As I said, the advantage is easy implementation which is why users of
pre-packages solutions are almost always very thankful for them.
The disadvantage in that is that if you have not bothered to learn to
understand how the implementation works, you will definitely have a hard
time or even be unable to apply it to your specific needs later. This
makes you completely dependent on the author of the solution -- whom you
will definitely not thank for and almost never contact them about it --
and on his will to fix or extend it if it does not work as supposed
-- for which you will rather wait because you have become so accustomed
to being fed that you will seldom consider the alternatives. It is the
way how Closed Source software works, and it's definitely a Bad Thing,
at least in the mid-term.
This is of course a matter of (personal) philosophy. Mine and it seems
also Richard's is:
"Give a man a fish; you have fed him for today.
Teach a man to fish; and you have fed him for a lifetime."
PointedEars
Thomas 'PointedEars' Lahn said the following on 10/29/2005 6:41 AM: Matt Kruse wrote:
<snip>
This is of course a matter of (personal) philosophy. Mine and it seems
also Richard's is:
"Give a man a fish; you have fed him for today.
Teach a man to fish; and you have fed him for a lifetime."
True but Richards, at times, seems to expand to:
"Give a man a fish; you have fed him for today.
Make a man a commercial fisherman; and you have fed him for a lifetime."
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Thomas 'PointedEars' Lahn wrote: Giving people what they want is not always the best approach. Most
people do not know what they really want. One has to consider what
they probably *really* *need*.
In some cases I agree, and in other cases I think that is an elitist
knot-it-all attitude. It depends.
The convenience of a pre-packaged solution is almost always balanced
by the problems that arise later because it does not fit special
needs.
Yet for most average 'consumers', the pre-packaged solution works just fine.
And in the few cases where it doesn't, they don't mind.
Most people are not 'power users' of a given technology or device. The
'typical' version works fine. Most people don't tweak their OS, customize
their web browsers, choose hardware piece by piece, mod their xbox, etc,
etc. Yet most people who are 'experts' (especially when it comes to
computers) can't quite comprehend this. They think everyone should learn and
tweak like they do, to get the most of everything. This is also why computer
nerds get made fun of so often ;)
With javascript development, the 'consumer' isn't just the end user viewing
the results in their web browser. The 'consumer' of code is also thousands
of average people who may not have much (or any) programming experience, but
who are working on a web site or a web app for their own use, and want to
put some advanced functionality into it.
If they were required to start from scratch and learn programming concepts
and then the javascript language and then the quirks of a web browser
scripting environment, many probably would never touch it. But if you can
give them a solution to plug in, it will solve their problem now and perhaps
give them insight into how it works. They can examine the code and read more
about it if they wish, and the whole idea of javascript programming won't
seem so intimidating.
As I said, the advantage is easy implementation which is why users of
pre-packages solutions are almost always very thankful for them.
The disadvantage in that is that if you have not bothered to learn to
understand how the implementation works, you will definitely have a
hard time or even be unable to apply it to your specific needs later.
This is indeed the trade-off, and I've never denied that such a trade-off
exists.
Pre-packaged solutions can work great for the exact cases which they cover.
When a more customized solution is required, the user may lack the ability
to make the changes they need, and be lost. Or, perhaps the user *is*
knowledgeable enough to customize the code, then they have their needs
mostly met, with only minor additional coding needed. This is the trade-off
with *any* packaged solution. You get convenience, but at the expense of a
solution tailored to your specific needs.
As a consumer, I sometimes prefer the pre-packaged solution, and I sometimes
prefer to build things myself.
But to deny the benefit of pre-packaged solutions entirely, as Richard and
others often do, is extremely biased and naive. When a person advocates a
single viewpoint and refuses to acknowledge that other viewpoints might have
some credibility, it makes them less believable, imo.
This is of course a matter of (personal) philosophy. Mine and it
seems also Richard's is:
"Give a man a fish; you have fed him for today.
Teach a man to fish; and you have fed him for a lifetime."
Using analogies usually takes a discussion off-course, but I'll bite ;)
1) If someone is starving, teaching them to fish isn't helping. They need
fish now. They might also learn to fish on their own, which will take time,
but for right now, they need a fish!
2) Someone need not learn how to fish if they know how to go to the store
and buy fish every time they need some. We can't all learn to fish!
Plus, I don't even like fish ;)
--
Matt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com
Randy Webb wrote: True but Richards, at times, seems to expand to:
"Give a man a fish; you have fed him for today.
Make a man a commercial fisherman; and you have fed him for a
lifetime."
Or how about,
"If you give a man a fish, you have catered to a lazy person who can't even
spend the time required to learn how to get their own fish. You've also
given them bones and other parts that they probably don't want to eat.
Furthermore, you haven't informed them of the potential harm that eating
fish could do to them. What if they are pregnant and they get too much
mercury? To give the person a fish without them understanding all of the
potential hazards is irresponsible. Therefore, fish should never be given to
anyone.
Instead, anyone in the world who wants fish should become a fisherman. There
is plenty of information out there about how to fish. It just takes
practice. And a boat. And a net. And lots of free time. If you don't have
all that, you don't deserve to eat fish anyway. But if you really want fish,
then you need to buy those things and practice and build up your skills so
that some day you can catch the exact kind of fish you want to eat. And by
the way, if anyone else asks you for a fish that you caught, tell them hell
no. Get their own damn fish."
:)
--
Matt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com
JRS: In article <dk*********@news2.newsguy.com>, dated Sat, 29 Oct 2005
11:05:16, seen in news:comp.lang.javascript, Matt Kruse
<ne********@mattkruse.com> posted : "If you give a man a fish, you have catered to a lazy person who can't even
spend the time required to learn how to get their own fish. You've also
given them bones and other parts that they probably don't want to eat.
Furthermore, you haven't informed them of the potential harm that eating
fish could do to them. What if they are pregnant and they get too much
mercury?
... "
IMHO, very few men worry about the possibility of being themselves in
the state described in the last quoted sentence.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
On Sat, 29 Oct 2005 10:52:31 -0400, in comp.lang.javascript , Randy
Webb <Hi************@aol.com> in <HL********************@comcast.com>
wrote: Thomas 'PointedEars' Lahn said the following on 10/29/2005 6:41 AM:
Matt Kruse wrote:
<snip>
This is of course a matter of (personal) philosophy. Mine and it seems
also Richard's is:
"Give a man a fish; you have fed him for today.
Teach a man to fish; and you have fed him for a lifetime."
True but Richards, at times, seems to expand to:
"Give a man a fish; you have fed him for today.
Make a man a commercial fisherman; and you have fed him for a lifetime."
Teach a village to fish and they soon depopulate the lake.
Teach a man to cook a fish and he starves to death with a greater
appreciation of what he is missing.
--
Matt Silberstein
Do something today about the Darfur Genocide http://www.beawitness.org http://www.darfurgenocide.org http://www.savedarfur.org
"Darfur: A Genocide We can Stop"
Matt Kruse wrote: Thomas 'PointedEars' Lahn wrote: The convenience of a pre-packaged solution is almost always balanced
by the problems that arise later because it does not fit special
needs.
Yet for most average 'consumers', the pre-packaged solution works just
fine. And in the few cases where it doesn't, they don't mind.
Well, as I wrote, due to the nature of people, you cannot know neither for
sure. Not that they are few cases and not that people don't mind. For
example, I have heard too many people complaining about MS Windows: that
it is too slow for them, takes too much system resources for simple tasks,
too whatever; yet the same people in almost all cases refuse to put some
effort into just exploring alternatives, let alone using them. And when
I ask them about it, still nobody ever considered sending those complains
to MS to make the OS better; they rather wait for it to happen.
Most people are not 'power users' of a given technology or device. The
'typical' version works fine.
Not in all, most or even many cases, which is the problem.
Most people don't tweak their OS, customize their web browsers, choose
hardware piece by piece, mod their xbox, etc, etc.
Which does not mean in any way that they are happy with what they have.
It does not mean the opposite either, of course.
Yet most people who are 'experts' (especially when it comes to
computers) can't quite comprehend this. They think everyone should learn
and tweak like they do, to get the most of everything. This is also why
computer nerds get made fun of so often ;)
Public opinion is seldom based on rational thinking.
With javascript development, the 'consumer' isn't just the end user
viewing the results in their web browser. The 'consumer' of code is also
thousands of average people who may not have much (or any) programming
experience, but who are working on a web site or a web app for their own
use, and want to put some advanced functionality into it.
That's the point. When I write `consumer' I mean the first-level consumer,
that is, the Web site responsible. And the Web site is for consumers, too,
even if only non-commercial visitors. However, if your customer/consumer
does not really know what he does, how can you expect that he will provide
a viable service to his customers/consumers? He depends entirely on you,
so he makes you responsible if something goes wrong, whether you deny that
in a legal statement or not.
I appears to be a Good Thing to shift responsibilities by allowing the
first-level customer to learn. I don't know whether that is a viable
approach, but why not provide a solution of components instead of a
complete solution? This would create the need for that customer to
understand how to make the components work together to achieve what
he wants.
If they were required to start from scratch and learn programming concepts
and then the javascript language and then the quirks of a web browser
scripting environment, many probably would never touch it.
To completely refuse learning before doing, would that not be a sure sign
of incompetence? Would they not deserve to have a not-so-good Web site,
if any? Ahh -- but there's the commercial aspect which brings us back to
the least-effort behavioral pattern. Why put effort in learning if it
*appears* that you can buy (or copy) knowledge?
But if you can give them a solution to plug in, it will solve their
problem now and perhaps give them insight into how it works. They can
examine the code and read more about it if they wish, and the whole
idea of javascript programming won't seem so intimidating.
Will they ever bother to learn if you keep feeding them?
But to deny the benefit of pre-packaged solutions entirely, as Richard and
others often do, is extremely biased and naive. When a person advocates a
single viewpoint and refuses to acknowledge that other viewpoints might
have some credibility, it makes them less believable, imo.
It of course depends on the matter discussed, but I tend to agree.
This is of course a matter of (personal) philosophy. Mine and it
seems also Richard's is:
"Give a man a fish; you have fed him for today.
Teach a man to fish; and you have fed him for a lifetime."
Using analogies usually takes a discussion off-course, but I'll bite ;)
I'm a hell of a good "fisherman", I suppose? ;-)
1) If someone is starving, teaching them to fish isn't helping. They need
fish now. They might also learn to fish on their own, which will take
time, but for right now, they need a fish!
I doubt that they really "starving". But to speculate on people's motives
won't bring us further in this discussion.
2) Someone need not learn how to fish if they know how to go to the store
and buy fish every time they need some. We can't all learn to fish!
But perhaps to make "fish soup".
Plus, I don't even like fish ;)
Me neither, I'm vegetarian. Yet I happen to like the proverb.
You may replace "to fish" with "to grow crops" or so ;-)
PointedEars
I was following this discussion and wondering: what in the name these
fisherman's talks have to do with the announced topic? My wild guess
would be that it is somehow related with the question "What of our
godlike knowledge should we give to mortal people and what is suitable
to know between gods only?". If I'm right here then I engage you to
leave the Olympus right now as you get there by the wrong ticket.
comp.lang.javascript is a good newsgroup but not only one source of
knowledge of JavaScript - and it's definitely *not* the ultimate source
of knowledge of common programming principles. Anyone can get the
answer from here or from any other place of her choice.
If you decided to give some "Best Practice" programming advises in
relation to ECMAScript-based languages then let's discuss it. If anyone
still remembers these are:
1. Square Bracket Notation
2. Referencing Forms And Form Elements
3. Referencing Forms From Element Handlers
4. Problems With Concatenation
5. Using onClick in <A> tags
6. Eval
7. Detecting Browser Versions
8. Don't Use document.all
9. Getting And Setting Form Values
I see nothing where what wouldn't be covered already in FAQ's but OK -
it could be a nice FAQ add-on. If the discussion is set over, OP is
welcome set a link on it from the FAQ page.
Most importantly you need to decide what is the "Best Paractice"? Is
the code that follows the "Best Practice" i) most readable or ii) most
universal or iii) most error-protected or iv) most resource effective
or v) most time effective.
These are all different and often mutually-exceptive issues. I say that
the best practice has to lead to code which is the most universal and
(upon the possibility priority level 1) most error-protected and (upon
the possibility priority level 2) most readable. From this position say "Eval is Evil" is totally right and nothing to
discuss here.
But let's us take "iv) most resource effective or v) most time
effective" priorities, and "Eval is Evil" becomes a good sounding but
pointless slogan. With the above mentioned priorities we should say
instead "Recursion has a Curse on". JavaScript is an interpreted
language and you have to accept this fact as say its loose typing. As
one of consequences of it recursions in JavaScript are almost never as
effective as runtime code generation. I have a set of *practical*
samples (starting from full array copy *including* nested arrays) to
demonstrate it. Actually better you may try to make a non-"new
Function()" based solution which would *be no more than two times
slower* than a "new Function()" based.
But again - it's all priorities' based. So the parting question would
be: what is the "Best Practice" definition in this thread?
P.S. And please stop profanities like "reusable libraries should not be
used in the programming". There may be children around here to hear
that.
Thomas 'PointedEars' Lahn wrote: For example, I have heard too many people complaining
about MS Windows: that it is too slow for them, takes too much system
resources for simple tasks, too whatever; yet the same people in
almost all cases refuse to put some effort into just exploring
alternatives, let alone using them. And when
I ask them about it, still nobody ever considered sending those
complains to MS to make the OS better; they rather wait for it to
happen.
Which illustrates my point: That people value the convenience of a
pre-packed solution far more than the value of a better solution which
requires additional effort. And even when better alternatives are available,
people will _still_ stick with the packaged solutions. Which means, no
matter how hard Richard or you or anyone else promotes the idea that
packaged javascript solutions are bad, it won't matter. People will still
search for them and use them. You can either let them all use low-quality
offerings, or write your own solutions and aspire to higher quality so that
you can benefit a wide range of people.
why not provide a solution of components instead of a
complete solution? This would create the need for that customer to
understand how to make the components work together to achieve what
he wants.
This is exactly the approach I would like to take. I would like to build a
repository of components which solve very specific problems, but which by
themselves offer no functionality. I would love to get the best programmers
on this group to combine their efforts into a standard repository of these
components. Then anyone building sites or apps or even packaged solutions
can reuse these solid low-level components and achieve higher quality.
Given a standard repository of components, I'm certain that a number of
developers who now choose packaged solutions would instead decide to build
their own. Because despite what some might argue, some of these low-level
components are not, in fact, trivial to develop and test. Developing
cross-browser scripts even for some simple things requires digging into
different DOM implementations, testing in a wide variety of browsers,
reading through different documentation, and dealing with quirks in browsers
where things don't work exactly as they ought to.
When I promote something like that, Richard replies with, "we won't help
you, because we know what your goal is, and your goal sucks." That's what I
call the 'elitist asshole' attitude. And when he promotes his own
methodology and publishes examples using his own low-level components, yet
refuses to make them available to others to benefit from, or even document
his approach, I have to wonder what he's really thinking... If they were required to start from scratch and learn programming
concepts and then the javascript language and then the quirks of a
web browser scripting environment, many probably would never touch
it.
To completely refuse learning before doing, would that not be a sure
sign of incompetence? Would they not deserve to have a not-so-good
Web site, if any? Ahh -- but there's the commercial aspect which
brings us back to the least-effort behavioral pattern. Why put
effort in learning if it *appears* that you can buy (or copy)
knowledge?
Let's not deny that every one of us benefits from buying, copying, or using
the packaged knowledge of others. I don't think that the viewpoint that we
must all learn to do everything ourselves and not benefit by using the
solutions of others has any merit at all. The only way to achieve greater
and more complex goals is to treat some knowledge as a 'black box' and add
your own knowledge to go one step further.
Clearly, if someone's goal is to be javascript programmer or an expert web
developer, then relying only on packaged javascript solutions is not a good
plan. They should learn the skills required to develop the code on their
own.
But if their goal is to have a decent web site where their small church can
make information available (for example), then understanding the underlying
technologies to their fullest is _not_ something they care about. They can
achieve their goal by either paying someone who understands everything
(often not an option) or they can use the knowledge of others without fully
understanding it, so they can achieve their goal. To say that they only
deserve a not-so-good website, if any, is an elitist response that I find
incredibly rude. If they can achieve decent results and accomplish their
goal and benefit from it - even if they didn't learn to do it themselves -
then I say good for them. I certainly wouldn't tell them that they don't
deserve it.
--
Matt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Charlene Russ |
last post by:
Learn on-line at your own in a user-centered format with plenty of
interaction and personal attention.
This is a basic level coursed designed to introduce the novice to
intermediate computer...
|
by: stephan |
last post by:
Hello,
I have a page in which an iframe calls an external website.
I'd like to disable javascript for the page called in the iframe.
Is it possible ? How ?
Thanks in advance,
--
stephan
|
by: knos |
last post by:
Here is a stripped, simple code for input of 2 numbers, and getting
their sum.
<HEAD>
<script language="javascript">
function adder() {
a=parseFloat(document.nform.ainp.value);...
|
by: optimistx |
last post by:
Which url in your opinion would be a good or even the best example of
javascript usage in a set of pages at least say 10 or more pages? How to use
css, how to split js-code to files, how to code...
|
by: pochartrand |
last post by:
Hello,
Is there a way to manipulate or at least read the pseudo-class of an
element ?
I know the style attribute can be accessed and gives the CSS properties
for a particular element....
|
by: charales |
last post by:
Hi everyone!
I'm having this problems with javascript. If you go to:
http://www.nikonistas.com/es_home/nikon2.html
you'll find at the top-left corner the typical username-password form with
the...
|
by: Doug van Vianen |
last post by:
Hi,
I often like to include some JavaScript coding in my web pages to make them
more interesting. Unfortunately, even when this coding is as simple as a
check to see what the display width is in...
|
by: petermichaux |
last post by:
Hi,
I have tried the following based on suggestions of the best way to
insert JavaScript into a page. This is instead of using eval().
Unfortunately IE says "unexpected call to property or...
|
by: Phlip |
last post by:
Javascripters:
I have a page with an iframe inside. Let's say the iframe looks like this:
<script src="/javascripts/prototype.js" type="text/javascript" />
....
<iframe id='grinder'...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
| |
