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.
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!
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.
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?
80ies are calling. They want their GOTOs and error handling paradigms back.
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org Errors found while checking this document as HTML5!
That shouldn't be terribly difficult.
Required reading for internet skeptics
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.
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.
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
Instead, I want *all* of my cores to be hung on some advertisements embedded javascript!