Web Assembly Working Group Charter Approved | Hacker News Reader

Web Assembly Working Group Charter Approved

lists.w3.org

101 pointsgfredtech64 comments

How is it different from “Web Assembly” (aka “wasm”) that has already started to gain support in major browsers[1]?

Edit: Found the answer myself. This is part of the same effort, as mentioned in the official website of Web Assembly[2].

[1] http://caniuse.com/#feat=wasm

[2] http://webassembly.org/roadmap/

What are the changes compared to current Implmentation. Is DOM access on radar?

I haven’t found anything specific about future changes. I just found out that this is part of the same effort.

Here's a recent meeting about future changes: https://news.ycombinator.com/item?id=14873594

I'm slightly disappointed by the target end date : 31 July 2019. WebAssembly seems like a huge deal to me and I was hoping things would progress quicker than that :(

Let's not mess it up just because we want it quickly, if we (they) do this correctly, it might be the final big progression, but if we do it too quickly, it might turn into the next JavaScript (problem-wise).

This. They want to get it right, and iron out any kinks NOW so we aren't worried about "breaking compatibility" 20 years down the road.

Why can't we have versions that can be turned on and off? It seems like a no brainer to avoid javascript nightmare. Thinks will still need to be updated.

Two points:

- Presumably there's a preference to be pessimistic on schedules so they don't have to go through the process of being re-chartered if things drag on unexpectedly.

- By the time the standard is wrapped up, you'd expect the major browser vendors to have had fully production-ready implementations for a while, just waiting on any final tweaks.

(Also, v1 is supposed to have achieved recommendation status by Q2 2018.)

That's the expiration date for the charter. The charter is now approved and can be renewed.

It's already enabled by default FF and Chrome (since March 2017), and both pass the huge battery of standardized tests.

A charter end date is not the date when their work is published. It's the date the working group ends and can not publish/proceed with additional standards.

I hope they at least have unaligned atomics in this version. I feel that is a major omission from the current plans, since it makes algorithms difficult/impossible that use 64 bit atomics to change two 32 bit atomic numbers next to each other in an interlocked fashion.

Other than x86, do many processors permit either of those things--1) unaligned atomic operations, or 2) type-punning where memory ordering is guaranteed for a 32-bit read of a 64-bit atomic write.

64 bit ARM and POWER both do as far as I know. They definitely all support aligned 128 bit atomics.

An aligned word won't span a cache line. So any aligned 64-bit or 128-bit word is always wholly within a single cache line.

But two 32-bit words can span a cache line if the first isn't 64-bit aligned. So what you're doing relies on hardware supporting atomic operations not only on unaligned words, but on words spanning cache lines. Are you really sure ARM and POWER support that?

> An aligned word won't span a cache line. So any aligned 64-bit or 128-bit word is always wholly within a single cache line.

On x86 a 64 bit atomic can span cache lines.

> Are you really sure ARM and POWER support that?

Do they not?

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc....

On older processors, such as ARM9 family based processors, an unaligned load had to be synthesised in software. Typically by doing a series of small accesses, and combining the results.

"The ARMv6 architecture introduced the first hardware support for unaligned accesses. ARM11 and Cortex-A/R processors can deal with unaligned accesses in hardware, removing the need for software routines."

Ok so they have hardware support for unaligned accesses, but is it atomic?

Apparently not. From "ARM Architecture Reference Manual ARMv8 for ARMv8-A architecture profile",

  Apart from Load-Exclusive, Store-Exclusive, Load-Acquire,
  and Store-Release, addresses can have any alignment unless
  strict alignment checking is enabled....

  -- Section C3.2 Loads and Stores, page C3-160.


  The Load-Exclusive/Store-Exclusive instructions other than
  Load-Exclusive pair and Store-Exclusive pair require natural
  alignment, and an unaligned address generates an Alignment
  fault. Memory accesses generated by Load-Exclusive pair or
  Store-Exclusive pair instructions must be aligned to the
  size of the pair, otherwise the access generates an
  Alignment fault. 

  -- Section C3.2.6 Load-Exclusive/Store-Exclusive


  The Load-Acquire/Store-Release instructions other than Load
  Acquire pair and Store-Release pair require natural
  alignment, and an unaligned address generates an Alignment
  fault. Memory accesses generated by Load-Acquire pair or
  Store-Release pair instructions must be aligned to the size
  of the pair, otherwise the access generates an Alignment
  fault.

  -- Section C3.2.7 Load-Acquire/Store-Release


  The LoadLOAcquire/StoreLORelease instructions require
  natural alignment, and an unaligned address generates an
  Alignment fault.

  -- Source C3.2.8 LoadLOAcquire/StoreLORelease


  The CAS and CASP instructions require natural alignment, and
  an unaligned address generates an Alignment fault.

  -- Section 3.2.12 Compare and Swap, page C3-172


  The LD<OP> and ST<OP> instructions require natural
  alignment, and an unaligned address generates an Alignment
  fault.

  -- Section C3.2.13 Atomic memory operations, page C3-173.


  The SWP instructions require natural alignment, and an
  unaligned address generates an Alignment fault.

  -- Section C3.2.14 Swap, page C3-175

