But the people calling for a bytecode for the browser never went away, and they were never entirely wrong about the perceived advantages. And now they’re going to get their wish. WebAssembly is a new project being worked on by people from Mozilla, Microsoft, Google, and Apple, to produce a bytecode for the Web.
WebAssembly, or wasm for short, is intended to be a portable bytecode that will be efficient for browsers to download and load, providing a more efficient target for compilers than plain JavaScript or even asm.js. Like, for example, .NET bytecode, wasm instructions operate on native machine types such as 32-bit integers, enabling efficient compilation. It’s also designed to be extensible, to make it easy to add, say, support for SIMD instruction sets like SSE and AVX.
Please, raise your hands those who think that blobs inside the web is the latest of the WORST IDEAS from a security POV.
Right here
These things are TERRIBLE at security as it is.
Why is it bad for security? It is all sandboxed. Such bytecode is not less secure than Javascript.
Edited 2015-06-18 17:28 UTC
Exactly, such bytecode is dangerously insecure, just as Javascript is.
Javascript itself is just a language, just like bytecode is basically a “language” (just a very simple one). It’s the implementation of the interpreter that’s potentially insecure.
One can argue that having this sort of flexibility for webpages causes a lot of security risks. But that’s an entirely different argument than “bytecode is worse than what we have now (Javascript)”, which is simply untrue, as Alfman nicely illustrated with the Javascript minimization process versus Java decompilers.
Sooner or later, the web programmer cry for more performance and the sandboxes get direct access for this and that. Starting with the right to access local files.
But with byte code, it will be harder to analyze what is going on.
DeepThought,
My posts earlier refute this very point; Javascript does not imply transparency. and although I haven’t covered this as much, having a bytecode does not imply an opaque black box.
Edited 2015-06-19 21:32 UTC
franzrogar,
The “human readable” quality of javascript became irrelevant when javascript became a compilation/obfuscation target. Alas, once we concede that reverse engineering is necessary to understand the code, then it’s not really worse than a bytecode.
Another thing to consider is that some bytecodes, such as Java’s, are so strongly structured that it’s quite strait forward to produce very human readable source from them. In fact, if it weren’t for the lack of comments, one might even mistake the decompiled code for the original source.
http://jd.benow.ca/
Conceivably, a browser’s web developer tools might feature a WebAssembly reverse compiler. Not only would this render the bytecode transparent, but it could be much more readable than a lot of the obfuscated javascript or asm.js gibberish we have today.
It’s done for compactness (I never understood why it couldn’t be just compressed proper) to reduce load times. But you can easily restructure it back into normal format and it will still be way higher level code than WebAssembly.
shmerl,
It’s done for various reasons. But I want to make sure the point doesn’t get lost that once you take this approach, it nullifies any benefit that javascript had in terms of readability.
The initial design documents already mention that an isomorphic text format is mandatory for the MVP (i.e. minimally viable product). In other words version 1 will have a human readable text format that is equivalent to the binary format, and conversion between the two is lossless.
And of course you could always generate source maps to allow debugging using the original language semantics.
https://github.com/WebAssembly/design/blob/master/TextFormat.md
Really where is the problem ? I have no problem reading that code when I put it into this:
http://jsbeautifier.org/
It’s even built-in to your browser:
https://developer.mozilla.org/nl/docs/Tools/Debugger#Pretty-print_a_…
There is no maybe, WebAssembly will support a text-format:
https://github.com/WebAssembly/design/blob/master/FAQ.md#will-webass…
Edited 2015-06-19 00:13 UTC
Lennie,
Original C code:
https://raw.githubusercontent.com/kripken/sql.js/master/c/sqlite3.c
In order to run everywhere, asm.js is forced to use exceptionally odd syntax work around javascript limitations. Look above, see how the code is littered with the bit-wise or operator “|”, this is to work around loose typing. Javascript lacks a 1:1 mapping for native data structures, and anyways javascript’s object model is intentionally avoided because it’s too slow, so instead asm.js uses byte arrays. Technically hacks like this can work to maintain an equivalent state. But most of the original structure gets lost in translation.
Regardless of one’s opinion about whether a browser should use asm.js versus a bytecode, I hope we can agree upon these points:
1. Being in javascript does not automatically make it more intelligible.
2. A bytecode that’s designed to be used this way could have a better 1:1 representation, which would increase coherency of code & intentions when translating forwards and backwards.
3. Also, in terms of the OP’s point about security, using a bytecode instead of javascript doesn’t make a difference.
Edited 2015-06-19 02:13 UTC
Ahh, the first code looked a bit like it might be hand written and optimized. That is why it looked readable.
Yes, I know the asm.js syntax, not very pretty at all.
And that was going to be my point too. The ‘byte code’ won’t be the same. It won’t need all the extra silly asm.js-like workaround code.
So it will be more readable than the asm.js code.
Not saying it will be great. 😉
The security is mainly problem of APIs and quality of the runtime, the form of code serialization is secondary.
If you had checked the FAQ you’d know it’s just a binary representation of the Javascript syntax:
___
Will WebAssembly support View Source on the Web?
Yes! WebAssembly defines a text format to be rendered when developers view the source of a WebAssembly module in any developer tool. Also, a specific goal of the text format is to allow developers to write WebAssembly modules by hand for testing, experimenting, optimizing, learning and teaching purposes. In fact, by dropping all the coercions required by asm.js validation, the WebAssembly text format should be much more natural to read and write than asm.js. Outside the browser, command-line and online tools that convert between text and binary will also be made readily available. Lastly, a scalable form of source maps is also being considered as part of the WebAssembly tooling story.
https://github.com/WebAssembly/design/blob/master/FAQ.md#will-webass…
If you compare this:
https://github.com/WebAssembly/design/blob/master/AstSemantics.md
with this:
http://asmjs.org/spec/latest/
You find that the former is largely identical to the later as far as programming model, data types, etc. In other words WebAssembly is an idealized representation of the programming model of asm.js.
As such, it can be converted into JavaScript, because it maps directly to the semantics of the asm.js programming model (same data types, same statements, same mechanism to represent the heap, etc. etc.) But it isn’t in and of itself JavaScript at all.
galvanash,
It was javascript’s inadequacies that make asm.js so convoluted. WebAssembly is a super-set of asm.js, with capabilities for datatypes and (bounds checked) heap access. From what I can tell, this will allow it to much better represent the original languages without needing to emulate such capabilities using javascript byte arrays.
So it should be trivial to convert asm.js into WebAssembly, but conversion in the other direction from WebAssembly to asm.js will still be a convoluted process because once again the heap & structures have to be reduced to javascript byte arrays.
Well yeah… But the asm.js programming model isn’t convoluted, its rather mundane. Its translating to a JavaScript representation and all the baggage that entails that results in the convolution.
I’m all for this. I think it is a great idea. I just don’t think it is quite on the mark to say JavaScript’s inadequacies make asm.js convoluted… The idea of using a rather simple dynamically typed functional language as a compiler target for C/C++? That is convoluted. This WebAssembly thing is definitely much better than that…
galvanash,
Ah ok, I guess it’s just the wording that had me confused. I agree that, if by “model” we mean the concepts behind asm.js as an abstraction, then it’s fine. As you say, it’s the implementation on top of javascript that made it convoluted.
If WebAssembly is any good and pans out, I expect it will find uses outside of the web also, such as spawning new kinds of portable app stores and maybe even portable operating systems.
Sorry, instead of Javascript syntax, I should have described it as: Javascript VM AST ( https://en.wikipedia.org/wiki/Abstract_syntax_tree )
Because minified, obfuscated – and often terribly written, and unstructured – JavaScript isn’t a blob?
Get a grip! ByteCode, especially when it implements a standards isn’t any different. At all.
Yes, YES, YESSSSS!!!!!!!!!!!!!!!
Finally, _REAL_ programming languages for the web. I’ve been waiting for this for the last 20 years. I feel I’m going to cry!
Next step: get rid of HTML.
So all websites would, in essence, be apps? Would that make simple text-and-jpeg web pages load faster, slower, or no difference?
No, I mean something that actually lets you design the layout properly.
We have HTML (5) for that. However separating format, layout, and content in HTML requires discipline, and mastery in CSS-fu, which does not happen all too often.
It is quite possible to write structured HTML which layout and format neutral, and use separate CSS files for managing layout (i.e: mobile, print, etc), and format (i.e.: beautify). Of course, so far the only reasonable option for behavior was JavaScript, which could be fixed by this, or similar initiatives.
Edited 2015-06-18 20:35 UTC
[q]We have HTML (5) for that. However separating format, layout, and content in HTML requires discipline, and mastery in CSS-fu, which does not happen all too often.[/quote]
And that’s exactly the problem. Current HTML layouting is utterly broken. I see web developers at work – they spend hours and hours to design and fix the layout for every damn browser.
And when they’re done, someone else comes in and adds something that breaks everything. The situation is bad especially in mobile.
You know the web is always evolving, the web has everything it needs in a modern browser for example for building toolkits in an efficient manner:
https://elements.polymer-project.org/
Yes, and lets get something better than CSS, ditch that non-standard crap. It has been a nightmare since it was introduced.
Questions:
How asm.js and WebAssembly projects are related?
Is WebAssembly the natural (joint effort) evolution of asm.js?
Are they the same idea implemented in a different way?
Will WebAssembly replace asm.js? Does it have different goals?
https://github.com/WebAssembly/design/blob/master/FAQ.md
Imo yes, assuming it works as intended. It has all the same benefits, eliminates many of the former’s weaknesses, and by virtue of what it is should be much more amiable to optimization and future extensions.
It wants it’s terrible idea back.
Anyone remember java applets?
The horror.
A lot of differences here:
* It will let native and legacy apps to run inside the browser (opening the possibility to run games in any platform at minimum cost). Porting of legacy applications to web environments can be delayed/postponed.
* It will run the bytecodes inside the JavaScript sandbox; so it is inherently more secure than Java applets.
* It will use all the JavaScript infrastructure that already exists.
Yup. I liked those. It took 15 years for javascript to reach the same functionality and speed (as in “javascript needs a Core 2 to equal the speed of Java on a Pentium 2”). The only real thing missing from Java applets was the integration with the DOM.
Loading speed was and still is a problem of Java.
Look at how long it takes for a Java application to start.
I think this is finally a step into making the Web civilized.
This is not your 1997 Java Applets thing. This is bytecode done after 20 years of experience in bytecode and with bytecode running successfully in a protected environment on all the mobile platforms. This is done with the horrible experience of JavaScript, which I want forgotten for the rest of eternity. JavaScript is the things that horrifies me the most, and all I can say is “Good riddance”.
WASM is, in my own view, the big four of browser market getting together to improve the darned thing. Just like HTTP/2 it drops the human readable element for the computer readable element, the idea being that if a computer can read it, it can translate it for you. It’s a step towards really using the power of the present-day processors, not copying text and mapping text to code, which is the most that JS does.
And JS is a horrible language. I’m looking forward to writing C++ and C# code for the web, and be confident that it reaches all the users in the world. Finally.
The project is initiated by dev’s from MS, Mozilla and Google. I think taking a WebKit Bug report requesting support as “being worked on by” is stretching it a bit.
I hope you’re right, I really hope so, but after the PointerEvents fiasco I don’t have much confidence in that.
Didn’t Java start like this? The ultimate Web language? Compile once, run everywhere?
I doubt that another byte code will solve future problems. And most likely, they will have to search a lot to find today’s problems this new thing.
Why do web pages load slowly? Because >60% of the content is rubbish like animated advertisement.
1) It is NOT Assembly, even CALLING it Assembly is ignorant halfwit nonsense and insulting to anyone who ever actually learned machine language. As someone who started out hand assembling my own RCA 1802 machine language and entering it on toggle switches — and who STILL writes 8088 and 6502 machine language today — them even using the term borders on offensive!
Is it processor specific? Is it using opcodes that ACTUALLY correspond to hardware specific machine language instructions? NO? THEN IT’S NOT ASSEMBLY!!!
Just like the “virtual machine” BS, it’s an interpreter that may someday have a JIT compiler. It’s bad enough Java went and made up some BS claims about what it is, without this “new” technology abusing a term that has little if anything to do with what it is. … and yes, that’s me making air quotes with my fingers around “new”
It’s ALMOST as ignorant as the nitwits who call XML a “machine readable format” or think that base64 is a native efficient storage method. (the latter only being true if you’re still on a PDP-11) — Makes those of us who actually understand these terms and used them when they MEANT SOMETHING feel like delivering a pimp slap to the current generation.
Hell, given some of the idiocy I’ve seen cross-processor transcoders and P-Code interpreters do, and the history of BS claims about speed from previous attempts (like Java) that still have zero basis in reality, I’m not entirely hopeful on this.
That said, it’s about damned time there was a bytecode transmission method for scripttardery; except for one little problem.
2) the LAST thing we need right now is MORE scripttard BS pissing away functionality, bandwidth and accessibility of websites. IT’s bad enough people crapping all over their websites with mouth-breathing idiocy like jQuery and ignoring the very reason HTML and CSS even exist with dumbass bull like bootcrap, without giving them YET ANOTHER way to add “gee ain’t it neat” nonsense to websites like all the other web crapplet asshattery that has effectively made websites today a fraction as useful and often slower than they were 20 years ago.
But of course, such sensibilities are lost upon the mouth-breathing halfwits sleazing together websites any-old-way with shortcuts and outright scam artist bull like Turdpress, bootcrap and jQueery — since they see nothing wrong with wasting 3 megabytes in six to eight dozen separate files to deliver 5k of plaintext and a dozen content images that shouldn’t even total 128k.
Of course, they’ll probably also use the SCRIPT tag for it or want their own tag, just like the idiotic redundancies that the 5-tard bull introduced with AUDIO and VIDEO, instead of using the tag meant to fight vendor lock-in called OBJECT. Yay for bleeding edge of pre-strict coding methodologies! Nothing like dragging everything back to the WORST of the 1997 to 2000 browser wars.
3) … and get off my damned lawn!
Edited 2015-06-21 11:59 UTC
deathshadow,
Wow, what a rant… haha it made me laugh! You are right, it’s not really assembly, rather it is a bytecode. I’d be for calling it “web bytecode” maybe.
I’m not so sure that things are slower (given the rapid technological advancement). But if they are, it’s probably just because we’re transferring so many more resources than before. Even just a plain vanilla HTML/CSS website can get resource heavy. And moving things into the client can and sometimes does help save a lot of the overhead going on between the client and server. So I believe we’d be in the same boat regardless of scripting.
Now with this said, when scripts are abused they clearly have the potential to make things much worse. My favorite parts store (newegg) has been using more and more scripting to control the experience, which has me going to alternatives because their scripts are so damned buggy. Some navigation links use javscript to update the contents, which gets refreshed but the “loading divs” aren’t deleted afterwards and occlude the new page contents. Very frequently the product image browser breaks with javascript errors. I would gladly take their website from two years ago over this new piece of garbage.
Edited 2015-06-21 17:06 UTC
I’m actually looking forward to this. A lot of languages already compile to bytecode in various ways: java and python being the two that I use regularly. They always need some bytecode interpreter or vm or some equivalent that is domain specific. If this gets supported by all the major browsers, I’d be willing to wager that projects like PyPy.js are abaondonned in favour of directly compiling to the new bytecode. Essentially, we’re going to have a browser standard bytecode interpreter that all the compilers can target. So Yay!
And with google involved, and their experience with Dalvik and ART, they’ll probably find a way to compile Java directly to this bytecode as well. Which, I’d wager, means Oracle probably gets cut out of the Java ecosystem for browser plugins. So no more Ask toolbar bullshit.