You Don't Know JavaScript
w2lessons.com
w2lessons.com
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?
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").
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".
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.
"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')
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.
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.
> 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.
Sure, but knowing JavaScript isn't just knowing how to program; it also involves grasping how the various language (mis)features work.
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.
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.
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.
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?
If you don't read things that don't bend over backwards to avoid offending people, you'll be the worse for it.
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.
seems he doesn't know "use strict"
other than that i believe most of us know that there are shitloads (and then some) of bad javascript devs out there.
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.
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.
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.