DEV Community

Ben Halpern
Ben Halpern Subscriber

Posted on

What is the oddest JavaScript behavior?

JavaScript is notorious for its inconsistencies in a lot of areas. It's also powerful and popular and has a lot going for it.

But can we poke fun at weird things? (whether or not the behavior is a good thing in general)

Let's start with an example:

+'a' resolves to NaN ("Not a Number") because it coerces a string to a number, while the character a cannot be parsed as a number

document.write(+'a');
To lowercase it becomes nan.

Adding NaN to "ba" turns NaN into the string "NaN" due to type…

Top comments (85)

Collapse
 
peiche profile image
Paul
'11' + 1 // 111
'11' - 1 // 10
Enter fullscreen mode Exit fullscreen mode
Collapse
 
xanozoid profile image
XANOZOID • Edited

I love this. It just made me think about something pretty interesting... If you think of this in terms of what it actually could mean for a mathematical function, then the string appendage (regarding integers) could be thought of as its own math operation too - in a very round about way.

Collapse
 
alephnaught2tog profile image
Max Cerrina

Absolutely, and not even in a very roundabout way, you're pretty spot on :)

Collapse
 
leob profile image
leob • Edited

Question: should we (as JS coders) assume that people know this, and not hesitate to write this sort of code? or should we refrain from this and use explicit type conversion ...

(well the answer is probably that if it is 100% clear that the data type of the first operand is always string and the second operand is always number then this would be okay - if in obscure corner cases it can sometimes suddenly be different then good luck debugging/troubleshooting ...)

Collapse
 
ahkohd profile image
Victor Aremu

😂😂

Collapse
 
jacobmgevans profile image
Jacob Evans

JS coercion at its best and worst in two lines lmao!

Collapse
 
bradtaniguchi profile image
Brad • Edited

This took an hour of my life:

typeof null === 'object' //true
Enter fullscreen mode Exit fullscreen mode
Collapse
 
eliasmqz profile image
Anthony Marquez

omg thank you for your service as I really didn’t know about this.

Collapse
 
willsmart profile image
willsmart • Edited

yep, a good check for an actual object is

thing && typeof(thing)==='object'

Kind of insane they did that that.

Collapse
 
sleeplessbyte profile image
Derk-Jan Karrenbeld • Edited

It's not insane. null, like nil in ruby, a singleton instance of NilClass is technically an object.

Technically an array is also an object, which is why there is Array.isArray (which has its own caveats).

Thread Thread
 
willsmart profile image
willsmart • Edited

But at least ruby is rigorously consistent OO like that.

irb(main):004:0> nil.methods
=> [:&, :^, :|, :===, :inspect, :to_a, :to_s, :to_i, :to_f, :nil?, :to_h, :to_r, :rationalize, :to_c, :tap, :public_send, :instance_variables, :instance_variable_set, :instance_variable_defined?, :remove_instance_variable, :private_methods, :kind_of?, :is_a?, :instance_variable_get, :method, :public_method, :singleton_method, :instance_of?, :extend, :define_singleton_method, :to_enum, :enum_for, :<=>, :=~, :!~, :eql?, :respond_to?, :freeze, :object_id, :display, :send, :hash, :class, :singleton_class, :clone, :dup, :itself, :taint, :tainted?, :untaint, :untrust, :trust, :untrusted?, :methods, :protected_methods, :frozen?, :public_methods, :singleton_methods, :!, :==, :!=, :__send__, :equal?, :instance_eval, :instance_exec, :__id__]

In JS there are very few object-type calls that work in any way with nulls, so it's neat that they aimed to make this aspect of the language more OO, but they should have followed through better.
typeof(null) being 'object' is seldom anything but annoying for JS devs.

eg.

> Object.getOwnPropertyNames(null)
< Uncaught TypeError: Cannot convert undefined or null to object
    at Function.getOwnPropertyNames (<anonymous>)
    at <anonymous>:1:8
> null.foo
< Uncaught TypeError: Cannot read property 'foo' of null
    at <anonymous>:1:6
(anonymous) @ VM176:1
> for (const k of null);
< Uncaught TypeError: null is not iterable
    at <anonymous>:1:17

Basically there are very few times you might write typeof(thing)==='object' where you shouldn't do the null check too

Thread Thread
 
sleeplessbyte profile image
Derk-Jan Karrenbeld

Absolutely true. I was only referring to the use of the word "insane" which just sounds very unknowing/ignorant to me.

FWIW, now that we use TS for most things, this is not problem for us often, except for when something is nullable ánd multiple types (object/number/string/undefined).

My recommendation is to never use null and only use undefined. Replace your "null"s with an "EMPTY/UN_SET" data type.

Thread Thread
 
willsmart profile image
willsmart

Fair enough. I didn't mean insane in the sense of completely without reason, just in the sense that it was badly thought out.

The thing is that nulls are now baked into JS at a few levels, so in our own code we can avoid them, but they pop up throughout the various JS apis, eg

> /a/.exec('b')
< null
> document.body.getAttribute('a')
< null

That's what I mean by the loose "insane" comment. It was a mistake that was bad enough that as JS devs we're now best off to generally avoid the fundamental null value in JS.

I totally agree with you about TS, which corrects many of these issues, and how in JS we're best to use undefined whereever possible.

Collapse
 
brianemilius profile image
Brian Emilius

