JavaScript is Web Assembly Language and that's OK.

http://www.hanselman.com/blog/JavaScriptIsWebAssemblyLanguageAndThatsOK.aspx

by daigoba66 • 13 years ago

72 108 13 years ago

mbrock2• 13 years ago

Isn't it more like, uh, Java for the web, except without a bytecode? This analogy is just weird.

Drakim• 13 years ago

Java was always an external plugin to the web (like Flash), while JavaScript sits more comfortable in the same shelf alongside HTML and CSS.

mbrock2• 13 years ago

The web is an external plugin to the computer. JavaScript is its programming language.

codeulike3• 13 years ago

The article does say "Maybe 'JavaScript is the Web's Bytecode' is better." - in the first parapgraph.

xradionut• 13 years ago

JavaScript is a kludge. It's a bag on the side of a bag. The amazing thing is that it works well enough to be useful.

codeulike3• 13 years ago

JavaScript is a dynamic language with C-syntax, prototype-inheritance and lambdas. Embedded into every browser on the planet. Whats not to like?

vijayp• 13 years ago

Also, no integers. Who needs integers anyway?

arocks• 13 years ago

One of the endearing qualities of web design and development was how the source was open for everyone (HTML, CSS and JS). Developers could read the code, understand and remix each other's work. This helped in its rapid growth from a design platform to an application platform.

Enter asm.js, where the source code is as readable as a compiler's assembly output. Once again we are back to code that is hard to hack and improve. Sort of similar to the days of Flash except that entire applications are being built on this platform.

It might be a great end user experience, but it is not the best way forward for web development.

k__2• 13 years ago

I know, there was a time when people took their scripts from different sites and included then into their own.

But does this still happen?

I mean most of the scripts are minified anyways :\

jiggy20116• 13 years ago

People still do that, when they want a rotating banner effect for their website or whatever.

Once you get into more complex applications it doesn't really make sense to do that anymore.

wwwtyro5• 13 years ago

> Enter asm.js, where the source code is as readable as a compiler's assembly output.

What do you mean? Isn't it roughly as readable as C?

jerf4• 13 years ago

No, it's roughly as readable as decompiled executable, without even a symbol table to provide semi-readable names. John Resig has a somewhat reformatted example a couple of pages into this: http://ejohn.org/blog/asmjs-javascript-compile-target/

pekk4• 13 years ago

Not C written by humans

pornel2• 13 years ago

No, asm.js is not readable, and doesn't look like C nor even typical JS.

Due to very limited set of expressions available it's too hard to write by hand (e.g. no objects, casts required everywhere, one flat array representing memory), so all non-trivial asm.js programs are spit out by compilers that treat it like assembly and preserve very little structure of source programs.

jerf4• 13 years ago

Does it matter anymore, though? Back in "the day", documentation was poor and nobody knew what they were doing. Document is massively better now. Javascript libraries abound, perhaps to a fault. Does anybody learn how to program the web by looking at other people's work now?

In those rare cases I've done this in the last few years, the sum total has always been to find out which CSS property or JS function I didn't know about was being used, and then simply pop that into Google. I certainly didn't stare at their code for any longer than that.

zampano• 13 years ago

Wow, I'm still a relative newcomer, but I constantly pull up the CSS and JS for any site that seems interesting. Considering how easy Chrome devtools makes it to play around with sites, I figured most enthusiasts/professionals were doing the same thing.

mistercow• 13 years ago

But we already had arrived at the point of unreadable source code with the advent minifiers and tools like Closure Compiler.

wslh4• 13 years ago

I bet that in less than 10 years we are running a standard VM in the browser instead of Javascript.

BTW, it would be interesting to add real $$$ bets in HN. In this way users can play with real money, not only with argumentation.

mattmanser• 13 years ago

Both the Chrome and Firefox teams seem so incredibly reluctant to do it though and are almost desperately trying to do anything but.

pekk4• 13 years ago

I don't see how Chrome is dragging its feet on this.

michaelwww3• 13 years ago

http://longbets.org/

wslh4• 13 years ago

Yes, I would like to have one integrated in HN :-)

wslh4• 13 years ago

http://predictionbook.com/ ?

JonSkeptic2• 13 years ago

It would be OK if Javascript was a better language. It is terrible, but it works. Most importantly, there is no alternative. That's why we use it.

jiggy20116• 13 years ago

assembly is a pretty nasty language if one tries to write an entire program in it.

