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?
With Firefox dropping support for XUL and NPAPI, they will drop WebAssembly for the next programming fad in a few years time. Google had native client and gears, but they dropped them too.
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.
Engineering large software of any type in javascript is a truly horrific experience (or for that matter, anything at all). I think the fact that we have true cross browser support is also excellent indication of the level of confidence that browser vendors place in javascript.
Javascript is plagued by a mixture of poor language design and implementation, incompetent developers, and a chaos of badly engineered components. I can only say that I look forward to the day than I can deploy web applications written in a sane language, using proper toolchains. C++ may be a massive and complicated beast these days, but it's a massively superior, and infinitely more disciplined language for writing real software.
Too much technical overhead for portfolios, sales channel CRUD and click-bait articles. But coding a native compiled game engine and compiling yeah! ... need ... time ...
As an excuse to write C instead of react for web apps it does sound appealing, but I've been abusing a thick client (get your mind out of the gutter) for a while and worst case just rewrite out jquery once the prototyping is done.
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.
On the surface, I agree that WebAssembly is an impressive technology, but I also question how it will affect the web as an open ecosystem. There's been a lot of discussion about the problems of allowing DRM into the standards and similarly, it does not seem like a world where you can't relatively easily look under the hood of a web page would be an entirely positive development for the web. As a developer, I've learned quite a bit by examining the code of sites I liked. Granted, there are obfuscation techniques today, like minification, but Chrome can easily beautify the code. With Web Assembly, it may not even be practical to determine what source language something was written in. The good may outweigh the bad, but it's an interesting direction things are moving...
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.
The next progression from there is to replace bytecode runtimes for scripting languages: 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 (since if syscalls have got to pass through a compiler backend at least once, there is no longer a need for a static numerical list of syscalls, and so processes can optionally be given a custom restricted set of syscalls to use: the so-called principle of least privilege).
So what's the principle difference between this and Java byte code?
People don't just hate flash because it's buggy, and insecure.
They didn't seem to like Java as a web-language either.
When I go to a web page, I usually want to see static text, and maybe some static images.
I don't want animation, blinking, buttons that morph, pop-up windows, pop-under windows, or non-scrolling menu bars.
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
Does it expose low-level synchronization primitives? Seems a pretty crucial question if we're going to start claiming it'll be the equivalent of writing C. (We can ignore little things like the limitations of the functionality exposed through web APIs.)
I am not going to let your shitty code run on my computer. Run it on your own.
as a developer? I guess it might mean my code runs on really low end devices. There's some money to be made there I suppose. But complex JavaScript apps already run fine on my el-cheapo LG phone. Unless I'm targeting the developing world or writing games I'm not sure I see the use case.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
and fuck whoever came up with the name webassembly. invoking the name of assembly language to describe yet more stupid web shit is like awarding the peace prize to obama. don't even waste your time on more pretend schemes to try to salvage your shitty coding. we already know that your apps are garbage, and that is why phones and wristwatches have ghz multicore processors and 5 minutes of battery life. and your apps have only been getting shittier over time, and will continue to get shittier because you are morons. we know it, you know it. give it up.
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.
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) ...
Too bad I use my web browser for - you know - browsing the web, like 99% of the time and I suspect most other people do too. Those other things are better suited for local applications. Ya, I know: but, but, but ... no buts. Firefox; stop trying to good (or mediocre) at everything and concentrate on being great at one thing. Seriously, you're not Emacs.
It must have been something you assimilated. . . .
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.
A browser is not an operating system!
Write and/or read. https://scifurz.wordpress.com/
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.
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.
Only datatypes are integers and floats. No strings. No arrays. No garbage collection.
FORTRAN, a language more than sixty years old, is more powerful that WebAssembly, and it even has a simple source form to boot.
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.
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 jokes, they assemble themselves!!
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...
It will be amazing to finally have enough performance to run a windows95 virtual machine in the browser so that we can correctly render sites written for internet explorer.
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..
Just what I wanted! Yet another way for Web pages to run proprietary unauditable code on my computer!
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.
And then after that,
What - we'll need AV software for WebAssembly?
NO!, in one fucking word: NO!
WTF Mozilla, seriously, are Mozilla SW engineers/developers competent - or are they just fuck stupid?
I downloaded .51 and that's the last fucking version of Firefox that I will run. Stupid fucks..
Dvorak is a better keyboard layout that improves efficiency and speed. I'm typing this on my qwerty keyboard of course.
I actually do own a Dvorak but I never use it. Just because there's a better way doesn't mean people will stop using the way they're used to if it's sufficient for purpose... even if they're used to JavaScript.
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".
http://webassembly.org/demo/
yeah its just a sucky demo but hey...
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.
JavaScript is weak so the solution is to imbue godly powers into the browser ?
Can see a security nightmare forming now that browsers can download remote code, compile and execute based on URLs.
The average user in the dark days ahead are going to face alot of challenges in wielding the mighty browser.
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.
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.
we already have transcompilers for that. The real problem is HTML.