JS is Assembly Language for the Web: Brendan Eich, Crockford, & others comment
hanselman.com
hanselman.com
It looks a bit like the thing that happened with XML. In years 2000-2005 developers got really, really excited about XML, and started to use it for everything. Everything, including things that it was never meant for. And yes, the resulting technologies worked (kind of), but they caused more problems than they solved. SOAP/WSDL. XSLT. All that XML-to-SQL-query stuff.
Right now people are really excited about JavaScript and begin to use it for things that are less and less appropriate for it. Yes, you can compile languages into JS, just like you can use XML to generate an SQL query. But is it really a good idea?
What I've seen personally often involved overly complex SOAP/WSDL services for things that could be accomplished with a simple HTTP request. Look at query prams, return the correct HTTP code and you're done.
Another common pathology is problem over-solving. Instead of writing a library to solve some problem and providing a sensible API, people write the library, hide it, then write an XML "driver" that consumes a custom-designed language encoded via XML tags. The alternative in this case is simply providing the original API.
CIL is insanely simple (I've written a CIL->x86 compiler in a matter of hours) and has only had small, incremental changes since the very first version.
Are there really any examples of what you're talking about outside of the Office team?
Subtle chains of cause and effect were at play among people involved, going back years to Silicon Graphics (Netscape drew from UIUC and SGI, plus montulli from Kansas, and jwz). Also going back through the living history of programming languages. SICP and some of the Sussman & Steele "Lambda the ..." papers made a big impression on me years before, although I did not understand their full meaning then.
Remember, I was recruited to "do Scheme", which felt like bait and switch in light of the Java deal brewing by the time I joined Netscape. My interest in languages such as Self informed a subversive agenda re: the dumbed down mission to make "Java's kid brother", to have objects without classes. Likewise with first-class functions, which were inspired by Scheme but quite different in JS, especially JS 1.0.
Apart from the "look like Java" mandate, and "object-based" as a talking point, I had little direction. Only a couple of top people at Netscape and Sun really grokked the benefit of a dynamic language for tying together components, but they were top people (marca, Rick Schell [VP Eng Netscape], Bill Joy).
Rather than dumb luck, I think a more meaningful interpretation is that I was a piece of an evolving system, exploring one particular path in a damn hurry. That system contains people playing crucial parts. Academic, business, and personal philosophical and friendship agendas all transmitted an analogue of genes: ideas and concrete inventions from functional programming and Smalltalk-related languages.
You might think "it's still luck, it could have been Forth, or TCL". Not likely. There were not years or even months to spare. I had hacked language implementations for fun since I was an undergrad, and for SGI's packet sniffing tools earlier my career. I was a C/Unix fanboy, I knew the C grammar by heart. Independent of me, the "Make it look like Java" order was not just lucky, it was congruent as a consequent, even predictable, given the rise of C in the '80s and C++ in the '90s, and the direct influence of C++ on Java.
My point is simple: the likelihood of any other language syntax than C (C++ -> Java, but really: C) was low. The likelihood of something without "objects" was also low. Netscape recruited me in part because I could hack quickly, and in part because I had some language implementation chops (not enough, in hindsight). I was "that guy", not in any brag-worthy sense, just the only person who was in the position to do the deed, with (barely) enough skills to pull it off.
Many hackers could have done a better job with more time, or perhaps a better job had they been in my shoes. Who knows? But no one at Netscape could have, and the opportunity was there and then.
The path dependence part is spot on. Netscape's business plan for 1.0 was getting out in six months or someone else would kill Mosaic and take over. The entire platform push in 1.1 (plugins) and 2 (frames, JS) was about getting on first. We knew Microsoft was coming, because Netscape had rejected a low-ball offer from them in late '94.
He couldn't just have used scheme wholesale though, since a major part of JS is the integration with the DOM. He would have needed to create some custom object system anyway to support that. So it would have been a new language anyway, and due to the time constraints at the time, it would probably have had the same amount of bugs and mistakes that JS ended up with.
Still, some pretty sizable element of luck is there indeed.
If the common browser language had been brainfuck we would have had to use that.
That said, it is important to note why brainfuck (or any other blub) wasn't the common browser language (or CBL from here on in) - the CBL is the CBL because it was relatively easy for humans to write small snippets of code in it. Without that, the language would never become the CBL.
Unfortunately that statement also means that the odds were against the CBL being anything other than an imperative style language. That we got something so close to a functional language is really quite a bonus (even if I do end up having to modify strings and eval() because we aren't using s-exprs)
Note that VBScript were much more familiar to many developers, because VB was one of the most popular language at the time. But it fell by the wayside because it was not supported at ubiquitously as JS. (It was also a much worse language than JS, but that was not the reason it failed.)
Where I believe they are actually cross compiling cil into js.
> Shaver's right, assembly without a great macro processor is not good for programmers or safety. JS is. So the analogy needs some qualification or it becomes silly.
This way you can compare anything to anything else and then try to qualify.
Don't they teach this stuff any more?
Why not just say "JS is the common language of the web" without the horrible analogy.
The key aspect of the analogy is that you have compilers emit or JIT to JS, rather than writing if yourself, and then have languages/DSLs that users write to, rather than JS.
Yes. That's why JS is the target (and its ubiquity).
but if you were to design a browser language with this kind of usage in mind it seems you'd want something that was a lot easier to optimize than JS
JS isn't turning out to be too bad to optimize. Post-lower optimization already occurs in the browser. The part the compiler would do is optimization prior to emission to JS.
What other language runs in all browsers?
JS could be called something like In-Browser Java (and it is heading to be the same bloated failure) or something. But assembly.. ^_^
Reality distortion is very common think among Java fan-boys. Some of them, for example, believe that a VM implemented as user level C++ program which uses its own unrelated to CPU base data-types and several layers of abstractions to interact with an OS, will run faster and more efficient than other c++ program linked directly with core OS libraries.
Now JS fan-boys thinks that if there are things like V8 or such as artificial as popular things like Nodejs, everything must be written in JS. That reminds me the very same slogan from Java's best days.
To dear down-voters: Think for a moment what is v8 or Spidermonkey and count how many code you should pile up to get access to something as simple as data stored in a MySQL table (or any other data behind its own socket-based protocol). ^_^ (yes, reality-checks are always painful)
Legeds of Javascript are thinking about their own fame, their own place in the world, their money and their own selves, in the first place.
His entire premise is based on the idea that you can convert one language into another, and therefore the target language is equivalent to assembly. That's ludicrous. I believe Facebook converts PHP into C or C++, therefore C/C++ is the new assembly. What?
The guy should just stick to talking about techniques for using cleaner languages and converting them into JS. Instead, a bunch of link-bate BS was poorly conceived and thrown in.
This won't be fully true until everyone is on the same page with ECMAScript5.
ES3 has become the universally compatible "write once, run anywhere" bytecode VM that Java promised to be.
x86 assembly language is to an x86 processor as; JavaScript is to ??
So in this case it would be wrong to say that "??" is the JavaScript interpreter, because assembly language is a representation of machine code - it's basically an set of labels attached to binary numbers right?
The x86 processor executes machine code (I think actually some of the "backwards compatibility" in an x86 processor is provided by a scripting-like-language implementation on the chip but that's invisible to the assembly language programmer so not part of this discussion).
So I think you'd have to say that:
JavaScript is to a JavaScript interpreter as; x86 machine code is to an x86 processor
Then:
x86 assembly language is to x86 machine code as; ?? is to JavaScript
Now one could argue that CoffeeScript is the assembly language of JavaScript (I've not used it but it seems to be a roughly 1-to-1 mapping of one set of instructions to another, aliased for aesthetic purposes).
But getting back to the original analogy, I think it would be better stated as:
If you think of a web browser as a kind of computing platform for which we can write applications, then JavaScript is like the machine code that makes it run.
I think that makes sense - and it also makes sense to build higher level languages on top of JavaScript in that case, since increased computing power has always enabled us to get more done with fewer man-hours, why should this be any different?
Rather than take it literally, let's restate the analogy to better capture the intent: If you want your language to run on an x86 processor, you should compile it to x86 assembly and if you want your language to run in the browser, you should compile it to Javascript. Simply put.
There was a time when many "alternate" languages compiled to C instead of directly to assembly (e.g. early implementations of Eiffel). If this were still the trend today, then the analogy would better be stated as "Javascript is the C of the cloud".
(as an aside, I've been saying that "Javascript is cloud assembly" since late 2008...)
"x86 assembly language is to an x86 processor as; JavaScript is to the Web."