JonSkeptic2• 13 years ago

Agreed, but there are numerous alternatives that compile easily to assembly without ridiculous amounts of set up and prayer. We can program in C, C++, Python, Ruby, Java, any number other languages that will ultimately all be executed in the exact same fashion, barring some technical differences.

This does not exist for Javascript. You can jump through hoops to compile other code to Javascript and hope that it works and works acceptably, that's it.

Javascript isn't assembly, it's the only language and it's terrible.

zxcdw3• 13 years ago

How so? That's how programs were written back in the day(and some still are, see for example Demoscene), which arguably were somewhat simpler than what we have these days(but that's more because of vast libraries than languages, imo).

The awesomeness of assembly language is that it's perfectly exact, deterministic and thus very predictable and efficient. No unnecessary indirection unless you build it yourself. No implicit type casting(infact, no types at all). Nothing. Just plain instructions with very specific semantics to build from.

Now how does JS(or even asm.js) fare with it's tons of indirection and ambiguous implicit typecasts compared to an actual assembly language? From a technical standpoint for a compile target the comparison is embarrassingly unfair, but hey, this is something which is supposedly "OK" and acceptable, right?

jumblesale• 13 years ago

That doesn't account for node's popularity. I like Javascript. That's why I use it.

saosebastiao• 13 years ago

I'm not an arbiter of what makes things popular, but from what I can see, Node's popularity has more to do with the fact that front end guys no longer have to learn a new language to work on the back end.

smrtinsert3• 13 years ago

So you're saying you weren't a web dev before, and that you went straight to Node.js.

Herald_MJ4• 13 years ago

No, it's not, and it's certainly not OK. Javascript is a quirky interpreted scripting language created for scripting minor workflow events. It's an afterthought by Netscape, duct-taped to a bundle of silly hacks, wrapped up in some interesting attempts to standardise, with a few more vendor-specific hacks crowbarred in there for good measure. asm.js is one more hack on top of the mess, and while it's technically interesting, and probably very useful (much like the rest of javascript), we shouldn't be building these monstrous feats of engineering on top of such shaky foundations.

> there's only one language that works everywhere without installation or trouble and that's JavaScript.

This is true. But we've arrived at this situation virtually by chance, and it's a huge mess and we shouldn't be readily accepting it. We need a real bytecode for the web, we need it to be standardised and we need to push for browsers to support it. NaCl seems to be the furthest down the road to this objective so far.

_pmf_2• 13 years ago

Concise and correct; there's really not much more to say on this topic.

tg33• 13 years ago

Javascript is not just a "quirky scripting language for minor workflow events." It is a powerful, expressive language, that has many benefits over contemporary languages, regardless of setting. Yes, it has quirks, and yes, there are some things that coming from another language are difficult to grasp, but it is not a Bad Language.

The fact that Node.js, Javascript on the server, is gaining so much popularity in the developer community means that it has benefits beyond its universality in the browser.

Asm.js is not a "hack on the top of the mess", it's a simplification of "the mess" down to it's simplest, most bytecode-esque parts. And it's performance is shockingly close to Native.

Javascript is not the perfect bytecode for the web. But it does work as a bytecode for the web, and with asm.js, it seems that it works decently well. I think efforts are better spent improving Javascript, asm.js, and languages that can target it rather than swimming upstream.

Herald_MJ4• 13 years ago

> Javascript is not just a "quirky scripting language for minor workflow events." It is a powerful, expressive language

I didn't say it was just for minor workflow events, I said it was created for minor workflow events - it's just good fortune that Brendan Eich was an experienced language designer and created something that was powerful and extendable enough to bring us to the situation Javascript is in today.

It's certainly powerful (particularly considering it's original intentions), I disagree that it's expressive in comparison to other modern languages.

Why anyone thinks server-side javascript is a good idea is beyond me.

mbesto2• 13 years ago

The fact that Node.js, Javascript on the server, is gaining so much popularity in the developer community means that it has benefits beyond its universality in the browser.

The fact that Node.js is becoming popular is simply a symptom of having a ridiculously large ecosystem of developers, and not much else.

bradleyjg• 13 years ago

tg3 circa 2002:

The fact that PHP is gaining so much popularity in the developer community means that it has benefits beyond its universality in shared hosting environments.

johnpmayer• 13 years ago

> We need a real bytecode for the web, we need it to be standardised and we need to push for browsers to support it.

