8 ms·
Web Assembly Working Group Charter Approved
- grondilu 9y agoI'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 :(
- TomMarius 9y agoLet'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).
- alekratz 9y agoThis. 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.
- nickthemagicman 9y agoWhy 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.
- twoodfin 9y agoTwo 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.)
- titzer 9y agoThat'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.
- detaro 9y agoA 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.
- baybal2 9y agoYet 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
- scriptproof 9y agoNo, 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.
- grondilu 9y ago"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/pldi2017.pdf https://github.com/WebAssembly/spec/blob/master/papers/pldi2...
- sqeaky 9y agoAnd 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.
- tejtm 9y agoThe web was never composed of x86 hardware
- tannhaeuser 9y agoI'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/ https://trevorlinton.github.io/
- mostafah 9y agoHow 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 http://caniuse.com/#feat=wasm [2] http://webassembly.org/roadmap/ http://webassembly.org/roadmap/
- akmittal 9y agoWhat are the changes compared to current Implmentation. Is DOM access on radar?
- deleted 9y ago[deleted]
- CyberDildonics 9y agoI 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.
- wahern 9y agoOther 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.
- CyberDildonics 9y ago64 bit ARM and POWER both do as far as I know. They definitely all support aligned 128 bit atomics.
- wahern 9y agoAn 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?
- CyberDildonics 9y ago> 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.faqs/ka15414.html 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."