The Birth and Death of JavaScript (2014)
destroyallsoftware.com
destroyallsoftware.com
Feels like the world is hanging on a single thread by now.
My explanation was that it signals intent to me, and is different from some property not being part of the expected object shape or not having been initialized because of some accident or logic failure.
Since then, I've sticked to it, and am "allowed" to use NULL ^^
It can lead to some annoying checks in TS for primitively-typed properties, so for these, I still allow explicit usage of undefined when it's simpler given the surrounding code.
But I agree with you in principle. Using "undefined" as a "second nullish value" and explicitly checking for it is a programming error.
When there's object/areay vs null/undefined, thankfully, the truthiness narrowing often allows me to interface with code relying on "undefined" without explicitly handling this "value" in my own parts of the code base :)
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
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
All not things you should do, but taints the "purity" argument, doesn't it? :D
undefined camp:
- out of bounds array index access [1,2,3][42]
- non existent object key access {}.foo
- array.find(...) no result
- ...
null camp:
- document.querySelector(...) no result
- regex.match(...) no result
- ...
Could the language have done without both null and undefined? Definitely. But it's here and here to stay.
Though, it's not the only language with two nulls. Julia has nothing and missing, though their semantics are more well defined and with different behaviors than in JavaScript.
[0]: https://jsfuck.com/ relies on Array#toString for casting values to strings
Since the "Array" is a reference to the prototype, I think it might be outdated due to changes in undefined behavior of runtimes when serializing array objects, or logging them.
I'm pretty sure that [object Array] used to be the result of logging an array at some point.
Object.prototype.toString
Array.prototype.join
> 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
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.
Incidentally it’s also a great introduction to thinking as a functional programmer if you are used to imperative logic with state spread all over the place.
1. He calls Array(16) and then talks about there being 16 separators. Of course, there are only 15. This kinda breaks the Batman joke.
2. He writes {}+[] and claims that he's adding a list to an object, then mocks the fact that it gives a different result than []+{} which gives [object Object]. In reality, if you write ({}+[]), you also get [object Object]. I'll leave it as a puzzle for you to figure out why {}+[] is different. (Hint: Gurer vf ab bowrpg gurer.)
> {}+[]
'[object Object]'
> []+{}
'[object Object]'
The 'death' being discussed here means that JavaScript becomes the substrate, a state where you don't use it directly, but it's everywhere. And that has truly come to pass.
The benefit of JavaScript is, that, after Google really pushed it to its limit with V8 and of course NodeJS made it a backend dream, that it is ubiquitous and once written usable everywhere, much kinda like PDF.
Its versatility gave it the advantage over WebAssembly to this day, because it is not as widespread available as JavaScript.
I agree with you, that JavaScript itself is nowadays tantamount with TypeScript - what a giant leap this has been. Angular (2) was the unsung hero here. Angular was harshly criticized when they went TypeScript right from the beginning while still offering a native JavaScript version as well (which was basically unusable to be honest).
It is funny, that the last hideout not featuring TS as their default option is React, while more and more major integral projects like NextJS rely out of the box on TS. ReactJS will fall, too. It wouldn't be the first time regarding innovations coming from other projects. Again Angular is leading the innovation while ReactJS is a follower.
You rarely can go wrong with JavaScript and Python, I would say.
I also agree with your opinion on Angular.
But I like React, so I'm a little sad. Still, I mostly agree with you.
The reasons you criticize React are exactly the reasons I love React. Because it changes slowly, even someone like me can keep up. (Just kidding.)
This is a pedantic point, but that's not really what the definition of compiler is as much as a common understanding of it. By definition, it just translates one language into another, and a human-readable to human-readable translation is still a compiler ("transpiler" is more slang than actual formal terminology).
This might just be one of those already lost battles, but like "crypto" being used to mean "digital money" rather than "cryptography", I feel like the new terminology is weird and unnecessary, so it's something I have trouble adapting to even though I rationally know that usage evolves over time and sometimes the words I like less will become the norm.
> This is a pedantic point, but that's not really what the definition of compiler is as much as a common understanding of it. By definition, it just translates one language into another
The history and etymology doesn't support that definition, either; that's just another "common [mis]understanding" of the term. It's in the name. A compiler produces a compilation—an aggregate of multiple subroutines, including user-supplied ones and some by the system/programming environment, transformed into a single program for a given target.
(You're describing the process of "autocoding", a job that every compiler does, and a term that predates "transpiler" but that no one uses because they favor stretching the more frequently encountered term "compiler" for their use case.)
Depends on how much you care about your user's computers.
More a nightmare than a dream. It lead to the terrible practice of tightly coupling frontend and backend code bases that led to inevitable pain. The language barrier between front/back-ends was a key aspect of web-dev that allowed it to a foothold vs. previous, unsuccessful attempts. Fortunately this practice hasn't taken over and sane architectures are still prevalent.
Flutter exists too, and supports iOS and Android in addition to the desktop OSes. The dev time is pretty fast too imo.
That said, idk how the performance compares to Electron or Native apps.
As a small team, optimizing for "actually getting the thing shipped" is so much better than optimizing for speed anyway.
Flutter is a joke on the web, and it consumes as much as Electron, sometimes worse, on a desktop.
I'm not sure if the web render engine has gotten better since then, and am too lazy to look up the links rn, but threads should be easy to find using HN search.
Still seems like a common source language + GUI toolkit that targets the web platform and various native platforms (mainly Android, iOS, macOS, Windows, and desktop Linux of course) without significant overhead has not been achieved yet. And it's questionable whether it's possible, given the special requirements (and capabilities) of the web platform and the different native platform.
For Flutter web, yes as it's canvas based it doesn't have all the same web features but generally for crud apps it doesn't much matter, especially if it's near zero effort taking your Flutter mobile and desktop app and putting it on the web. With the new impeller renderer and Wasm improvements it has gotten quite faster too.
And for web just open any Flutter web app: https://demo.invoiceninja.com/
Hopefully the desktop story is going improve as Canonical is now leading the Flutter desktop side.
Google lost the opportunity to actually make it take off, had they replaced the Java stack with Dart, instead of staying in the Java world and adopt Kotlin.
However the Android team was never a great supporter from Dart in first place, hence why you won't find anything Dart on https://developer.android.com.
Kubernetes was originally written in Java, and Docker in Python, it was thanks to early Go advocacy, that those projects got rewritten in Go, and then they got lucky.
Just like the download server rewrite into Go, that was done by someone from Go team, as part of their advocacy.
Check how many public projects does Google do, outside anything related to CNCF project landscape.
Having just finished moving from GWT into AngularDart.
As far as I am aware, most teams would rather use J2Objc or KMM than Flutter.
As for the rest thanks for the list.
Performance is very fast as it's all natively AOT compiled machine code without any web views like Electron.
"i can't program, i only make CRUD apps"
"i don't write anything that requires computation"
"i do server side rendering on a serverless platform"
in reality rails runs circles around typescript for productivity for CRUD/webapps.
https://spidermonkey.dev/blog/2026/05/20/saying-goodbye-to-a...
iirc, v8 never had any special compilation path for it to begin with.
Websites have actually long been a great cross-platform mechanism
Just a shame about the giant browser you have to load first
But even document rendering with light scripting is not trivial so yeah, the required browser is the bottleneck.
I always wonder (layman question): couldn't native Electron apps (and similar technologies) save a great deal of RAM by using the same sandboxing model for apps that browsers use for tabs, instead of fully-fledged instances?
Was that an idea that Tauri also tries to implement, or am I remembering this wrongly?
I am hesitant to call that "support". If even Meta can't get their Electron application to work reliably, who can? WhatsApp client for macOS is awful and it's getting worse. Discord is awful and it's getting worse. Spotify works better when running through the browser. At this point, when I see that the application is using Electron, I am assuming it's not supported on my OS and I move on.
Not sure what timeline you’re living in, but people absolutely still write tons of JS, and WebAssembly has yet to take over as a commonly used runtime for web applications. You can definitely find examples of companies building on it, but don’t mistake that for the kind of sea change Gary was describing here.
But why make an app when websites is enough? And I don't need to run n web browsers for that.
Tcl with TK or Free Pascal on Lazarus
Not really. his two predictions are
1) that EVERYTHING will be running on some javascript assembler. We are getting incrementally closer with things like firecracker, but plenty of stuff still runs on bare metal, and it doesn't seem like it's going away so easily.
2) that no one will write javascript anymore. I don't think typescript is different enough to count.
Is really that simple compared to a normal cross platform web application written in (for example, but there are multiple frameworks) QT?
I mean, sure you have to write JavaScript and not C++, but in the end is that more simple? Maybe to start with yes, but then you get into tooling, typescript, multiple build steps, etc that makes it probably more complex than a old boring QT program in C++. And nowadays with most software not even written by humans, does the argument "but javascript is simpler than C++" really holds?
It's absurd than we could have very performant computers, and we still have the performance of 10 years ago because the added resources in modern PCs gets wasted by programs that need to run an entire Chrome instance to do basic stuff. I mean, open 4 programs that use Electron (Discord, Spotify, VSCode, WhatsApp desktop) on a modern PC and you consumed most of the available RAM just for them.
Precisely because I don't write it directly, I think what I need is not C++ but JavaScript. Thread safety and verification responsibilities in C++ are, in my opinion, the biggest bottlenecks in the age of AI development.
I'm tolerant of the brief pauses caused by JavaScript's garbage collector, but users are not tolerant of crashes. That's the key.
And while the core engine should be in Rust or C++, the code presented to the user? Yes, I think Electron is the right choice. The reason is that it's a familiar UI. If you present an unfamiliar new UI, users have to relearn it. But web UI is already familiar to most generations. From this perspective, I think Electron is far better than C++ in terms of design. I don't believe performance always wins.
Let's fix that!
ASMOP
At the time I just thought it was funny. Now I find it surprising how much of these ideas ended up sticking around.
It's only 2 years predates this talk in the title.
webOS and Firefox OS was at least 20 years ahead of its time.
Just asking out of curiosity.
Also, the screenshots I've seen of webOS makes me long for a revival... not only on smart TVs
The thesis is that javascript-compatible source will be the substrate of the future. A javascript engine, though one highly optimized to efficiently interpret a compatible subset, is a potential universal platform of the future despite generic javascript being a terrible substrate.
WASM fundamentally rejects this by creating a new javascript-incompatible substrate that is actually designed to be a low level target. Claiming WASM is confirmation of the thesis makes as much sense as claiming that a future where everybody has a Rust interpreter in the browser is confirmation of the thesis.
If you are arguing that, then you are just arguing that web browsers will run code in some form in some language as they already do. As the video is clearly discussing a “surprising” possible future, it makes little sense for it to be consistent with literally business as usual and literally every possible future.
They have a lot in common. So it's not at all wrong to say WASM fulfills the prophecy. It's an iteration of the concept that resulted in JS as a compile target and later asm.js.
It's like PHP, it will never die.
I predict that PHP will live a long life, but not as long as C, and I predict JavaScript will have a lifespan closer to C's than PHP's.
* With the one exception of BLAS which is widely used via NumPy
And now with typescript and running it in the server... I'd rather just use Java.
js is mutant C with dementia - hacked together over over a fortnight, full of inconsistencies and weird corners.
console.log(1 + "2"); // "12"
console.log(1 - "2"); // -1
console.log(NaN === NaN); // false
console.log(+0 === -0); // true
const obj = {};
console.log(obj.foo); // undefined, not an errorAlso I suppose my memory could be pretty foggy as I don't think I've looked at the spec since about 2014.
There were two buttons, one labeled "Our Web Site", the other labeled "Our Competitor's Web Site".
When you moved the mouse over the "Our Competitor's Web Site" button, it would quickly slide out from under your cursor before you could click it!
Then when you stopped moving your mouse, the "Our Web Site" button would slyly slide right underneath your mouse!
Dammit Microsoft!!! ;)