I've only ever dabbled in assembly programming, but the ability of x86 to do atomic operations across cache lines is, AFAIU, rather unique. That Intel and AMD engineers are able to accomplish it relatively performantly is an incredible achievement. But it's not a handicap anybody else wishes to adopt and then compensate for.

Yet another ActiveX-like tech re-spin, we are going back to the dark age.

Having usable and capable _SCRIPTING_ language for web was the biggest achievement of the whole Web 2.0 push, now the browsermaker is about to reverse that

No, in no way. WebAssembly is more a tool to create a library for JavaScript and it is standard unlike ActiveX. It is possible for example to put wasm functions in IndexedDB to use them with multiples apps.

"Microsoft’s ActiveX[1] was a technology for code-signing x86 binaries to run on the Web. It relied entirely upon code signing and thus did not achieve safety through technical construction, but through a trust model."

https://github.com/WebAssembly/spec/blob/master/papers/pldi2...

And no one used that trust model. Every place I was aware I was using activex, even deploying it in a few places, part of the process was showing the users how how to click the "Run Anyway" or "Ignore security warnings" type of buttons. It was such a night mare for support.

The web was never composed of x86 hardware

I'm siding with baybal2 on this one. No matter how much you're wishing to use your favourite language on the Web, WASM is at best unnecessary, as the kind of application it enables (near-native speed) can be had with ordinary native apps as well. Why does something like that have to run in the browser? The only reason I can think of is because software/game publishers want to control your usage even more.

But it doesn't stop there: the worst possible outcome of WASM is that entire custom browser runtimes are being pushed to you [1]. Say goodbye to content linking, sharing, saving, translation, accessibility, ad blocking, etc. Not to mention content will only work on the bundled WebKit version.

WASM is user-hostile and anti-Web. What does it even mean that W3C "approved" a working group? I thought WASM was a WHATWG thing. W3C shouldn't lend what's left of its credibility to it.

[1]: https://trevorlinton.github.io/

> Say goodbye to content linking, sharing, saving, translation, accessibility, ad blocking, etc.

That is already posible without WASM. But it's not done because it hurts search engine scores.

> the kind of application it enables (near-native speed) can be had with ordinary native apps as well. Why does something like that have to run in the browser?

For the same reasons all the other kinds of web applications are not developed as native apps as well. Hint: it's not only about speed. Some of the main reasons web apps are winning over native apps is easy of distribution, updates and being multiplataform. And it's being increasingly harder to force javascript to behave as a general application programming environment.

> But it doesn't stop there: the worst possible outcome of WASM is that entire custom browser runtimes are being pushed to you [1]

If we ever come to the point where all you need to develop a web browser is a wasm vm, don't you find exciting how much simpler a web browser would become? At the moment it is one of the most complex pieces of software out there. It is so hard to build a modern web browser from scratch nowadays that doing so as a hobby would take a lifetime. This takes the power away from individual developers, since it's not very realistic to build a new browser unless you are a big corporation with money to spare.

This situation also poses a big problem for the development of new operating systems. If your shiny, awesome, new research open source OS does not have a modern web browser, it will never reach wide adoption and thus never atract enough developers to build critical mass. The alternative is to make your OS compatible with POSIX and thus reuse the work of others so that you can build existing web browsers. But then you are most likely bound to become just another unix/linux alike, thus hindering innovation.

> This situation also poses a big problem for the development of new operating systems.

I am currently developing a new kind of operating system using nothing but web technologies (ie, it is technically a single-page web app). It might not be the same kind of legacy hardware-centric operating system that most techies fret over, as I am just interested in "userland" ideas (ie, what new kinds of applications can we build, using what new kinds of higher-order abstractions). IMO, the kinds of research programs you are thinking of are really, practically speaking, solved problems.

