JavaScript creator Eich's latest project: KILL JAVASCRIPT Brendan Eich, the former CEO of Mozilla, has announced a new project that could not only speed up web applications but could eventually see the end of JavaScript as the lingua franca of web development. Dubbed WebAssembly, the new effort is a kind of successor to Asm.js, the stripped-down JavaScript dialect that backers …
Java very similar to the Pascal it is based upon.
For very small values of "very", I suppose.
The Java language is not close to Pascal at all, in terms of its syntax - aside from the similarities common to all the ALGOL-influenced imperative languages - or paradigms, since Java is an OO language and Pascal is not.
As for implementations, while the UCSD p-System Pascal did compile to a bytecode that was later interpreted by a VM, it's hardly "very similar" to Java. Certainly it was an influence, as was the Smalltalk VM, but many variations on compiling to intermediate forms that were then interpreted had been around for decades when Gosling invented Java. Besides p-System and Smalltalk, there were various tokenizing BASIC interpreters and Micro Focus' "int" format for COBOL programs, for example.
... makes him look like he's smelt something unpleasent. Probably the javascript section of the latest HTML5 spec.
"kind of binary object format for the web, one that can be used as a compiler target for all kinds of languages"
Err, we've had that for years. Its called Java bytecode. Oddly craplets didn't prove too popular.
Silverlight didn't last much longer either,
Flash is finally dying.
If they put their minds to it I think they would be able to produce a round circular contraption that could be used as an interface between the ground and a moving object being pulled along by some means of locomotion.
"If they put their minds to it I think they would be able to produce a round circular contraption that could be used as an interface between the ground and a moving object being pulled along by some means of locomotion."
Except it would probably be triangular and fashioned from mud, bits of twig and titanium.
This post has been deleted by its author
What's really needed is to be able to run the LLVM bitcode directly in a page with some APIs that allow it to interact with the DOM, input, rendering and so forth. How the browser executes the bitcode is entirely up to itself - it could even emit JS bytecode if it wanted in-memory (much like Emscripten turns bitcode into asm.js code but without the need to parse it), Or it could do something more sophisticated such as compile it into native assembly code (suitably seeded with stack guards, hooks and so on).
Google's Chrome more or less has this already in PNaCl which is LLVM hooked up to a Pepper API which does the outward bindings. What should really happen is that other browsers adopt PNaCl or use it as the basis of a cross-platform specification which does something similar.
While we're at it, let's dump ALL the Bad Parts (tm): DOM, HTML, XML, CSS... until all that's left are LLVM and some cross-platform 'native' APIs. Cross-platform apps! Wait, this sounds familiar *cough* Java *cough* ... but can we learn from those mistakes? Nah...
I was hopeful about JS and HTML5 a few years ago but it's not working out. On to plan C...
The never ending switches to something old, something new something {Big Red, Chocolate Factory, Big Blue, ...} is getting, no beyond that, f---ing to the point of rendering me homicidal!
Yup, all those promises about fucking code reuse? How does that work when you keep changing the code! <mumble, grumble, lock & load>
This post has been deleted by its author
well, they kind of are, if you extend the metaphor so that your browser becomes a VM or container in its own right because they are a mid-point for addressing the "CPU" of the vm/container/browser.
I understand your pedantry on the matter (hence upvote) and find it tempting myself but it we have to admit that it is either pedantry or a failure to think in terms of abstract entities rather than physical transistors.
So I read Eich's actual blog... he freely admits it's become a cliche that JS is web assembly. This is actually a binary AST format for Asm.js, to cut the client's parsing overhead.
I share your scepticism, 1980s_coder. To paraphrase a line from yesterday's Elon Musk article, it's a shame that all these language designers are fiddling with the web instead of just designing a better language.
it's a shame that all these language designers are fiddling with the web instead of just designing a better language
There are hundreds of language designers out there designing (purportedly) better languages. Most of those languages are never used for real work. Improving the state of web-application development is much more complicated than simply "designing a better language".
And since there will never be agreement on what that "better language" should look like, providing a common runtime for multiple languages - whether it's Asm.js or WebAssembly or something else - that will actually be available on a decent subset of browsers seems rather more productive.
I'm looking forward to the day when the latest WebAssembly version will be 4.0, but 85% of browsers only support up to 3.0, 40% only support up to 2.0, 10% support only 1.0, 35% have dropped support for anything below 3.0 due to security issues, and the boss wants me to use a library that only works reliably on versions 2.0 or 3.0 because 4.0 has changed an opcode. Meanwhile, telling a div to occupy all remaining screen space will still require hours of swearing.
Seriously, the JS syntax is frequently annoying, but it's really not the major problem with the web, not by a long shot.
At last year's PyCon Gary Bernhardt gave an entertaining and informative talk on this kind of thing called The Birth and Death of Javascript. Basically, the combination of LLVM and modern hardware (lots of memory required) allow compiling from one language to another in near real-time.
Javascript was thrown together in a matter of days and has struggles with all kinds of things which could not really have been thought of at the time (yes, I know proper languages had already solved most of the problems correctly) considering its extremely limited domain. Personally, I hate trying to write anything in it but the web has made it ubiquitous. Hence, the desire to find reasonable solutions to the limitations without creating new, incompatible runtimes. Be interesting to see where this goes but I think it's got legs.
I don't think the availability of other languages for the browser will kill JavaScript now. Five years ago, maybe, but today most of its peculiarities have been turned into strengths.
It's very odd. JavaScript spent the first half of its life as the idiot cousin of the family of block-structured procedural languages. Then, apparently without significant change to the language, developers started to bend and twist it to the extent that modern JavaScript looks very different, and can do some remarkable things.
Personally I still find working in JavaScript makes me feel like I'm going round Hyde Park Corner on a bicycle, and it's exasperating the way every month brings a new best-ever framework or library. But these days it doesn't owe its continued existence to the fact that it's the only thing that runs in the browser.
JavaScript itself has never really been the problem - not since ES3 at least.
The real problem is that most "programmers" have never understood that the craftsman maketh the tool - not the other way around.
If you think there is such a thing as "async hell", or that the new hip flavour-of-the-month framework will save you from such-and-such then your problems aren't in JS or ASM or bytecode....
JS code can and should be beautiful, expressive and elegant, but it will happily offer you enough rope to hang yourself. Sure it might be different rope to that of C, but nonetheless it will gladly hand you the rope if you ask for it.
Snobbery and jealousy have long played a part in the JS world, after all - we all know it's not a "real language" don't we?
AS3, Dart, Coffee, Typescript are all borne of people desperately trying to pretend that they don't really write JavaScript - they write in a "proper" programming language.
The thing is despite its flaws - it's succeeded spectacularly where everything else has failed.
The Java community especially, have never got over the fact, that the bastard little runt that was to provide some petty hooks for their web ambitions, ended up delivering the write-once-run-anywhere dream that their blue-eyed boy never could.
Brendan Eich said it best: "Again we see how the Web favors a succession of “little bangs”
Always bet on JS
JS code can and should be beautiful, expressive and elegant, but it will happily offer you enough rope to hang yourself. Sure it might be different rope to that of C, but nonetheless it will gladly hand you the rope if you ask for it.
That, surely, is why JavaScript IS the problem (or part of it, anyway).
A safer language would be beautiful, expressive, and elegant without going around handing out unwanted ropes to all an sundry. Given that half the programmers in the world are of no better than average ability (for some definition of average) we should surely strive to ensure that they use only languages that keep their ropes to themselves.
Snobbery and jealousy have long played a part in the JS world, after all - we all know it's not a "real language" don't we?
Snobbery and jealousy have nothing to do with it. JS is a language that is easy to use badly and difficult to use well.
They say that a bad workman blames his tools -- but the truth is that a good workman knows to choose good tools, and to care well for them. In this case JS is the only tool available, and while a good workman might prefer to avoid it he has little choice. It is a tragedy that such an unsafe tool has become the de facto language for web programming.
Suddenly you wouldn't be able to simply patch buggy Javascript any more, you'd have to mess around with some opaque binary files.
It will make the web even less free and less reliable and it'll introduce whole new classes of vulnerabilities. Suddenly web apps will have buffer overruns, so one part of a web app will be able to overwrite code from another one by accident. Combine that with the typical idiocy of your mediocre web developer and you've got a recipe for disaster.
Web apps already have Javascript which is way fast enough for everything you should do with it. For the rest you have video tags and other cool stuff.
Its a virtual machine being designed for the web, how the hell do you think it will introduce buffer overruns. Do you really think Google, MS and Mozilla aren't aware of the need for security?
Technologies like asm.js are much, much worse - the load times are simply prohibitive for anything beyond a simple demo. If the web is too evolve, something like this is badly needed.
IMO, the idea of a low-level language supported efficiently by all browsers is a great idea. But it should be designed from a clean slate instead of being based on Javascript. That would allow such things as verifiable code (that carries proof hints to speed up verification), vector parallelism that can be executed on the graphics processor, and several more things that the baggage of Javascript hinders. Also, Asm.js does not (as far as I know) support garbage collection, so every language needs to roll its own. Since nearly every high-level language these days uses GC, this ought to be standard on a virtual machine.
What goes around comes around...
23 years ago I worked with a DRA project that was defining an Architecturally Neutral Distribution Format for compilers to target, to allow generation of common object files that could execute on any machine architecture via a machine/architecture specific translator. The project was trying to reduce the complexity of specifying, provisioning and maintaining huge number of applications running across a wide range of machine architectures. It died a death due to the rise of Java, which promised to do much of the same thing with the jvm.
https://en.wikipedia.org/wiki/Architecture_Neutral_Distribution_Format
Not sure which iteration this is on the path to the promised land, but I'm guessing not the last.
From the blog post this was garnered from:
"No, JS isn’t going away in any foreseeable future. Yes, wasm should relieve JS from having to serve two masters. This is a win-win plan."
From the FAQ it links to:
"No! WebAssembly is designed to be a complement to, not replacement of, JavaScript (JS). While WebAssembly will, over time, allow many languages to be compiled to the Web, JS has an incredible amount of momentum and will remain the single, privileged (as described above) dynamic language of the Web. "
So to say "his" project is to KILL JAVASCRIPT is simply clickbait, inaccurate and frankly godawful journalism.
You also fail to mention that it isn't his project, he just blogged about it. Teams from Mozilla, Google and Microsoft have been collaborating on this - which should be an indication it should be taken seriously.
I think some of Apple's webkit dev's may be on board too, but that seems less certain (its listed in a PR requesting to implement support, from one of their own engineers, but that isn't exactly official confirmation).
But... there is something exactly like this already. With existing toolchains, and several languages/compilers targeting it (including LLVM so you play buzzword-bingo and win!). And open implementations*. It's called Flash. But, of course, that's not cool anymore. And certainly doesn't sound as hip as "web assembly". Maybe if we referred to it as "AVM+" instead Brendan could avoid reinventing the wheel.
Not to mention the whole issue of whether we want yet ANOTHER Turing-complete Rube Goldberg machine running in web browsers...
*VM: avmplus; VM+API: lightspark; API: OpenFL
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
