WebAssembly is coming soon will it change the internet?

WebAssembly (WASM) is bytecode for the internet browser, so instead of parsing the javascript strings for a webapp a browser can just download the bytecode which is smaller (to download) and faster to parse.

Also WASM can be used as a compile target for a range of languages, so any programmer can probably use their favourite language to write web apps.

And the best bit WebGL games should be smaller to download and faster to play than previous ASM.js versions.

WASM is expected to arrive in a browser near you around Q1 2017, and already in a lot of the current browsers/development builds with with an optional flag to enable it.

So this is cool for WebGL games, along with the new WebGL 2.0 we should see some amazing games.

But think of what it will do to websites, in effect it's bringing apps back to the web, we can have way more powerful web apps than before.

And Unity developers can be web app developers as well!

It's still early days for WASM, as this version 1.0, is a minimal viable product so won't have threading, SIMD, 64bit memory space, fine grained memory management e.g. map_file, co-routines. (roadmap)

So do you think WebAssembly could change the internet as we know it, or just make it run a bit faster?

 

<insert another politifact joke here>

Technology change doesn't happen overnight. Give it a couple of years. Like 3 or 5 years. Then you'll see a change. As for "run a bit faster", this is not gonna happen. People will clog bandwidth with content, as they did many times before.

 

Great. Now there is another technology to support. The internet is already a Wild West with different techs and standards.

 

What would actually be amazing and actually useful is if people would quit creating new things for the Internet thus makin gmore things for us to support, and should instead be learning compression. Like heck, I've compressed a 64 meg bitmap down to 20 kilobytes and then reconstructed it... But it was only useful for photo compression, it was also lossless, so it didn't loose any quality. Which in theory, would be good for the Web and useful - if browsers supported the file type it was.

I even tried compressing a 1 gig rar file and made it down to roughly 80 megs. But it as before, was only useful for singular files. So it didn't help much unless it was for Photos.

EDIT: Oh and the compression was near instantaneous.. Well for Photos at least. the 1 gig file took roughly 30 seconds to 2 minutes roughly.. (Don't remember - been awhile sense I messed with it).

 

LOL you could convert your decompressor to WASM and have it run in browser!

 

Well I wasn't really trying to do anything with it, only trying to do something new.
Haven't messed with Assembly much to convert it lol. Plus I didn't realize Browsers
were that much of Open Source now days.

Would converting it with WASM make (all) browsers support it? E.G. (I.E. Edge, Chrome, FireFox, Safari, Netscape, etc).

 

All browsers that support WebAssembly would run your decompression app, so Edge, Chrome, Firefox should work once they release WASM support in browser.

 

How's that different to writing something in JavaScript and having all browsers that support JavaScript able to run it? Keep in mind that JavaScript doesn't have to be interpreted. It can also be JIT compiled or whatever you'd like.

To me the question is whether or not WASM supports things that JavaScript does not.

Not necessarily. The language and compilation targets are only a part of a bigger picture. What libraries are available? What rules apply to this new platform?

Even in Unity, which does a lot of the work for us, I can't write something in C# and assume it will run on all supported platforms just because the compiler is compatible. There's far more to it than that.

 

Probably not. Ultimately we are still dealing with a web browser. The fundamental issues around security and sandboxing won't go away.

This might speed things up a little behind the scenes. But it's not going to change much on average.

 

I was thinking about things like threading support. Changing languages doesn't inherently provide a speed boost. Providing better ways to use hardware, on the other hand...

 

I can't wait for the security vulnerabilities this is going to open up. In the mean time I'll be logging in as root with the default password being password.

 

The FAQ on the official website mentions that the binary code format that WebAssembly uses is considerably faster to parse than JavaScript which results in significantly less wasted time for large code segments on mobile devices. WebGL games made with Unity are not exactly lightweight.

http://webassembly.org/docs/faq/

 

So it'll work slower than native code and with more hassle. Amazing idea.

 

Isn't that practically the motto for anything related to web technology?

 

ArrowX threads the tabloids of the unity forums.

 

Thought I was starting to become the only one to notice that lol.
I mean nothing wrong with creating threads, but generally all ArrowX posts are about some future technology lol.

 

This presents some good arguments: https://github.com/WebAssembly/design/blob/master/FAQ.md

For myself I'm looking forward to posix threads (and hopefully sockets) as I have a lot of native c/c++ code I'd like to reuse... The lack of posix threads is the bane of Web apps.

 

Some benchmarks asm.j vs WebAssembly scaled against native C.

Measured on 64-bit Firefox 52 (Nightly), Intel Core i7-2600 @ 3.40GHz, Linux (source)

So it is slower than native C code on most tasks taking about 1.5 times as long but this is the pre-release version so there is room for improvement.

 

Hey, that's not "against native". That's against "asm.js".
Which is not a native code, but something cross-compiled into javascript.
Do your research, alright?

 

Yes, it's clearly "normalized to native" as mentioned in the very image he linked to.

Am I the only one feeling underwhelmed by this image? We're not provided any real information. While I could run the scripts myself to see the performance I feel like it would be nice to at least see the time each task took to complete to know if there is any reason to feel impressed by WebAssembly.

 

Hopefully Unity will Run their WebGL benchmark so we can compare asm.js and wasm.

 

Alright, I missed that.

Yes, it is missing couple of pages of data. Algorithm, platform, compielr, etc. Basically, no reason to think that "native code" (which langauge? C? C++?) was written by anyone competent.

 

Yeah...I've got an article for that.

How it feels to learn JavaScript.

Full disclosure - my day job is as a full-stack developer. There's days when this is not an exaggeration at all.

 

If it wasn't for the gun in my mouth, I would have laughed at the python 3 joke.

 

So, I've never dealt with Python yet in my career. What's with that joke?

 

From what I understand, it's basically that they changed things that make it a nightmare to upgrade old code. It's still pretty common to need old python versions in dependencies, even for the same program. Spend any time with linux and you'll start to realize how dependencies are a F***ing mess just in general.

 

There are two different pythons. 2.7 and 3.0. Python 2 and Python 3 code is not fully compatible.

https://wiki.python.org/moin/Python2orPython3#What_are_the_differences.3F

Both python 2 and python 3 are being used today and they exist in parallel.

 

Check the source -> https://hacks.mozilla.org/2016/10/webassembly-browser-preview/

Mozilla what would they know about writing code, their a web company!

 

It doesn't provide any meaningful information on the chart. I don't care how good Mozilla may think they are, if they're not willing to provide any real statistics then it makes their benchmarks seem questionable.

 

So you weren't impressed with Unity's WebGL benchmark data then?


(The scores have been scaled so that Firefox = 1.0, to fit onto a single chart. Higher is better)

Unity's WebGL Benchmark Post

You do grasp that a lot of benchmarks are just ways to test and show the performance differences between competing systems on fixed hardware.

As no benchmark can show you how well your unique Unity game will run on everyone's hardware.

Personally I can't wait to see how the above benchmark runs with both asm.js as well as wasm on all compatible browsers, as the browser developers have had time to tweak and improve things.

Also there is WebGL 2.0 will that run faster than WebGL 1.0 or slower?

 

Don't wanna. You're promoting(?) it, so it is your job to pull all the data from the source and put it here.

Either way, this is not a kind of tech that's worth getting excited about.

 

That's not what's being said.

The chart doesn't tell us what was tested or what the test results were. It's just some vague normalised values that expect us to know what's being tested based on the name of a test alone. To be fair, if I were an enthusiast in this area I quite possibly would know about the named tests, or be happy to look them up (I get the impression they're pretty standard), so in the context of the post it was copied from it's probably ok. As @neginfinity points out, though, if you want to convince us of something then it's up to you to do the convincing.

