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

Comments

Entry level job?

[Anonymous Coward]

There are no entry level jobs. Not for Americans at least.

Re:Entry level job?

[Anonymous Coward]

You should apply for Indian citizenship; it'll make getting a job in the US much easier than having a US citizenship.

bullshit

[zr]

> JavaScript is a programming language that's easy to pick up

this statement is the single biggest source of damage to the ecosystem of javascript.

Re:bullshit

[Anonymous Coward]

I've been programming professionally since the 1970s. I cut my teeth on COBOL, ALGOL, FORTRAN, and PL/I. Then I did years of Ada, a few months of Smalltalk, some Modula-2, and years of C and C++. I very briefly used Objective-C on actual NeXT systems. Then came a decade of Java, with some Delphi, VB and Perl. That was followed by some time with PHP, Ruby and JavaScript. Of all of those languages, JavaScript was the hardest to learn, and even after using it for years, it is the hardest to use. It's just so fucking awful, and I've worked with some pretty awful languages in the past. So much of it is just plain dumb. It's the kind of dumb that just shouldn't happen. It's the kind of dumb that shouldn't be allowed to exist 20 years on, even if it was first introduced during a rushed release! What's dumber is when people defend the dumbness as if it's some kind of a feature or a benefit. It's neither of those. It's just dumbness gone wild. It's fucking idiotic that it has taken over 20 years for JavaScript to get something that barely resembles a usable form of object orientation. It's stupid that its standard library is so terribly lacking, and what is there is mighty shitty. It's beyond belief how bad its type system is, and how awful its automatic type conversions are. Something is really fucking wrong when a so-called 'modern' language is worse than the ones developed 20 or 30 years prior to it, back when programming language design was in its infancy. That's right: the people who developed the earliest programming languages managed to do a much better job at it than those who have created JavaScript, decades later. In the 1980s and 1990s, I never though I'd be dealing with a programming language as shitty as JavaScript, especially so far into the future. We could have done great things, yet now we're saddled with the worst programming language around.

Re:bullshit

[Anonymous Coward]

Really, the greatest thing about JavaScript is that you're very unlikely to run across ridiculous things like an "abstract factory factory".

Instead, you run across every JavaScript developer trying their best to fake class OO using prototypes. Each one uses an approach that's different from every other developer, and each has its own set of serious limitations. Worst of all, none of them are compatible with each other.

Languages that compile down to JavaScript, such as CoffeeScript, TypeScript, and Dart, are so popular because they add real class OO. Hell, even ECMAScript 6 is adding real class OO. Classes, not prototypes, are the only practical tool. Prototypes are a detriment; they are a sham.

Re:bullshit

[UnknownSoldier]

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.

Re:bullshit

[DrXym]

Classes are an incredibly powerful way to encapsulate functionality. Javascript has never had the proper concept of a class (let alone inheritance) so we have half assed equivalents such as prototypes, bind methods, or function constructors which attach functions to raw object classes. Aside from being half assed, they're inefficient in different ways. Even understanding how the "this" keyword works is a nightmare because unlike sane OO languages, "this" can point at the object, nothing, or something else such as a toplevel window object depending on where it's used from. So it's not uncommon to see code where someone assigns "that" to "this" to work around some issue. Add in other esoteric issues like scoping rules for var and it's just a nightmare.

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.

Ahh Dice

[Verloc]

Last week it was "How much C++ do you need to know for an entry level job"

next week it'll be "How much Python do you need for an entry level job"

Must be nice crowd sourcing your job requirements from Slashdot.

Re:Ahh Dice

[Livius]

Followed by,

"I know all the languages; what else do I need to get an entry level job. Any job. I haven't worked in years -- I'm desperate! Please!"

High unemployment has a terrible social cost.

Re:Yuck

[Anonymous Coward]

Java != JavaScript; not even close, really.

Expert knowledge of tomorrow's framework

[i_ate_god]

While Angular and React might be all the rage today, you're expected to be an expert in whatever framework comes out tomorrow.

You should be able to write the same Todo List application several thousand times, justifying the existence of each one.

