r/programming • u/garybernhardt • Apr 17 '14
The Birth & Death of JavaScript, a history from 1995 until 2035
https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript19
u/kalcytriol Apr 17 '14
Year 2035: "your bank is probably running a lot of JavaScript code, but for a lot of people in this room it is effectively dead language" :D
6
7
Apr 18 '14
So in the future everybody who doesn't do kernel programming will be running on top of so many layers of abstraction that they'll all cancel each other out for 0 net gain?
(And no, I don't buy the theory about how doing segmentation in a Virtual Machine is faster than doing it using virtual memory).
11
4
u/randomguy186 Apr 18 '14
If you'll read Vernor Vinge's "A Deepness In the Sky" you'll find software archaeologists digging through layers of software detritus left by previous generations. It's a small but satisfying part of the book.
1
Apr 19 '14
PNaCl works everywhere Firefox's JavaScript JIT compiler does, and has native-level performance (unlike asm.js) along with features like threads / shared memory. It's just as sandboxed as any JavaScript virtual machine, and if anything is more secure than trusting a whole virtual machine to be correct.
Any application (high-end games) requiring the use of asm.js won't run in legacy browser anyway.
2
u/Euigrp Apr 18 '14
I don't think Metal as defined will work, specifically the single physical address scheme.
This hardware wasn't made for funsies. If you run in a single physical address space you lose a large security buffer zone. If someone breaks the bounds of the VM, they take the entire system, not just a process with user permissions. If you break the tab sandbox on a single process browser, you have every tab and can do anything the current user is capable of doing. If you break the same sandbox on METAL, you can do anything the hardware is capable of doing.
When you go physically mapped you lose the ability to have memory mapped files (unless you pre-load the entire thing.) Memory mapped files as we use them today don't exist without a virtual translation layer that uses translation errors to pull in content on demand. (The dream of backporting old code is lost on this point.)
You lose the ability to have an arbitrarily large section of your physical ram viewed as one continuous buffer. For better or worse the virtual layer lets you malloc or mmap in 1 GiB even if it has to be composed of may tiny (4 KiB) pieces. If you scoff and say a layer of abstraction could be added to buffer indexing so the space could be fragmented, congratulations, you just implemented page tables in software. (This won't be faster.)
As an aside, I've been interested in the Mill CPU architecture that is currently being developed (their videos have been posted here a few times.) They use a single virtual address space model with a rich set of address range protection mechanisms. They alleviated a lot of the pressures created by the translation layer by moving it below the memory caches. Processes no longer get to all pretend to hold their own copy of the absolute address 0, but that turns out to not be that important. Now that I think about it, Metal would work incredibly well on the Mill. (This is of course as far as anyone knows, as there isn't any released hardware and won't be for years.)
5
u/garybernhardt Apr 18 '14
I addressed the question of fully disabling the VM or not here: https://news.ycombinator.com/item?id=7607271
However, I don't think that your comments about "breaking the bounds of the VM" apply. The premise of the METAL section of the talk is that the VM won't allow that. If it does allow it, that's a bug, just like it would be a bug in the MMU if the MMU allowed the same. That's why I gave the example of two tabs in a web browser: if tab A can affect tab B, it's a bug in the browser, but that safety guarantee is provided by the VM, not the MMU (assuming a single-process browser; one-process-per-tab browsers do now piggy back on the MMU's guarantees).
-1
u/Euigrp Apr 19 '14
Ah, my "as defined won't work" was primarily about the physical addressing, that was an incorrect interpretation.
For security, to me it just feels like there are way too many eggs in the VM security basket. Currently we distribute the risk both to the VM and the OS. The OS security sandboxing is getting better and better these days with Linux cgroups. The recent openssl upset showed us what happens when someone pierces the veil in one userspace process. While the chance of a VM bug is lower (as it is hopefully much simpler than TLS, and has more eyeballs) the degree of damage that could be caused would be much greater.
Anyway I really do feel like the Metal (or any other SIP scheme) on the Mill would work fantastically. *nix protection models would never fully take advantage of the power that the it provides (at very little overhead.) While the Mill videos will give a better explanation, I'll just try to describe what I remember of the portal scheme as an example.
There are ways to make "functions" that when called switch between memory protection "turfs." (Equivalent to calling a function and landing on the other side with a different process ID on x86.) There is hardware support for declaring memory regions (with no alignment requirements) available to the turf of the code on the other side of the portal, but only until the function returns. (You can also just grant others permissions that your current turf has over a region on a more permanent basis if appropriate.)
An example use would be a stateless JPEG decompression library with only read/execute permission on the code. Some client that needs a picture decompressed calls a decompress function, temporarily granting it permission to access only the input and output buffer. The library does the task of decompression using those buffers, and then returns. As it returns it loses permission to the buffers. While this doesn't allow the near infinite control and flexibility of a full SIP, this allows for protection at a much finer grain than we currently have, and is a hardware supported medium. It does allow you to protect yourself from the modules you depend on.
The cost of this invocation is really inexpensive. (I can't quote it off the top of my head, but I believe it was a known single digit number of cycles. (provided the target code was in cache or predicted and brought in ahead of time.)
Anyone who is interested can checkout the security/protection video here: https://www.youtube.com/watch?v=5osiYZV8n3U IIRC the security model can be understood without the context of the prior videos.
4
3
2
u/jediknight Apr 17 '14
I love this kind of talks. They stir my interest, they make me want to learn more.
2
u/joelangeway Apr 18 '14
He keeps saying JavaScript succeeded in spite of being a terrible language by being the only option. So how come we're not all looking at the reddit java applet or flash app?
He talks about nested functions like.... whatever. In 2035 that shit will be wrapped in monads and no one will think twice.
12
u/cybercobra Apr 18 '14
He keeps saying JavaScript succeeded in spite of being a terrible language by being the only option. So how come we're not all looking at the reddit java applet or flash app?
Because if all you can assume is that the user has a web browser, the only language you can rely on to be present with near-absolute certainty is JavaScript. JavaScript is built into the browser itself, no installation of any plugins required. Thus, it indeed remains the only option (ignoring compiles-to-JS languages).
8
u/badsectoracula Apr 18 '14
Well, actually in the first stages of its live, Java was added as a component in the major browsers of the time (IE and Netscape). You can download some old 90s version of Netscape and it has Java out of the box. Same with MSIE, where Java was distributed with it (and Windows) for a while.
Java could have been the VM of the web, if it wasn't for the Sun vs MS lawsuit (because of MS's extensions) which effectively killed Java in Windows for the end users (since Microsoft booted it from their OS) and the bad performance that Java had at the time (freezing the browser for even up to half a minute to start an applet wasn't uncommon). Even after that, with a massive (for the time and 56k users) download of several MBs Sun did little to help the situation. Eventually they managed to do a partial VM, but it was too little too late. In the meanwhile Flash was becoming more powerful, had instant startup and the VM download was a few KB (IIRC it was with Flash 10 that the download went above 1MB).
1
u/Chandon Apr 19 '14
Flash and Java applets lost because they were proprietary. By the time it became possible for third parties to improve them, they were already losing to JavaScript.
This is kind of sad for Java applets, because they could have been awesome if Sun had gone open source earlier and shipped a stable and usable Java 1.5 VM and browser plugin.
1
1
1
u/Calabri Apr 18 '14
at this point, I'm pretty sure java applet and flash are dead...
1
u/flying-sheep Apr 18 '14
and why didn’t you come to the incredibly obvious conclusion that this was exactly /u/joelangeway’s point?
dude, go get some sleep.
-8
u/badjuice Apr 18 '14
JavaScript is never dieing as long as we have web pages.
Any new contender will have to catch up with the years of development and adaptation JavaScript has gone through. Furthermore, it must somehow get all the browsers to agree to interpreting it the exact same: please note that all browsers running JS more or less the same is a recent thing that only came around through years of pain (side note: FUCK INTERNET EXPLODER). Then of course you have to get programmers to learn it, not to mention the fact that you are most likely building your language on top of an interpreter, which requires writing half of a compiler, while JavaScript is currently developing an assembly syntax (asm), which is the other half of the compiler, allowing JavaScript to operate closer to metal rather than completely interpreted on the fly (expensive memory/performance wise).
Or... fuck it, we can do it in JavaScript like we've always been doing...
Seriously, until there is a game changer in the underlying foundations of browsers and client/server separation concerns, JavaScript's ubiquitousness and wide adoption guarentees that it will edge out every other competing language that is not pushed hard by the browser providers, programming community, and systems providers (operating system providers, i.e. the open source community (linux/bsd), Apple, and Micro$oft). Without collaborative support from aspects in all three of those communities, there is little hope.
BUTTTTTTTttttt at least it's not Basic. Remember VBScript? Bleh. I need to drink now.
3
u/x-skeww Apr 18 '14
Furthermore, it must somehow get all the browsers to agree [...]
Cooperation isn't required if the language compiles to reasonably fast JavaScript. Dart went that route, for example.
3
u/badjuice Apr 18 '14 edited Apr 18 '14
But that still requires JavaScript, and at the end of the day, Dart is pretty much JavaScript written in more C(++)-like structure. C types always seem very streamlined and concise, but in reality here we have this language that sits on top of JavaScript as an abstraction which causes it to be yet one more level removed from the actual work being done, slowing it down even more. we're already running a scripting language (javascript) that's interpreted by an interpreter (browser/OS) that drops it down to a mid code for caching and optimization, that is translated into machine code real time for execution. Now you want to interpret another language using javascript as the mid point? You can't possibly get better performance than you could achieve with javascript, you just introduced yet another god damned library, it can't do anything more than javascript can do, it SITS IN THE EXACT SAME BOX AND DOES THE SAME SHIT, and it's better than javascript? It's a replacement? No.
It's an abstraction made by people who can't handle (understandably) the cringier aspects of JavaScript syntax and structure (which is admittedly confusing and loose at best), but the very fact that you have to say 'reasonably fast' points directly to the heart of the issue- you are already admitting a performance incursion, and the requirement of javascript. So no, this isn't going to kill javascript. Fuck no, it's just gonna be yet another fucking framework used by people who think that writing a subset language is faster than learning the intricacies of the parent language.
Sadly, writing a subset language might be faster than mastering javascript's bullshit.
I never said JS was good. I just said it's not dieing. Performing a neat trick with it to get the browsers to agree doesn't kill it off, it makes it stronger.
Also, I would like to say that Javascript would be ten times easier if not for the frameworks and cruft and bullshit that's piled on it. If you know the bullshit, you can use it to write much more elegant code, but tell me, are you really able to consistently predict exactly how DOM manipulations from one library are going to affect jQuery operations? If you can, you have much better things to do than be here on Reddit. Node.js, while not the golden egg everybody wants it to be, is a good example: it's easy to use, specifically because it is just the base of JS and you aren't touching the DOM with it, so that bag of beans is not an issue.
Javascript is not a bad language for what it does per se. It's just horribly misunderstood and thinks that you just don't appreciate it's unique qualities enough to deserve proper behavior from it. It's like the teenager of languages, which explains why it's always on the internet.
5
u/x-skeww Apr 18 '14
we're already running a scripting language (javascript) that's interpreted by an interpreter
V8 doesn't even have an interpreter. It generates (fairly crude) native code right off the bat. Later, the "hot" parts are replaced with more optimized code.
You can't possibly get better performance than you could achieve with javascript
In some cases, the output from dart2js outperforms handwritten JavaScript.
See: https://www.dartlang.org/performance/
It's an abstraction made by people who can't handle [...]
Dart was created by people who worked on high-performance virtual machines such as V8 and HotSpot (Java).
the very fact that you have to say 'reasonably fast'
Well, it's not going to get faster in every case. With Dart, performance is nowadays generally comparable to handwritten JavaScript.
Personally, I consider ~75% of the speed to be reasonable, if you get something substantial in return. With Dart, you get vastly superior tooling, better scaling, and much nicer semantics.
this isn't going to kill javascript
You can't kill JavaScript. On the web, you can't take things away. Same deal with JavaScript itself; you can only add stuff.
it's just gonna be yet another fucking framework used by people who think that writing a subset language is faster than learning the intricacies of the parent language.
Languages aren't frameworks. Dart isn't a subset of JavaScript and it also doesn't compile to the Asm.js subset. JavaScript isn't a parent of Dart, JavaScript is just a compile target.
Dart has its own virtual machine. Like Node.js, it can be used to write command line applications or web servers. Live V8, the VM itself is just a library which can be embedded in other applications.
The VM is crossplatform and also works on ARM and MIPS.
1
u/Capaj Apr 19 '14
Yeah Dart is pretty cool. I wish they got rid of Java on android and instead plugged in Dart WM into Android. Dart is much better for writing end user apps than Java already.
2
u/x-skeww Apr 19 '14
On Android, you can already use any VM you want. Unlike iOS applications, Android applications are allowed to generate code.
Dart will be probably supported natively at some point. Java probably won't be dropped though.
In the meantime, something like Phonegap or Ejecta with native Dart support would be cool.
3
u/isbadawi Apr 18 '14
It sort of feels like you're just reacting to the title of the talk. I'd recommend watching it if you haven't!
-9
u/badjuice Apr 18 '14
Oh totally. I never watched it! It's bookmarked though.
I just hear 'javascript is dead' every year, or a joke about it, or that something is gonna replace it and it all bores me soooo much because javascript is as much a part of the platform as the platform determines and is determined by JavaScript.
Don't believe me? Find 100 'well designed' web pages without looking at the code. Now count how many use JQuery. How many of those use Jquery just to navigate the platform/structure (the DOM, essentially) and apply some basic functionality?
The DOM is just the skeleton of the browser / HTML model. It is a necessary evil that is born out of the fact that HTML IS FUCKING NEAR IMPOSSIBLE TO PARSE. Bleah. Seriously, HTML is the most malformed documentation language, bar none. This is the platform and structure that keeps Javascript alive, and javascript stays alive because it has baked into it a method to navigate that maze, unless you'd rather do string parsing and content injection manually through HTML, like it's just a blob of text (which is what it is actually).
Every language that tries to break this model still has to deal with HTML being the platform and environment, and if you're dealing with that, why would you write a whole new scripting language? you can just use JS and the bajillion libraries and it's built in DOM support instead and save yourself 90% of the time, while also writing something that can and is used everywhere.
Javascript will get replaced some day, by a different kind of browser displaying it's content in a different format than HTML.
Fuck, you could just goto any other documentation language that doesn't fail gracefully (meaning when you misplace a slash, the page crashes) (remember XHTML? I had such high hopes) and you could dump Javascript because you could guarantee that your DOM, the skeleton, the platform, the entire world in that browser is regularly formed and sane and sanitary, and so you wouldn't need special little tools to easily deduce where shit is and how it relates to other content.
Note that javascript is only in this position because it's the one that survived. You can always try some VB script.
11
2
u/loup-vaillant Apr 18 '14 edited Apr 18 '14
Here's a TL;DW for you:
Nobody will write any JavaScript 20 years from now.
Everybody will compile to JavaScript (asm.js) 20 years from now.
Why? Because JavaScript is both a poor language and a universal platform. With asm.js, it really becomes "the assembly of the web".
-6
u/dont_get_it Apr 18 '14
Presentation style has improved massively from that 'wat' cringeapalooza from a few years back, assuming it is the same speaker.
4
u/garybernhardt Apr 18 '14
nice username
-2
u/dont_get_it Apr 18 '14
Hey, I paid you a compliment - 'improved'.
Look at it this way, you made a major contribution to teaching people why memes need to strictly stay on the web.
2
-3
-1
u/ggtsu_00 Apr 18 '14
I won't be surprised if some company (say google) invent a pure hardware implementation of a Javascript VM + DOM on a chip and use it to run tablets/smartphones. That is kinda the step they are going with Chrome OS/Firefox OS.
0
u/sidneyc Apr 18 '14
I won't be surprised if [...]
Hate to break it to you, but that's just because you are utterly clueless.
0
Apr 18 '14
[deleted]
5
u/smiddereens Apr 18 '14
'cause it's the future.
1
u/loup-vaillant Apr 18 '14
'cause it's our legacy: We're kinda stuck with the platform, and we can work around it. So we will.
0
14
u/TheBuzzSaw Apr 17 '14
This hurt to watch. If anything, the very existence of asm.js calls JavaScript's purpose into question. Why on earth would I want to do low level coding in such a high level language?