So you want to write JavaScript for a living? | Hacker News Reader

So you want to write JavaScript for a living?

nczonline.net

72 pointstaylorbuley32 comments

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

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.

This is especially true with toolkits/frameworks written in node.js. I wrote a server side version of jQuery in node.js, called nQuery, that changes the DOM paradigm by allowing you to access the DOM in real-time from the server with RPC via the $(). It turns the DOM paradigm into something quite different.

Note: Still a WIP.

https://github.com/tblobaum/nodeQuery

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.

Keep in mind this post was originally from 2007. jQuery started in mid-2006. When this was originally written, there really weren't many effective abstractions of the DOM.

Ah, yeah I missed that on my first read through. I guess I'm still interested to see if that is still part of the interview process at a lot of places.

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?

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

Because the job is rarely just manipulating the Dom in some simple way.

Sure, if you just want to add the current date to <div id="rightNow"> then use basic browser builtins, but it's usually more like "I need every other child of each list with the class 'rowStripe' unless it's the last entry in the list", in which case jquery saves you a ton of time.

I find that jQuery gives you a lot more than just DOM manipulation. If you were doing just that then JQuery is overkill. But JQ gives you a lot more in the way of animations, plugins, and all sorts of other useful methods.

I also like the community. There seems to be a jquery plugin for damn near everything. Kind of like PHP. Yes it can be a mess. But when you are just trying to "get shit done" JQuery isn't bad at all.

For me, it has always been about creating unified interface across all the different browsers. While getElementID is universally supported, many things are different (see all the remarks about setting the `name` attribute on elements in Internet Explorer http://msdn.microsoft.com/en-us/library/ms534184%28VS.85%29....).

I'd rather let the library developers abstract all that out for me.

Cross-browsers. If we only had Firefox, then ya, there could be some debate. Jquery handles cross-browser problems, while at the same time providing a more intuitive DOM manipulation layer. What more can you ask for? Use Jquery, build better things, move forward.

>Is it really necessary to expect a front end developer to have complete knowledge of manipulating the DOM without jQuery?

It depends. For your average front-end developer adding light functionality to a web page/app? No, probably not.

However, if you are creating heavy, full-featured, client-side web-apps...absolutely.

Not because you need to do it without jQuery, but because you need to understand what jQuery is doing behind the scenes. At least a couple times a year some major website like (to pick at random) Twitter crawls to a halt, bugs out, etc...because some front-end dev treated jQuery like magic without considering what is going on behind the scenes.

So I would say if you serious about being a front-end developer, then sure...spend some time browsing the jQuery source and learn to do things in "vanilla" JS.

In terms of whether to consider it re; hiring, it depends on what you are hiring for.

In some situations jQuery is rather large to have as a dependency (adverts).

Good point, hadn't thought of that - and I imagine the job description would probably drop some hints that you wouldn't be using any external libs, no?

80% of the time? No.

Perhaps not even 95% of the time.

However, someday, there will be a bug withing jQuery, or a misunderstanding of what it is doing internally, and you will have to debug. You will have to have understanding of the DOM itself.

FACT: 95% of the use of jQuery can be replaced with document.getElementById() and document.getElementsByTagName()

Bullshit. Unless 95% of your jQuery usage is just finding some elements and the… doing nothin with them.

Meanwhile others do some stuff: like attaching event handlers, manipulating attributes, class names; doing animation, making AJAX requests, etc. Most of these differ to some degree accross browsers and that's there jQuery comes in: to unify the API.

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

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.

Back when this article was written, you were using these methods about every 10 lines of code or so.

If they weren't embedded in your memory, you were probably lying about how much Javascript you had written or were really bad at it.

Agreed, but those should be considered early weed out questions, or a segue into deeper topics. For example, appendChild and removeChild, it's almost obvious what they do, but ...

1) What implications do those have on DOM performance?

2) Contrast appendChild when called on a DOM element, vs. an absolutely positioned DOM element, vs. a document fragment

3) Why do you want to avoid calling appendChild w/in a loop?

Keyword I'm looking for from candidates: Reflow, which requires a deeper level of understanding, and that's the level I'm really targeting in an interview.

Mozilla docs? If you can't tell what getElementById does just by the function name and a general understanding of what you are being interviewed for then there is a problem that goes beyond unfamiliarity.

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.

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

"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

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.

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

I think you could focus more of code organization and layout. What are possible ways to make Javascript code modular? Why are namespaces important? Why shouldn't you (generally) declare variables in the window context?

A few more: What are dangers of using prototype inheritance with many instances of that class (meaning accidentally attaching variables to the prototype rather than the instance)?

What are some gotchas with IE < 9 event objects in event handlers that contain closures?

Explain the same origin policy, why it's important, and how it impacts your development.

(jQuery twister): explain where the '$' variable is defined when used with jQuery. How might you manipulate the DOM in another popup window you've created?

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.

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.

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.

Reply on news.ycombinator.com