Or
Object.prototype.toString.call(thing)

Collapse
 
xowap profile image
Rémy 🤖

Without a doubt I'll say this: jsfuck.com/

Collapse
 
ohryan profile image
Ryan

My work firewall thinks this is porn.

Collapse
 
yorodm profile image
Yoandy Rodriguez Martinez

Ryan, HR needs to now why you're searching for programmers porn during work hours

Thread Thread
 
ohryan profile image
Ryan

Clearly :D

Collapse
 
deciduously profile image
Ben Lovy

check out the source for a full list of the nonsense they leverage. I feel like "explain each line of this file to yourself" is probably a pretty good JS litmus test.

Collapse
 
kspeakman profile image
Kasey Speakman

Wat is a funny talk about odd behaviors. JS starts at 1:22.

Collapse
 
alexanderholman profile image
Alexander Holman • Edited

A colleague the other day noticed that the setTimeout/setInterval takes a 32 bit signed int as an argument, which is fine except that (as far as I know) JS doesn't natively support integers... but but instead Numbers are specifically 8 byte signed doubles. If you happen to have a interval or timeout every 2^31 miliseconds (ish) or more, then the value is interpreted as a negative number and therefore executes instantly and in terms of intervals repeatedly. So timeouts and intervals are limited to just under 25 days.

Collapse
 
shayd16 profile image
Shayne Darren

I'm guessing a web app won't need a 25-day timeout or interval.

I tried a very basic test on node and it seems to be waiting on it to execute... any idea why?

Collapse
 
alexanderholman profile image
Alexander Holman • Edited

not sure... i just ran it in node and experienced the same issue as the browser. The following line should make node print without pausing:

setInterval(() => {console.log('log')}, 2**31)

or

setInterval(() => {console.log('log')}, -1)

where the following will take 596.5 hours (roughly):

setInterval(() => {console.log('log')}, 2**31-1)

I am currently on a Windows machine running v8.9.1, perhaps its solved in later versions?

Collapse
 
clarity89 profile image
Alex K. • Edited

I think most of the people get confused by the language's type coercion rules and operations related to those, which are quite often not intuitive:

0 == []            // true
[] == false        // true
[] + 1             // "1"
[] + "1"           // "1"
[] - 1             // -1
[] - "1"           // -1
{} + 1             // 1 
{} + "1"           // 1
{} - 1             // -1
{} - "1"           // -1
{} + []            // 0
{} == []           // Uncaught SyntaxError: Unexpected token ==
[] == {}           // false
Collapse
 
blindfish3 profile image
Ben Calder • Edited

The only thing that surprises me here are the loose equality comparisons between object and array; but it's not as though any sane programmer would be doing this. Otherwise almost all the others look fairly intuitive: coercion is applied to satisfy the operator being applied.

It's perhaps more useful to understand all the values that can be coerced to false; and why sometimes it's a really bad idea to use a shortcut if(isSomeValueTruthy) style condition...

edit - actually [] + 1 is weird :D

Collapse
 
jwkicklighter profile image
Jordan Kicklighter

Wow, this is a new one for me. The array coercion actually caught me off guard.

Collapse
 
ahferroin7 profile image
Austin S. Hemmelgarn

Yeah, this is a good one. Most languages try to coerce only one side of an expression at a time, and won't ever coerce collection types to non-collection types.

Collapse
 
sebastian_scholl profile image
Seb Scholl

My favorites...

alert(typeof NaN); //alerts 'Number'
alert(NaN === NaN); //evaluates false
Enter fullscreen mode Exit fullscreen mode
Collapse
 
ahferroin7 profile image
Austin S. Hemmelgarn

Most languages do this, but it could be a whole lot worse (fun fact, IEEE 754 actually allows for (2 ^ N) - 1 distinct NaN values not counting signed NaN values, where N is the bit width of the significand field in the binary representation (so for the 8-byte floats JS uses, there are 18014398509481982 possible NaN values including both signed values)).

The reason is simple, NaN is a numeric representation of a non-numeric value, so by definition it has to be the same type as numbers for the language (or, at minimum, it has to be at least one of the numeric types in the language), but you can't be certain what value it is, so you can't treat two NaN values as being identical.

Collapse
 
lukewestby profile image
Luke Westby • Edited
typeof document.all === 'undefined' // true
document.all instanceof HTMLAllCollection // true
Collapse
 
antjanus profile image
Antonin J. (they/them)

Encountered this one yesterday and spent a day on it.

A File object cannot be serialized into JSON. There's a StackOverflow question about it.

But essentially if you do

console.log(someFile);

The browser will happily return something like:

File {
  name: 'filename',
  size: 1898921,
  // other properties
}

But doing

console.log(JSON.stringify(someFile))

will result in:

{}

With no properties. I've noticed that it does this for object spread as well so if you wanted to copy File info, you can't just do: { ...someFile }, you'll need to call and pick out the individual properties manually.

Collapse
 
ahkohd profile image
Victor Aremu

This made my day 😂

Collapse
 
kenbellows profile image
Ken Bellows

Imo the implicit type conversion is a little weird, but even ignoring that, I think the point was the difference in behavior between '11' + 1, which converts the number to a string, and '11' - 1, which converts the string to a number. This discrepancy makes implicit type casting feel unpredictable and weird, at noon least to me