We had one. It was called Java. Actually, we still have it, but it just has such a bad reputation now; users don't trust it because of "security" and developers don't trust it because of "public static cruft()" and "Oracle".

But it is still quite capable. Did anyone else first play minecraft in a web applet? It worked incredibly well for me. So I argue that we do have a viable bytecode, we're just ignoring it.

mwcampbell11• 13 years ago

Java is not vendor-neutral as JS is. That makes JS better.

pekk4• 13 years ago

The experience sucks beyond compare, always has, and blaming the user isn't going to solve that.

You have to download a separate plugin with stupid ads in it. If your version is wrong, it won't work or it won't work right. A number of things won't work unless you use the one from Oracle. If you are lucky, a little tray reminder obtrusively harasses you every few weeks to update to a new version. If you don't, you have to worry about unpatched vulnerabilities. Now you come across a page with an applet in it. This applet stuck inside a little rectangle on the page takes a few seconds to kick off at all. Most of the time it looks terrible once it's up. It isn't at all uncommon that it crashes. Many people have experienced this bringing down the browser or even hanging the computer, which is especially awesome when you didn't even ask for the thing to run.

This isn't a matter of the users being stupid and not knowing what's good. This isn't good. It has never been good.

protomyth• 13 years ago

But the JVM was never really part of the browser, it was a plug-in like Flash. If we had a way to include JVM byte code in a page and JVM had just as much access to the DOM as javascript then it would be useful.

smrtinsert3• 13 years ago

Java moves ahead despite peoples continued misconceptions about it. There are js-based jvm bytecode interpreters: https://github.com/int3/doppio seems pretty nice.

hosay1232• 13 years ago

> duct-taped to a bundle of silly hacks, wrapped up in some interesting attempts to standardise, with a few more vendor-specific hacks crowbarred in there for good measure

By this point you could easily have been confused for someone describing amd64 (nee ia32, nee Pentium, i486, i386, 80286, 8088, 8080, 4004.. circa 1971).

Just as we still have a perplexing set of registers and operations that happen to encode efficiently on this ubiquitous architecture due to their suitability to application in our distant ancestors' desktop calculators (binary-coded decimal, anyone?), no matter what kind of cleanliness you're alluding to existing in proposed alternatives that you might hope supplant Javascript.. in 40 years it'll look just as stale and nasty as x86 and Javascript do today.

Not least PNaCl, where last I checked they were busy trying to shoehorn an architecture-specific binary format (bitcode) into something that might run on multiple machines. If that's not enough for you, the original NaCl relied on a vestigial 80286-specific hack (segmentation) that was finally removed in amd64. It's turtles all the way down.

winter_blue2• 13 years ago

> By this point you could easily have been confused for someone describing amd64 (nee ia32, nee Pentium, i486, i386, 80286, 8088, 8080, 4004.. circa 1971).

He said "We need a real bytecode for the web" not some architecture-specific machine language like x86 et al.

LLVM or JVM are examples of bytecode. They're highly portable (at least the JVM is), and they're not the mess that practically any real hardware instruction set is.

> last I checked they were busy trying to shoehorn an architecture-specific binary format (bitcode) into something that might run on multiple machines

The bitcode you're referring to is LLVM. It's an architecture-independent assembly that can be used to target most major real ISAs. For instance, the Clang compilers use LLVM as their backend. Any programming language designer could use LLVM and instantly (and easily) be able to generate native code for who knows how many different architectures.

So I think the parent poster was right in what he/she said.

fetbaffe2• 13 years ago

JavaScript is successful because it is a hack in it's very core.

espadrine• 13 years ago

Can't wait to see the rebirth of Java^W NaCl applets.

Seriously, though, if you never see the underlying JS, if you code and debug everything in your preferred language and the result is fast, why would you care what your program compiles to?

Nobody objects to having their programs compile to PE on Windows, nobody requires Microsoft to use ELF or Mach-O instead! Even though, nowadays, PE is a bunch of pieces of cloth sewed together, nobody cares as long as it works!

mwcampbell11• 13 years ago

Don't despise modest beginnings or sloppy evolution. Sloppy evolution from a very modest beginning has achieved things that we haven't yet come close to matching through deliberate design, such as our own species. And it does this by always taking the next incremental step from what it has, with no regard for the greater elegance of some hypothetical master plan.

pekk4• 13 years ago

