All Major Browsers Now Support WebAssembly (bleepingcomputer.com) 243
An anonymous reader writes: "It took only two years for all browser vendors to get on the same page regarding the new WebAssembly standard, and as of October 2017, all major browsers support it," reports Bleeping Computer. Project spearheads Firefox and Chrome were the first major browsers to graduate WebAssembly from preview versions to their respective stable branches over the summer. The second wave followed in the following weeks when Chromium-based browsers like Opera and Vivaldi also rolled out the feature as soon as it was added to the Chromium stable version. The last ones to ship WebAssembly in the stable branches were Apple in Safari 11.0 and Microsoft in Microsoft Edge (EdgeHTML 16), which is the version that shipped with the Windows 10 Fall Creators Update. Both were released last month. WebAssembly, or wasm, is a bytecode format for the web, allowing developers to send JavaScript code to browsers in smaller sizes, but also to compile from C/C++/Rust to wasm directly.
Original Article (Score:5, Informative)
Well that's unfortunate. (Score:5, Insightful)
Already about 1/2 of web pages I can only get to work by using "view source" and clipping out links from the source which for some idiotic reason the site wants to demand javascript to do something that pure HTML could do just fine, such as display an image or move to another URL when you click on the link.
Can't wait until that has yet another layer of obscuration due to WebAssem.
The modern web's idiocy only ever grows larger and larger. Can't wait for WebAssem based obscuring images over the text you're trying to read, or more obscured privacy obliterations or the like. At least firefox will have a way to shut that idiocy off.
Re:Well that's unfortunate. (Score:4, Insightful)
Just wait for WebAssembly to be the next Flash/malware ad vector.
Personally I hope it fails. The web browser should never have been an "app" ecosystem, because browsers can't keep their shit together.
Re:Well that's unfortunate. (Score:5, Informative)
Already about 1/2 of web pages I can only get to work by using "view source" and clipping out links from the source
Whatever possible damage you think javascript can cause you is tiny compared to your current nightmarish internet experience. Maybe it's time to move on.
Re: (Score:2, Funny)
Exactly! Stop being different, get baa-aa-aack in line.
Re: (Score:2)
Re: (Score:2)
or you could use Ublock origin and ghostery....
Re:Well that's unfortunate. (Score:5, Informative)
I have a colleague working on formal verification of WebAssembly. Part of this has involved fuzzing various WebAssembly implementations. There are a lot of bugs in all of them, though Edge is by far the worst (reproduceable crashes are hard, because it crashes randomly on most of his test inputs, but at different points).
It's also a pretty horrible design. It's replaced HSAIL as my go-to example for how not to design a good IR.
Re: (Score:2)
InfraRed? Irreproducible Results? Infinite Radix? Inscrutable Raven?
Intermediate representation (Score:3)
In the context of LLVM, JVM, CLR, and WebAssembly, IR means intermediate representation [wikipedia.org]:
Re:Well that's unfortunate. (Score:5, Insightful)
If you send a lot of random shit at something, of course it's going to crash.
If your thread model for something that is expected to accept random crap from the Internet is 'it's fine as long as input is well formed', then you are going to have a lot of fun dealing with security vulnerabilities. Contrary to your assertion, well-written code does not crash when you send it a lot of random shit, it gracefully handles errors.
Re: (Score:2)
Drag in real-time whiteboard requires script (Score:2)
HTML5 and CSS3 will offer everything the web user needs.
With only HTML5 and CSS3, how do you build a collaborative real-time whiteboard application? A server-side image map can capture the coordinates of clicks:
But ismap cannot capture drags. Would you require the user to draw a curve as a polyline by clicking, waiting for a full page reload, clicking, waiting for a full page reload, clicking, waiting for a full page reload, etc.?
Chrome & Safari are only browsers that matter (Score:2, Insightful)
Let's be honest with ourselves here, as of late 2017 the only browsers that matter are Chrome and Safari. Together they have about 85% of the entire market. IE/Edge comes next. Firefox, Opera and Vivaldi barely register.
Chrome, and to a lesser extent Safari, define what the web is. If they don't support a web technology, it effectively does not exist. If they support a technology, it's a standard.
Wasm's success will be fully determined by how well Chrome and Safari support it. It doesn't really matter if Fi
Re: (Score:3)
Firefox, Opera and Vivaldi barely register.
So change that. Apathy is useless. Use Firefox or Opera or Vivaldi.
Re: (Score:2)
I thought it was chrome over 50% then firefox follow by ie and lastly opera, vivaldi, and safari where all lumped into other
Re:Chrome & Safari are only browsers that matt (Score:5, Interesting)
Because Opera is 1) more stable, 2) has more features. Built in ad-block without any add-ons. Built in VPN without any add-ons. Built in communication tools without any add-ons.
Google shoves blind A/B tests to live end-user clients without any notification or sign-ups whatsoever. I've had this break countless times in a corporate environment and spent days debugging this shit. One time they changed the DNS resolver code on a hand full of "test" users to an implementation that took 60+ seconds to resolve DNS addresses. Luckily, I found a buried post on the Google Help forums which described this broken behavior and which setting to disable in the chrome://flags window. But even that window just lists things as "default", not "FORCED ENABLED FOR A/B TESTING". There is literally no way to tell if you're in a test or not. And more recently, they absolutely broke printer support for a month or two, killing all web based invoicing one of my clients was doing.
Opera? They wait for things to stabilize, then port them over to their browser. Its literally just been night and day in terms of stability switching off of Chrome and moving 100% full time over to Opera.
Re: (Score:2)
Chrome is available on a smaller set of platforms. That's my excuse, anyway. But Chromium sucks anyway because it's not 100% compatible.
Re: (Score:2)
Re: (Score:2)
But not changing the rendering engine.
That isn't the case. You should read about the changes in 57 [mozilla.org] and the changes to come [mozilla.org]
Re: (Score:2)
Re: (Score:3, Informative)
Firefox's 2% or 3% of the market doesn't matter at all.
Firefox is currently the 3rd most popular, with 13% market share. source. [netmarketshare.com]
Re: (Score:3)
That's the desktop browser share, but the majority of Internet browsing has been on mobile for several years now, so citing desktop numbers without providing any context is rather disingenuous.
When you look at overall browser usage [wikipedia.org], Firefox falls back to 4th with a 6-7% share (behind either IE or a Chinese mobile browser I had never heard of), depending on whose numbers you use. And regardless of whose numbers you use, Chrome + Safari account for about 2/3 of all browser usage (with Chrome alone accounting
Re: (Score:2)
Re: (Score:3, Interesting)
Which is a shame, because webasm is what it is because of mozillas asm.js
They really had the right approach and it won.
I say this using firefox at work and often wishing it was chrome (default search and printing suck on FF).
Re: (Score:3)
https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2)
They aren't the ones that matter to me. I find the Firefox the best current browser with Konqueror as an abysmal second best.
But I don't follow web standards. "What the hell is \"Web Assembly\"?", "Why should I care?", and "How can I disable it?" are the three major questions that pop into my mind. Presumably there'll be some way to disable it. My feeling is that the web has been going downhill ever since they introduced JavaScript. I already run a script blocker on most sites, and if I can't see the s
This is great but. (Score:4, Interesting)
It's not much use until the vast majority of users have adopted these compatible browser versions.
Not being intentionally negative, but how long will this take in reality?
Re: (Score:2)
At 65% [caniuse.com] at the moment, if you look at usage you'll see it's only iPhone 10.3 and Edge that's likely to switch... Opera Mini, UC Browser, Samsung Internet etc. are old phones that occasionally are used for the web and IE11 is also just for compatibility. I think it's to the point where you could have WebAssembly + fallback the same way you should have JavaScript + fallback for NoScript users today. Or if it's dependent on new functionality, just say you need to upgrade. Not every site needs to support 100% of
Re: (Score:3)
It's not much use until the vast majority of users have adopted these compatible browser versions.
Not being intentionally negative, but how long will this take in reality?
Not long.
caniuse.com says that 67% of browsers currently in use in North America support WebAssembly. The 33% breaks down like this: 10% iOS 9/10, 6% IE, 4% Edge, 3% Samsung browsers, and 10% for every other rickety thing out there.
Give iOS 10 -> 11, Safari 10 -> 11, and Edge 15 -> 16 upgrades another 3 months to roll through (these are all safe and good-quality updates), then WebAssembly availability will be over 80%. That's good enough to take a dependency on. Millions of people keep on using
Worst idea ever. (Score:5, Interesting)
What most people don't realize is webassembly is just a way to obfuscate the web in the same manner people already obfuscate compiler binaries.
Furthermore it will lead to integrated 'all in one' scripts that cannot be easily disentangled, making it harder for end users to filter what scripts on a website they are running.
Additionally it no doubt has engineered defects in it to help national intelligence apparatus' to more easily exploit target browsers, while also providing fingerprint opportunities far more opaque than even current browsers capabilities to deanonymize you.
Think twice before you let webassembly ruin the web for you!
Re: (Score:2)
Re: (Score:2)
What most people don't realize is webassembly is just a way to obfuscate the web in the same manner people already obfuscate compiler binaries.
Furthermore it will lead to integrated 'all in one' scripts that cannot be easily disentangled
webassembly, systemd, this thing has many names.
Tremendous mistake (Score:5, Insightful)
I think Web Assembly is a tremendous mistake.
This will end up being nothing more than an insecure vector for people you don't know to run programs on your computer.
1) It claims to be secure by only executing in a sandbox. Have other attempts at sandboxing had security flaws?
2) Assuming the sandboxing works as advertized, is there a way for the sandboxing to break the sandbox in ways the coders hadn't considered? (Such as periodically using a lot/little CPU time or memory as a way to communicate to a different tab?)
3) Can Web Assembly be used to steal CPU cycles, so your computer can be used for BitCoin mining or anything else while visiting a web page? (And no, that they can do this already doesn't invalidate the argument.)
4) Does Web Assembly add a level of obfuscation to the code, making it harder to see what it's doing?
We once had a period where E-mail attachments were automatically opened and run, where Excel macros activate when a spreadsheet is viewed, and where myriad ActiveX libraries were available for use by anyone.
Anyone remember that era?
We've locked down the ability to install and run programs on our computers, but now we've moved the goalposts. Our browser will now download and run programs for us from any random website, any website that contracts out to an agency to supply advertizing, and and website advertizing contractor who doesn't vet his clients.
"Oh, we're so sorry! That malware delivery got through our vetting process. We've terminated that one client, please feel safe downloading the ads from all of our other clients - they're clean. Pinky swear! :-)"
For the next 10 years expect to see a steady stream of exploits and patches. A mini industry will crop up selling antivirus checkers for web pages, and AdBlock extensions for browsers.
It's deja vu all over again.
Re: (Score:2)
Rowhammer attacks in Javascript were able to cross VMs.
https://media.ccc.de/v/32c3-71... [media.ccc.de]
And obviously if you have byte code the possibilities for obfuscation are really good. E.g. MOVfuscator the 'single instruction compiler'
https://www.youtube.com/watch?... [youtube.com]
Re:Tremendous mistake (Score:5, Interesting)
I think Web Assembly is a tremendous mistake. This will end up being nothing more than an insecure vector for people you don't know to run programs on your computer.
Not to spoil a good rant, but Web Assembly is just a more compact serialization (binary instead of text) of a subset of EcmaScript/JavaScript.
Everything you can do with it, you could already do with normal scripts, and it was already very common to "minify"/obfuscate these scripts into an unreadable mess.
So, if there are security issues with WAsm, they're also present in plain JS, and were already present a couple of years ago.
The only thing that changes is that your browser now doesn't need to download as much data for scripts, since the binary format acts as a compression.
Re:Tremendous mistake (Score:5, Interesting)
... Web Assembly is just a more compact serialization (binary instead of text) of a subset of EcmaScript/JavaScript.....
Much of what you say is morally true. But it's not technically true.
It's true that wasm is a binary serialisation of an abstract syntax tree (AST) but that AST is defined _without reference to JavaScript_, see https://github.com/WebAssembly... [github.com] . In contrast, the asm.js spec is genuinely a subset of JavaScript.
You're right that wasm doesn't introduce new capabilities to the browser as such. In the current 'MVP' version of wasm, the only way to invoke web assembly is via JavaScript, and the only way for wasm code to interact with the browser is via JavaScript.
But it does make certain scenarios, such as running large compiled C programs, much more practical. It is, by design, a far more efficient compilation target than JavaScript or asm.js, see https://github.com/WebAssembly... [github.com] . For example, we can expect Unity running on wasm to become commonplace, see http://webassembly.org/demo/ [webassembly.org] .
...if there are security issues with WAsm, they're also present in plain JS,...
You can't be sure of that. The wasm codepaths will reuse much of the existing JavaScript execution engine but there will be new code and that new code could - and probably will - have security vulnerabilities. But probably no more than any other major browser feature.
Re: (Score:3)
The only thing that changes is that your browser now doesn't need to download as much data for scripts, since the binary format acts as a compression.
It should also execute faster as bytecode is much less processor intensive to interpret than JavaScript and therefore more efficient. So even if someone does use WAsm to mine BitCoin it will still steal less processor cycles per coin of course they will simply generate more coins anyway.
Re: (Score:2)
execute faster as bytecode
But not by much. Most JavaScript engines now are JIT compilers and introduce a delay only at the beginning before running as fast as bytecode.
Re:Tremendous mistake (Score:5, Interesting)
No doubt about it, wasm has all the problems that all other prior attempts at sand-boxing binary blobs of code in the web browser have had. You hit the major ones.
Here's the thing though, the web circa 10 years ago had 3 competing mechanisms to implement sand-boxed binary blobs:
1. Adobe Flash
2. Java
3. Silverlight
Prototypes for Google NaCl were starting to show up around this time too.
All of these had their own sand-box implementation, and they were not sand-boxed themselves, so the surface area for attack was much higher. So HTML 5 tried to do away with that, but then PNaCl and asm.js show us that no matter how hard we try to get rid of binary blobs of code on the web, someone implements it anyway. So, given that there have been persistent attempts by the various large web players for the past 20 years to build binary code blobs in to web pages, and that there is no sign of it slowing down, the most sensible compromise to me is basically what wasm has become... a standardized mechanism for building those binary blobs that can be directly integrated in to the browser.
It does have its problems like you note, but its better that we only have 1 standardized sand-box implementation, and that sand-box implementation is bundled in with a bunch of other high risk code as part of the browser package, which is easy to keep vigilantly updated. Even before wasm, gone were the days of the web browser being a simple document layout renderer. The web browser is basically a visualized operating system... Google has taken this to IHMO a very dangerous extreme, see the Javascript USB API [google.com] for example. The web browser is basically a run time for USB device drivers at this point. To me wasm seems like the inevitable end result of the path that HTML 5 started us down.
Re:Tremendous mistake (Score:4, Interesting)
The Javascript USB API is actually a good idea. It's better than the current situation with binary drivers, especially on Linux where they run in the kernel.
For safe operation of USB you need the low level stack only in the kernel, the part that does the low level I/O and is extremely robust. Then there is a userland USB stack that sits on top of it, handling descriptors and I/O functions for userland drivers/applications.
The Javascript USB API adds some extra protection. Firstly, instead of having a bunch of random drivers with near zero quality control, you have just the browser. A browser that is security hardened and well tested. And all the browser does is provide some simple access mechanisms to various USB features like pipes and descriptors. The code that actually talks to the device, the place where most of the vulnerabilities are, is now sandboxed Javascript.
Even better, the browser prints you for permission to access the device. USB was designed around an insecure plug-and-play model, deliberately not requiring any user interaction for devices to start working. With the Javascript USB API, the user has to give explicit permission.
The main issue I have with the Javascript USB API is the same one as I have with all web applications - loss of freedom. I can't run old versions, I can't do much if they make changes I don't like, I probably can't fork it. But security-wise it's actually a good idea, it adds more layers of security.
Re: (Score:2)
I think Web Assembly is a tremendous mistake.
This will end up being nothing more than an insecure vector for people you don't know to run programs on your computer.
When you find a secure computer, you let us all know okay?
This isn't going to be any more or any less secure than what currently exists. Webassembly seeks to correct the problem of only having one craptastic language for developing on the web by essentially providing a common language runtime/VM that other compilers can translate code to. Will there be bugs? Of course. Is that any different than what we currently have? No.
Re: (Score:2)
What most people don't realize is webassembly is just a way to obfuscate the web in the same manner people already obfuscate compiler binaries.
And further helping protect the intellectual property represented by the source code - which the end user won't be able to access anymore.
Re: (Score:2)
which the end user won't be able to access anymore
No. You can view source on WebAssembly modules [webassembly.org]. Also see the FAQ [webassembly.org].
Re: (Score:2)
MSIE - and yes, there are a LOT of people using it, even on Windows 10.
Re: (Score:2)
MSIE won't have this. Ever.
It's been feature-frozen for years now.
Re: (Score:2)
Exactly my point.
Re: (Score:2)
What browser do you think people are using that doesn't receive regular updates?
Firefox ESR doesn't have WebAssembly.
People continue using Firefox ESR because it still runs XUL extensions. People continue using XUL extensions because the WebExtensions framework lacks counterparts to APIs on which XUL extensions relied. For example, WebExtensions lacks anything like XUL keysets, which makes it impossible to override keyboard shortcuts. This has been reported as bug 1325692, which was marked "wontfix" for Firefox 57 [mozilla.org]. Gregorio "Lord Kamina" Litenstein, developer of the Keybinder extension
Re: (Score:2)
we will no longer be able to monitor and audit the content of web pages and the scripts.
False. Read the FAQ [webassembly.org].
Re: (Score:2)
Have you looked at minified JS lately? It might as well just be bytecode that can be disassembled. It's already no loss in comparison.
Use LibreJS or LibreJS 7.0 alpha (Score:2)
we will no longer be able to monitor and audit the content of web pages and the scripts
Then use one of the following Firefox extensions developed by the GNU project to block running JavaScript that you can't audit.
I imagine that once WebAssembly becomes widespread, LibreJS 7.0 alpha will be updated to cover WebAssembly as well.
Okay, but ... (Score:2)
Is this a good or bad thing for the end-user, meaning *me*, and, if not good, how do I disable it?
Re: (Score:2)
um....good.....smaller package means less data, faster page loads, better feature support.
Re: (Score:2)
If you don't plan to look at WTF it's doing, WebAssembly is great. It's compact, fast and enables developers to use different languages to create client functionality. But like the name implies it's a binary blob not a script and you don't get the source code so it's non-trivial to inspect, edit or copy any functionality to use in any other context.
Re: (Score:2)
What you say is true.
But to be fair to wasm:
* 'View source' will display the text version of wasm.
* JavaScript is often minified or obfuscated too.
* Wasm supports sourcemaps, arguably better than JavaScript does.
* Most people get their sourcecode from github rather than 'view source' these days.
Does WASM support general execution? (Score:2)
Can I write a program in C++ and just compile to WASM like I do to X86 or ARM or do I need to use certain libraries to ensure it will function properly?
Re:Does WASM support general execution? (Score:5, Informative)
In general, yes you can. One important thing to keep in mind is that not all libraries are available in wasm. Obviously win32 won't work, and most C++ GUI toolkits have not been posted to render to a HTML 5 canvas yet.
Another big hole IMHO is there is no native support for garbage collected languages yet. The thing that excites me the most about this is once GC is enabled we could potentially see a Python implementation that runs in the browser (without having to recompile CPython to wasm, which would be huge and slow.) You could also do stuff like compile Java/C#/Adobe Flash directly to wasm and completely eliminate the terrible Flash/Silverlight/Java plugins.
Re: (Score:2)
LMAO! relying on GC is foolishness for sure.
Why? Until wasm showed up, the only language that browsers supported was Javascript, which has a GC. Wasm runs in the same browser sandbox as JavaScript, so there is already a GC present. In the web browser, you are relying on a GC whether you like it or not.
Re: (Score:2)
I bought more memory instead
That's fine if your computer's motherboard is capable of using more memory. A lot of laptops still in use are stuck with 2 GB or 4 GB because they have only one or two slots that take modules no larger than 2 GB. RAM in other laptops, tablet computers, and pocket computers can't be upgraded at all.
So, (Score:3)
You got your C code in my browser! (Score:3)
FTSubmission: WebAssembly, or wasm, is a bytecode format for the web, allowing developers to send JavaScript code to browsers in smaller sizes, but also to compile from C/C++/Rust to wasm directly.
[emphasis mine]
Who wants websites running arbitrary C code on their machines? C is a real programming language. Probably the flagship used for most of the software you buy. It is powerful and widely known. So why let any old website that you visit execute code, probably in the background, on their own machine?
I see lots more 'sploits coming down the pipe as wasm is implemented. With real languages at their fingertips, tons of unaware users who will effectively let anyone have access to their electricity and CPU time without even knowing.
This just swings the door wide-open for a flood of Trojan code, actual code, not JS, all over the web running who-knows-what bit-miner, or distributed child-porn torrent node, or who knows what? It's like a giant, anonymous Beowulf cluster capability (where you lose). . . on top of all of those "Punch the Monkey" Ads suddenly freed to fly around over the text you're trying to read... or constantly right under you pointer, like a big Ad-flag hanging there permanently while on the offending site.
Wait, Tabs aren't sand-boxed similarly to browser windows... Are they? I hope so.
Many people think that the browser IS the internet!
There will be chaos.
Re: (Score:2)
Re: (Score:2)
...and another FAQ left unanswered: How will it be abused?
Re: (Score:2)
WebAssembly will be abused in the same ways that JavaScript has been abused.
Re: (Score:2)
I agree with you that browsers can already run arbitrary code. And that wasm will be built into the browser. And that any bug would be a problem.
But wasm isn't just a standardisation of asm.js. It's more that asm.js is highly influential prior art. In 2015, Brendan Eich did say that wasm would be 'initially co-expressive with asm.js' but that's only approximately true of what actually shipped. See the start of the wasm FAQ: https://github.com/WebAssembly... [github.com]
web assembly (Score:2)
great news for spyware developers, advertisers, and websites who think they have a right to spy on their visitors.
shit news for actual humans.
Too bad IE is default on Win10 Enterprise (Score:2)
It will be many many many years just like with IE 6 before you can use modern standards if IE is still on any corporate desktop.
Re: (Score:2)
Major banks still insist on IE, literally saying they don't support anything else. Not even Firefox ESR etc. (which they did for a while).
Barclays ".NET" functionality... basically all the SME payment functions are IE-only, you can sort-of-coax them into working in old Firefox ESRs.
And even the BACS people, the main way of co-ordinating bank payments in the UK, literally say IE11 only.
They both basically say "You must use our Gemalto smartcard readers, you must use them in IE 11, you must install our Activ
webasm is binary blobs like flash (Score:2)
webasm is great for advertisers, and media companies.
not so much for users...
How to disable it? (Score:2)
I couldn't find any browser plugins that block Web Assembly.
I also couldn't find any way to disable it through settings or about:config in Chrome or Chromium.
Any tips? Is anyone working on this?
Re: (Score:2, Informative)
Firefox about:config, set:
javascript.options.wasm = false
javascript.options.asmjs = false
Great. Another crappy standard... (Score:3)
And they started so well.
Initial idea of their parent project was to replace interpreted stuff with native code where possible and low-level intermediate code where it isn't ( that could be trenslated without much CPU effort).
This means that browser would host basically just a VM machine, where it would run the code, natively in most cases.
What it evolved into was just another mix of java/script...
Who needs that ?
Re: (Score:2)
Zip and WAP (Score:2)
Has anyone tested if there are actually any benefits compared to just zipping up the js file and send that? This kind of wire format has actually been done before in WAP with horibble results. The problem with this approach is that you are hard coding the wire format to the data format, so if you add new data definitions you must also change the transfer format.
But what is actually worse is that this adds little benefit or possibly worse to just using a generic compressor like zip instead. So instead of get
Re: (Score:2)
Yes, people have tested it, hence web assembly being made.
What security issues are introduced with this? (Score:2)
Cool! It's so efficient! (Score:2)
I only get around 600% CPU issue (3 HT cores fully busy) for the framerate of around 20 fps in that tanks demo. WAY TO GO!
Re: (Score:2)
s/issue/usage/ too
And this is why Apple is losing Safari users (Score:2)
Safari 11 which requires the latest version of macOS, unlike Chrome which happily runs on OS X 10.9.5, the last true version of OS X before it all turned into iOS-like crap with a dead-flat user interface, nearly-identical pastel colours everywhere and unreadable fonts unless if you're over 20.
Re: (Score:3)
Re: (Score:2)
Your competitors' products can ban your spammy posts, and hosts files can't. You're advertising for your competitors with every single post you make here.
Re: (Score:2)
Yes. This sounds an awful lot like browser-based java virtual machine circa 1995. Good to see its time has finally come, in that people are now actually ready for the concept.
Back then, arguably, it was mainly Microsoft that killed it by not allowing Sun's technology into Internet Explorer without insisting on mangling it to a non-interoperable version.
Good that there are some saner heads prevailing for try number two.
Re: (Score:2)
Wasn't it Oracle that finally killed the Java applet? At least, my web browsers happily ran Java applets for a number of years, until Oracle took over Java and suddenly every web browser started refusing to run applets, even when you begged it to.
Re: (Score:2)
It only appears so at first glance. WebAssembly is a logical continuation of asm.js, which based on experience of developing of high-performance JavaScript engines. The goal of WebAssembly is to use existing Javascript engines to archive close to C performance within browsers, i.e. something that asm.js already does to lesser degree. In contrast, Java VM was developed to run independently from web browsers, and though you can run it
Re: (Score:3)
Re: (Score:2)
Interesting... I have to say I wasn't overly impressed by the bits of wasm implementation I saw when it was first announced. Sounds like they have gotten further along but also made a few mistakes along the way. Like the JVM not having unsigned ints, little things like that can have really icky consequences when the rubber hits the road.
I wonder if the control flow prohibition is cultural or technical baggage from the "I have an axe so every problem fits in a tree structure" DOM shortcomings.
Re: (Score:2)
jslinux?
The idea is much older. What about native java bytecode CPUs [wikipedia.org]?
Re: (Score:2)
The idea is much older. What about the the Pascal MicroEngine [wikipedia.org], which executed p-code [wikipedia.org]?
Re: They've gone full inner-platform. (Score:2)
Running on a few ing on your finger, no less
Re: They've gone full inner-platform. (Score:2)
A ring i meant. Thank you spell checker:(
Re: (Score:2)
I was "into" Java, back then. I just didn't think anybody here would remember.
Jazelle was quite popular on mobile platforms (under 2MB of RAM). It ran the common Java bytecodes natively (arithmetic, local flow control), but called out to the VM for things like virtual dispatch. It provided a pretty good intermediate, but was largely overshadowed by JITs (if you're doing any optimisation, you're translating from Java bytecode into something else and generating native ARM code from that was usually easier than translating it back into Java bytecode).
. I would have no problem with WebAssembly, if it was independent of the browser/web world. Which I'm predicting it will move to.
It is an explicit goal of the wasm
Re: Rust is becoming the language of choice (Score:2)
No it is not
Re: (Score:2)
Nobody seriously praises Rust.
Linus Torvalds would turn over in his grave, if he was dead.
Re: (Score:2)
Praise be to Rust, for if it were not then those users might make a better choice, and be underfoot.
Re: (Score:2)
Stable and universal webassembly would be already enough to do it. You can just write app in whatever language you want and cross compile it. There are already quite big apps on the web that are created this way (ported to js from mobile by cross compiling).
Re: (Score:2)
And Chrome is just Chromium. And Chromium is just Blink. And Blink is just Webkit. And Safari is just Webkit. And Webkit is just KHTML. And Konqueror is just KHTML. And KHTML is just KParts... PATHETIC!
Re: (Score:2)
How to disable it?
Use your browser's available settings (and/or argue with your browser vendor to put them in).
How to develop for it?
Run emscripten on your existing C codebase.
Or any of a thousand compilers that compile to WebAssembly just the same.
Pretty much it's the "JVM" of today, that can be targeted by almost anything.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
console.log("Hello world");
once obfuscated
var _0xa9ff=['log','Hello\x20world'];(function(_0x50318f,_0x347f74){var _0x4aa6cf=function(_0x1a665d){while(--_0x1a665d){_0x50318f['push'](_0x50318f['shift']());}};_0x4aa6cf(++_0x347f74);}(_0xa9ff,0xaa));var _0xfa9f=function(_0x276a74,_0x406450){_0x276a74=_0x276a74-0x0;var _0x534cc5=_0xa9ff[_0x276a74];return _0x534cc5;};console[_0xfa9f('0x0')](_0xfa9f('0x1'));
is much more readable.