>WASM Your thoughts?

I want this to replace js web applications

>>59379232
A really bad idea brought on by people who cannot handle working with javascript and thought, "fuck it, let's just make it so I can write C for websites", which will of course end poorly.

Even if there aren't a bunch of exploits related to where the assembly is executed, I expect it will result in a bunch of shitty web-devs making hang-prone websites and huge amounts of unblockable tracking and advertising.

>>59379232
On one hand, it lets you write languages that compile down to web assembly. This lets you write larger and more extensive programs on the front end.

On the other hand, you're solving the wrong problem.

>>59379232
Why not compile native applications, implement cross platform gui library and use one of the million os level abstraction libraries.
"""TRULY CROSS PLATFORM"""

>>59379232
Useless without direct DOM access and support for garbage collection.
And even then, it will be impeded by the remaining browser ecosystem, see >>59379280 >>59379832

I'm not worried about security, though.
In the end Silverlight bytecode had all his holes fixed and so can WASM, since it's designed that way from the beginning.
Also, third party served modules can be block, just like scripts from CDNs.

>>59379832
Barrier of exposure. You need far more than a single URL to install a GUI program and navigate it to a page. Not to mention, you will need compiled binaries for all the OS, device and architecture combinations, which lock you into Qt or similar, unless you want to develop each separately.

>>59380220
>DOM access
You can call JS DOM APIs from WASM for now and a separate WASM DOM API is coming later.
>support for garbage collection
So you can write your front end in a retardedly slow language like Python?

>>59380283
>You can call JS DOM APIs from WASM for now and a separate WASM DOM API is coming later.
resulting in slow garbage

>support for garbage collection
>So you can write your front end in a retardedly slow language like Python?
No, but in fast languages like C# and ML style languages

>>59379253
JavaScript is one of the shittiest language designs around. It's only acceptable as a compilation target, and WebAssembly is better for this purpose.

>>59379232
how fucking pathetic. How far do people want to go to make javascript babbys feel important?

>>59379280
>On the other hand, you're solving the wrong problem.
To solve the right problem you'll have to throw the entire modern web away, that's not going to happen.

>>59380307
>fast languages like C# and ML style languages
Those are JS-tier performance-wise at best - pointless for what WASM is intended for.

>>59380316
It actually makes "javascript babbys" less relevant in the long run.

>>59380341
right, I misread that bit actually from one of the blog posts I glossed over. My mistake.

So, if I understand it correctly, what is wrong with webassembly then?

Is the issue basically that it's just a fuckton less readible that current javascript running compressed in the browser? Because looking at it now, I get the feeling you'll only be able to read the assembly in string format?

>>59380336
Hate to tell you, but they are exactly what WASM is intended for - getting rid of JS and >>59380341.
It's not like performance actually matters if you are hampered by the browsers APIs. And for numeric crap and other benchmark stuff that usually is only interesting in ""technical computing"" the language frontend barely matters.

Will this work on my Alienware

>>59380404
only with the alienware theme applied and LED strips

>>59380390
>WASM is intended for - getting rid of JS
Nope. WASM is a lower level your JS can drop down to for better performance. Of course you can write a small JS init script and write your entire application in WASM, but JS will still be there.

>>59380415
pls no

>>59380415
Until DOM access is there.
Then, JS will be dead for anything but simple jQuery based garbage.

File: fig11-4.png (7KB, 438x418px) Image search: [Google]

7KB, 438x418px

How is it different from Java Applets from the 90s?

>>59380457
The bytecode hasn't security tacked on and you are expected to work with the garbage DOM APIs.

>>59380372
You don't actually read/write assembly code, it's all in C/C++

>>59380509
yes, but once it's in your browser and you convert the hex into a string, it'll be in assembly as far as I understand./

>>59380509
>C/C++
stop that nigger.
>You don't actually read/write assembly code
Just try to stop you turbonerd.

>>59380455
So in 10-15 years then.

>>59380518
>http://webassembly.org/docs/high-level-goals/
>define a human-editable text format that is convertible to and from the binary format, supporting View Source functionality.

>>59380581
so then why the fuck are people against this?

>>59380518
WASM comes in different formats. One is a lisp-like AST, one is indeed an assembly-like text format, but those are mostly for debugging and profiling. What most programs will be shipped as is a blob of machine code.

>>59380596
Because it's new.
Now go download the sdk and start working

>>59380596
They're buttmad, that only C/C++/Rust are sane compile sources for WASM.

>>59380632
>only C
fix

>>59379232
Finally I can write a true FORTH for the web!
webForth, I can already imagine the compactness and performance increase!

It's neat. As long as someone can port it to Opera 12.15, I'm okay with it.

>>59380743
>still using opera
topkek

>>59380743
Opera 12.15 not secure.

>>59380764
It's the best browser

>>59380770
No shit