
So you want to write JavaScript for a living? - taylorbuley
http://www.nczonline.net/blog/2011/10/20/so-you-want-to-write-javascript-for-a-living-repost/
======
simonsarris
It's funny because in these modern times - for the first time in JS history
perhaps and depending on the JavaScript you are writing for a living - you
don't necessarily need to know all too much about the DOM to make some amazing
web pages and apps.

This is especially true if you use node.js to write server-side JavaScript or
use jQuery to hide some complexity or if you are making things with HTML5
Canvas, where your DOM interactions are often limited to that single object
(or perhaps multiple Canvases). Some of the most impressive things I've seen
in the last year were JavaScript sites that had nothing to do with even the
slightest shred of DOM manipulation.

Of course I'm not saying that one shouldn't need or want to understand the
DOM. It's just interesting to me how things have subtly changed, and as
someone who loves and spends a large amount of time with Canvas, to see all
these beautiful new things on the web with no DOM-aches needed.

(After all I agree 100% with Resig: JavaScript isn't broken, its the DOM that
tends to foul things up.)

~~~
voidr
You still need to manipulate the DOM when using jQuery, the difference is that
you are using an API that is actually reliable. I still need to do this:

    
    
        $('<div></div>').appendTo(document.body).dialog(dialogOptions);
    

Also when you are writing custom widgets you gotta understand the DOM, not
even jQuery can hide everything away.

------
Stwerner
Is it really necessary to expect a front end developer to have complete
knowledge of manipulating the DOM without jQuery (or one of the other
libraries)? I'm definitely capable of reminding myself of it, since that is
what I learned when I first started learning javascript, I just do not see any
benefit to it. I write quite a bit of javascript for my job on a daily basis,
and am never without something like jQuery.

~~~
craze3
I never caught on to the whole jQuery hype. Why do people use jQuery for such
trivial things such as DOM? Wouldn't it be smarter to use getElementById() and
end up with universal code that could run on any site without the need for 3rd
party libraries?

~~~
asolove
\- Do you remember which events IE conveniently forgets about, like not
bubbling "submit" events above forms?

\- Can you write out AJAX code that reliably works in all versions of IE by
memory? And don't forget to add automatic jsonp support for cross-domain
requests.

\- Do you remember how to get the width and outerWidth of an element in a
reliable cross-browser way?

There was a time when I could do these things from memory. That time was when
I was interviewing for jobs. In daily work, I only have to half-remember these
things and can operate at a higher level of abstraction.

------
btipling
> "If your candidate doesn’t understand getElementById, getElementsByTagName,
> appendChild and removeChild, you have a problem"

Why, because you can't reach the Mozilla docs? Reference based questions are
no way to do an interview. It's easy to look this stuff up.

~~~
YmMot
These aren't some obscure "nice to know" functions...this isn't a "you don't
have the manual memorized" gotcha question. Those functions are __fundamental
__to writing JavaScript web applications...particularly at that point in time,
but even in today's world of DOM libraries. At this point in time (and even
today to a lesser extent) JavaScript's raison d'etre was to manipulate DOM
objects and those functions are key to that.

That's like saying "Heart surgeons don't need to be able to draw a rough
diagram of a heart when asked...they can always consult a medical textbook".

Sure...I agree with you that heart surgeons don't need to have every obscure
cardiovascular disease memorized...but they need to have memorized the basic
cardiovascular functions, how the heart works, what it looks like, etc. The
same is true for programmers of any type...there is a base amount of
information that you should __just know ___in order to be considered
proficient_ for a particular field.

If a candidate comes in and doesn't know this stuff, that doesn't necessarily
mean you shouldn't hire them...however it __does __mean they are __not
proficient __in whatever field and will need to be trained to some extent.

Also of course, as with any other sort of question; it could be they just had
a "brain fart" or off day...but not asking these sorts of questions doesn't
make that issue go away.

------
apaprocki
Writing Javascript doesn't mean you have to be writing front-end code or even
writing for HTML/browser output. The DOM is not part of the language, neither
is XHR. We have at least 1000+ developers who write server-side JS, so people
who enjoy writing JS definitely have other options.

~~~
reustle
This article was written a few years ago, when SSJS wasn't so popular. PS, I
hope the space plans are going well :)

------
chrisrickard
"6. Familiarity with popular JS libraries" - It seems now more than ever this
is an integral part.

JQuery walked on in and 'shook up' the world of JS - but now there are so many
strong libraries (& micro-libraries) that its more of a matter of filtering
out the junk

------
hackDaily
Seems to hit it right on the nose. I write JavaScript for a living and can say
that each of these skills is fundamental to my success. Good read.

~~~
TheCowboy
Are there any points you would emphasize, consider dated, or add?

~~~
hackDaily
Honestly, I didn't see much that doesn't still apply to writing JavaScript
today. However, I think overall code organization and re-usability is
something that today's JS devs need to think more about. It's too easy to whip
together a bunch of "cowboy code" with so many plug-ins and libraries
available.

~~~
papa_bear
Is the "cowboy code" any less reliable than non cowboy code? I feel like the
extra speed of writing in this case may be more valuable than using strict
javascript.

~~~
jt2190
Just as notes you take for yourself are not the same as an edited manuscript,
code you write in the cowboy way is not code that other developers should be
expected to easily understand and maintain.

If you're a solo developer writing small applications, this might not be a
problem. If you're growing an application and a business this is a very
serious concern. As you grow, you need to bring in more developers, but with a
cowboy codebase it will be harder and harder to keep everyone productive.
Instead of writing new features, they'll spend more and more time just trying
to undersand the code, and to fix the inevitable bugs.

Quick fixes are a fact of life though, but use them only until a solid patch
can be crafted.