And yet if we had to either write in or compile all our code down to QBasic in order to make web apps, we would be justified in complaining about that.

rmrfrmrf2• 13 years ago

No. If I want byte code, I'll use Java or a native app. This idea that a web browser should be an operating-system-in-a-box-over-http needs to stop.

JavaScript is not a bad language. If you're getting caught up in gotchas and 'quirky' behavior, why not just read EMCA-262 [1] ? It lays out all defined behavior of JavaScript so you'll know exactly what the interpreter is doing when it reads your code.

[1] http://www.ecma-international.org/publications/files/ECMA-ST...

mwcampbell11• 13 years ago

> This idea that a web browser should be an operating-system-in-a-box-over-http needs to stop.

Why? The Web platform is the only non-proprietary platform that has serious market-share among end-users and mind-share among developers. Therefore, it's the only thing that has a serious chance of ending the dominance of proprietary platforms. IMO, that goal is important enough to override any aesthetic concerns that we developers might have.

pjmlp• 13 years ago

It is no different than targeting C.

zxcdw3• 13 years ago

I don't understand why people say such silly feats of pseudo-"engineering" are somehow "OK" and acceptable. How have we arrived to this situation?

I get that 1) agreeing upon a more sane bytecode-based language for the web 2) implementing it on all major browsers 3) changing the tooling and workflow(no more a .js file, save and open in browser but a compiled file instead) would perhaps be not worth the benefit(more sane target, better support for common programming constructs without performance, safety or determinism issues and so on).

Simply, people don't give a fuck, web works "well enough" and iterative engineering solves the major problems. These just are things we have to deal with, something we can't change, which I find pitiful but understandable, but most definitely not "OK" or acceptable.

pornel2• 13 years ago

> I don't understand why people say such silly feats of pseudo-"engineering" are somehow "OK" and acceptable.

Network effect and worse is better.

Any solution that cannot be introduced gradually with backwards- and forwards-compatibility is very unlikely to gain traction on the web. You'll always get a vendor that doesn't like some tech or has multi-year-long development/distribution/upgrade process. Tools can be even slower to upgrade and you'll also need to educate developers and get them out of their comfort zones.

It's not that people don't give a fuck. It's not pseudo-"engineering". It's the best you can get within constrains that are both technical and social.

fetbaffe2• 13 years ago

Thanks to JavaScript we rediscovered functional programming, because we realized that the inheritance model Java polluted everywhere just stinks.

TheCondor• 13 years ago

I prefer to think of it as web COBOL.

Ygg2• 13 years ago

I had a silly idea. Why not make LLVM a part of browsers? I heard it was a really performant albeit hard to write languages in. It seems to not have the stigma attached to JVM, especially association with oracle.

mwcampbell11• 13 years ago

This is what PNaCl (Portable Native Client) is trying to do. I'm skeptical though; PNaCl is still experimental in Chromium 29 (the current development version), and requires the browser to download extra files outside of the Chromium package itself, probably because LLVM is quite bulky. If we're going to run high-performance code with the C memory model in a browser, I think asm.js is the best way to do it.

mwcampbell11• 13 years ago

What bothers me about asm.js and Emscripten is that, if used on a large scale, they'll perpetuate the C memory model, that is, a single flat heap of arbitrary size in which things are referenced via fixed pointers. Perhaps this memory model is necessary for small pieces of high-performance code, but I wouldn't want us to keep using it as the primary memory model for new applications, especially when at least some of the current JS engines have advanced copying/compacting garbage collectors.

I would love to have a memory-safe language that compiles to efficient JavaScript with no intractable semantic or runtime mismatches between the JS and the source language or its libraries (e.g. no preemptive threads with shared memory) and takes full advantage of the JS engine's garbage collection, but can also be compiled ahead-of-time to fairly efficient native code for environments where JIT compilation isn't an option (e.g. iOS apps). I suspect that a language like this would need static typing. To gain traction, such a language would need to stick to fairly mainstream concepts (e.g. not purely functional). Perhaps this language could be a subset of JS itself. The trouble with Java and C# is that their standard libraries and most third-party libraries assume multiple threads and blocking APIs; perhaps the compiler to JS could transform the code into continuation passing style.

taylodl• 13 years ago

JavaScript is most emphatically not the assembly language of the web. It is instead the lingua franca of the web. I actually think this is what people intend to convey when they say this sort of nonsense.

JavaScript is Web Assembly Language and that's OK.

Related Stories