Re: Javascript Best Practices Document v1.0

Richard Cornford wrote:
> [snip]

Richard, your posts are too verbose to be responded to in detail, and we've
disagreed on this before. As I've said before, you're an intelligent guy and
you do good stuff, but your perspective is very different from mine. Your
experience with Javascript is not the norm. In my experience with many web
developers, Javascript is this piece-of-crap scripting language that they
have to deal with and struggle with. It gets in the way of what they want to
do, but they have to use it. Many have no interest in learning the language
or its quirks, nor do they want to spend hours learning best practices of
FAQs.

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?
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? Or do
you offer a generalized library that might have some 'bloat' but
accomplishes the task way better than they would have written themselves?

Not everyone wants to be a javascript expert. You do. That's nice. But don't
pigeon-hole everyone into your mindset.

> 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? If it's an extra 5k or even 10k, that is often way
over-shadowed by graphics sizes, flash, etc.
If your goal is to create tight, compact pages, then fine - don't use libs.
But that is _NOT_ a requirement for most people.
The convenience of using a lib with a little code bloat is more important
than the extra few k of text that is downloaded.

> 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.

>> 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.
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.

> 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.

> 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. Or
they may not even care. They just want their 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.
You don't see regularly how many people _DESPISE_ javascript?
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.

>> 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.

> 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.
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. 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.

> 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.

> 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.
If you can add value in a specific area, even without solving the entire
problem, that is a good thing.
A 'Best Practices' document doesn't need to cover everything. IMO.

> 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.
I cater to the masses. You cater to those you deem worthy.
I understand the problems of the average developer. You tell them to RTFM.

I prefer my view.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com


.

Relevant Pages

  • Re: Javascript Best Practices Document v1.0
    ... >> practices of FAQs. ... Anyone expecting the be paid for using javascript ... web developers are expected to use, but that employers almost never devote ... If I were you - someone repeatedly advocating reusable low-level functions ...
    (comp.lang.javascript)
  • Re: VB or C#
    ... Your response which I (and probably Clinton, although I can't speak for him) ... JavaScript is seldom OOP used, this can as well with C#, ... however with that you are in my idea misusing the language. ... for the developer to be familiar with not only the server-side programming ...
    (microsoft.public.dotnet.general)
  • Re: TRICK: methods in ASPX pages with <%%> code blocks
    ... > developer, adopt best practices. ... They are called "best practices" because ... > experiences, and by observing the experiences of others, over a long period ... >> I didn't come from classic ASP so I can't speak for someone's been used to ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Crockfords JavaScript, The Good Parts (a book review).
    ... of the DOM (that which changes the UI for the user in response to ... JavaScript can get some predone and prepackaged stuff from Yahoo's ... *not* discuss CSS and/or the DOM. ... practices. ...
    (comp.lang.javascript)
  • Re: TRICK: methods in ASPX pages with <%%> code blocks
    ... important "Best Practices" consideration regarding Pages is that Pages ... ..Net Developer ... > With the subject of code-behind, however, Best Practices indicate that ... >> their own experiences, and by observing the experiences of others, ...
    (microsoft.public.dotnet.framework.aspnet)