The Birth and Death of JavaScript (2014) • Hacker News Board

Re: The Birth and Death of JavaScript (2014)

#141

Post by moritzwarhier » Mon, Jun 15, 2026, 9:47 PM UTC

chrisandchris wrote: post #139

sheept wrote: post #106

Earlier quoted context omitted.

You probably meant [object Object] :) Since arrays have their own default toString implementation (its own can of worms that is the basis for JSFuck[0]), you'd have to go out of your way with Object.prototype.toString.call to get [object Array] [0]: https://jsfuck.com/ relies on Array#toString for casting values to strings

Yep, there are no arrays in JS. There are just objects, that behave like arrays.

https://tc39.es/ecma262/multipage/indexed-collections.html#s...

> Arrays are exotic objects that give special treatment to a certain class of property names. See 10.4.2 for a definition of this special treatment.

I just meant these special properties. The behavior, apart from the square-bracket syntax for construction, can be emulated using Object property descriptors, Symbol.iterator etc, but AFAIK, much of this is retro-fitted.

Not disagreeing with the fact that arrays are almost just regular objects in JS, but the "just" in "just objects" does have nuances, AFAIK.

JIT Optimizations for non-sparse arrays might just be part of a larger hot-path optimization system, but I think there are still differences.

Is it possible to create an object for which

  Array.isArray

returns true without it being instantiated using an array constructor or other array-returning function, the Array prototype, or square-bracket syntax?

E.g.

  Array.from({"0": 1, "1: 2})

  Array.from({length: 2}, (i) => i + 1)

  [1, 2]

  [...Object.values{"a": 1, "b": 2})]

...

all implicitly use the built-in Array prototype.

I'm not sure if it's possible to build an array using only primitives and functions from the

  Object.

namespace, for example.

Re: The Birth and Death of JavaScript (2014)

#142

Post by moritzwarhier » Mon, Jun 15, 2026, 9:52 PM UTC

crdrost wrote: post #89

jschrf wrote: post #87

Earlier quoted context omitted.

Protip: never even mention undefined in your codebase. Erase it from your vernacular. If you ever need to pass or return nothing, you use null.

If you're a type purist then undefined looks nicer... It'd be like being upset at booleans because things get coerced to them or some 'ish. No: it's the type that has one inhabitant—it's not that type's fault that it appears as a default argument or var or was left out of JSON... So long as typeof null === "object", null is the absurd one

undefined is not less absurd because there are parts of the standard that allow you to differentiate between

  undefined

and a non-initialized value.

Of course you shouldn't do that, but I once encountered a library that behaved differently depending on whether an option in an options bag object was not present or explicitly set to undefined.

You can run into similar ugliness with function parameters, if you do evil things like using

  arguments

And of course you can explicitly check keys of objects, including parameters that are going to be destructured.

All not things you should do, but taints the "purity" argument, doesn't it? :D

Re: The Birth and Death of JavaScript (2014)

#143

Post by mpweiher » Tue, Jun 16, 2026, 1:30 PM UTC

jdw64 wrote: post #11

JS became a compilation target (and it really did), and back then in the video it was asm.js (that's been deprecated, hasn't it?), but then WebAssembly came along... Seeing it actually being implemented and running natively, it seems his prediction was accurate. I mainly use TypeScript myself, and now with Electron, web technologies are wrapped into desktop apps, so web syntax has even entered computer programs. Peop…

> People say Electron is heavy and not great, but it's also the fastest way to support Mac, Windows, and Linux all at once.

Let's fix that!

ASMOP

Re: The Birth and Death of JavaScript (2014)

#144

Post by SonOfLilit » Wed, Jun 17, 2026, 9:53 AM UTC

bryanrasmussen wrote: post #108

SonOfLilit wrote: post #78

Earlier quoted context omitted.

Why dynamic? `NAN != NAN` is just as true in C.

well as I understood it, it was implemented for languages without static data typing although I suppose you could implement it in other languages. Also I suppose my memory could be pretty foggy as I don't think I've looked at the spec since about 2014.

To my understanding, NaN is a range of particular values (all exponent bits set to 1, mantissa nonzero) of the IEEE 754 float datatype, and its semantics are defined in the standard, including the "not equal to itself" semantic. If your language uses IEEE 754 floats and it has div or sqrt operations that don't raise exceptions on out of range inputs (which is something scientific computing people want very much, so it probably has them), then it must ensure nan != nan.