Never thought Windows 8 app development using WinJS + JavaScript + HTML5 + CSS3 would be so easy and never thought it would be so complicated… to open external page in the browser programmatically. After our first Windows Store certification fail we wanted to add privacy policy link in the Settings charm, which would open our online privacy policy in
JavaScript Archive
Eval and evil differ by only one letter, ever thought about that? I am just kidding though. Eval in itself is not at all evil, actually it is rather handy – it evaluates a string and if that string is a JavaScript statement, executes it. Nothing bad about that, however many JavaScript developers have misused eval() and did things like: eval(‘document.’ + myVariable + ‘.style.color= “#000000″‘); This makes code injection attacks possible. Since eval() will try to read whatever the myVariable contains. Using eval() in this way makes the code harder to maintain and debug. All in all, you should start learning to avoid eval() since in ECMAScript 5 “strict mode” eval is not allowed and will probably be deprecated or removed in ECMAScript
When I search online for good JavaScript code examples there is one thing that I immediately look for inside that code. Does it have == or === comparison operators (double or triple equal signs). The reason for doing that is that it gives me an idea of how reliable the code is. I understand that this is not the only reliability indicator, but it is pretty important. However, I have noticed that during the last couple of years many JavaScript developers became aware of the possible pitfalls of == (double equal) comparison. Maybe because of Douglas Crockford, maybe because of JSLint or JSHint. Nobody knows why, but I definitely find less and less examples with == in the code… So, what is all the fuzz about these comparison operators? Well you might have guessed it – they are one of the bad parts of JavaScript language. Consider this example: ‘ ‘ == ‘0’ // false 0 == ‘ ‘ // true 0 == ‘0’ // true ‘ \t\r\n ‘ == 0 // true *Example taken from Douglas Crockford’s book: JavaScript the Good Parts, which I highly recommend for new JS developers. What was going through the heads of JavaScript language creators when this was allowed to happen?! All in all, the general suggestions would be to use the === and !== comparison operators. Unless, you are a seasoned JavaScript developer avoid == and != . Even if you are seasoned developer there must be a very specific reason why you choose to use the less predictable comparison operators, right
As you may know JavaScript has some of the best features that modern programming languages can offer, however it also has some really terrible parts. This is going to be a series of short posts about those terrible parts. My intention is to shed some light on these problems and help you mitigate or avoid them entirely. I will start of with my personal favorite – plus operator. JavaScript has this terrible design flaw – plus operator is overloaded. Meaning that it can have two distinct behaviors depending on the situation. The same operator can both add and concatenate. Let me give some examples of this weird behavior: var foo = ” + 2 + 2; //foo === ’22’ var bar = 2 + 2 + ‘2’; //bar === ’42’ var baz = 2 + ‘2’ + 2; //baz === ‘222’ var qux = ‘2’ + 2 + 2; //qux === ‘222’ console.log(“The sum is ” + baz + qux); //The sum is 222222 Basically, when you mix numbers with strings bad things start to happen. In order to avoid problems with addition and concatenation try to ensure that all of your operands are of the same type: numbers or strings. This will ensure that the plus operator is working in the expected mode and will not switch in the middle of you operation. Thank you for reading, everyone
Once in a while, you stumble upon a JavaScript tool that is so awesome that it blows your mind. While I was reading through Rebecca Murphey’s blog I found JS-Assessment. What it actually is is “a test-driven approach to assessing JavaScript skills”. In essence it is a bunch of tasks which have tests written for them and you have to come up with functions to pass the tests. Does not seem very extraordinary when you put it like that. However, consider the fact that the whole thing is written in JavaScript! As described in the JS-Assessment GIT Hub page the software underneath the project consists of “RequireJS for dependency management and Mocha and expect.js for the tests themselves.” And everything runs inside a node.js server