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).
There are no entry level jobs. Not for Americans at least.
All of it.
> 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.
If it's a web design job, you probably just steal someone else's modules and code like most web designers. Complete with not even changing the link back to their website.
For other jobs, why the hell are you using the abomination that is JavaScript anyway?
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.
Java != JavaScript; not even close, really.
Next question.
For a number of websites that I visit routinely, I disable javascript - too much overload. If you want to work for those websites, I will ignore you. Learn to code clean html without javascript - much better.
Java sounds like a great reason to get out of IT entirely!
also 90 years of experience with Windows 10.
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
... is the ability to say "No" to an idiotic team leader who thinks it's OK to display nothing but a blank page when the client is behind a company firewall and JS is blocked or constrained or not available on a low-power embedded system.
Graceful degradation seems to be a lost art among many so-called "JS experts" who seem to have no idea how to make a website resilient to client diversity. If you can deal with their nonsense and show them a better way, you'll be worth your weight in gold to the company.
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.
I'm god, but it's a bit of a drag really...
Real programmers use C and provide the foundation that web kiddies rely on to get anything done.
Now get off my lawn.
Considering the comment, glad you did.
Your comment is a perfect example of Cockfoster's Law in action: When a professional computer programmer with decades of experience presents a thorough and insightful analysis of a contemporary programming language, some shithead will always come along and babble about getting off of lawns.
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.
Nothing with "JS" in its name should be running on the back end.
I agree, but the only serious competitor at this point is go.
Honestly, js on the server be nice... If you code it right, and declare things rather than code them. Also babeljs rocks.
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.
A few months working with jQuery.... Events.... DOM on realistic websites, some fiddling with Prototype.js, and you'll be fine.
Thas' assuming you know programming in general, and not just Javascript, and had time to learn Javascript's language quirks, such as functions, variables, conditionals, ===, strings, integers, dates, custom objects, and basic structures.
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
If you were me, you'd be good lookin'. - six string samurai
STFU already Dice. We won't fall for your click bait articles.
The basics of JavaScript you need to know are:
Then, you need to learn the basics of the libraries that are advertised in the job posting, which will likely be:
Finally, you need to know how to look stuff up on Mozilla Developer Network, which is the only JavaScript documentation worth looking at anymore.
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.
It's interesting to me to compare Cogswell's post to Matt Briggs' one on the role of senior developers here. http://mattbriggs.net/blog/201...
It seems to me that Briggs has the right of things; the skills that bring real value to development efforts are less connected with specific language functions or quirks and more associated with understanding how to develop software projects.
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.
Pick a mainstream web page as an example of visually ugly [JavaScript] code! They're everywhere!
That's because mainstream web sites have minified their scripts. This process removes blank space and shortens variable names in order to pass fewer bytes over the wire.
Stop trying to say that it is. It happens with Node, Angular, and other stuff to a lesser extent, but jQuery seems to be the de facto JS gap-filler that everyone insists is part of core JS skills.
But even worse are the feckless noobs who say they don't know JS, but know jQuery instead. That's like saying "I don't know English, but I know its verbs."
The biggest problem with it are the twits who are using [ECMAScript] on the server
Without using the same language on the server and client, and without repeating yourself, how else are you supposed to have both client and server perform the same input validation logic?
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.
Say you're designing the front page of a news or blog site. You want anonymous visitors on small "mobile" screens to see a list of headlines, but you want anonymous visitors on larger "desktop" screens to see headlines and a one-sentence summary of an article. Anonymous Coward says script is better than User-agent sniffing. How would you implement sending only headlines for mobile and headlines plus first sentence for desktop?
I swear to God, you can pick any 10 words at random from a dictionary and 4 of them will be the name of some half-baked framework.
So in what language do you write input validation logic for the server, which gets translated into JavaScript to be used as input pre-validation logic on the client? Writing it twice, once in JavaScript and once in your preferred server-side language, is repeating yourself and can lead to subtle disagreements in behavior between the two implementations.
So how do you deploy your client-side C code to 14 different client platforms? Consider that some of these platforms have onerous developer qualifications designed to discriminate against startups, a devkit fee of thousands of dollars, and final veto power over apps. I guess perhaps you could use Emscripten to, well, compile your C into JavaScript.
Forall X? Honestly, the DHI shilling has a mediumish level of intrinsic offensiveness which is greatly exacerbated by lazy content-mill plugs and gender trolling. If you're going to abuse a non-captive audience, there's a cap on the level of abuse possible. And if you didn't know what to do with Slashdot, which you plainly don't, why buy it? What was the theory? Enrage, bore, and alienate the readership, then...profit?
I think I'm going to go on a Slashdot vacation until there are no more dice plugs. Any suggestions for alternatives? Soylent news seems like it might be nice one day, but it currently has less traffic the official star wars holiday special forums. Reddit is full of beautiful microcommunities of people who can go days without experiencing a complete thought. Maybe I'll just go reread old k5 posts from 2000.
It takes a freaking rocket scientist to properly check for 'equals' in that language
In both PHP and JavaScript, === checks whether two expressions have the same type and value. Anyone who read Douglas Crockford's JavaScript: The Good Parts knows that. Now can I work for NASA?
Your complaint is that a script language is not Object Oriented enough? Are you the same guy who complains about Perl and Python not being Semaphore ready? It's a scripting language! Scripting languages are not really intended to be object oriented, they are intended for task management with pragmatic functionality. JS has about the same Object Orientedness of Python or Bash. You can use those scripting languages for some pretty complex stuff and define all the functions you want. You have a massive performance penalty, but you can.
There are surely a couple of valid complaints about JavaScript. Like:
1. Lack of consistent implementation and/or libraries by every browser vendor and often even version to version in the same vendor.
2. Lack of documentation on functions that are built in, so it's a huge amount of trial and error.
To TFA's question, just like the same exact question 2 weeks ago about C++ it depends. If you are creating a custom front end for an ERP system, you had best be up on lots of JS, including all of the various browser implementations your app needs to support. If you are writing simple proxy auto configurations or simple web pages you need to understand coding more than subtleties with the language.
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
Since personnel became HR.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
I have seen shit code in every language I have worked with. Starting with Cobol and Fortran, then to Pascal, C, Perl, Python, and various *SH. The language is not the reason for the shit code, it's the programmer.
Want to read some great JS, go get a WordPress rootkit. JS is used to it's fullest in those (no I don't use them, I spent years learning how to hunt them down). PAC files are another area that usually has well written JS, and plenty of examples exist.
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
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.
...the proper answer should be "none."
I don't really care what languages people know when I'm interviewing. I care how they think, that they have the ability to solve problems, and that they know how to research to get themselves out of holes. The specifics of any given language can be learned on the job by a reasonably smart person who understands how to break problems down and solve them algorithmically, and if they know how to use Google they'll be able to pick up the syntax of whatever the language of the day happens to be.
I really don't understand this fascination with checklists and expecting people to have memorized giant chunks of specific languages or libraries when it comes to programming. Just show me some stuff that you've built on your own time, in any language, and talk with me about it intelligently and convince me that you didn't plagiarize the code. That's what matters most at entry level, not whether or not somebody has used closures or promises or whatever. They can learn that stuff as they go, usually in short order, if they're actually smart.
picpix image polls. create - share - vote. fun!
Write a shopping list app. If you have a significant other, you'll be a hero, and besides todo apps are so 1990. Use a framework like angularjs to learn front end MVW, and learn how to consume web service calls that deliver json to populate your model. There will be enough javascript in this small app for you to wrap your head around it. In an interview, smugly say "I know jquery, but I avoid it". That much should at least get you out of the bottom of the pack.
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.
This would have been more funny 10 years ago when people still said 'Java applet' without laughing and both statements could have been applied to either language. I rather like the top answer though: 'Java and Javascript are similar like Car and Carpet are similar'.
I am TheRaven on Soylent News
Assembler. C.
Not read that book, but if that's everything, it's not even a beginners book! So I'm guessing he covered the first couple of chapters.
There's a nice paper from the developers of the Apple Newton, which argues that class-based OO maps very well to model objects (where you have lots of objects that are mostly the same), whereas prototype-based OO is a better fit for views, where you want a bit of customisation for almost every instance
Perhaps I'm kinda dense today ... I just couldn't find that 'nice paper' that you have mentioned
If there is a link somewhere, would you kindly share the link with us?
Thanks!!
Muchas Gracias, Señor Edward Snowden !
When I was a hiring manager the joke was "I'll hire anybody that spell computer"
Do you know what jquery is? Do you know what DOM means? You're hired!
None. But it would be weird if you didn't.
Religion is what happens when nature strikes and groupthink goes wrong.
The key is to really understand how closures work (and by extension, why javascript "classes" look the way they do). If you manage that, the rest of the language just comes easy and shouldn't be an issue. ;P
JS alone will get you nowhere. JS is part of todays web ecosystem. And developing for the web today is so hard, people doing it are either inexperienced and naive or - like me - sort-of specialized/focused in some vertical toolstack like LAMP + Wordpress + Bootstrap or something and never really happy with their results.
The problem is, that you have to know HTML5, CSS3, DOM perhaps some jQuery UI or HTML canvas stuff + UX + responsice webdesign + Typography & Layout + a workable set of backend tools (LAMP or such) to do anything usefull with JS. Which makes the whole thing basically impossible for an "entry level" developer to learn.
I suggest you find a team that has a working development pipeline, uses versioning (far to many webshops don't) and puts out good results and learn by doing.
As for JS in general - there's a lot of academic ragging on JS here, but most of it misses the point about JS entirely:
JS alone is like a mix of Python and Ruby made to look like Java (yeah, I know) and doesn't look very modern. However, what makes JS interesting is the fact that as a platform it is available basically anywhere. JS is todays PC of platforms. A toy, not taken seriously by anyone, but available for cheap/free everywhere. Which is why it is going to win in the long run, just like the toy-technology x86 did, eventually squishing every other architecture like a bug on it's way to total world dominance. In the early eighties, people would've laughed you out of the room for predicting that.
I personally wouldn't be suprised if JS eventually replaces PHP, Java and Co. on the serverside and takes over everything but system development on the clientside within the next decade or two. Be it natively or with languages that cross-compile to JS ... We already have a ton of those. Google is heading for bringing the second half of humanity online, and as far as I can tell, they're succeeding. Which in itself does put JS in a future-safe position.
JS, Browsers and the clientside webstack are a mess, but they are truely cross-platform, open and not controlled by a single entity. Very much like x86.
So no matter what you're doing, getting into JS at a professional level one way or the other isn't the worst thing to do.
My 2 cents.
We suffer more in our imagination than in reality. - Seneca
/Oblg. /sarcasm Right around the time Python was created ...
Sad, I know.
> a consistent type system
Mwuahaha. I was following you until you said that. With JS you get stupid automatic silent conversions that are the source of hidden bugs. And just to drive the point home (JS starts @ 1:22 )
* https://www.destroyallsoftware...
Javascript's == operator is fundamentally broken as this chart shows:
* http://dorey.github.io/JavaScr...
When even Douglass Crockford, who wrote the excellent "Javascript: The good parts" says @34:31 "Why am I betting my life on this piece of crap" in this video "Javascript: The Better Parts"
* https://www.youtube.com/watch?...
You know there is something horribly broken with JS.
I would (almost) rather someone force me to learn PERL, rather than ever seriously programming in javascript again.
The thing I noticed about Perl is that 5 minutes after you have written something that works, you could look at it and it would be completely unclear how or why it works.
If you are not allowed to question your government then the government has answered your question.
The problem with JavaScript is that it appears easy, but in reality it is a fairly complex language that requires skilled programmers to use correctly. I would be more apt to hire an entry level programmer for C/C++/C#, and leave JavaScript for the more senior developers who can use it correctly.
Someone without a lot of experience with good coding practices and software architecture concepts may be able to write some "working" JavaScript, but it will probably be unorganized spaghetti code that is impossible to maintain, inefficient, and probably contains a ton of undetected bugs.
I am a team lead, and If you want to get hired at the company I work for.. all you have to be is smart and not too socially toxic.
Sure, we give a programming test that basically asks "have you ever written any code in any language?" 90% of applicants fail this test (Think Fibonacci or leap year level difficulty, not 9 queens or tower of Hanoi hard). Any applicant that passes the "have you ever written a line of code" test, we just talk.
I don't care if you know node.js or angular.js or Knockout or whatever. Angular and node are both 6 years old. If I required every developer to know everything about a 6 year old framework, what happens when something better comes along? How hard will it be to get them to use the new thing, or learn it. If I hire a smart person who can learn whatever, then when something new comes along they can learn that too.
Encyclopedic knowledge is not a selling point by itself. FAQs are free, brains are expensive. Hire the brains and feed them FAQs, not the other way around.
Without a backend database, how does a site accept reader comments? Without client-side scripting, how does the site know when to send a particular image so as not to waste the server's and client's valuable data transfer quota on sending photos and illustrations that the user will end up not viewing?
The minified JavaScript file is smaller than the corresponding file before minification even after both are gzip compressed.
Great minds think alike ...
Wrote this yesterday on the other site ...
2bits.com, Inc: Drupal, WordPress, and LAMP performance tuning.
So how do you deploy your client-side C code to 14 different client platforms? Consider that some of these platforms [are controlled by an entity with] final veto power over apps
Package it using an exploit kit ;-)
We saw how badly that went for George Hotz.
I haven't, directly, needed to write any Javascripts in over five years. I've fixed a few nit-wits hand-coded JS, but that's it.
When "coders" routinely became too incompetent to see beyond the syntax of the one language they somewhat know. This is the main reason so much bad code is around.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
except when someone else's code that you call has conveniently changed the variable type on you.
If the type of the value your code gets from someone else's code is either not documented or not as documented, you can A. report this as a bug in someone else's code, B. cast the values to the expected type before doing anything with them, or preferably C. both.
> There was value there
There was just rambling! ZERO arguments, 100% opinion. You seem to be of the *opinion* that having a string feeling equals "arguments": It doesn't. I'm modded troll by a troll, and the parent post this is about is the biggest troll post of all. More and more little kids on Slashdot with "opinions" unable to express ANY argument.
Without a backend database, how does a site accept reader comments? ;D
Last time I checked, files whee not abolished
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Using files complicates concurrent attempts to write, such as if two users attempt to leave a comment at the same time. By the time you write a library that guarantees correct locking behavior for concurrent writes, you might as well just use SQLite and be done with it.
JavaScript: The Good Parts
Unearthing the Excellence in JavaScript
By Douglas Crockford
https://kat.cr/douglas-crockfo...
Casteism
Yeah the Car/Carpet one is probably a better 'answer', but not as funny :P
Problems:
* You are comparing Perl to JS as if one replaced the other. Perl was never a client-side language. Or if it ever was, it was never a popular cross-platform option that didn't require a plug-in but certainly it wasn't in the contexts you've been referencing. And JS was primarily a client-side web language long before it ever became available and ultimately popular as a server-side option.
* You are reminiscing about things being long gone that are in fact still in place. I just wrote a Node app leveraging postgresql that in fact features an old-school submit with JavaScript intervening for client-side validation only.
* There being an explosion of libraries is not generally considered a weakness in a language unless you are required to use every last one of them to get anything done. I assure you, you are not. I don't even link jQuery half the time nowadays because most of the value adds it brings are now available through native JS or DOM features and browser support for standards (i.e. compatibility) are actually better now than they ever have been, not worse as you suggested.
It is not JavaScript's problem that you couldn't be bothered to learn anything new about the state of the technology since the first tech crash and given your client/server-side fail I'd wager you didn't understand what you were doing with the technology very well to begin with. And yes, it is obvious, painfully obvious, that you haven't learned a damned thing about web development since the late '90s. If you are lamenting the career that you no longer have in web development I highly recommend some introspection. If you're not up to learning something new every week, you're not cut out for it. And no, most of the new stuff isn't frivolous. It's evolution. There are some stupid and unfortunately popular libraries like Angular.js but I would never trade the DOM or CSS or JS as it is now for the way people had to do it in the '90s. It was a pain in the ass. And Node's had its growing pangs but overall it's !@#$ing amazing. Nothing else just works like core Node has across platforms for me (sadly, you can't make that claim about even some of the more popular modules just yet - too many Linux/Mac OS supremacists in the mix unfortunately).
I know I shouldn't feed the trolls ...
My day job IS using Javascript.
Don't assume.
Grow up with the ad hominem attacks already.
Every comment is its own file, obviously.
This carries three disadvantages compared to use of SQLite:
one command that comes to mind is: grep.
O(n).
If you want an index use Lucene.
So now you're recommending that the server administrator install the Java virtual machine, which is listed on the front page of Lucene's site as one of Lucene's dependencies, as a means of avoiding use of SQLite. Oracle's legal shenanigans aside, I was under the impression that switching to a plan that includes Java support was unaffordable to a lot of shared hosting customers.