Hacker News new | comments | show | ask | jobs | submit login
JS is Assembly Language for the Web: Brendan Eich, Crockford, & others comment (hanselman.com)
152 points by mbrubeck 2314 days ago | hide | past | web | 50 comments | favorite

How about Rube Goldberg Virtual Machine of the web? I don't see what people are so happy about.

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?

The analogy fails because using XML is, often, a choice. You can't get around JavaScript if you want to make a decent web app. The platform dictates it.

The analogy works in the way that maybe sometimes you shouldn't do a web app but a native client. I don't agree with the conclusion but I think it's what he meant.

We found out about it and started to look for alternatives to XML eventually. Hopefully, if the world does come to believe that compiling to JS is an unnecessary layer of abstraction, we'll have enough force of change from browser vendors to actually implement a lower-level change. At least with XML, we were free to change whenever... in-browser technologies isn't going to change without a concerted effort from just about everyone involved in browsers.

I presume you are talking about CoffeeScript and not something like GWT. The thing about it is that it is not really a layer of abstraction. Just consider an alternative syntax for javascript. The javascript that it produces is really readable.

Just curious, can you give some alternatives to XML? for example like JSON etc.

There is no single alternative to XML, and I don't want to say that all XML is bad. But it's very commonly misused, because someone, somewhere tried to solve the wrong problem and XML happened to be the "default" solution. So, really, the alternatives depend heavily on the context.

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.

JS is ubiquitous because it's the only runtime that MS has ever bundled with Windows that was more or less compatible with other non-MS implementations running on non-MS platforms. It also does not utilize obfuscated and constantly changing object code formats, which is MS's forte.

> It also does not utilize obfuscated and constantly changing object code formats, which is MS's forte.

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?

I assumed he referred to the PE file format, but it looks like Microsoft actually makes a spec available for it.

Well, they have a spec for it, but it's not very good. That said, despite PE's history, it's remained largely the same for what, 15 years? Small changes to support various things, which make parsing arbitrary PEs a pain, but it's not bad considering its age.

Forgive me for parroting the thoughts of those smarter than me, but there was an engaging debate on Lambda the Ultimate recently on how terrible JS is as an assembly language: http://lambda-the-ultimate.org/node/4308#comment-66084

The success of JS is the strongest case for the worse-is-better argument that I can think of.

It's just dumb luck and path dependence. If Netscape had put scheme into Navigator we'd be using that instead.

Dumb luck, as in winning the lottery? Not really. What did Ben Kenobi say to Han Solo about luck?

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.

I doubt an s-expr language would have been palatable, but if Eich had taken a few years to really get the browser language right it would never have taken root like JS has.

I don't see the problem with s-expressions? It would be a nice symmetry - pointy brackets for markup, round ones for code. Eich have stated that he intended to create something like scheme for the web. The Java-inspired syntax (and name) were chosen for marketing reasons, not technical reasons.

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.

Well, M$ had VBScript in their Internet Explorer too, but we aren't all using VBScipt now.

Still, some pretty sizable element of luck is there indeed.

I don't think so.

If the common browser language had been brainfuck we would have had to use that.

Ok, thank you for that, I think I'll just curl up in a little ball under a blanket and shiver for a while!

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)

I think that developers would have learned to write CBL whatever the language. The hype of the web combined with the CBL being the only language available for client side programming practically guaranteed its success, whatever the shortcomings of the language itself.

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.)

For an example of JS truly working like assembly, see here: http://jsil.org/

Another project in the same vein: https://github.com/kripken/emscripten/

Also, here: http://hildr.luminance.org/Platformer/Platformer.html

Where I believe they are actually cross compiling cil into js.

And, of course, http://visual6502.org/JSSim/, where it's acting like an HDL.

Comparing JS to assembly is quite silly.

> 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.

Comparison != Analogy. Analogy != Equivalence. Equivalence != Identity.

Don't they teach this stuff any more?

What a horrible, horrible analogy. It doesn't even make sense.

Why not just say "JS is the common language of the web" without the horrible analogy.

Because "JS is the common language of the web" doesn't capture what the analogy is saying.

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.

You can do that with almost any language. The analogy holds in that you can't get underneath JS in a browser 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 clearly was a language that was designed to be written directly.

The analogy holds in that you can't get underneath JS in a browser

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.

Knowing the ins and outs of the DOM API implementations can get a bit arcane but optimizing JS is mostly about work avoidance and making sure you know how to make the native-code-implemented methods work for you to avoid putting extra work on the JIT/interpreters. You have to maintain a knowledge-base to be strong at it, but it can be very rewarding to see how much more you can get out of your code with a little bit of thought and study. The analogy also holds in that JS is extremely flexible and denies you very little. You can design and code to most any paradigm you want although I suspect attempting to implement static typing would get a little silly where numbers are concerned.

You can do that with almost any language

What other language runs in all browsers?

None, I'm just saying that nothing in Javascript other than its ubiquity makes it particularly suitable for this.

Shouldn't Flash be the choice then? There are languages compiled to Flash file, such as Flex or ActionScript.

There's a reason why Flash has mostly been relegated to video, audio, and games, and it's not because Flash integrates so seemlessly smooth with websites. Javascript is in the bones of the web, Flash is just a layer on top.

What powerful drugs they're using to produce such great distortion of reality? ^_^

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)

Pretty sure you're getting downvoted due to the insinuation that the legends of JavaScript aren't thinking clearly due to drug use. You could just address their points directly if you think they are misguided.

The link above is just a compilation of quotes.

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.

The most interesting insight is that because JS is higher level than Java bytecode, it avoids some of the lower-level compatibility issues, which actually makes WORA easier, even when considering JS a VM language.

It's a bit worse than an assembly language, because it doesn't have JMP.

Eyeroll. Sorry for the content-less comment, but I think it reflects the content value of this post.

Yeah, I just listened to the entire podcast on the subject, and this whole "JS as assembly" is just dumb. The guy seems utterly mixed up about what JS, assembly, and IL represent.

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.

"Javascript is the x86 of the web"

This won't be fully true until everyone is on the same page with ECMAScript5.

What do you mean? I think you might be missing the point. ECMAScript 3 is almost universally supported to the letter and will continue to be for the forseeable future, just like modern x86 processors are backwards compatible with the ABI from decades ago, and hence is a rock-solid foundation for projects like GWT that compile to it.

ES3 has become the universally compatible "write once, run anywhere" bytecode VM that Java promised to be.

Actually, I'd say that having multiple different "standards" from different vendors is a pretty good description of both Javascript and x86.

Let's just phrase this analogy explicitly:

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


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?

You're really torturing the analogy there, aren't you?

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...)

I think the first analogy is the right one, and I think I've got what's missing from it:

"x86 assembly language is to an x86 processor as; JavaScript is to the Web."


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact