Rendered at 02:57:06 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
DavidPiper 6 days ago [-]
I love(?) that he absolutely predicted a global disaster between 2020-2025, he just got the wrong type. Which is very JavaScript.
noman-land 6 days ago [-]
He was pretty close to being NaN% correct.
moritzwarhier 5 days ago [-]
To be fair there were a couple of disasters, such as [object Array] and undefined.
Feels like the world is hanging on a single thread by now.
sheept 5 days ago [-]
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
moritzwarhier 5 days ago [-]
I intentionally corrected it, because vanilla JS arrays used to behave like this in some contexts, but I'm not even sure about which ones still.
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
always returns the result of
Array.prototype.join
per spec, afaik, so for an empty array it's the empty string.
chrisandchris 5 days ago [-]
Yep, there are no arrays in JS. There are just objects, that behave like arrays.
> 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?
I'm not sure if it's possible to build an array using only primitives and functions from the
Object.
namespace, for example.
jschrf 5 days ago [-]
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.
moritzwarhier 5 days ago [-]
I do it this way, but this led to people asking me in reviews why I use NULL^^
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 :)
ngruhn 5 days ago [-]
You can't get rid of undefined. You can't ban null either. They're both used in the core language all over the place:
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
- ...
sheept 5 days ago [-]
In general the language uses `null` if it would otherwise return an object (similar to Java; this is also why null is an object but not really in both languages), while `undefined` is used if it could otherwise return any value.
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.
crdrost 5 days ago [-]
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
moritzwarhier 4 days ago [-]
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
Tade0 5 days ago [-]
null is of type 'object' though, while undefined is undefined - way better to have a separate type.
veidelis 5 days ago [-]
I personally think null is useless. I write TS not JS btw.
eranation 5 days ago [-]
Surprised no one mentioned this is the guy who brought us this masterpiece. If you haven’t seen it, drop everything and watch it, best 5 minutes of your day guaranteed.
All his talks are very good. ‘Boundaries’ is probably the most illuminating video I have ever seen on software architecture, its lessons I still think about when I design any complex application.
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.
is there nobody else who thinks "A Whole New World" was the best one?
Timwi 5 days ago [-]
There are a few mistakes in this talk; I'll list just two that I noticed.
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.)
eranation 5 days ago [-]
Good catch. I'm sure there could be more technical inaccuracies in the talk, but again, this is for entertainment purposes I assume, not education.
... because Node's REPL and some consoles pre-wrap input that looks object-ish :)
5 days ago [-]
pentacrypt 5 days ago [-]
Amazing, thanks!
nosioptar 5 days ago [-]
That's actually fantastic.
flufluflufluffy 5 days ago [-]
amazing
jdw64 6 days ago [-]
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. People say Electron is heavy and not great, but it's also the fastest way to support Mac, Windows, and Linux all at once. Sometimes insights like that are surprising.
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.
frail_figure 6 days ago [-]
> but it's also the fastest way to support Mac, Windows, and Linux all at once.
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.
wiseowise 6 days ago [-]
> Flutter exists too, and supports iOS and Android in addition to the desktop OSes. The dev time is pretty fast too imo.
Flutter is a joke on the web, and it consumes as much as Electron, sometimes worse, on a desktop.
ifh-hn 6 days ago [-]
You got sources to back this up, or is this just you're opinion?
moritzwarhier 6 days ago [-]
Regarding the "joke on the web", there's plenty of HN threads about Flutter where you will see this sentiment, not only about performance, also about UX (e.g. text rendering, selection, scrolling...).
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.
satvikpendem 5 days ago [-]
Dioxus Native supports both web and native platforms because they serve HTML and CSS for the web and then on native they turn that into canvas rendered code just like Flutter, not a webview, because they built their own HTML and CSS renderer.
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.
Try using any demo app from their user showcase on web.
satvikpendem 5 days ago [-]
Where does it consume more than Electron?
5 days ago [-]
derfurth 6 days ago [-]
In my experience performance is about the same as native on mobile. On desktop I cannot compare as I thankfully never had to make cross platform desktop apps using native platform SDKs, but Flutter is doing fine. I am a working on a non trivial desktop app, and I am pretty happy about it.
Hopefully the desktop story is going improve as Canonical is now leading the Flutter desktop side.
Zigurd 5 days ago [-]
I'm working on an app that's cross-platform on mobile devices. I do builds for macOS as a convenience for my colleagues demoing the app. Pretty much zero effort to add that as a target. I get some benefits out of it too in the form of being able to see how well the UI responds to unusual screen dimensions, running in a resizable window.
"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.
satvikpendem 5 days ago [-]
Flutter is great, still the fastest way to make cross platform mobile apps and you get desktop and web support essentially for free.
Performance is very fast as it's all natively AOT compiled machine code without any web views like Electron.
greekrich92 5 days ago [-]
On desktop does flutter have native access to the machine it's running on? Can it talk to printers for example?
Zigurd 5 days ago [-]
I have successfully added AppFunctions on Android to a Flutter app. I figure that's about as hairy a platform-specific feature as it gets. So far nothing has interfered with other platform build targets. I look forward to adding Apple's agentic tool calling interface, too.
satvikpendem 5 days ago [-]
Of course, via FFI. Not sure why one would think it couldn't, it's just a programming language based GUI framework after all.
vips7L 6 days ago [-]
Darts an amazing language too.
pjmlp 5 days ago [-]
It is basically a revamped Java.
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.
Zigurd 5 days ago [-]
Google uses Flutter/Dart for their own apps fairly frequently. Obviously not the right choice for the most complex apps. Android system programming and cross platform apps are use cases that are divergent enough that trying to smash them together would result in nobody being happy about the outcome.
vips7L 5 days ago [-]
Pretty sure AdWords is built on dart too
pjmlp 5 days ago [-]
Of course, they were the ones that saved Dart in first place, after DartiumVM was killed.
Having just finished moving from GWT into AngularDart.
pjmlp 5 days ago [-]
Except for AdWords and Google Pay, which ones?
As far as I am aware, most teams would rather use J2Objc or KMM than Flutter.
Zigurd 5 days ago [-]
Everything running on Fuchsia; NotebookLM; various dashboards and admin apps like Google Classroom, Google Analytics; Google Earth; Google Pay, etc.
pjmlp 5 days ago [-]
Fuchsia, well so much OS for nothing.
As for the rest thanks for the list.
vips7L 5 days ago [-]
They should have pushed dart instead of Go imo.
pjmlp 5 days ago [-]
Google never pushed Go, the UNIX/Plan 9 and Oberon folks did, as means to avoid doing C++, with support of their line managers as their 20% project.
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.
_the_inflator 6 days ago [-]
JavaScript is the new assembler layer so to say. Every compiler as per definition translates human readable code into machine language.
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.
saghm 6 days ago [-]
> Every compiler as per definition translates human readable code into machine language.
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.
cxr 6 days ago [-]
It's no use being pedantic if you're not going to be correct.
> 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.)
jdw64 6 days ago [-]
You seem to have said what I was trying to say, but much more eloquently.
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.)
eikenberry 5 days ago [-]
> course NodeJS made it a backend dream
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.
pjmlp 5 days ago [-]
> You rarely can go wrong with JavaScript and Python, I would say.
Depends on how much you care about your user's computers.
Uehreka 6 days ago [-]
> 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.
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.
Dwedit 6 days ago [-]
Within the video's story, they removed virtual memory and memory protection because the JIT was good enough. Nothing like that has happened at all.
wffurr 5 days ago [-]
The WebAssembly component people are pushing Wasm as a replacement for container-based virtualization, so it's not that far off.
jdw64 6 days ago [-]
Sometimes I think, I wish I had the knowledge to dig into these kinds of detailed parts like you do. I tend to obsess only over the context of what the video is trying to say, so I miss these small details. You probably achieved that through hard study. I looked it up, and you were definitely right
neonstatic 6 days ago [-]
> People say Electron is heavy and not great, but it's also the fastest way to support Mac, Windows, and Linux all at once
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.
krzyk 5 days ago [-]
> People say Electron is heavy and not great, but it's also the fastest way to support Mac, Windows, and Linux all at once.
But why make an app when websites is enough? And I don't need to run n web browsers for that.
satvikpendem 5 days ago [-]
As someone else said, Flutter is good, but also look into Rust based GUI development. With frameworks like GPUI or Slint or egui, they are optimized for cross-platform desktop use cases specifically and are significantly faster and more lightweight than Electron and these days do also support macOS, Windows, and Linux out of the box.
dnautics 5 days ago [-]
> it seems his prediction was accurate
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.
iirc, v8 never had any special compilation path for it to begin with.
wffurr 5 days ago [-]
V8 also supported AOT for asmjs but it's since been removed as well.
veqq 5 days ago [-]
> the fastest way to support Mac, Windows, and Linux all at once
Tcl with TK or Free Pascal on Lazarus
winrid 5 days ago [-]
Python with TK at least gives you a type system and same cross platform support...
mpweiher 4 days ago [-]
> 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
bee_rider 5 days ago [-]
I wonder, has did anyone try a hardware accelerator for web assembly? Cursory googling, I found a research paper, but from 2024, so maybe too recent to be a “real thing.”
throwaway_95283 5 days ago [-]
haven't web browsers always been C/C++? they are typescript now? it would seem the fastest way to support Mac, Windows and Linux is 500MB of C++.
alerighi 5 days ago [-]
> but it's also the fastest way to support Mac, Windows, and Linux all at once
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.
jdw64 5 days ago [-]
You're not wrong, but users' UI/UX experience is already aligned with web apps. QT is weak on the web side, and with C++, there are too many things to worry about.
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.
lelandfe 6 days ago [-]
> People say Electron is heavy and not great, but it's also the fastest way to support Mac, Windows, and Linux all at once
Websites have actually long been a great cross-platform mechanism
Just a shame about the giant browser you have to load first
moritzwarhier 6 days ago [-]
To be fair, implementing something like the Spotify client does require a web app, not "just" a web site.
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?
ymolodtsov 6 days ago [-]
It'd be great if Electron itself became a core part of the OS. Tauri is closer to this on MacOS because it tries to use WebKit but not enough.
oakinnagbe 6 days ago [-]
Every few years, we invent a better JavaScript. Then we transpile it to JavaScript.
notarobot123 6 days ago [-]
Mass adoption trumps good design every time.
jerf 6 days ago [-]
It's all assembly code in the end. There's nothing intrinsically wrong with compiling down to Javascript, a high-level language can still implement many things that direct Javascript does not. Just about every language guarantee you've ever used can be violated by raw assembler.
satvikpendem 5 days ago [-]
The problem is Wasm is not improving nearly as fast as predicted here. We don't have DOM manipulation so we will still need JS regardless as glue code, or just eschew HTML and CSS altogether and render everything on a canvas as Flutter and some Rust GUIs do but that's a shame to lose the feature set of the web.
Zigurd 5 days ago [-]
People choosing Flutter would say the uniformity of a canvas across all browsers is more valuable than gaining the inconsistently implemented web feature set.
satvikpendem 5 days ago [-]
Yes that's probably true.
jansan 5 days ago [-]
JS is just so much more approachable than WASM. You can debug it on the fly, feed it to an LLM, there is no wrapper, it's just so much easier to tinker and work with it.
ifwinterco 5 days ago [-]
The DOM and JS are joined at the hip - the DOM APIs are designed assuming JS is used to access them, and the design of JS and some of its more “unique” features is partly because it was designed for use with the DOM
cbhl 5 days ago [-]
I remember watching Gary Bernhardt give this talk live at the Canadian Undergraduate Software Engineering Conference (CUSEC) back in 2014. PNaCl had just come out the year prior, and Google was using it to cross-compile, run, and sandbox OpenSSH and RDP clients inside of Chrome and ChromeOS, and the Mozilla/Firefox folks counter-proposed asm.js as a response.
At the time I just thought it was funny. Now I find it surprising how much of these ideas ended up sticking around.
devy 5 days ago [-]
Gary Bernhardt's Wat lightning talk [1] was my favorite of all time.
It's only 2 years predates this talk in the title.
Almost everything happened according to the script. Now we are just waiting for another OS fully based on browser technology or WASM OS.
webOS and Firefox OS was at least 20 years ahead of its time.
Veserv 5 days ago [-]
Not at all. WASM is a repudiation of the thesis, not a confirmation.
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.
TimTheTinker 5 days ago [-]
WASM is literally a direct replacement for asm.js. In fact, for a long time emscripten supported both simultaneously - both as outputs from the same tool chain.
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.
moritzwarhier 5 days ago [-]
Is there a technical reason you don't mention ChromeOS?
Just asking out of curiosity.
Also, the screenshots I've seen of webOS makes me long for a revival... not only on smart TVs
frollogaston 5 days ago [-]
Not the parent, but: ChromeOS isn't what I'd call a web-based OS. It supports Android apps, and that's how you get a lot of things that don't have web versions. Not much different from how Ubuntu can run Chrome and also supports native apps.
moritzwarhier 5 days ago [-]
Good point. Since I've never owned a Chromebook, I didn't even know that they are capable of installing arbitrary Android apps.
nosioptar 5 days ago [-]
Personally, I dont consider chromeos wheb thinking about operating systems because it's not a real os, its a toy released by a shady advertising company. (Same as android.)
Retr0id 5 days ago [-]
[dead]
arkadiytehgraet 6 days ago [-]
Regardless of the content, this is one of my most favourite talks ever, especially in the delivery aspect. It served me as an inspiration for quite some time when I had to present anything to a wide audience.
jhatemyjob 5 days ago [-]
Same. I think I watched this 10 times when it first came out.
RIshabh235 6 days ago [-]
We’re past the halfway point of Bernhardt’s 2035 timeline; JavaScript hasn’t died yet, but it’s clearly writing its own eulogy in WebAssembly.
wiseowise 6 days ago [-]
Multiple generations of your family will be long dead before last JS instruction gets executed. Unless there's going to happen a global thermonuclear war. I still bet on JS surviving over most humans.
Macha 5 days ago [-]
The same is true of COBOL and Fortran. But also for most purposes, they are practically* dead.
* With the one exception of BLAS which is widely used via NumPy
5 days ago [-]
jazz9k 6 days ago [-]
I review many sites/month from different clients. They are all using some form of JavaScript.
It's like PHP, it will never die.
jerf 6 days ago [-]
"Death" is hard to define for a programming language. It's tempting to say "the last time anyone writes it", or maybe "runs it", but to put that in biological terms that seems like defining "death" for a person as "the last chemical bond that was part of their body is broken"... sure, it'll happen someday, but all the properties we associate with the term "death" happen rather soon than that.
matt_kantor 6 days ago [-]
> 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.
varun_ch 6 days ago [-]
It’s also relevant that LLMs have so much JavaScript training data that I don’t see a world where we’re not still using JavaScript.
fishfasell 6 days ago [-]
The JS death and AI bubble are two events I keep hearing about but will never come.
inigyou 6 days ago [-]
The AI bubble is now, maybe you mean the AI bubble pop
fishfasell 5 days ago [-]
Yes sorry, bubble pop
lezojeda 6 days ago [-]
[dead]
marking-time 6 days ago [-]
"YavaScript" made me smile.
checkthisgot 5 days ago [-]
I think JS, is yet to rise the agents, and using all the next.js components.
j16sdiz 6 days ago [-]
I skim though it and saw they had something javascript asm.js in kernel.
Dwedit 5 days ago [-]
The presentation is a work of speculative fiction presented in a deadpan manner. The things demonstrated in the presentation (Unix shell with C compiler targeting asm.js running inside a web browser) did not actually exist at the time.
jhatemyjob 5 days ago [-]
Great talk. I'm glad he was wrong about this. Having js/wasm be the standard ABI would have been horrible. Obviously he could have never predicted in 2014 that Valve would pour a metric fuckton of resources into improving Wine/Proton, to the point of getting x64 binaries to run on other architectures. But here we are, past the year of the Linux desktop, well on our way to the year of the Linux handset.
bpiroman 5 days ago [-]
JavaScript is the greatest programming language of all time.
thedelanyo 5 days ago [-]
I was actually expecting, typescript takeover.
6 days ago [-]
roshiya 6 days ago [-]
[dead]
naveen99 6 days ago [-]
interpreted languages carry a lot more context than compiled ones. Sandboxed compiled languages don’t have the context baggage, but come with other parts of the brain dead.
Dwedit 6 days ago [-]
I don't think Javascript is still interpreted though?
DonHopkins 5 days ago [-]
Let's just say it's open to interpretation.
flufluflufluffy 5 days ago [-]
It is necessarily interpreted. Specific functions or code blocks can be JIT compiled to native code, but not an entire script.
naveen99 5 days ago [-]
Sandboxed
Surac 6 days ago [-]
My first contact with js was trying to make a button change its color on mouseover. There was no css back then. I bought a book and was so put off from the syntax that i never looked back to js from that day on. Never regretted my decision
satvikpendem 5 days ago [-]
I find these sorts of comments quite strange. So one tried something over 30 years ago and was put off by syntax of all things and then decided they'd never look at it again? So weird to base opinions on 30 year old experiences that were not even in-depth experiences but cursory glances.
notesinthefield 6 days ago [-]
I had a similar path and never came back to JS until work forced me to learn. To me, it has only gotten more readable.
julianlam 6 days ago [-]
s/JS/PHP
afavour 6 days ago [-]
There are a ton of reasons to object to JS but the syntax? It isn’t even all that unique.
falcor84 6 days ago [-]
The syntax? I got 99 problems with js, but syntax ain't one of them. It's just C-style syntax, no?
TheOtherHobbes 6 days ago [-]
C syntax was never that great. It's basically mnemonic PDP-11 assembler with a few added data structures.
js is mutant C with dementia - hacked together over over a fortnight, full of inconsistencies and weird corners.
NaN is a standardized dynamic languages datatype governed by IEEE 754, this is not something to complain about as its behavior is part of the official standard and for good reason, as outlined in the standard.
SonOfLilit 5 days ago [-]
Why dynamic? `NAN != NAN` is just as true in C.
bryanrasmussen 5 days ago [-]
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.
SonOfLilit 3 days ago [-]
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.
flufluflufluffy 5 days ago [-]
None of those examples are showing something you find wrong with the syntax
Dwedit 5 days ago [-]
C syntax dropped the ball badly on operator precedence. Left Shift <<, Right Shift >>, and Bitwise And & should have been at the same priority as multiplication or division, while Bitwise Or (|) should have been at the same priority as addition.
lezojeda 5 days ago [-]
[dead]
comrade1234 6 days ago [-]
I kind of like real JavaScript with prototype inheritance. It's not how we use it in browsers though.
And now with typescript and running it in the server... I'd rather just use Java.
DonHopkins 5 days ago [-]
Reminds me of one of Microsoft's first Dynamic HTML demos:
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!
Feels like the world is hanging on a single thread by now.
[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.
always returns the result of per spec, afaik, so for an empty array it's the empty string.> 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
returns true without it being instantiated using an array constructor or other array-returning function, the Array prototype, or square-bracket syntax?E.g.
...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
namespace, for example.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 :)
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.
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
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
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
https://www.destroyallsoftware.com/talks/wat
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.
https://www.destroyallsoftware.com/talks/boundaries
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.)
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.
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.
"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.
Performance is very fast as it's all natively AOT compiled machine code without any web views like Electron.
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.
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.
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.
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.
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.)
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.)
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.
Depends on how much you care about your user's computers.
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.
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.
But why make an app when websites is enough? And I don't need to run n web browsers for that.
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.
https://spidermonkey.dev/blog/2026/05/20/saying-goodbye-to-a...
iirc, v8 never had any special compilation path for it to begin with.
Tcl with TK or Free Pascal on Lazarus
Let's fix that!
ASMOP
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.
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?
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.
[1]: https://www.destroyallsoftware.com/talks/wat
webOS and Firefox OS was at least 20 years ahead of its time.
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.
Just asking out of curiosity.
Also, the screenshots I've seen of webOS makes me long for a revival... not only on smart TVs
* With the one exception of BLAS which is widely used via NumPy
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.
js is mutant C with dementia - hacked together over over a fortnight, full of inconsistencies and weird corners.
Also I suppose my memory could be pretty foggy as I don't think I've looked at the spec since about 2014.
And now with typescript and running it in the server... I'd rather just use Java.
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!!! ;)