Slashdot Mirror
How Much JavaScript Do You Need To Know For an Entry-Level Job?
Nerval's Lobster writes: JavaScript is a programming language that's easy to pick up, but extremely difficult to master. Even some of its beginner-level functions are decidedly not beginner-friendly. When someone lands their first JavaScript job, they're going to want to know as much as possible, if only so they can navigate through some of the language's trickier aspects without needing to ask for help. Developer Jeff Cogswell picked through JavaScript and came away with a couple of lists of what he thought were the minimum baseline of skills for JavaScript use in a work context. That list included understanding how to use built-in objects, functions , closures, and DOM (Document Object Model). While his points are comprehensive, not everyone will necessarily agree with what he lists (and doesn't list).
Java != JavaScript; not even close, really.
AMEN! The "best" part about Javascript is that if you don't use that stupid HACK:
"use strict";
at the beginning of your .js file it will behave _worse_ then shitty BASIC. Didn't we learn _anything_ about using variable without declaring them??
"Javascript: 10 days for the designer, 10 years of frustrations for users"
* http://www.computer.org/csdl/m...
PHP is another fucking retarded language.
Why the hell does the internet run on 2 of the shittiest languages ever half-assed designed??
> What's dumber is when people defend the dumbness as if it's some kind of a feature or a benefit.
You're talking about automatic-semi-colon insertion aren't ?
Someone needs to be taken out back and shot for all the pain and suffering that bullshit "feature" has caused.
If you want an entry level programming job and don't have any experience, you'd had better made something non-trivial on your own time that you can show in an interview and explain the code. If I'm skimming your code and I see you picked a certain data structure or implemented a algorithm when there is more than one way to do it, you should be able to explain your reasoning for coding it the way you did. Also make sure you learn at least the basics of one of the popular frameworks and use it in your demo.
So make a Javascript web app, or something on the server side with a free or low cost hosting account. Make it functional, make it as bug proof as you can, make the code clean and easy to read, and be prepared to show it to a skeptical audience. Think of your interview as an audition and your code as the music you're going to play.
If you can't make something to show, you don't know enough Javascript yet.
Open the "Reply to This" link in a new tab and you'll get the no-JS version of the comment composition form, which I'm using to enter this very comment.
Slashdot is still quite useable without javascript if you use the Classic discussion system, I find.
Disclaimer: IANAL. This post is, however, legal advice, and creates an attorney-client relationship.
I've been working in JS for years and there is no such thing as some "minimal amount" you need to know; the language and the DOM are just too fucking disorganized and sprawling. The syntax is garbage and constantly evolving, who can remember the differences between innerText and textContent? Then there are the platform specific inconsistencies: event handlers or Ajax requests are maddening without external libraries. Then there is the pseudo-standard tooling for which there is always 2+ competing solutions: NPM and Bower for asset management, CommonJS and AMD and WebPack for packaging, Gulp and Grunt for builds, Closure Compiler and Uglify for minimization/compiling ... it's maddening!
Trying to keep even a fraction of that in your head is impossible. If an employer wanted me to do an intense coding session without Google, I would laugh and just walk out of the interview.
Why not just read the good parts
Because that's not really a Javascript guide, but rather a concept of how to use Javascript once you already know it. If that's the only book you have, then you'll be missing a lot of Javascript.
Which is not to disparage the book, it's an excellent book.
"First they came for the slanderers and i said nothing."
You've not used Microsoft's ASP.NET MVC, have you? you define a view model (class) and add attributes to the properties of that class that define constraints. When HTML is rendered to the client, the html-helpers make use of the attributes to add client-side javascript for validation. When a post to the server brings back the same object, you can check it's valid in your Controller, with ModelState.IsValid - and hence, you do get the same validation on the client-side as well as the server. Better still, is the MVC approach doesn't expect the javascript to even execute on the client-side. It's just nice if it does.
And of course no JS IDE is remotely as forgiving or useful as it might be because there is no way at compile time to figure out what an object *is* beyond some simple inferences.
This is the reason the likes of Typescript, GWT and other JS generators exist at all. Javascript is treated as the problem to solve. e.g. Typescript extends JS with modules, classes, interfaces, typechecking and so on. The compiler can use those to catch errors at compile time instead of runtime and it can emit functionally equivalent JS. Stuff that allows an IDE to construct an AST and offer refactoring, method signatures and other useful functionality they've enjoyed for years in other languages. It even a specialised function where "this" behaves in a sane way. On the whole, programming Typescript is a lot more pleasant than JS but it's still a thin veneer.