91–100 of 115 posts
One caveat not mentioned is that while float is 64 bit floating point number, int is only 53 bit integer, unlike having 64 bit int in most other languages. Yeah, I've got bitten by this before causing a nasty bug.
Earlier quoted context omitted.
Uh, what's the reason for the downvote?
Perhaps that the reason for that is not some "bug" in JS?
It's why ES5 has bind to get around this.
Example from MDN [1]
this.x = 9;
var module = {
x: 81,
getX: function() { return this.x; }
};
module.getX(); // 81
var getX = module.getX;
getX(); // 9, because in this case, "this" refers to the global object
// Create a new function with 'this' bound to module
var boundGetX = getX.bind(module);
boundGetX(); // 81
var module = {
x: 81,
that: this,
getX: function() { return that.x; }
};
1. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
One caveat not mentioned is that while float is 64 bit floating point number, int is only 53 bit integer, unlike having 64 bit int in most other languages. Yeah, I've got bitten by this before causing a nasty bug.
[1]: 32-bit integers show up under the hood, in expressions such as `5000000000|0`. Both 0 and 5000000000 are precisely represented in JS's Number type, but you cannot (correctly) take a binary OR of the two.
Earlier quoted context omitted.
Uh, what's the reason for the downvote?
Probably because when you editorialize in your comment, you may get an adverse reaction.
Why do you think they decided to do this? Strict mode is to allow folks to transition their code to the new standard - and the new standard has made this decision to fix a flaw in JavaScript - it acknowledges its a hack to return the global object in this case.
So I'm less editorialising and more pointing out what is already known. Hope this helps.
Earlier quoted context omitted.
I haven't either, only that delete will cause code to be de-optimized.
Its main purpose is deleting a property from an object, which is a pretty slow operation on modern JS engines. Unless some code tests for the existence of a property, setting it to null is a better idea.
Though, I don't use delete much, I honestly don't worry about it much. In most contexts it's a bit of a premature optimization unless you are in a very low-level tool that will be used for example gaming, video or photo manipulation, there are probably better optimizations to make.
Earlier quoted context omitted.
Oh jeez, I just saw that the section you're referring to repeats the old canard about caching the length of an array when iterating over it. Come on, that can't still be good advice. It always struck me as ridiculous to begin with, but almost certainly now it's optimized away. Not to mention the suggestion you're talking about, which I bet would bite programmers for the reason you mention. Seems like a bad idiom, I'v…
I think nearly every JS engine now optimizes `for (...;i In fact, even `for` is likely an over-optimization. In nearly all JS code you can get away with just using `forEach` (or its friends).
Caching the array length still gives you a small speed boost in most browsers, but it's probably an over optimisation unless you're doing something really intensive.
I think there's no point trying to avoid memory leaks in older versions of IE. Circular references due to closures are too common and it's not worth messing with your code. IE users are probably used to getting a horrible user experience anyway. I'm sure they can cope with a few browser freezes/crashes every once in a while - They know how to take a beating :p
It was very important for IE <=6. Early AJAX web apps like GMail ~2004 were quite hard to get right - avoid most memory JS leaks or the memory consumption got out of hand too fast. That was in the days of 512 MB memory and WinXP.
In the end a lot of people using the application would either have to restart during the day, use portable Firefox, which many actually did. Of course, there are/where many worse things in practice dealing with supporting IE<9 for relatively modern web applications. I'd still rather deal with that, than the v4 browser days.
Earlier quoted context omitted.
Oh jeez, I just saw that the section you're referring to repeats the old canard about caching the length of an array when iterating over it. Come on, that can't still be good advice. It always struck me as ridiculous to begin with, but almost certainly now it's optimized away. Not to mention the suggestion you're talking about, which I bet would bite programmers for the reason you mention. Seems like a bad idiom, I'v…
the problem with using it even when you don't have falsy values is that, eventually, you're going to forget that you can't use it when you do have falsy values. You're going to get too comfortable with it, and it's not general-purpose enough. Can't wait for ES6 to no longer be 'experimental', as I'd much prefer to use 'for..of' loops
On the server-side async/await are worth their weight in gold... and using lambdas is very nice. I still don't like the ES6 module syntax over node/commonjs require statements though.
The only thing to be really mindful of is when you browserify for the client that you don't accidentally include, for example the entire crypto library, buffer or similar shims because they can get very big, very quickly.
> You can also use the unary + operator to convert values to numbers: + "42"; // 42 > [...] However the "+" operator simply converts the string to NaN if there is any invalid character in it. Being a bit pedantic here, why not recommending the Number function which may be less obscure for beginners? Number("42"); // 42
Earlier quoted context omitted.
I think 99% of the problems people have with Javascript are not actually types, but `this`. It's the most confusing part about Javascript. This context, var foo scope, what? Why is this value not updating? undefined? What???
I actually found the Javascript 'this' keyword more understandable after working with Python. >>> class foo(): ... def test(this, x): ... print this, x ... >>> x = foo() >>> x >>> x.test(1) 1 >>> y = foo.test >>> y(1) Traceback (most recent call last): File " ", line 1, in TypeError: unbound method test() must be called with foo instance as first argument (got int instance instead) >>> y(x,1) 1 In Python, the referen…
var foo = {
doSomething:(...argv)=doSomethingMethod(foo, argv)
};
return foo;
It's similar to what Crockford now presents as a preferred approach in dealing with having context for functions... I just like discrete functions that can be tested independently of their execution context... by passing the context as a parameter, this becomes explicit... with binding, the process becomes transparent.