Also, my OS is compatible with POSIX, as it is the first (that I know of) Javascript implementation of IEEE Std. 1003.1 (Shell Command Language).

The project is called "Linux on the Web" :

- https://linuxontheweb.org

~or~

- https://linuxontheweb.appspot.com

As individual developers, we really need to start thinking of web browsers as the hardware layer, virtualized as it may be. Just as the scripting languages of the early 90's allowed us all to start thinking at higher levels at the language layer, modern web browsers allow us to start thinking at higher levels at the OS layer.

If we ever come to the point where all you need to develop a web browser is a wasm vm, don't you find exciting how much simpler a web browser would become?.

But you're not removing complexity, just moving it into the wasm-based runtime, and in the process it removes the power that comes with building the browser, which is shaping how the user sees and interacts with websites.

If every website is a blob of code that you have to execute as a black box, what's the point of writing your own browser? It'll just be a slower copy of every other, since all the potential for making it different has been taken away.

Because not all websites need all the complexity built into a browser. And wasm does necessarily imply that we need to leave html and css behind. But we get the freedom to choose and build better options.

>If every website is a blob of code that you have to execute as a black box, what's the point of writing your own browser? It'll just be a slower copy of every other, since all the potential for making it different has been taken away.

A very insightful comment

If that's the case then OTOH an argument can be made not to cram any more functionality into web browsers, such as entire language runtimes.

Browsers are becoming out of control behemoths.

You are basically saying we shouldn't bring good scripting environments into the web, because if we do, people will use them.

As much as I hate all the "javascript required to render text" sites out there, I can't agree. Scripting has its uses, and a proper environment will not only make it easier to deal with those accessibility and compatibility problems, it will also make it easier for browsers to sandbox those scripts so they won't mess with your computer.

> can be had with ordinary native apps as well.

Ordinary native apps are not safe.

Was going to reply something something about sandboxing but then I realized: If we're going to sandbox native apps, I'd rather it be done by a cross-platform standard like wasm instead of done differently by each vendor.

The fact is, this web assembly stuff could be seen in some ways as a response to the walled gardens being built by each vendor right now. I prefer native apps too, but if we're going to have walled gardens, why not one big one we can share.

Ah ok, I didn't see it from that PoV, I'm not into third-party apps on my phone. Speaking of which, do you believe Apple will allow running WASM apps on iOS?

Haha no idea, I wasn't even thinking of phones at all, but I guess it's a consideration too.

I'm a fan of anything that will help ease the pain induced by the ever-growing Electron cancer on the desktop. Hopefully this will catch on before I need 64GB of RAM...

Native apps are not compatible across platform. But more importantly they can't be safely installed by the user. I don't want to install your websites app because I have no way of knowing it won't give me a virus or drain my battery. How does that let "software publishers control my usage even more"? It takes a significant amount of their control away by putting them in a limited sandbox.

Wasm is the first time we will get cross platform and fully sandboxed native speed code.

None of what you speak of has anything to do with wasm. You can do all that just fine with JavaScript. We've had that world ever since browsers allowed disabling right clicking. Even before js, you could always distribute your webpage as an image if you wanted that. Wasm just let's you run code faster. It doesn't change anything.

You are unaware of issues with sandbox.

Here they are:

1. A sandbox can have bugs, and they do have them

2. Sandboxed environments have to give huge reach of system api's anyways, and you can do a lot with them

3. There are classes of vulnurabilities that sandboxes can't do anything about: instruction level exploits, hardware bugs, "gpu frying webgl shaders"

4. Human factor (see comments about "run anyways" above)

All of that applies to JavaScript again. Wasm is just lower level and simpler. If anything it should be significantly easier to sandbox because of its simplicity. It doesn't provide any more access to Apis or anything than JavaScript does.

Some sandbox is better than no sandbox. When's the last time somebody delivered ransomware through the browser without a user explicitly opening a downloaded file?

I agree its antiweb. But as these clowns at Google and Microsoft try to figure out ways to guarantee their long term employment, whether its through the appstore or this kind of bullshit - one thing they don't realize is most ppl have enough disk space on hand to store most of the useful internet and enough processing power to index it themselves. People really don't need the crap that is called the internet today. Just check out what kiwix can do and ask yourself what browser makers are trying to do.

