The Birth and Death of JavaScript (2014) [video](destroyallsoftware.com)
destroyallsoftware.com
The Birth and Death of JavaScript (2014) [video]
https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript
44 comments
I get more and more excited the closer we get to an eventual reality that a kid learning about programming, operating systems, Linux, etc. is just a click on their phone away from starting it all. No gatekeepers--appstores, sideloading, hacks, jailbreaks, locked down BIOS, etc.--to hold them back. Your browser, a shell, and the entire world in front of you.
I get the feeling that the world was significantly more open to kids growing up with access to computers in the 80s and 90s, because as someone whose formative years were the 00s and early 10s, the interesting bits of technology were already buried under a thousand layers of abstraction and indirection. Kids nowadays won't ever learn what a shell is unless they go out of their way to learn it for some reason.
My daughter finished her CS degree about a year ago. I was glad to see that one required class had her build a very simple computer from gates as her final project. I don’t know the details, but I think the computer had perhaps 10 different instructions. She didn’t like that project very much, but I thought it was valuable; someone has got to understand the principles of operation at that level.
I started programming in the 60’s and at times had to load instructions into machines using binary on front panel switches. That’s the reasons that machines of that time had the lights and rows of switches on the front so that one could debug programs by looking at the lights to see the program counter, data value, or instruction. See [1] for a photo of a large front panel on an iconic machine of the time.
I even recall pulling plug panels out of card processing equipment to reprogram the sorting and selecting of input data being run through machine as huge stacks of punch cards, see [2] for a picture of a mid-20th century plug panel for data-processing.
The layers of abstraction are important. They enable us to construct some of the most useful, complex, and intricate artifacts ever made on our planet. Today I program in high level languages, and I get to use powerful frameworks, database systems, and amazing hardware right on my desk. Yet, I do miss some of the fun of invention and hacking on systems that I really understood in depth.
[1] https://en.m.wikipedia.org/wiki/Front_panel#/media/File%3A36...
[2] https://www.ebay.com/itm/133017817600?hash=item1ef87ad200:g:...
I started programming in the 60’s and at times had to load instructions into machines using binary on front panel switches. That’s the reasons that machines of that time had the lights and rows of switches on the front so that one could debug programs by looking at the lights to see the program counter, data value, or instruction. See [1] for a photo of a large front panel on an iconic machine of the time.
I even recall pulling plug panels out of card processing equipment to reprogram the sorting and selecting of input data being run through machine as huge stacks of punch cards, see [2] for a picture of a mid-20th century plug panel for data-processing.
The layers of abstraction are important. They enable us to construct some of the most useful, complex, and intricate artifacts ever made on our planet. Today I program in high level languages, and I get to use powerful frameworks, database systems, and amazing hardware right on my desk. Yet, I do miss some of the fun of invention and hacking on systems that I really understood in depth.
[1] https://en.m.wikipedia.org/wiki/Front_panel#/media/File%3A36...
[2] https://www.ebay.com/itm/133017817600?hash=item1ef87ad200:g:...
>My daughter finished her CS degree about a year ago.
Interesting I thought CS was all software where computer with gate and low level programming were something of EE / Computer Engineering.
Interesting I thought CS was all software where computer with gate and low level programming were something of EE / Computer Engineering.
I believe that it was a two semester sequence that covered gate level logic, microcontrollers and assembly language, and a hardware lab with oscilloscopes etc. I would have picked slightly different classes than the ones she ended up taking for her degree, but having worked in industry myself, I thought the exposure to hardware she got could be useful for her in the future.
My own educational background (Math, EE, CS) has given me a lot of flexibility over the last 50 years.
My own educational background (Math, EE, CS) has given me a lot of flexibility over the last 50 years.
Sorry, you would be wrong. There was no internet. You were lucky if there was one other person around you who knew BASIC and could answer questions. Everything you needed to learn came in books that cost $30 each (at a time when $30 was a lot of money), and most of the books at the computer store were for using spreadsheets and word processors, not actually coding. Great, you had a DOS shell right in front of you, but learning what to do with it was a struggle. And writing .bat files isn’t very exciting. Maybe if you were in a place like SV, there would be tons of resources to learn, but in most other places you would be in an information desert. I was interested in computers but gave up because I hit the limit of what I could learn pretty quickly and couldn’t get any further. Kids have it MUCH better today.
That's really not true though, lots of dev-focused tools explicitly require hopping into a terminal and typing away commands. Plus at a certain point, anyone with any real curiosity is going to think "I wonder what's hidden behind these abstractions I see all the time?" and dig deeper anyways
You'd think that, wouldn't you? Yet here I am, someone who grew up thinking computers were obtuse and boring because getting the computer to do anything interesting seemed like it would require knowing a thousand things not related to the issue at hand. I was always a mechanically minded person, so while the inner workings of things seemed interesting, making toy websites (the entry level computer thing to do in that time period) seemed about as interesting as watching paint dry.
But here I am, working as a software engineer and half way through my MSc in computer science. It took a couple of low level microcontroller classes in my mechanical engineering undergrad for me to see the light.
But here I am, working as a software engineer and half way through my MSc in computer science. It took a couple of low level microcontroller classes in my mechanical engineering undergrad for me to see the light.
It's still a lot harder (abstraction layers add complexity) to get close to metal as opposed to say, DOS.
You’re still stuck in the browser sandbox (I prefer to think of it as a Browser-Plato’s-Cave in the context of whole nested systems). And you can’t escape the rectangular box imposed on you by the browser. …especially on mobile OSes: there is essentially zero system-integration by going that route because Apple and Google both need incentives to entice people into forking over that lovely 15-30%.
Things like Push notifications. Background activity. Guarantees about data persistence. First-class Home Screen app icon. Ability to directly share data with other native applications even if they don’t want to (to the extent it’s enabled by the platform’s native Share Activity). And to a lesser-extent: the ability to use native widgets for the best user-experience on that plstform. Too many SPAs fall into uncanny-valley when they start to look too similar to native widgets - and it’s off-putting.
And the fact that Fortnite still isn’t available as a PWA on iOS is telling… I was expecting them to launch an OnLive-like service rendered to a <canvas> over WebRTC by now… and worryingly this gives Apple a strong incentive to immediately halt any work on improving WebRTC in PWAs…
Things like Push notifications. Background activity. Guarantees about data persistence. First-class Home Screen app icon. Ability to directly share data with other native applications even if they don’t want to (to the extent it’s enabled by the platform’s native Share Activity). And to a lesser-extent: the ability to use native widgets for the best user-experience on that plstform. Too many SPAs fall into uncanny-valley when they start to look too similar to native widgets - and it’s off-putting.
And the fact that Fortnite still isn’t available as a PWA on iOS is telling… I was expecting them to launch an OnLive-like service rendered to a <canvas> over WebRTC by now… and worryingly this gives Apple a strong incentive to immediately halt any work on improving WebRTC in PWAs…
> I was expecting them to launch an OnLive-like service rendered to a <canvas> over WebRTC by now… and worryingly this gives Apple a strong incentive to immediately halt any work on improving WebRTC in PWAs
Like Stadia? (https://youtu.be/3_RAyxpFurU?t=113)
Like Stadia? (https://youtu.be/3_RAyxpFurU?t=113)
Exactly the same, yeah.
Are we getting closer or is it the opposite?
Very close, almost all of POSIX is implemented in browsers now. Look at for example JSLinux https://bellard.org/jslinux/ for the classic example, or more recently stuff like pyodide that compile real desktop Python to run fully in the browser with WASM https://github.com/pyodide/pyodide
AFAIK there are a few loose ends still TBD with WASM & WASI to support sockets and networking, but once that's in place we'll likely have a full WASM POSIX environment in your browser. Get some of the core tools like gcc, etc. prebuilt and you're good to go to just start building the world in your browser. No app store reviewer to hold you back, no megacorp to decide homebrew apps aren't allowed anymore... the world is your oyster to create and share anything.
AFAIK there are a few loose ends still TBD with WASM & WASI to support sockets and networking, but once that's in place we'll likely have a full WASM POSIX environment in your browser. Get some of the core tools like gcc, etc. prebuilt and you're good to go to just start building the world in your browser. No app store reviewer to hold you back, no megacorp to decide homebrew apps aren't allowed anymore... the world is your oyster to create and share anything.
> almost all of POSIX is implemented in browsers now.
POSIX is not implemented anywhere. There are degrees to which it's implemented in various systems. It also doesn't mean that having POSIX implemented makes things accessible to anyone, or that this 40-year-old standard is even relevant anymore.
> Look at for example JSLinux https://bellard.org/jslinux/ for the classic example
It doesn't mean that POSIX is implemented in the browser:
- it's basically an emulator running on top of some browser tech that runs linux.
- Linux is mostly, but not entirely POSIX-compliant
> we'll likely have a full WASM POSIX environment in your browser. Get some of the core tools like gcc, etc. prebuilt and you're good to go to just start building the world in your browser
This will literally never happen outside of some geek circles. If only for the simple reason: you'll have to download the entirety of Linux and its tools into the browser for every user.
POSIX is not implemented anywhere. There are degrees to which it's implemented in various systems. It also doesn't mean that having POSIX implemented makes things accessible to anyone, or that this 40-year-old standard is even relevant anymore.
> Look at for example JSLinux https://bellard.org/jslinux/ for the classic example
It doesn't mean that POSIX is implemented in the browser:
- it's basically an emulator running on top of some browser tech that runs linux.
- Linux is mostly, but not entirely POSIX-compliant
> we'll likely have a full WASM POSIX environment in your browser. Get some of the core tools like gcc, etc. prebuilt and you're good to go to just start building the world in your browser
This will literally never happen outside of some geek circles. If only for the simple reason: you'll have to download the entirety of Linux and its tools into the browser for every user.
I don't know where your rage is coming from, other than to be a pedant.
Downloading the entirety of Linux, coreutils, etc. _is_ the point. Right now a kid with an iPhone is limited to programming it with whatever toy apps Apple has decided to allow on their app store. Or on Android you're lucky to be allowed to use Termux to run a little proot environment to mostly use core linux tools. There's _no_ way for that kid to learn and use 'real' programming languages and tools--want to learn rust? Sorry, you're SOL. Want to program some Go? Not going to happen. Etc.
But give that kid a browser window that's a full POSIX shell with gcc and all the coreutils built. Perhaps some CDN hosting precompiled packages just like apt/rpm/etc. repos... and now we're talking. They can do _anything_ and no app store limit or whatever will stop them.
This is precisely for geek circles. The kind of geek that opens up that weird qbasic.exe they found rooting around their parents DOS machine and then blew their mind at the possibilities. We don't have anything like that for kids today and it's a real shame, but the birth and death of JS demo here made into reality can change that. I look forward to the day some kid clicks a link, sees a blinking bash prompt and a pointer to read some man pages or help files and has their mind blown too.
Downloading the entirety of Linux, coreutils, etc. _is_ the point. Right now a kid with an iPhone is limited to programming it with whatever toy apps Apple has decided to allow on their app store. Or on Android you're lucky to be allowed to use Termux to run a little proot environment to mostly use core linux tools. There's _no_ way for that kid to learn and use 'real' programming languages and tools--want to learn rust? Sorry, you're SOL. Want to program some Go? Not going to happen. Etc.
But give that kid a browser window that's a full POSIX shell with gcc and all the coreutils built. Perhaps some CDN hosting precompiled packages just like apt/rpm/etc. repos... and now we're talking. They can do _anything_ and no app store limit or whatever will stop them.
This is precisely for geek circles. The kind of geek that opens up that weird qbasic.exe they found rooting around their parents DOS machine and then blew their mind at the possibilities. We don't have anything like that for kids today and it's a real shame, but the birth and death of JS demo here made into reality can change that. I look forward to the day some kid clicks a link, sees a blinking bash prompt and a pointer to read some man pages or help files and has their mind blown too.
> I don't know where your rage is coming from
I don't know why you assume I have any rage. I'm just pointing out facts.
> There's _no_ way for that kid to learn and use 'real' programming languages and tools--want to learn rust?
Ah, yes. "Real programming languages", not "toys provided by Apple". "Kids wanting to learn Rust on a phone".
> But give that kid a browser window that's a full POSIX shell with gcc and all the coreutils built.
And?
> They can do _anything_
No. They still can't do "anything". Since Linux is already running in the browser, go ahead, run it on a phone, install rust into it, and go do "anything". Then come back and tell me if any kid will want to do that.
> This is precisely for geek circles. The kind of geek that opens up that weird qbasic.exe
Ah yes. So now you're limiting all kids to just geeks who are willing to tinker with a rust compiler running in a shell in a linux running on a wasm on a browser on a phone. God forbid it would be other kids with "apple toys" and "non-real programming languages" that don't require "a full POSIX shell with gcc and all the coreutils built".
> I look forward to the day some kid clicks a link, sees a blinking bash prompt and a pointer to read some man pages or help files and has their mind blown too.
More likely than not that kid will see a blinking prompt, and will go away saying "what in the fresh hell is this".
Modern "toys" open significantly more opportunities for kids to learn than any posix shell. Apple's Swift Playgrounds will teach and interest a few magnitudes more kids to learn programming than a "bash shell with a prompt to read man pages".
I don't know why you assume I have any rage. I'm just pointing out facts.
> There's _no_ way for that kid to learn and use 'real' programming languages and tools--want to learn rust?
Ah, yes. "Real programming languages", not "toys provided by Apple". "Kids wanting to learn Rust on a phone".
> But give that kid a browser window that's a full POSIX shell with gcc and all the coreutils built.
And?
> They can do _anything_
No. They still can't do "anything". Since Linux is already running in the browser, go ahead, run it on a phone, install rust into it, and go do "anything". Then come back and tell me if any kid will want to do that.
> This is precisely for geek circles. The kind of geek that opens up that weird qbasic.exe
Ah yes. So now you're limiting all kids to just geeks who are willing to tinker with a rust compiler running in a shell in a linux running on a wasm on a browser on a phone. God forbid it would be other kids with "apple toys" and "non-real programming languages" that don't require "a full POSIX shell with gcc and all the coreutils built".
> I look forward to the day some kid clicks a link, sees a blinking bash prompt and a pointer to read some man pages or help files and has their mind blown too.
More likely than not that kid will see a blinking prompt, and will go away saying "what in the fresh hell is this".
Modern "toys" open significantly more opportunities for kids to learn than any posix shell. Apple's Swift Playgrounds will teach and interest a few magnitudes more kids to learn programming than a "bash shell with a prompt to read man pages".
On the other hand, having a 70M sloc OS act as a bootloader for a similarly sized pile of hacks which is treated like an OS does not sound like a very exciting platform...
Submitted multiple times earlier. The thread with the most comments (227 comments) -
https://news.ycombinator.com/item?id=7605687
https://news.ycombinator.com/item?id=7605687
Wat?
Javascript will never die, unless there's something to come along and either replace browsers or replace the scripting language used by browsers.
WASM is not a replacement to JavaScript and never will be. It's not even a damn language.
WASM is not a replacement to JavaScript and never will be. It's not even a damn language.
I beg to differ. WASM, if it doesn't go off the rails with future revisions, will supplant JavaScript because of WASM being a compilation target. This, in effect, opens up any language to run on the web. JavaScript may not fully disappear, but usage will most likely greatly diminish.
A small JavaScript text file which can currently run natively on any browser will always be far superior to a binary WASM blob that's compiled.
WASM fills in a use case where you need to run highly performant code on a browser. It just so happens that you can write it in whatever language you choose.
WASM fills in a use case where you need to run highly performant code on a browser. It just so happens that you can write it in whatever language you choose.
There's no difference--that small JS text file gets compiled on the fly into platform-specific assembly language with today's JIT compilers in browsers. WASM is just skipping the text source step and giving browsers something they can compile directly.
I do agree it is a shame to lose direct insight to the text source code, but let's be honest the production JS shipped to browsers today is far, far from being human readable. It's minified and shrunk to the most small and incomprehensible degree to save bandwidth. View source and try to read and understand the JS on any big site like facebook.com, etc. and you won't get very far.
I do agree it is a shame to lose direct insight to the text source code, but let's be honest the production JS shipped to browsers today is far, far from being human readable. It's minified and shrunk to the most small and incomprehensible degree to save bandwidth. View source and try to read and understand the JS on any big site like facebook.com, etc. and you won't get very far.
There's a big difference in how you develop, ship and share the code.
I would say a page loading a 1KB JS file better off than a WASM binary blob that's 2MB.
Edit: to be clear, I'm not focusing on performance
I would say a page loading a 1KB JS file better off than a WASM binary blob that's 2MB.
Edit: to be clear, I'm not focusing on performance
> WASM fills in a use case where you need to run highly performant code on a browser.
That's not exactly correct. It's possible to write equally performant code in just Javascript, by being careful to avoid certain features of the language (e.g. garbage collection, expando objects, dynamic types for variables, etc). Writing code in a stricter language like rust or c++ might make hitting those targets a little easier, but also using TypeScript can make it easier, too.
With the exception of loading, parsing and some JIT profiling, as WASM can potentially be smaller, and it can skip the majority of parsing and early profiling.
So WASM shouldn't be thought of as a tool for achieving speed. It should more be thought of as a means for running cross-platform code, for languages other than Javascript.
That's not exactly correct. It's possible to write equally performant code in just Javascript, by being careful to avoid certain features of the language (e.g. garbage collection, expando objects, dynamic types for variables, etc). Writing code in a stricter language like rust or c++ might make hitting those targets a little easier, but also using TypeScript can make it easier, too.
With the exception of loading, parsing and some JIT profiling, as WASM can potentially be smaller, and it can skip the majority of parsing and early profiling.
So WASM shouldn't be thought of as a tool for achieving speed. It should more be thought of as a means for running cross-platform code, for languages other than Javascript.
Javascript is still popular today even if you ignore the browser. Node is all over the place.
Javascript is the C of the web. We had a chance to learn from hindsight, and instead we made a different behemoth without realizing it.
Or is it? One thing JS and C have in common is a minimal core, kinda loosely defined, relatively easy to implement, that nonetheless lets you create powerful abstractions. I don't think it's a coincidence. I think anything more sophisticated and "well-built" ironically would have seen less initial traction, and lost first-mover advantage.
That JS wasn't a Lisp is kind of a pity, though. But again, Lisps have been around longer than almost any other language yet are still comparatively obscure, which tells me something inhibits their broader adoption.
That JS wasn't a Lisp is kind of a pity, though. But again, Lisps have been around longer than almost any other language yet are still comparatively obscure, which tells me something inhibits their broader adoption.
sad news for some people but now that it has been truly made independent of the browser JavaScript will never die, in the same way that every other programming language that has ever been used to build applications is still puttering around.
There are too many people with worthwhile JavaScript skills to service, too many companies who have things built in it and employees with those skills who will keep building things in it.
Maybe in 2050 there will be Cobol style posts on HN about JavaScript.
on edit: changed removed from to something more understandable
There are too many people with worthwhile JavaScript skills to service, too many companies who have things built in it and employees with those skills who will keep building things in it.
Maybe in 2050 there will be Cobol style posts on HN about JavaScript.
on edit: changed removed from to something more understandable
I think it's not too unreasonable to say that this includes a successful prediction of webassembly.
Wasn't the contemporaneous asm.js already in commercial use in 2014?
I tend to disagree. Asm.js is dying. Webassembly is not "everything on top of JavaScript". While higher layers can work the same as they could with asm.js (still in the web browser), it's not what GB predicted.
asm.js already existed when this was written with AOT compilation support in Firefox
I was thinking of a new 'open source website' concept, where you can call your website 'open source' if all the javascript behind it is unobfuscated/unminified, comments still there.
I would even like to take it a step further, an 'open source' OS where every binary has symbols available. The system can be stopped anywhere and the full stack trace is understandable.
I would even like to take it a step further, an 'open source' OS where every binary has symbols available. The system can be stopped anywhere and the full stack trace is understandable.
Symbols being stripped isn't usually for "open source" reasons. Neither is minification. It's done to reduce sizes.
A binary with symbols has tons of extra crust that is largely unnecessary. Even if you have them, what good does a stack trace do if you don't also have the source to fix it?
A binary with symbols has tons of extra crust that is largely unnecessary. Even if you have them, what good does a stack trace do if you don't also have the source to fix it?
The point is complete transparency into everything happening on your computer through installed application, operating system, or loaded website. Absolutely nothing would be running as an obfuscated binary.
The source to build it is not just 'open'. All running binaries would be able to be mapped to their corresponding source.
The source to build it is not just 'open'. All running binaries would be able to be mapped to their corresponding source.
Again, we don't "obfuscate" binaries to make them harder to decipher. We do it because debug symbols are massive and cause a lot of bloat and sometimes even performance hits.
If you want a system like that, just compile Linux and all of your tools in debug mode. But again, why do this when you can just recompile from source?
This is a gross misunderstanding of how computers work, I feel.
If you want a system like that, just compile Linux and all of your tools in debug mode. But again, why do this when you can just recompile from source?
This is a gross misunderstanding of how computers work, I feel.
> Even if you have them, what good does a stack trace do if you don't also have the source to fix it?
It makes patching the binary yourself a heck of a lot easier. As is often the case with legacy enterprise software from a vendor now long-gone…
It makes patching the binary yourself a heck of a lot easier. As is often the case with legacy enterprise software from a vendor now long-gone…
Do you want full open source? Or allow enterprise software? pick one.
How are those mutually exclusive?
Enterprise software ends up as something invariably so specific to the company using it that it doesn’t matter if it’s open-source or not - absolutely no-one could extract any value from it than the original company and whatever kafkaesque internal processes lead to its development.
Anything more general-purpose is already commodity - ERP being the prime example.
Enterprise software ends up as something invariably so specific to the company using it that it doesn’t matter if it’s open-source or not - absolutely no-one could extract any value from it than the original company and whatever kafkaesque internal processes lead to its development.
Anything more general-purpose is already commodity - ERP being the prime example.