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.
But not in the near future: JavaScript is a very well established technology for web UIs!
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
Hello ActiveX, its been a while! And you never had any security issues did you, noooo, perfectly safe. Thats why its still around today... err, oh, wait...
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?
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
Javascript is utter trash that should be cleansed from this world
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.
I will go against the majority opinion here and assert that, at least in my use case, it will precisely replace javascript as a language to allow remote control over my local computer. I currently block javascript, and will also block WebAssembly by equal measure, so this makes them functionally equivalent. Hence WebAssembly will be a fine replacement for javascript.
Captcha: Turtles!
But a longer answer is: 99.999% of the Javascript out there is not slow but waiting on some server to send back content.
You'd be surprised at how much time the browser spends running ad exchanges' "real-time bidding" processes, collecting bids from a dozen different ad networks for each ad unit on a page just to eke out a larger fraction of a cent. On the weaker ARM or Atom CPUs of compact laptops, tablets, and smartphones, adtech scripts often cause the web content process to take a whole core for several seconds.
If we can get rid of the current source code soup in web apps, that would be a good thing.
http://michaelsmith.id.au
If it finally kills that damn Flash dead, I'm all for it.
So what's the principle difference between this and Java byte code?
The old "web browsers don't support standards the same way" problem strikes again.
But it's still probably a lot less effort to port a web app from Chrome to Firefox or vice versa than to port, say, a macOS app using Cocoa to Windows.
I agree about removing Flash Player from the mainstream web. Almost everything modern has moved to HTML5 technologies. Classic animations and games, such as those found on Newgrounds, Dagobah, Albino Blacksheep, Homestar Runner, or Weebl's Stuff, can be run in a specialized browser in a virtual machine.
But Flash is more than Flash Player. Without Flash, what timeline-based graphical tool do you use to author an SVG or Canvas animation? Typing the coordinates of each vertex of each keyframe into a text editor is unlikely to cut it for animations of more than trivial complexity. Is Synfig any good yet?
Web Assembly is like the bytecode of Java. In the future, JavaScript will compile to it. As will other languages. The only question is whether languages other than JS can be distributed as source code and compiled to WebAssembly inside the browser.
I suggest you read all the articles
I'm going to pretend you didn't say that.
#DeleteChrome
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.
a WebAssembly VM will be a common feature on all OSs, and most scripting languages can then simply transpile down to this. Do something similar with generation of LLVM bytecode, and you can remove the need for actual binaries for most purposes, and also tweak OS designs so that many security properties can be enforced at the language level more easily
That's what the experimental Singularity operating system tried to do, except with .NET IL instead of WebAssembly.
But at least WebAssembly will allow use of languages that currently compile to native code, unlike .NET that required changes to popular languages to get them to work. For example, Microsoft's C++/CLI is set of extensions to the C++ programming language to allow creating managed code. But the syntax for arrays, pointers, and references differs between the unmanaged and managed "worlds". This means a program intended to compile in both a standard C++ compiler and the verifiably type-safe subset of C++/CLI ( /clr:safe ) can't use arrays, pointers, or references, which more or less restricts the common subset to programs not much more complex than Hello World. In fact, not even that works as advertised because most of the C++ standard library is missing in the verifiably type-safe subset.
I don't want animation, blinking, buttons that morph, pop-up windows, pop-under windows, or non-scrolling menu bars.
So much so that you apparently stopped using the web altogether around 2001 since you think these are the reasons people use JS. XHR is the backbone of the modern web. Web pages are not static any more.
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.
In theory, one could extend LibreJS to support WebAssembly. In practice, I imagine few major for-profit web sites would bother to support LibreJS, particularly because all major web ad networks track users from one site to another using proprietary JavaScript.
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.
I have gathered that many users of Slashdot actually want the barrier of installation because it protects a user from code that he hasn't explicitly chosen to run. Some even want the barrier of compilation because distributing source code to the public discourages underhanded behavior by putting a program's developer on notice that any third party could audit the code.
Both do the work locally, and can save the work locally - even on a device with no network connection.
I thought web applications were subject of a quota of 5 MB of local storage per origin. You aren't going to be able to fit a lot of video into that, unless by "video" you mean a vector or sprite animation analogous to what people used to use Macromedia Flash to build. When was this increased?
Nothing is stopping you from installing your own web server and use these apps on your intranet. But most people don't like paying thousands of dollars for software anymore.
Nor do they like paying thousands of dollars over the course of several years for a subscription that allows access to what FSF calls "service as a software substitute". Just because it's on the web doesn't mean it's available without charge.
Unless I'm targeting the developing world or writing games I'm not sure I see the use case.
If you follow @Mozilla on Twitter, you'll get an idea of how Mozilla is "targeting the developing world". See, for example, the Digital Inclusion section of its Internet Health Report.
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.
Then for which operating system should a developer make applications, if not the browser?
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.
"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 the best defense against advertisement blocking today."
FTFY.
Like Posix threads?
Yep.
Never happened. True story.
It's beyond me why people confuse operating systems with web-browsers. Being able to run code from somewhere on the net and executing it locally (either sandboxed in a virtual machine or directly on the hardware) is something every major operating system has been able to do for many years.
And there have been good reasons why operating systems got safety mechanisms to not overly trust code from somewhere on the net.
Having a browser instead of an operating system do that just means to exchange the expertise and security awareness of operating system programmers with the utter lack of skill and security awareness of pixel-pushing GUI application programmers.
This will be the worst thing to happen to the internet since Internet Explorer.
The ability to implement a web browser within WebAssembly is going to change the Internet forever. No more downloading and installing browsers. This is so exciting.
No. They're constantly changing, spying, cpu hogging, oversized, clunky, bloated, unnavigable abominations meant for fisherpriced mobile junk.
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
The module definition http://webassembly.org/docs/mo... omits basic metadata such as author and version information and there is no defined place to sign the binary. I know they want small but I am sick and tired of browsers having to run unattributable code. Their security model looks like it ignores attacks such as an "enhanced" advertisement filtering all browser key strokes from a background thread and sending them home.
It's hard to know for sure because the account that posted the parent comment seems to be new and it's unclear who the commenter is in real life but this seems to be a well written complaint about the outcome of WebAssembly. I did a quick search and it doesn't immediately look like a copy/paste of critique from elsewhere so it seems a shame to see this slip below the waves. Sadly, I suspect few will see it because this story has passed the "breaking news" point...
Nim compiles to C and then to wasm via emscripten. My favorite among the newcomers with automatic memory management, mainly because it's simple and offers pretty powerful metaprogramming and can do functional when necessary.
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 agree. Unless/Until we build a parallel internet for banking and serious infrastructure stuff, the proper replacement for Javascript is no scripting at all. The notion that anonymous folks somewhere in the world can ship us arbitrary computer programs to run on our machines without creating a massive security issue is really quite bizarre. But scripting is sandboxed and therefore perfectly safe? Right. And free markets with no regulation will make us all wealthy beyond belief.
There are a handful of sites -- e.g. Google Maps -- where the benefits of scripting clearly outweigh the risks. And I don't have any problem with turning on scripting for those sites. But mostly, script seems to be used by lazy/incompetent/demented web designers (is there a difference?) to implement annoying "features" or even to do stuff that could equally well be done (probably better) with html/css.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
"Seriously, you're not Emacs."
Emacs is a remarkable accomplishment. And it's easy to see how the handful of folks who can memorize the bizarre key bindings and innumerable conventions and navigate the buffers efficiently could love it and find it to be enormously satisfying and productive environment. But it's not something most of us can use, much less use effectively. A road better not taken I think.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
Honest question: How is this different from the much maligned Java Applet concept?
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.
"Looks like someone doesn't understand how computers work."
True, but maybe you can cure your ignorance by taking a class or something.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
"Seriously, you're not Emacs."
Emacs is a remarkable accomplishment. And it's easy to see how the handful of folks who can memorize the bizarre key bindings and innumerable conventions and navigate the buffers efficiently could love it and find it to be enormously satisfying and productive environment. But it's not something most of us can use, much less use effectively. A road better not taken I think.
Agreed and, just noting that, I've used Emacs since the mid 1980s and am a big fan. To be fair, the key bindings aren't really that bizarre and most are pretty logical (and you can re-bind them as you like, but I recommend against it and, for commonality, I only add using unbound sequences), but the learning curve is a bit high.
It must have been something you assimilated. . . .
Should anyone be crazy enough to want to disable WebAssembly support in FF,[1] use about:config to set javascript.options.wasm to false.
[1] I am, and did. There are so many config options that I can't bear to read through them all, but when my attention is drawn to a new feature like this, typically the first thing I do is find the option to disable it. If it's new, chances are I don't want it.
I'm fed up of having to use JQuery and Bootstrap for the most basic of layouts, and spending 10 minutes moving a text 3 pixels to the left. When you have a programming background it's painful to have to use SQL/php/CSS/HTML AND Javascript for what would take 5 minutes native. I predict WebAssembly will be used for EVERYTHING.
So convince people to use Java. Javascript is just even worse trhan that. Or use open source and recompile. There are like 1000 other solutions that don't confuse "software is crossplatform" and "software should auto-run in a browser when you visit a webpage".
Your ad here. Ask me how!
15k gets you several nice machines to run in HA/Failover for a roll-your-own linux groupware system with enough left over to pay for a small AWS instance to run a backup VM on in the event of a catastrophic disaster that burns your entire office to the ground.
I'm not seeing the point you were trying to make.
Ok, since you don't get it, please think about these:
- who maintains those servers
- who does the backup and where do you store it
- who monitors those servers
- who maintains the blacklists, spam rules, etc.
- who creates mailboxes and how
- how fast can support react to support tickets, such as password resets or lost emails recovery
- who pays for the power and cooling of those several nice machines, and how much is it
- what about physical security for those machines
- where is the DNS that allows a smooth failover and how do you address webmail failover
- what kind of link do you maintain between your on-site servers and your cloud server, and how much does it cost (I'm assuming vpn)
- what is your DR strategy if you lose your nice servers? because then you've got a spof
- from which budget are you going to take $15k upfront since you'll also have monthly fees for the same service
Besides the fact that the building burning down is an extreme scenario (as opposed to common ones like power failure, hardware failure, theft, internet connection issues, blacklisting of the outbound IP following a malware incident, etc). your approach also only works if the company has:
- someone on-site 24x7 and costs nothing
or
- someone who is available within minutes 24x7 for a ridiculously low fee
See, that's the point with using cloud providers for commodity computing (such as email). Google or Microsoft (and now Amazon) are the ones dealing with all those issues and they're better equipped than some local guy and his 2 servers running in a closet. You can't compete with them, not at this price. Otherwise that's like thinking that running your own power plant is more cost-effective than being connected to the grid.
Move on. There's plenty of areas even in IT infrastructure where the cloud providers can't compete at an acceptable price (ex: anything that requires a lot of memory or cpu), but email is not one of them.
lucm, indeed.