That second graph is even less useful, by the way. Out of context of wherever you took it from we don't even know what's on the horizontal axis - are long bars or short bars better? (Edit 2: *facepalm* Hah, I missed that written right under the graph. My bad!)

- - -

Edit: To put my comments in perspective here, I'm fully aware of how easy it is to make data look like it proves any point by putting it on a dodgy graph. And that's putting aside the fact that you can perform dodgy tests to get get data that supports almost any claim. I'm not saying that either of those things are happening here - both graphs are probably fine for their originally intended purposes and audiences - but it does mean that a graph presented out of context or with missing data is useless.

In short: data isn't useful just because it's in a graph.

 

Speak for yourself... webasm has better support from all the major browser players than probably anything in the history of the Internet (no hyperbole, everybody seems to be on the same page and adoption is moving faster than anything I've ever seen), and the performance improvements should be huge. Some of us live and die by such things -- and by all accounts (e.g. those players I just mentioned) support should be fast and widespread.

It's a Big Deal.

 

I always speak for myself, just don't see a point in adding three paragraphs of disclaimer in front of ever ypost.

It is one more framework to learn when you need to use it. And that's about it.

 

It's not really a framework in the sense that you appear to suggest (e.g. you'll rarely use it directly), and "speak for yourself" isn't meant literally, it's an indication that you're making inappropriately sweeping generalizations. Just in case that's news to you (I keep forgetting who's a native English speaker and who is not, but this sounds like missing the point of an idiom).

Point is, webasm probably won't have Arowx-style "change the internet" effects but it really is a Big Deal. Blowing it off as "not worth getting excited about" might be true if you're Random Facebook User 472,975,201 who only knows the web is that thing that brings you cat pictures and email, but if you're a developer who ever deals with browser-based junk (and probably extending a bit beyond that), then yeah, it's worth getting excited about.

 

"big deal" != "things worth getting excited about", because "things worth getting excited about" is subjective classification. Do you want to waste time on semantic argument?

It is just another technology that changed with time. Alright, you may get faster performance, there are few nicer things, someone will probably rewrite snowman to support that, so what? It may have impact, it might make someone's life easier/harder, but it is just another piece of tech that you may end up using on relying onto, if you have to. So, I'm not getting excited about any of it.

 

Which is speaking for yourself... semantics sure, but you're the one declaring the whole thing unworthy of discussion. The bottom line is yes, it's a big deal in a lot of circles. Circles with budgets that have a whole bunch of zeros behind the sig-figs.

Name one instance where all the major browser companies got behind something major like this in much less than one year.

 

And?

That's why I said that I'm always speaking for myself and don't feel like writing three paragraphs of legal disclaimer in front of every thing I post.

----

Almost every single thing people write on the internet is their opinion. You'll make your life a lot easier if when reading something you imagine that author started the post with "I think that...". That'll greatly reduce number of semantic arguments. Your position amounts to pretty much claiming that your local definition of "exciting things" is more correct than mine. I suspect that both you and me have more interesting to do than arguing about something like that.

So... are we done yet?

 

Yes, all two of them. With one being funded by the other at that.