It's only 2 years predates this talk in the title.
The Birth and Death of JavaScript (2014)
131–140 of 144 posts
Re: The Birth and Death of JavaScript (2014)
#132Re: The Birth and Death of JavaScript (2014)
#133Almost 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.
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-incompa…
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.
Re: The Birth and Death of JavaScript (2014)
#134Surprised 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. https://www.destroyallsoftware.com/talks/wat
Re: The Birth and Death of JavaScript (2014)
#135Surprised 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. https://www.destroyallsoftware.com/talks/wat
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 [ob…
> {}+[]
'[object Object]'
> []+{}
'[object Object]'
... because Node's REPL and some consoles pre-wrap input that looks object-ish :)Re: The Birth and Death of JavaScript (2014)
#136Earlier quoted context omitted.
Except for AdWords and Google Pay, which ones? As far as I am aware, most teams would rather use J2Objc or KMM than Flutter.
Everything running on Fuchsia; NotebookLM; various dashboards and admin apps like Google Classroom, Google Analytics; Google Earth; Google Pay, etc.
As for the rest thanks for the list.
Re: The Birth and Death of JavaScript (2014)
#137Earlier quoted context omitted.
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.
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.
Re: The Birth and Death of JavaScript (2014)
#138Earlier quoted context omitted.
> 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.
You got sources to back this up, or is this just you're opinion?
And for web just open any Flutter web app: https://demo.invoiceninja.com/
Re: The Birth and Death of JavaScript (2014)
#139Earlier quoted context omitted.
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.
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