Hacker News new | comments | show | ask | jobs | submit login
You Don't Know JavaScript (w2lessons.com)
94 points by mwbiz on Apr 16, 2011 | hide | past | web | favorite | 38 comments



This 'irritating problem' of people claiming that they know _____ when they actually don't, is best solved with... drum roll... Source code. Don't tell me you know _____, show me what you did with _____.

Today that problem can be solved with Github, Sourceforge, Google Code or whatever. A decade ago I remember asking for a job as a Java developer by taking the source code for a Scheme interpreter written in Java into the interview. A checklist of features is a nice starting point for things to look for for when learning, but there is no substitute for solving problems with the language. Thus, one day you will be able to say what you did with it, rather than which features you understand.

So my feedback for the author is this: Write a followup suggesting some sample projects to write, organized by level of difficulty, just as you've organized language features by difficulty. The projects shouldn't be large, just things that will tend to force the developer into an in-depth understanding of one or more of the advanced features you have suggested. For example... You mentioned timers. What could/should I build if I want some experience using timers?


"This 'irritating problem' of people claiming that they know _____ when they actually don't, is best solved with... drum roll... Source code. Don't tell me you know _____, show me what you did with _____. Today that problem can be solved with Github, Sourceforge, Google Code or whatever."

That isn't really a complete solution to the problem, take my situation as an example: I've been working as a C# dev for some years now, but since the company I worked for ended up owning all the code, and since almost all the applications I helped create for them are internal, I have nothing to really show for it. Why don't I have any side projects I've done with C#? It's just simply not my first choice of language for personal projects due to the fact I have to use it so much on a daily basis; instead, I tend to go with lesser known languages that I'm certainly not as familiar with just because it makes writing some of the code a little more exciting. In essence, I'm claiming to know the language, but the only proof I can give is saying "Well, I used it daily for X amount of time".


This came up a while back, and I feel your pain. That Java job I told you about? All the Java and C++ code now belongs to Quest, who bought my employer. And I did some good work on ING Direct (USA), but I can't show that to you, either.

My wife once bought a bunch of postcards from a printer to promote her business as a photographer. Right on their price list was a charge for a credit waiver. basically, every postcard had to have a small "Printed by FooCorp 1-800-888-8888" on it. If you didn't want that, you paid extra.

I have reached the point where I feel the same way about the code I write. Naturally, nobody can see trade secrets. But if there's a portion of the code that is not a trade secret, perhaps a Rails or jQuery plugin that gets developed along the way, I want that open sourced. If the answer is "No, we want to own everything 100%," I need to make extra money to make up for the fact that I am going to go dark, just as that printer needs to charge extra money to make up for the lost advertising opportunity.


Our employment contracts actually require us to open source everything our hackers build (except some client-specific configurations or templates of course)


Thanks Ragan, I completely agree with you and this is one of the first things that I do in an interview.


This is totally off topic, but there's no 'Ragan' (and he's not Mr. Wald either). From one of his sites:

the answer to an infrequently asked question

Raganwald is my own made-up variation on the Norse name Ragnvald, which is the origin of the Norman name Reginald (if you go back to back to Sanskrit, you find that Ragnvald is loosely related to the Indian name Raj). Braythwayt is a very rare spelling for my surname. I first encountered “Braythwayt” in a P.G. Wodehouse short story when the hapless Bingo Little abandons Honoria Glossop to chivvy Daphne Braythwayt about, and Honoria assumes Bertie loves her and accepts what she thinks is his implied proposal… But perhaps you should read that story for yourself.[1]

I suppose this jumps out at me because I'm not actually Telemachos (and my last name isn't actually "Son of Odysseus").

[1] http://reginald.braythwayt.com/


Very true, although I have no objection to the nickname "Ragan." Call me anything you like, as long as you don't call me late for dinner :-)


So despite the mostly vapid nature of this article one thing called out to me:

"Given the lax nature of JavaScript, it's easy for your application to spiral into a mess of unmaintainable spaghetti code."

Let's not forget: it's entirely possible to create a mess of unmaintainable code in any language. Or, "guns don't kill people, people kill people"

The other half of this complaint i think is somewhat elitist (unwittingly so?) and it seems to do with the notion that because there is a such a low barrier to entry, that much js code is cargo-culted, but i've seen this from developers in every language. What I find even worse than cargo-cult code is Pattern Zealots going about specifically coding up Pattern X in javascript. It's like they studied Design Patterns but the point of it just went over their heads.

