Re: Javascript Best Practices Document v1.0

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


.

Relevant Pages

  • Re: Javascript Best Practices Document v1.0
    ... group of developers. ... I'm actually not all that interested in your specific solutions, because although you might be technically skilled, you're just not that pleasant of a person. ... Javascript Best Practices - ...
    (comp.lang.javascript)
  • Re: Browser support
    ... > probably about 1000 lines of javascript, ... I've been looking at XQuery, a dog of a spec, ... The hard part, of course, is convincing their developers that it's ... > Finally, pardon my ignorance--what's AJAX? ...
    (comp.databases.pick)
  • Re: Javascript Best Practices Document v1.0
    ... experience with Javascript is not the norm. ... I see absolutely horrible javascript practices so often that even suggesting ... > potential of the "average web developer" and then cite their opinion ... And yet your expectation is that every web developer in the world should ...
    (comp.lang.javascript)
  • 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: how to enable linux flash player [9] in firefox
    ... bit of proper javascripting, then stuff would be easier for viewing on ... but the VM isn't as lightweight as the flash runtime ... Not only that, it takes better developers ... About the only thing that flash can do that javascript and the rest ...
    (freebsd-questions)
Loading