Slashdot Mirror
WebAssembly and the Future of JavaScript
Nerval's Lobster writes: WebAssembly is the next stage in the evolution of client-side scripting. In theory, it will improve on JavaScript's speed. That's not to say that JavaScript is a slowpoke: Incremental speed improvements have included the rollout of asm.js (an optimized subset) in 2013. But WebAssembly—while not a replacement for JavaScript—is intended as a "cure" for a variety of issues where JavaScript isn't always a perfect fit, including video editing, encryption, peer-to-peer, and more. (Here's a full list of the Web applications that WebAssembly could maybe improve.) If WebAssembly is not there to replace JavaScript but to complement it, the key to the integration rests with the DOM and Garbage Collected Objects such as JavaScript strings, functions (as callable closures), Typed Arrays and Typed objects. The bigger question is, will WebAssembly actually become something big, or is it ultimately doomed to suffer the fate of other hyped JavaScript-related platforms such as Dart (a Google-only venture), which attracted buzz ahead of a Minimum Viable Product release, only to quickly fade away afterward?
Never heard of it. Probably a passing fade. I predict decades more of Javascript and (alas) Flash.
I can learn assembly language! On the web, no less!
One of the big "security benefits" I've heard claimed is that WebAssembly will only be able to invoke the same functions/methods as JavaScript itself. So that implies that WebAssembly is nothing more than pre-compiled JavaScript.
As the compile phase of JavaScript pales in comparison to the execution phase, the only people I can see pushing for this are those who want DRM-style protection of their JavaScript so no one else can read it.
I do not fail; I succeed at finding out what does not work.
Google and MS are teaming up on this and it will be in AngularJS 2. With that kind of weight behind it, I'd bank on it being the next JS replacement/supplement.
Previous attempts at replacing JavaScript always suffered from a boot strapping problem. While there are only a small number of major desktop browsers, overall, there are actually a lot of different minor browsers that people expect to work. And even among the desktop browsers, not everybody always runs the most recent release.
Content producers don't really like writing content that only 30% of their users can view. So, unless a new technology is rolled out to 90+% of the deployed browsers, nobody is going to write content for it. On the other hand, if nobody writes content, the rest of the browser manufacturers won't put any resources into adding support for the new technology.
Both asm.js and WebAssembly have a fallback mode that uses plain JavaScript, as available in virtually 100% of all browsers. Performance will obviously be degraded, but that's much better than making the content completely inaccessible. And users are more likely to upgrade their browsers, if they can see a low-fidelity version of the content and know by switching to a newer browser they'll get the high-fidelity version. So, unlike the previous scenario, this is actually a virtuous circle.
JavaScript execution speed is not the important thing about WebAssembly. What does matter is that it may open up the development of software for execution inside a browser to a wider variety of languages, almost all of which are likely to be better than JavaScript in one way or another.
you know, like a shadow!
Need to be more useful than jQuery, AngularJS, etc.
Content producers don't really like writing content that only 30% of their users can view.
Developers of exclusive apps for Mac, iOS, and video game consoles have historically not had much of a problem with limiting their market. They think they can get a better overall return on investment from targeting OS X only compared to OS X and Windows, or iOS only compared to iOS, Android, and Windows Phone, or one console compared to all consoles plus Windows PC.
What does matter is that it may open up the development of software for execution inside a browser to a wider variety of languages
That already existed: Emscripten compiles any language with an LLVM front-end, such as Clang++, to asm.js. Apparently one of the goals of WebAssembly is to make Emscripten more practical.
We'll use it when it has 95% browser support. And no, polyfill doesn't count.
This signature can save you $400 on your car insurance!
Hello, it's 2015, where's my MULTIFUCKINGTHREADING? I a fucking sick of seeing just one particular core die under JS duress while the others just sit there sucking their thumbs.
For some reasons some people think that on the WEB there should only be that crap that javascript is.
I think some of the problem is that some codgers think the World Wide Web is the wrong place for interactivity in the first place. They want to read static documents. And if they want to interact in any way, they prefer doing so through POSTing a <form>. Finally in cases where the form paradigm is not enough, they prefer native apps such as an SMTP/IMAP, NNTP, or IRC client. They don't want any JavaScript, much as the couple in that Monty Python sketch didn't want any SPAM luncheon meat.
To those people I say: If someone releases a new native app for communication over the Internet, good luck installing a Windows .msi on your Mac or a Mac .dmg on your not-Mac. Or good luck recompiling any app for a major set-top box and running it, even if you have written your own 10 foot user interface.
Hello, it's 2015, where's my MULTIFUCKINGTHREADING?
What problems have you run into with Web Workers?
Might as well read an interview with the man behind webassembly. Found it extremely informative and I'm looking forward to a future where all major browsers support first-class alternatives to javascript through webassembly.
But is ES6 polyfillable, or does it require serving transpiled pre-ES6 files to pre-ES6 browsers?
It's time to rework the web presentation and GUI (non) standards. There are too many layers in the current stack, and it relies on fat clients where large GUI libraries and GUI-related code have to be potentially downloaded for every site. It's very poor factoring of tools, libraries, and bandwidth. The bulk of GUI libraries should be part of the browser.
I suggest we start over with 2 new standards: one for a practical work-oriented CRUD & down-to-business browser (or browser mode); and one "eye-candy" browser (or browser mode) for store-fronts, visually gimmicky pages, style fads, and games.
New markup languages with common GUI idioms built in would be designed, reducing the amount of custom client-side code and client-side GUI's libraries needed or downloaded.
The eye-candy standard would be allowed to change faster. If your toys crash, it matters less than if your bank forms crash. Think of it kind of like an open-source Flash competitor.
There would be some overlap between the practical browser standard and the eye-candy standard where appropriate, but we don't want to hold one back to cater to the other.
CRUD-oriented GUI idioms mostly settled by the late 1980's and don't need to be redone every 3 years. By separating eye-candy from practical UI standards, the practical side doesn't have to be bumped around by web/style fads, and the styly side doesn't have to worry about crashing real work.
Call this new standards kit "The Mullet": Business in the front, party in the back. Well, actually it's the reverse for most sites: Party in the front (main page is the attention-getter) and business the back: the details once you subscribed and start doing your stuff. Thus, "Tellum", mullet in reverse.
Forget the job security of the current arcane stack: let's feel the joy of being altruistic, and blow it up and do it right. Let's build Tellum! We'll put half us of out of work, but at least feel the joy of refactoring the web world. (Bots & H1B's will replace us all soon anyhow.)
Table-ized A.I.
How did we get to the point where we so thoroughly depend on a SCRIPTING LANGUAGE that we have to resort to this crap?
If you need this kind of speed, why aren't you writing native code?
Both asm.js and WebAssembly have a fallback mode that uses plain JavaScript, as available in virtually 100% of all browsers.
ASM.js and WebAssembly require the ArrayBuffer and other modern JS features. There's really no reason not to just keep JS and add a secondary more efficient bytecode language (like Java, etc.) and have it be lean, mean, browser-embedded language (unlike Java). I mean, think about that flash plugin crap, and how it got started even though we already had scripting.
Graceful degradation smegradation, the truth is that the browser MFGs should have been pushing forward a standard bytecode whether anyone develops for it or not. The devs have to push out things like native 32 bit Integer array buffer objects or web workers before anyone can make use of them.
ASM.js is crap right now, if you want to instantiate a secondary ASM.js function, you're SOL unless you turn that ASM.js code into a GIANT string and call the Function constructor with the code as an argument (rather than just adding "use asm" to the function). The foolish designers of ASM.js were only interested in features that Emscripten could use and so you can't bind a secondary heap or share a heap amongst multiple ASM.js compiled objects -- That makes using webworkers with ASM.js really shitty, as you have to either rebuild the ASM.js object to pass the array buffer between them, or copy the buffer into the ASM.js object from "external" JS code. As long as advancements are kept backwards compatible with such retarded designs then we'll wind up in the same boat as we have with JS (since that's what the problem is). Rather than just designing a new system from scratch (or dropping in the FLOSS Davlik VM that Android uses and calling it a day) we're going to limp forward towards some broken shit that'll eventually be binary bytecode and even harder to debug. Sure, it'll be more performant than JS, but WHAT ISN'T?!
The whole "you have to have devs before you can push it out" is nonsense because no one was writing JS code before it was bolted onto HTML. The sunk cost fallacy is shite.
Javascript IS the Minimum Viable Product. If you cannot present all of the standard features people expect, you cannot be viable. Use jquery's documentation as a crib sheet. Ask yourself "how will I implement this in my thingamajigger?" If you're feeling frisky look at angularjs too. (protip: when you're done supporting the minimum jquery feature set, please remember that jquery is shit and does jack with text. We're going to expect you to deal with text too.)
If you release a halfassed piece of shit that can't even do javascript navigation like github uses, nobody's going to do anything but point and laugh.
If it's web then it ain't assembly. Shit bust.
Here's a better idea, create a less impacting DOM, and/or rewrite the entire DOM system from scratch since it is a piece of shit that literally nobody in the history of ever likes.
DOM is the absolute worst part of webdev and is also the thing that slows down the evolution of standards because every new feature needs to go through a shitastic amount of testing to be sure it doesn't break every single thing ever.
Also, while you are at it, rewrite CSS too.
You bet your ass you will be adding version control in. Versionless standards are absolute cancer to development.
Lesser and older machines should be capable of being served or represented in a simpler way trivially using a very basic version system and nothing more, none of this JavaScript crap should be needed, no hacky CSS either.
JavaScript is generally heading in the right direction. The next major version will be incompatible as well, bonus points to them for not letting the mistakes of old ruin EVERYTHING.
And finally, someone remake "tables for layout" in CSS already. You had ONE JOB. ONE!
Every "replacement" for it has been obtuse as high hell and back. NO. Go. Just go. Straight F. Don't even see me after class, go home and cry for your complete and utter failure of work.
Minor apologies for being a bit pedantic, but just in case anyone's confused by the possible misuse of the term "closure" in the summary...
From the Wikipedia entry on closures:
Building Better Software
Why? Widgets are the one thing that Javascript does right? And I doubt you will see a difference in performance as its sync access to the framebuffer that usually slows down 2D graphics drawing on modern hardware.
> Image / video editing.
Why would I do this in a web app? And the issue with doing this in a web app has to do with taking better advantage of the UI interaction model (using touch, multi-button mice, etc well) which WebAssembly doesn't nothing for.
> Games:
X3D and WebGL do this just fine but I guess it could help. Probably the strongest use case for this tech.
> Peer-to-peer applications (games, collaborative editing, decentralized and centralized).
No, just no. This is an invitation to a security nightmare.
> Music applications (streaming, caching).
Its not broken now.
> Image recognition.
Sure, why not.
> Live video augmentation (e.g. putting hats on people's heads).
Seriously?
> VR and augmented reality (very low latency).
Will have custom hardware and software to support it and I seriously doubt the VR folks will consider JS for their language. They mostly use C++ for good reasons.
> CAD applications.
Same as Image Editing above.
> Scientific visualization and simulation.
Not broken now although some serious cool stuff with WebGL and X3D is coming.
> Interactive educational software, and news articles.
??? No idea, guess they were running out by this point.
> Platform simulation / emulation (ARC, DOSBox, QEMU, MAME, ).
Just no...
> Language interpreters and virtual machines.
A VM on a VM?
> POSIX user-space environment, allowing porting of existing POSIX applications.
So access to the filesystem. That can't possibly go wrong.
> Developer tooling (editors, compilers, debuggers, ).
WebMonkey is already pretty good and you can have my xemacs when you pry it from my cold dead hands. The idea of a web code editor is almost insulting.
> Remote desktop.
No, HTTP is a terrible protocol for this and a native app works way better.
> VPN.
No, too many serious security issues here
> Encryption.
Built into the browser already.
> Local web server.
Why? And more security issues...
> Common NPAPI users, within the web's security model and APIs.
Ok, finally a good idea. But it causes the browser to be a central point of failure for the security model.
> Fat client for enterprise applications (e.g. databases).
Bad, bad, bad idea. App servers and web servers exist for a reason. That reason is that DBs typically don't handle large numbers of connections well so app server allow users to share connections and thus reducing load on the DB. Not knowing the reasons for something are not the same as something being useless.
Until now I always assumed people would chose to run the installer designed for their operating system.
That's fine if an installer designed for your operating system exists. So let me rephrase: If someone releases a new native app for communication over the Internet, good luck installing a Windows .msi on your Mac because there's no .dmg or a Mac .dmg on your not-Mac because there's no .msi or .deb or .rpm. Or is every developer expected to provide 14 different installers for each application, one for each of 14 operating systems?
No one seems to know what Webassembly should be good for. Let it die, it burns human brain cycles for nothing.
the confusion arises from the fact that languages with real closures generally support anonymous functions
trivially
and languages which only support some sort of restricted function-as-value syntax with limited call semantics
go out of their way to call these things lambdas
Gary Bernhardt was ahead of the curve with his extremely amusing talk The Birth & Death of JavaScript.
https://www.destroyallsoftware...
A look back from the year 2035, he talks about the importance of having a assembly language for the web (asm.js) and tongue and cheek allowed the world to move past JavaScript where it finally becomes both a dead language and also what everything is built on.
Not again some binary mumbo jumbo you cannot look into without specialized tools.
Not again some special apis that are only available in browser xyz.
Not again something that may have the capability to create draconian drm.
The real problem with Javascript is that it is code that gets pushed to your browser from an essentially unknown source. It doesn't matter if it is fast or not, it gets pushed at you in a situation where you are not in a position to make a good decision about what this software is and whether you want it or not. My own, somewhat awkward solution is to use NoScript and not allow any Javascript as a default. Most sites work OK without, and for those that don't, I have the control I need to make a decision about things.
Javascript can be a brilliant tool and if used correctly, can make a web application run like a desktop application; but I have been around far too many obscenely abusive Javascripts to allow it unlimited access to my system. It isn't a lot of fun, when you have to go to a console to kill off your browser because some idiot has served you a looping Javascript.
which was a form of Ruby-like language that would be converted to javascript automatically.
As always, it's the rubbish languages that are well supported so they end up being popular, e.g. JavaScript and PHP
Find a feasible FOSS replacement for Flash that enables fast and easy cross-plattform development for performant non-trivial 'good-looking' client applications - and you have a winner. Offer some tacky half-assed JS cross-compiler nonsense, and your new tech won't get off the ground. The Web and DOM tech is a mess enough as it is, without yet another PL/runtime solution thrown into the mix.
However, I remain slightly optimistic that this may be the long awaited not-fucked-up-by-adobe FOSS Flash successor we've been waiting for. All other non-foss contenders failed throughout the last 15 years, but this might have a chance, also since there is nothing else around and the web has taken over as platform of choice due to 80ies style tech fragmentation via the mobile revolution.
Two cents from a senior webdev.
We suffer more in our imagination than in reality. - Seneca
Why would an anonymous function need to be a function literal? What if it's the result of a compose, or some other higher level function?
To summarize the linked page...
Intended Use Cases:
Really, the only type of programming not listed there is hard real-time. Way to narrow your focus, guys.
Chelloveck
I give up on debugging. From now on, SIGSEGV is a feature.
Technically, the anonymous function is just the literal in code, and it's only "anonymous" because the programmer didn't give it a name—the compiler will sometimes assign it a generated name, but it will sometimes do something else (eg. reuse code from elsewhere in the program, roll the function into the caller, etc.). It becomes a closure when that function is combined with a scope.
So higher level function would return a closure value, which would be the function bound to the values in scope. Those aren't the same thing as anonymous functions. For example, they could all be reusing the same anonymous function—that function might be compiled into one location in the assembly or bytecode (if it's .NET bytecode, for example, it might have a generated name like "b__0"), and then called from within scope.
A composed function would generate another literal function valuelike if you have two functions F and G and compose them into lambda(i) => F(i) + G(i), then that lambda would return an anonymous function. But if you assign it to a variable and call it, then it's bound to a scope and becomes a closure.
Make sense?
Building Better Software
I don't give it much chance unfortunately. Even if I wanted to code in C (which I don't), I wouldn't be able to get it used in our development shop.
However if they had a C# to WebAssembly compiler (that utilized the JS garbage collector), it would be much easier to start using this at work.
Thank you for the explanation, as an FP user I didn't have an issue with the concept of anonymous function vs. closure, so let's forget about closures - e.g. assume that there is no variable capture and all functions are pure - and let's stick to the meaning of anonymous functions as defined by the cited wiki page.
If I have functions f and g, and have a higher order function C, which, for example, composes two functions, then C(f, g) is a definitely a function. Also, it is a function that has no programmer assigned name.
While I don't know if such a function is most properly named 'anonymous function' or just 'function', in my opinion it makes sense to not conflate two different concepts in a way the wikipedia article did.
One of the concepts is how we _denote_ a function (e.g. through a literal directly in the source code, vs. via a series of function calls involving compose, currying etc. sprinkled around in the code base, which is pretty customary in FP).
Another, orthogonal concept is whether capture is involved or not.
There can be named functions which do capture, or which don't capture; and there can be unnamed (anonymous) functions which capture, or don't capture. So I think the cited wiki article poses a false dichotomy, possibly arising from the fact that in certain programming languages, functions have not traditionally been first-class objects, and aspects of FP filtered in gradually.
>Sure, it'll be more performant than JS, but WHAT ISN'T?!
Practically every other scripting language worth using. The following are generally NOT more performant than JS: Python, Ruby, Perl, Lua, etc. At least on Chrome's V8 runtime, I don't know about SpiderMonkey, JSC, or Chakra.
We could compare WASM to compiled languages, but we also have to keep in mind the "W" means "Web" and therefore "sandboxed". So we pay a security penalty.
Why do we need yet another "standard". I know Java gets a (mostly undeserved) bad rap from a lot of people, but plenty of other languages are compiling to the JVM.
You're definitely right about the Wikipedia article glossing over some of the specifics, but I'm not sure I agree that the dichotomy is false. (I'll have to dust off the cobwebs a bit—I first learned this stuff when I was studying CS at Carnegie Mellon way back in the early '90s. :)
My understanding is that one important reason to separate the literal function from the closure (function + scope) has to do with separating syntax from semantics. You the function itself just gives you the symbol manipulation; you can't interpret the meaning of it until you have its context, in the form of a scope (or stack frame, etc.).
Symbolic manipulation versus semantic meaning is really important when you're proving things like computability. I remember back in a graduate mathematical logic course, we used only formal logic to prove some complex fundamental theorem of calculus—but the meaning of that theorem was completely irrelevant, we did the proof entirely through symbol manipulation. So we were able to derive the proof syntactically, without any of the calculus semantics. Not sure if that helps illustrate the difference. Like I said, it's been a while since I studied this stuff. :)
From a more practical perspective, this matters a lot when doing compiler optimization. When you use an anonymous function—where "anonymous" literally just means "doesn't have a name"—a typical compiler will do all sorts of optimizations. I see this a lot when doing .NET programming: if you have an anonymous method that has the same contents as a named method, the C# compiler will just call it, or if the anonymous method is only called once, it may just embed it directly into the calling method, etc. (You can actually see this yourself by writing some code, compiling it, and using ildasm to look at the byte code.) Capture is really important here: this won't work with a closure, because it has the scope. However, a lot of times something that looks like a closure doesn't actually require the scoped variables, or they can be passed in as references, so it can be compiled into an anonymous function.
I've been doing a lot of Scala programming lately, and it's done a lot differently behind the scenes in Scala—and the delineation between anonymous and named is a lot more blurry from a compiler perspective. If you define a Scala function:
object MyScalaObj { runAFunction(f: Int => Int) { println(f(3)) } }
this looks a lot like it takes as its f parameter the kind of method that's compiled into a compiler-named anonymous method. But Scala is bytecode-compatible with Java, so this is actually done on the object level—you can pass it an instance of an object (in this case, an instance of scala.runtime.AbstractFunction1):
static Function1 FunctionObj = new AbstractFunction1() {
@Override
public Object apply(Object i) {
return (Integer)i + 6;
}
};
and call it like this from Java:
MyScalaObj.runAFunction(FunctionObj);
So when the Scala compiler compiles an anonymous method, it generates an object like FunctionObj. The reason this is relevant is because what looks anonymous to Scala is actually not just a function with a stack context, but in fact an actual object on the heap. This is about as far from a literal function as you can get.
And now you know why I thanked Bob Harper in the preface to my most recent book. :)
Building Better Software