Slashdot Mirror
Will WebAssembly Replace JavaScript? (medium.com)
On Tuesday Firefox 52 became the first browser to support WebAssembly, a new standard "to enable near-native performance for web applications" without a plug-in by pre-compiling code into low-level, machine-ready instructions. Mozilla engineer Lin Clark sees this as an inflection point where the speed of browser-based applications increases dramatically. An anonymous reader quotes David Bryant, the head of platform engineering at Mozilla.
This new standard will enable amazing video games and high-performance web apps for things like computer-aided design, video and image editing, and scientific visualization...
Over time, many existing productivity apps (e.g. email, social networks, word processing) and JavaScript frameworks will likely use WebAssembly to significantly reduce load times while simultaneously improving performance while running... developers can integrate WebAssembly libraries for CPU-intensive calculations (e.g. compression, face detection, physics) into existing web apps that use JavaScript for less intensive work... In some ways, WebAssembly changes what it means to be a web developer, as well as the fundamental abilities of the web.
Mozilla celebrated with a demo video of the high-resolution graphics of Zen Garden, and while right now WebAssembly supports compilation from C and C++ (plus some preliminary support for Rust), "We expect that, as WebAssembly continues to evolve, you'll also be able to use it with programming languages often used for mobile apps, like Java, Swift, and C#."
Mozilla celebrated with a demo video of the high-resolution graphics of Zen Garden, and while right now WebAssembly supports compilation from C and C++ (plus some preliminary support for Rust), "We expect that, as WebAssembly continues to evolve, you'll also be able to use it with programming languages often used for mobile apps, like Java, Swift, and C#."
From the web assembly web page:
Is WebAssembly trying to replace JavaScript?
No! WebAssembly is designed to be a complement to, not replacement of, JavaScript. While WebAssembly will, over time, allow many languages to be compiled to the Web, JavaScript has an incredible amount of momentum and will remain the single, privileged (as described above) dynamic language of the Web....
Yeah!
Website Just Down For Me? Find out
This new standard will enable amazing video games and high-performance web apps for things like computer-aided design, video and image editing, and scientific visualization...
But I don't *WANT* to do that shit in a web browser. I want it to live on my local computer where companies can't charge me $5, $10, or $250 per month or I lose access to all my critical data.
I'm still astonished that one of my clients is running a Linux mail server and it works perfectly for them. Their total cost over the ~8 years they've been running it has been about $1,000/year, and most of that is paying for us to add new users, create mailing list/groups, and remove fired employees.
Their first year on the Exchange 358 cloud bullshit would have cost them approximately $15k in licensing.
Well, Google Chrome 57 also incorporates WebAssembly, and soon, so will Safari and Edge. If you're interested in the future of the web, I suggest you read all the articles, they are quite interesting. I think it's the only chance the open web has against walled app gardens.
I take it that you don't know that WebAssembly is made by a joint team of all major browsers?
Open Source Java Web Forum with LDAP authentication
But I don't *WANT* to do that shit in a web browser. I want it to live on my local computer
What's better: using a JavaScript or WebAssembly app in a web browser, or not being able to use an app at all because it's native but doesn't happen to have been ported to your device's operating system?
Meh, not so much - its the *default* language for clientside web interaction right now, and thats the *only* reason it has the establishment that it has.
The only thing that would have to happen for Javascripts domination to be threatened is for multiple browsers supporting something better, and thats happening with WebAssembly. Once developers realise they can stick to their language of choice and cross compile to WebAssembly, thats pretty much game over for JS - think of all the reasons touted for using Node.js, just this time think about them being used against JS...
I wouldnt be at all surprised to see a significant shift start to happen in the next 18 months.
But a longer answer is: 99.999% of the Javascript out there is not slow but waiting on some server to send back content.
Yeah if you're crazy enough create a image editor or a game that runs only in a webbrowser then maybe you would consider this. But no it won't replace Javascript.
Google also officially added support for WebAssembly in Chrome 57, released 3 days ago, btw
WebAssembly will primarily allow real coders to write applications that run in browsers. No JavaScript wannabees need to apply.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Yaaaaayyyyyyyyy!!!!!!
I, for one, cannot wait to load webpages with near-native busy-wait code written by some amateur to do really really useful shit, like check every 7 seconds if there's been an update to their homepage (a la Huffington Post).
This has nothing to do with Active X, and furthermore your implication that if Microsoft tried and failed at something then nobody else need try is absurd.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
No, Native Speed. Not native code. It can't do things javascript doesn't do, it does things javascript can do, but much faster.
So what's the principle difference between this and Java byte code?
So with WebAssembly, they can spend even more CPU power on collecting bids.
Do something similar with generation of LLVM bytecode, and you can remove the need for actual binaries for most purposes
Not really, no. Not with C.
C has platform-specific behaviour of primitive types, and uses macros for platform-specific conditional-compilation. Not something that translates well to bytecode, and certainly not to LLVM bitcode.
and also tweak OS designs so that many security properties can be enforced at the language level more easily
Not really. If you want something like array bounds-checking for C, or runtime checking for signed integer overflow, GCC can take a pretty good stab at that already. Just use the right flags.
I read through the fine articles and even watched a couple of the videos. Overall this looks like a good idea to me.
The basic idea: WebAssembly is an assembly language for a virtual machine, which is very easy to translate into native code. It was designed to be compact so it will download quickly; in particular they chose a stack-based virtual architecture so that an "ADD" instruction implicitly adds the top two numbers on the stack, so "ADD" and similar operations are always single bytecodes. Also, while JavaScript only has a single "number" type which is implicitly float, WebAssembly has multiple built-in native types including 64-bit integer.
It should be no less secure, and no more secure, than JavaScript. However almost all the overhead of an interpreted language is gone: instead of just-in-time compilation, detecting "hot spots" and optimizing, and de-optimizing when assumptions are invalidated, all the browser has to do is translate the virtual machine code into native code and run it.
For the initial release (i.e. right now) WebAssembly does not support garbage collection. This is a sensible decision given what it is and what it does, but they said they will look at giving it some GC abilities in future releases.
I like the original idea that JavaScript would always be human-readable and people could learn by studying the code from the sites they visit. However, this idea is not really active now. It's common practice to run JavaScript code through a "minifier" that packs it to make it as small as possible so it will load quickly, and minified code isn't very friendly to read. There are tools available to somewhat beautify minified JS, but I'm certain that there will be tools to "decompile" WebAssembly and produce something sort-of readable. So while in this one area WebAssembly is not quite as nice as JavaScript, I don't think it's a significant thing, and it's not even remotely enough to make me oppose WebAssembly.
Developers will be able to take existing code in languages like C, C++, etc. and compile them into this portable virtual machine language, and web browsers will be able to load and run them quickly. People will be able to write browser apps that run at near-native-speed and they will run on all the major web browsers and on whatever CPU you have (x86 and ARM for now). I don't really see a downside and I see lots of upside.
lf(1): it's like ls(1) but sorts filenames by extension, tersely
The first difference I see is that wasm is not encumbered by Oracle's licensing restrictions. In addition, wasm is designed such that traditionally unmanaged languages like C++ can compile to it, whereas the JVM and CLR impose type system constraints that make it hard to define how to compile something like standard C++.
I also like to save my work locally. I don't like to do everything via the cloud. Let's be specific about what that means:
The cloud:
The real work of the application is done on some company's servers. Your machine is only the UI.
Web Assembly and asm.js (and C, C#, Swift etc):
The application runs on your local computer. The whole thing is on your computer, not just the UI.
Javascript is rather slow (thousands of times slower than C), so you don't do video editing in Javascript, Javascript sends your data off to some server that does the actual work. C, C#, Swift, and Web Assembly are fast, so they can do video editing locally, without sending anything to any server.
In C, C#, Swift, or Web Assembly you *could* write an application to send the completed output to Dropbox or Google Drive, but there is no need to do that. You can save your work locally if you want to.
The only required difference between the traditional applications you're accustomed to and Web Assembly applications is that Web Assembly applications don't have to be installed. Both do the work locally, and can save the work locally - even on a device with no network connection. Obviously to get the application in the first place, any application, you need either a network correction, a USB stick, or some other way of getting the code to your computer.
Those other things are better suited for local applications. Ya, I know: but, but, but ... no buts.
Good luck rewriting said "local applications" from scratch when the available "local applications" are made for a platform other than the one you use. Even with a cross-platform UI toolkit such as Qt, an application's developer still has to make a conscious business decision to compile, test, and ship for each platform.
That's more because of cargo cult and copy paste programming.
It always amazes me how bad programmers like me can throw shit at a wall without any real in depth understanding and have it stick.
Obviously this will allow much faster "apps" but we all know what that means. Tons of "features" i.e. yet more bloat and "innovation" i.e. new version of shit that looks like it's for cell phones and runs 4x slower.
Javascript engines got a lot faster a few years ago and all we got was a ton of garbage and google making their "Maps" excruciatingly slow unless you run brand new hardware. Also, javascript Doom got taken off the internet for copyright infrigement and all the games are on Android Google Play anyway.
Devs, stop masturbating to your i5/i7 laptop and your Samsung S7 and don't forget to also test on sensible specs like 1GHz and unsupported AMD graphics. People aren't interested into upgrading every other year to a computer that can run Crysis just to do the same things we did back in 2005 or so.
Not quite true.
Amongst other things, Web Assembly can do multi thread support (posix style) and actual sockets.
For anyone wanting to port existing apps/libraries to the web, this is a significant step.
Never happened. True story.
I worked on this development for over two years, since before the WebAssembly CG was created, and have been demonstrating some of the best performance from asm.js and wasm style code, and I believe the process and outcome has been somewhat of a failure. There are some positive outcomes, such a set of operators, but this seems just a small step from asm.js (adding some 64-bit operators etc).
At the end of this process it became clear that seeking a single virtual machine or encoding was not a good outcome, because it means that the web community is stuck with the lowest common supported feature set. It seems that the key enhancement that was required was a translation layer from the deployed binary to a VM that might be somewhat specific to particular web browsers, plus a build process. This would have allowed the major web browsers to offer different competing solutions and web developers could still target code to them by having the translation layer rewrite for each. While this can be done in part with the wasm 1.0 version released, I do not believe this is well supported because it needs to work very well with streaming and caching.
Caching can work well with named sources and their versions and the dataflow that produces the translated output and the compiled output. For these products to be safely shared across origins the web browser needs to control the inputs into this build process - a defined and sandboxed build pipeline was needed. Scheduling of the builds could also be far better managed by the web browser using global knowledge that is not practically available to each context.
Optimizing memory accesses is also critical. The key sandbox requirement is to ensure that accesses to the linear memory are contained so safe. To achieve near native performance requires some design attention to this challenge. My impression is that the design of wasm assumed only that memory protection would be used to efficiently catch accesses that are out of bounds. Early on I had been demonstration very good performance using a pointer masking technique, so to mask off the high bits and have the VM derive that the index is within bounds, and even for translated C code this was giving very good performance. For code that uses tagged points and naturally masks off these tags it could mask off the high bits at the same time almost for free. For this to work well requires that the memory be a power of two plus a spill area, and that the masking be baked into the code, and this could be done in a translation layer if the linear memory size were negotiated and an input into the pipeline. The WebAssembly project just would not accommodate this use case, my patches across JS compilers were stalled and some still sit there today with no progress in the past two years.
With pointer masking it helps to move the masking before small offsets are added to indexes, so that the machine index+offset instruction addressing modes can be used, and this helps hoisting the masking and reduces register pressure etc. One complication is that this only works assuming the index is non-negative so the offset does not wrap the index. Some C code would break without extra care. Emscripten refused to merge patches to improve support for this, claiming that it was not a good approach. Guess what, wasm adopted a similar memory access offset restriction, that indexes must be positive! There is a lot more to optimizing this, and I see little progress in the past two years. I can still demonstrate some of the best performance.
Another memory related optimization is to be able to place the base of the asm.js/wasm linear memory at absolute zero in the address space, so that a register is freed from having to point to this base, and so that the machine instruction addressing modes can be better exploited to help the code. I had demonstrate how much this helped well before the WebAssemembly CG was created. Practically many systems already protect access to the low pages, so for code to use this strategy it would need to avoid using th
Maybe my english isn't good enough, but if "dynamic" means "dynamically typed" here, then the sentence as a whole doesn't mean too much. WebAssembly (wasm) is clearly a target for mostly statically typed, compiled languages. And future plans point to direct access to the page DOM and other Web APIs. If this becomes real, I will happily forget about JavaScript for ever..
I'm just going to leave this here: https://en.wikipedia.org/wiki/...
If you want native speeds, use the OS. This is doing nothing more than complicating development - now rather than just OS differences you have every possible permutation of OS and browser to deal with when bug fixing.
A web app lives and dies on the whim of the developer, which can go bankrupt or be DDoS'd out of existence overnight
So do some kinds of native app if they can no longer connect to the developer's server that provides user license verification, communication with other users, or communication with your other devices running the same app. Examples include applications in Adobe Creative Cloud (once your subscription expires or once Adobe stops offering a particular application), MSN Messenger (which was shut down in favor of Skype), and the "Copy" file sync client (which was discontinued), respectively. Another example is any game for the original Xbox (2001) that uses Xbox Live.
After all, how many people run an web browser offline?
The goal of things like Service Workers is to make this practical. Google has lately been promoting "Progressive Web Apps".
So, in the end, it's another competitor to Java, and the question I have is why is that necessary?
It's necessary because a company with the corporate culture of Oracle Corporation acquired a company with the corporate culture of Sun Microsystems. All four major web browser publishers are expected to contribute independent implementations of the WebAssembly virtual machine to the public. The license for the Java spec, on the other hand, prohibits distribution of incomplete work-in-progress implementations to the public, forcing all reimplementations to be developed in private by a single entity.
In addition, the Java virtual machine has several limits that reportedly keep it from being an efficient target for a C++ compiler.