This Week in JavaScript - 10 March 2014

Welcome to your weekly update of JavaScript news and goodies.

Features

Tells you what percentage of users can use your page based on the features you employ
JavaScript Tools of the Trade: JSBin
To Hell with jQuery - get jQuery out of your frontend and replace it with simpler, more performant CSS equivalents (video)
Creating and publishing a node.js module
Create an Analog Clock Using the Canvas - here’s how

About

The JavaScript Alternatives - Three languages compete to make JavaScript easier to write and faster to execute. Which to choose?
Why I don’t suggest JavaScript as a first programming language
How Node.js Got Big

List of languages that compile to JS
10 JavaScript editors and IDEs put to the test

Coding

Finding Array Elements with Array#indexOf
JavaScript Array: slice vs splice
JavaScript String: substring, substr, slice
Evaluating JavaScript code via eval() and new Function()
Truthy and Falsy Values in JavaScript - what do the terms actually mean?

Testing

Extending JavaScript with inline unit tests
JavaScript unit tests with YUI Test
Generating JUnit test reports with Jasmine 2.0
Headless Javascript testing with Jasmine 2.0
Unit Testing JavaScript

Bonus

Disable the User’s JavaScript Console - because you can

So what are your thoughts on the latest going-ons in the world of JavaScript? We’re all testing our code, right? Is JavaScript a good first language to learn?
Let us know and the debate can begin.

Please PM us if you have anything of interest for the next issue, and happy reading! - Paul & [URL=“http://www.sitepoint.com/forums/private.php?do=newpm&u=184222”]Pullo

Whether JavaScript is or isn’t a poor first language to learn depends on how it is taught. The way that JavaScript was written back in the Netscape days made it very different from all the other programming languages around. That made just about any other language a better choice for learning programming as very little of whay you could learn from JavaScript could be applied to make it easier to understand other languages. On the other hand properly written modrn JavaScript uses many of the same constructs as other languages.

Nicholas Zakas’s book “JavaScript for Web Developers” takes the same approach to teaching JavaScript as other books take to teaching other programming languages. This makes the book ideal for those who have already learnt one or more other languages to learn JavaScript properly as a serious programming language. I am not convinced that this type of programming book works as well for someone learning their first language and who is therefore unaware of many of the basic concepts of programming.

The fact that such a book exists does show though that JavaScript can be treated as a serious programming language and so there is no reason why JavaScript could not be used as a first language provided that it is taught the right way so as to properly teach those programming concepts that make learning additional languages so much easier.

As far as I am able to determine, the vast majority of courses teaching JavaScript do not teach it the right way (many are still teaching how to write JavaScript for Netscape). That you are more likely than not to be taking a history class rather than a programming class if you take a class that is teaching JavaScript as a first language is a good reason for NOT choosing to learn it as your first programming language. It will be much easier to determine if the JavaScript class is teaching programming or history if you already know another programming language and have a knowledge of programming concepts.

That article about disabling the console was interesting, but it’s fairly easy to get around.

All you have to do is to use the location bar to delete the custom console, which then returns control back to the standard one.


javascript:delete console

I tried this, but it didn’t work for me in Chrome.
I opened the console, ascertained that it was disabled, then entered “javascript:delete console” into the address bar, pressing return.
The console was still disabled.
Am I missing anything?

I checked FB using FireBug. That still works as expected :slight_smile:

I agree that how a language is taught makes a great difference.

I think the author’s point is that it’s not very good for “software engineering” and/or “end-to-end systems programming”, as its focus is too web-centric.
For example, I recently wrote a small desktop GUI that should do some basic file manipulation, then upload the altered files to an FTP server.
I ended up using Ruby, but briefly entertained having a go at writing it in JS. The file manipulation part and the FTP part put me off.

I recently read some kid’s page but can’t find it anymore, listing a bunch of vulnerabilities in the Chrome dev toolbar, where manipulating the console allowed an attacker to take control of the browser… wish I could find it. All I remember is the kid was 17 and had this long list of vulns, showing Javascript code for each exploit.

My search-fu is poor today. It was fairly recently tweeted.

That’s interesting - I tested using a local test page and things went well. I’ll try again tonight and see if I can get my results to differ.

Social engineering sucks, that’s for sure, but disabling the JS console in this way is like disabling the terminal on a Linux machine in case you enter rm -rf / or :(){:|:&};:

Aha, someone else who saw the post vaguely remembered the logo looked like a fire hydrant. Adding “hydrant” to my search suddenly brings it up :confused:

http://www.hydrantlabs.org/Security/Google/Chrome/

The vulnerabilities outlined in the post allow the following:
Detect the opening and executing of commands in the console. (Unpatched)
Prevent the execution of commands in the console (Unpatched)
Log the commands that are executed in the console (Unpatched)
Censor variables from being accessed/read from the console (Unpatched)
Other unexplored potential vulnerabilities that are children of these (Unpatched)
Use these vulnerabilities to execute arbitrary scripts on webpages that can be framed (Patched)

The exploits require little technical ability to exploit (many people can write some simple JavaScript), and the majority of them have remained unpatched for over a year. I hope that this post will help get those vulnerabilities fixed.

I don’t actually buy the “Facebook is doing it to protect you” line.

That’s interesting reading, poes.
Thank you.

Wouldn’t it be easier to just create a userscript to attach to your browser that runs that command just on those sites that try to disable the console? That way it would be a set once and forget (until you find another site that you need to add to the list) rather than having to enter it every time.

The following userscript will work in Google Chrome (tampermonkey) to reinstate the console. It should work in Firefox (GreaseMonkey) as well, may need slight alteration to work in Internet Explorer (depending on which userscript plugin you use).

// ==UserScript==
// @namespace     http://javascriptexample.net
// @author        Stephen Chapman
// @name          Fix console
// @description   Reinstates the console when one of the following sites disables it
// @include       http://facebook.com

// ==/UserScript==

delete console;

This is set and forget - the only time you’d need to change it is if you need to add an include statement for another stupid site.

It didn’t work for me either in Chrome.

Typing in the address bar in Chrome didn’t work for me either but setting it up as a userscript did.