Matt said:
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.
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.
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?
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.
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 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?
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.
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?
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.
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.
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.
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.
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.
Yep, if it is a technical subject RTFM. I have no problem with that.