It does not change anything substantial about the web today. It will just be a saner output format for compilers than javascript. Unless you write compilers, nothing changes.

It does not matter weather your language compiles to JS or WASM, and it does not matter what the browser executes.

I agree with most of what you say but it is a bit extreme to say "Unless you write compilers, nothing changes".

Some troubleshooting methods will change, the ability to view source will be reduced, performance will be increase, safety will increase...

And many more subtle things. I agree it is a huge win, but there are some (minor) negatives.

There is a major negative effect - you will be running obscure blobs of code - you can't think of anything worse for security.

Sandboxing as such will not help you to any degree with that. People promoting sanboxing as a universal solution have poor knowledge of computer security

I don't know a complex web app that doesn't minify and/or obfuscate its source code.

You do not see a difference in between two?

No, not at all (practically). Either way I need a source map and/or a decompiler to read the code.

The parsed VM bytecode and calls to native code by the interpreter are two quite different things

Come on, don't downvote him just because you disagree with his opinion.

That is only discouraging people from expressing their opinions.

I would agree 95% of the time, but honestly this one is just absurd.

"Each successive version will incrementally incorporate improvements to support more...features such as: Multiple return values, Multiple memories + tables, Threads + shared memory, SIMD, DOM/HTML integration, Garbage-collected object support..."[1]

It does sound like we're headed for some fragmentation here. That list will allow for other scripting languages to run on browsers without having to download a huge runtime, and to interact with the DOM just as JavaScript does. Wasm starts to look more like a multipurpose VM versus looking like ASM.

[1] https://www.w3.org/2017/08/wasm-charter

Your comment makes no sense. Of course it will allow you to use multiple languages. That's the point! Like how you can implement any language using assembly.

Sorry, but your comment makes no sense. Those features are needed for some popular languages to work well in WASM. They aren't implemented yet.

Yes, you can hack around and push an entire runtime now. There's a reason nobody is doing that. It isn't practical, performant, or a good experience.

Here's Brendan Eich's quote on the matter:

"Certainly GCC or similar could generate wasm, but I think to get to the dynamic languages, like I mentioned Dart, or Ruby, or Python, even JavaScript — that’s gonna require some extensions that I mentioned earlier, like: garbage collection hooks, JIT support, things like that. Otherwise they just won’t be competitive."

I don't disagree that we're moving further and further away from the documents with links model, but that ship has long past sailed. It wasn't just ActiveX, it was Flash. And Java. And Silverlight. And EME. And JavaScript (which, despite the presence of "Script" in the name is not just a scripting language).

Web browsers are currently (to take a reductionist view) just VMs with the ability to also view traditional HTML pages. Java had the right idea with its run-anywhere code and the JVM; it was just a bit too early to the party, and didn't have an HTML viewer to get its foot in the door.

> Java [...] was just a bit too early to the party, and didn't have an HTML viewer to get its foot in the door.

Well, it kindof had one ([1], [2], [3]). Rhino JS (still used all over the place; for example by Google's closure compiler) originated from that time.

[1]: https://en.wikipedia.org/wiki/HotJava

[2]: http://jazilla.sourceforge.net/pmwiki.php

[3]: https://docs.oracle.com/javase/7/docs/api/javax/swing/JEdito...

Oh, swing.

Java is a bad language, bad design, and bad execution.

Having more of Java in JavaScript is bad. Turning browser into a VM is just a recipe to bring pretty much every problem inherent to VMs to web development

JS isn't going anywhere? And now you can write code in lots more languages that compile down to Wasm, so that's really the opposite of a reversal.

This is wrong on so many levels it's borderline trolling. As if minifying and uglifying and mangling ASCII Javascript is so readable and accessible.

It was fine for displaying a "Hello dear user please enter your name" dialog in the 90s.

Now we are just joking ourselves pushing ASCII program code for full-blown web applications down the wire to the user.

If WASM isn't making that any better, it's not making it any worse either.

>This is wrong on so many levels it's borderline trolling

>full-blown web applications

Well, for underhanded "premium plugin" devs, this opens opportunities. I understand your position.

What is a "scripting" language? At this point JavaScript has effectively become a general purpose language. And one that usually gets transpiled and then minified for production anyways. Plus, since WASM is essentially for providing libraries to JS code, is there really much of a difference to either the developer or the end user between including a JS library via npm and a WASM library?

A scripting language, is a language whose main utility is to manipulate and run functions provided from outside of its execution environment

Reply on news.ycombinator.com