You should also demonstrate a strong desire to re-implement every single piece of software in existence in Javascript, including Linux (http://bellard.org/jslinux/), 8bit Console Emulators (https://fir.sh/projects/jsnes/), and possibly the software that drives your Kuerig. For example, I would expect you to tell me that you're just dying to start a new github project where you'll re-implement MS Flight Simulator 10 in Javascript, and how awesome the cockpit checklist feature will be.

You must demonstrate a complete misunderstanding of the differences between asynchronous and concurrent, and you must also be able to give a short presentation on what "web scale" means, without being able to explain it. You'll probably win a few favors by throwing in the term "cloud".

This and more, is what it takes to be a 21st century javascript developer.

Re:Yuck

[Anonymous Coward]

Considering the comment, glad you did.

Blinders

[Luthair]

I think the author is wearing blinders based on his previous positions. As someone who has spent the past 4-years 60-70% writing JS (and irregularly since the 90s) most of what he considers important is almost never used.

Re:Blinders

[Anonymous Coward]

I wholeheartedly agree.

1) You mostly do not want to manipulate the dom directly. Use templates/css to do as much as possible (so your designer has the freedom to fiddle with it).
2) List most object based languages, you do not want to actually focus on creating/extending a bunch of objects.

Your goal is to map the data from the server (most likely JSON) into something the View can use (most likely related to your choice of template technology).
Since you likely have multiple views using the same data, you may need to store it in a model to be handed to each of them or transformed on demand.

So know JSON. Know data structures, (arrays, objects, maps, sets). Know how to bind functions. Understand scoping. Then know how to hook into templates.

Also, for the sake of anyone who may work with your code in the future, learn a unit test framework. Use it. Understand the difference between unit and system tests and favor unit tests.

Re:Yuck

[johnsnails]

http://stackoverflow.com/a/245... What's the difference between JavaScript and Java?

One is essentially a toy, designed for writing small pieces of code, and traditionally used and abused by inexperienced programmers.

The other is a scripting language for web browsers.

Learning it now

[Rinikusu]

Most of my career has been bumbling along doing systems programming in c, perl, python, and lately c# writing a lot of console apps/utilities. Unfortunately, everyone now wants web developers and the like, so I find myself in the unenviable position of playing "catch up" and facing the possibility of having to return to a jr. role due to "lack of experience", but I'm not so proud to do these things if it gives me a steady paycheck with room for advancement... I digress...

I'm going through Eloquent Javascript at the moment with a look towards the SImpson "You don't know" series to get a little more in-depth in some of the areas that I see people having issues with.. followed by working with node and angular (basically, the MEAN stack). I don't know where this would put me vs "beginners", but it's the route I'm headed down.. :P

Crockford's JavaScript: The Good Parts

[tepples]

You just need to read [JavaScript: The Definitive Guide].

Read it cover to cover a couple times

Why not just read the good parts? Bonus: knowing the good parts of JavaScript may help you tame the fractal that is PHP as well.

Re:Crockford's JavaScript: The Good Parts

[maroberts]

The problem is that whilst Crockford will teach you to write good JavaScript, as often as not you have to wade through and understand the crappy JavaScript that has been written by someone who hasn't read that book, or any others from all appearances. And then to top it off, the sick bastard has minified and/or obfuscified the fuck out of it.

Reply to This, without script

[tepples]

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.

There is no core to Javascript.

[Anonymous Coward]

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.

By definition, the answer is "none"

[melchoir55]

By definition, the answer is "none". An entry level position doesn't need to require experience in a given programming language. It needs to require some familiarity with programming, sure. There is all kinds of stuff you probably should look for in such an individual. Aptitude to learn (from your senior and mid level developers who you picked partly because they are good at sharing knowledge), existing understanding of symbolic logic, common software design concepts like when to use sets instead of lists, the list (pun) goes on.

It is really absurd how snobby software developers are about who joins their ranks. Part of the absurd job req ads in tech aren't just due to hr managers trying to game the h1b system. They are in part there because of clueless software devs who have been moved into management because that is (for god knows what reason) considered a normal career path. Don't respond with "it is better to have no one then to have a bad coder!". You're right, but inexperience with a given language doesn't mean they won't be productive with that language in two weeks to a month. This is the very definition of entry level.

Re:Node is DRY: Don't Repeat Yourself

[Guildor]

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.