Knowing the principles of software development doesn't prevent you from making ridiculous decisions[1]. It seems like everyone wants checklists of coding standards or something for measuring code quality / standards compliance these days in js. But these are hollow measures if the code behind the module/black box/library is just plain wrong.

Maybe i'm missing something here, but why is this article getting voted up?

[1]: http://stackoverflow.com/questions/1635800/javascript-best-s... (found when googling 'javascript singleton')


Let's not forget: it's entirely possible to create a mess of unmaintainable code in any language. Or, "guns don't kill people, people kill people"

That's true. You can write FORTRAN in any language. However, some languages make certain classes of mistakes easier. For example, C makes it very easy leak memory. Java, with its automatic garbage collection, makes it considerably harder.

Does this mean that memory leaks are impossible in Java? Of course not. But I'd still rather have memory management than not.


an aside: i have been asked three times in separate technical interviews (several years apart even) how to leak memory in java (once in python).


I would like you to show us some examples!


I can't remember any Java examples at the moment, but I do recall a memory leak that I had created in C#.

Registering an event handler in .Net creates a reference to the handler. This means that an event handler that doesn't un-register itself from it's event will never be garbage collected. In the context of a GUI application, this means that you have to be careful to ensure that child windows remove their event handlers when they're closed. Otherwise, your application will leak memory, as the closed windows will never be garbage collected.


Obviously the author is knowledgable about javascript, but this article would have carried more weight with me if he'd taught me something more instead of just alluding to all of these concepts that I haven't encountered yet. It kind of makes the whole thing come off like he has an inferiority complex about being "just a front-end developer"


Also, to teach all this stuff I'd have to write a whole book, this is why I've suggested two good ones that will do just that.


Alex, I'm actually a back-end developer, there is no inferiority complex.


I think altering the tone with which you use to deliver your message will have a beneficial effect in reaching people.

For example, I am not going to read this because it sounds really pretentious, and you are replying to everyone here to argue trivial things. If you don't have a complex, you don't need to bother with this.

Also, because it ends with this:

>As for the resume decoration, I would say that if you've covered the beginner level and are venturing into the intermediate stages it is justifiable to put it on your resume. Once you find yourself developing your desired functions rather than copying and pasting them, you can then claim to know JavaScript, until then, please don't advertise it.

Really?


Are you skeptical of the idea that there are really people so dishonest that they would claim on their resume to know a language of which they have only copied and pasted chunks? Don't be. I've interviewed some of these people. I wish I could add them to some kind of global blacklist to stop others from wasting their time on them.


The post is pretty harmless, and here he's making just slightly brisk replies to being told that he has an inferiority complex and doesn't know "use strict", although I agree it's not worth bothering with.

If you don't read things that don't bend over backwards to avoid offending people, you'll be the worse for it.


Huh, apparently I know JavaScript. I didn't think I did.


The fact that developers add languages to their resumes that they have only touched on is a result of job postings that list incredible numbers of skills which are probably only touched on in the job itself. It took me 10 seconds to find a job posting on Craigslist, titled "Web Applications Programmer". Here are only a few lines from the "Position Requirements"

Fluent with PHP, Python, JavaScript, MySQL, HTML, XML, CSS, web services (SOAP, XML – RPC…) Knowledge of java, ActionScript, Flex and C# is an asset Experienced with AutoCAD, SolidWorks, Inventor, 3D Studio Max, Flash, Photoshop, Dreamweaver, Adobe Illustrator

The list goes on to include a bunch of other stuff, plus an array of other non-technical skills.

What do companies expect? Just to get an interview one might need to add something they've only touched on.


"You Don't Know JavaScript". Then, it says "With statements and why you shouldn't use them" is an advanced concept. I guess this post doesn't apply to hacker news :)


The author apparently has a rather low bar for attributing an advanced level of understanding.

> Understanding a methods 'arguments' variable and how it can be used to overload functions through arguments.length and make recursive calls through arguments.callee

The arguments object is one of the first things anyone learning about functions in JavaScript is introduced to. arguments.callee is a little more obscure, but not a particularly difficult concept.

> Advanced closures such as self-memoizing functions, partial functions, and the lovely (function(){})() call

Using an immediately-executed anonymous function to enforce a scope change and hide variables is a pretty common pattern. I suppose memoisation might belong on an 'advanced' list. As indicated later, the author clearly doesn't know what a partial function actually is.

> Function and html prototyping, the prototype chain, and how to use base JavaScript objects and functions (e.g. Array) to minimize coding

Surely this should be part of the basic level of understanding required of any JS programmer. Understanding the basic semantics of a language's object model is pretty essential to doing anything much with it.

> Object type and the use of instanceof

I once had to teach some novice programmers about JavaScript. We dealt with objects and the 'instanceof' operator in, I think, around the third session. Understanding the JS object model is basic knowledge.

> Regular expressions and expression compiling

This should be meat and drink for any professional programmer. There's nothing particularly weird about regular expressions in JavaScript. Fine, you can create regular expressions by writing new RegExp("my pattern as a string"), but so what? A quick read of any JS reference will reveal this fact; it's not exactly arcane knowledge.

> Knowing how to handle and use partial functions

Err, what? All functions in JavaScript are partial, insofar as there are arguments at which the value of the function is not defined. Perhaps the author meant partially applied functions, which are a completely different thing.

> With statements and why you shouldn't use them

The concept of 'with' statements is fairly straightforward. I admit that understanding just why they're generally a bad idea (and the problems they cause for people writing JS interpreters) requires an understanding of some subtleties of the scope model.

> The most difficult part of all, knowing how to tie all these tools together into clean, robust, fast, maintainable, and cross browser compatible code.

Finally, something that uncontentiously belongs on an 'advanced' list! Note that unlike the others, it doesn't turn on grasping how some particular language (mis)feature works. In other words, there's more to knowing what you're doing than knowing what the language does.


> Understanding the basic semantics of a language's object model is pretty essential to doing anything much with it.

This is usually true, but I'd argue Javascript is different. Due to the language's similarity to C (or Java), lots of beginners will basically write C in Javascript, use the very basic languages features, put all functions in the window scope, etc., and get away with it. It's enough to get some some working and pretty good-looking (on screen at least) Javascript code. Which is what the author is complaining about — that's not "knowing" Javascript.


No indeed, and I'm quite willing to concede that one can do a certain amount in JavaScript without knowing what the prototype property is. But you can't seriously be taking the line that knowing how to attach methods to an object's prototype is advanced knowledge: it's essential to any sort of OOP in JavaScript.

I suppose my basic objection here is that most of the criteria given set the bar for "advanced knowledge" so low that it would be met by any half-decent programmer with a decent working knowledge of the language. In other words, it's the absolute minimum I would expect of anyone I intended to hire for a position where a fair bit of JavaScript programming was required.

JavaScript is perhaps unusual amongst programming languages in that there are many more people than usual who've never got above the first rung on the ladder of understanding, but that doesn't mean the ladder is any shorter than for other languages.


> there's more to knowing what you're doing than knowing what the language does.

Sure, but knowing JavaScript isn't just knowing how to program; it also involves grasping how the various language (mis)features work.


Obviously. All I'm claiming is that knowledge of the language attributes listed isn't sufficient for being an advanced JavaScript programmer, not that it's not necessary.


Understood, but I think providing a list of attributes that you consider sufficiently advanced would be far more constructive / interesting.


I think raganwald has already put the case better than I could, further up the thread: the mark of an advanced programmer is being able to use her knowledge of the language to write programs that solve interesting or difficult problems. Admittedly that's not JavaScript-specific, but one can easily specialise this general criterion by reference to specific language attributes and types of tasks which the language is commonly employed to solve (DOM scripting etc.).

That's all a bit hand-wavy, so here are some more concrete suggestions. Even in these days of Node.js et al, JS is mainly used for developing web frontends, so this will be heavily slanted towards those sorts of issues. An advanced JavaScript programmer should be able to:

* Develop her own DOM library along the lines of the functionality provided by jQuery or YUI: a CSS selector engine, DOM traversal, element manipulation, all wrapped in a clean and well thought-out API.

* Build an extensible UI toolkit suitable for writing the frontend of a CMS, capable of handling numerous different object types, and communicating with the backend via a specified serialisation protocol.

* Write a testing framework with an equal level of features and stability as common current ones, such as QUnit.

* Create a form validation DSL capable of handling not just simple binary cases and regex-based validation of input fields, but the specification of more complex dependency relationships and requirements. For bonus points, tie it into the backend so the same code generates the frontend DSL code and the backend validation rules, ensuring that they always harmonise.

* Develop complex (as in, complex to implement using the DOM) interface elements such as sliders, drag-and-drop controls etc.

Again, I'm not saying our hypothetical advanced JS hacker should have done all this—just that she should be able to. Note that while some of these require quite extensive knowledge of the DOM and cross-browser issues, one could easily construct examples which pitched more towards different specialities—those above are just problems I'm somewhat familiar with.


>Understanding a methods 'arguments' variable and how it can be used to overload functions through arguments.length and make recursive calls through arguments.callee

seems he doesn't know "use strict"


Yes I do, if you're using strict this won't work.


just saying, mentioning a well known anti pattern as "advanced level of understanding" is kinda odd.

other than that i believe most of us know that there are shitloads (and then some) of bad javascript devs out there.


It is an anti-pattern but it's one that every framework takes advantage of. jQuery and Dojo use it heavily and it can be dangerous if you plan on incorporating it in strict mode. I will note strict mode in the article, thanks for pointing it out.


You don't know what I know.


I've seen a repetitive pattern of programmers dressing their resumes with technologies that they don't really know, but have merely touched on.

I always find attitudes toward resumes to be interesting. The entire reason we mention technologies on resumes is because we used them, and (assuming we're not completely desperate) we want to use them again. The mere fact that you have done anything in a language gives you a foot up on the person who truly has zero exposure to it. Experience is compounding, and each small step can be worth dramatically more than the last.

I've met too many people who believe that in order to list a technology on your resume, you must be an 'expert' in it, where the meaning of 'expert' varies wildly. These tend to be the same people who think that "evaluating a prospective hire," means, "find any point of weakness and exploit it." It's a weird, insecure defensiveness. A need to prove candidates wrong, rather than gaining an understanding of their skill set and experience.


A former coworker once caught someone whose claimed PostScript experience consisted of clicking "Print to File". I consider that nothing short of fraud. If a skill is on my résumé, I am offering to rent it to you for substantial money, which means at a minimum that I have already developed it to the point of being commercially useful. If there is no honest way for me to claim I've dabbled a little and I hope to be useless for less time than some others, it's because nobody has much reason to believe my uninformed self-assessment or care very much even when it's true.

That said, we once hired a guy who didn't know any Java (actually it was the same guy as above), because the interview made it perfectly obvious that given his intelligence and fluency in similar languages, picking up Java was not going to be a problem for him. He did not try to find an excuse to smuggle Java into his résumé, he was honest and let us make the call, and it worked out fine for both of us. If he had cram-studied Java and tried to pass himself off as experienced, we would have caught him being incompetent or dishonest or both, and that would have ended the interview.


A former coworker once caught someone whose claimed PostScript experience consisted of clicking "Print to File"

Was that deceit, or tremendous ignorance?

It seems to me that there's a huge problem with resumes and interviewing regarding unknown unknowns. 1-10 ratings, for example, vary wildly depending on how much you don't know that you don't know. When I graduated college, I was a 9/10 in C++. Now I'm about a 6, even though I'm ten times the C++ programmer that I was. :-) But I don't dare tell a recruiter that...

I do agree entirely with this statement of yours: at a minimum that I have already developed it to the point of being commercially useful

Which is sort of my point. You can have employed a language or technology, professionally, to solve a problem, gaining very meaningful experience, without coming anywhere close to being an expert, or even meeting most people's requirements for 'knowing' something. I'm certainly not saying that people should list anything technology they can conceive, on the most tenuous bases they can rationalize.


I have seen resumes with 20 different languages. I simply email them to rate on a scale of 1 to 10, how good are you with each language. (So that I can have interview questions on their better language). Surprisingly (to me) or maybe not surprisingly, a lot of such people never get back to me on their ratings at all. It could be the same "weird, insecure defensiveness" you are talking about.


I can't speak for those people, but I might be put off by a request for 1-10 language ratings, rather than asking what my core skills are, or something about choosing technologies for a given problem. 1-10 ratings strike me as a bit like, "what are your weaknesses?"




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: