WebAssembly Browser Preview
v8project.blogspot.com
v8project.blogspot.com
https://blogs.windows.com/msedgedev/2016/10/31/webassembly-b...
https://hacks.mozilla.org/2016/10/webassembly-browser-previe...
http://v8project.blogspot.com/2016/10/webassembly-browser-pr...
[edited to make links clickable]
> compatible and stable implementations of WebAssembly behind a flag on trunk in V8 and SpiderMonkey, in development builds of Chakra, and in progress in JavaScriptCore
[Emphasis Mine]
They also make the bulk of their profits selling phones that view web pages, so this is very important to their core business.
They've paid out 50 billion USD to app developers since the beginning of the app stores (1). Since they are taking 30% of the profits, are you saying it has cost them around 21 billion USD to run the appstore?
(1) http://www.theverge.com/2016/8/3/12371006/app-store-50-billi...
Apple suggested last week they expect around a 40% profit margin, and sold 45m phones last quarter. Assume an ASP of $500 that's $200/phone profit. Multiply it out you get $9bn in the quarter (not their strongest, they expect winter to go better.
But that's a quarter. So take a quarter of 3bn and you get $750 million, which is only 8.3% of the phone profit.
They make some money on the App Store, but it's not like it's 30% of their busines.
http://kangax.github.io/compat-table/es5/
Getting to 100% on ES6 was pleasant, but still a surprise given their track record not just with JS support but with some CSS features too. They're often stragglers, even more so now that Microsoft's browser is getting better.
Asked about the missing Apple, he responded that he was sure they were on board but hadn't submitted their written statement by his deadline. I asked why he would assume they were going to publicly commit to it if they hadn't. It would have taken a one-line statement.
He got very snippy and said that they were obviously just a bit busy getting ready for one of their regular public performances (maybe WWDC, I don't remember.) Yeah, sure, that must be it.
Their show came and went, and I must have missed the announcement. More shows came and went. If Apple ever publicly committed to supporting wasm, as all the other companies did on day one, I haven't seen it, but maybe they eventually did. (It would be easy for me to miss, so I'm seriously asking here.) Is anyone aware of any link to that public announcement of support, the one that we would have seen on day one if Apple hadn't been so busy?
If not, then there is another possibility. There are Apple people contributing to the wasm technology, both the development of the spec and the implementation in WebKit (I believe, but correct me if I'm wrong.) That would give Apple the option of supporting wasm if they ever chose to do so. I'm sure they want that option. And no public announcement of support means they are hanging on to their option to exercise their iOS/Safari veto power over this significant advance for open web apps (vs. vendor-controlled native apps).
If they're primarily about tablet and mobile devices now (lots of indicators that's the case), they're going to be concerned about battery life, performance, and other impacts on user experience. If history repeats itself, they're probably concerned about these things at a level of fussiness that other vendors often don't share. They might well not be on board with wasm for related reasons, or they might take longer to conclude it'll be OK, or work out whatever efforts make them feel good about it.
Or they might just lurve their walled garden a lot.
I expect wasm to be be less resource intensive than JavaScript, as GC's and such won't be necessary.
But, then again, most people don't write ASM. They target it. So in practice, the performance of apps taking advantage of wasm will have a lot to do with compilers and the culture/choices developers bring to writing the software targeted at the browser-as-runtime.
Apple is the new Microsoft (but worse than MS ever was).
Apple's lack of public engagement probably has more to do with management's priorities. Apple's lack of community engagement is a problem: they drag their feet on WebView, block 3rd party browsers, and stymie adoption of open codecs like Opus and WebM.
However, Wasm can be polyfilled, so it can reach critical mass without Apple's explicit cooperation. At some point, not supporting Wasm will mean losing market share (and thus revenue) to Firefox and Chrome.
As such, I'd read absolutely nothing in to them refusing to commit to supporting it in a future release: that's just their normal behaviour, because per Apple policy they cannot. What actually are signs (whether they're implementing a given feature—typically publicly, whether they're sending detailed feedback on the spec, and what they're willing to say about implementing it off-the-record in private) are all there for WASM. I would be entirely unsurprised if Eich had off-the-record confirmation that it will almost certainly ship in Safari 11.
I'm an Eich fan, so what I DO trust is that he's doing everything he can to make this happen. I do trust that whatever he says is an attempt to help the web platform become the best it can be, meaning he's trying to help me.
I'll remain a bit skeptical about the literal correctness of those words until I hear what Apple has to say, but I'm encouraged by some of the other comments I see here.
They haven't made such a statement, but that's not unusual for them because their corporate policy is to "not make forward-looking statements". They do have representation in the WebAssembly W3C community group and do send representatives to the (rare) in-person summits that we've held. (Turns out the proverbial smoky back rooms do exist, it's just that smoking is not allowed).
This seems to be mainly an abundance of caution rather than obstinance or objection. It does seem that they have started working on an implementation, but we are careful not to put words into their mouths or read too much into that.
They were kept abreast of the planning this particular announcement and of late have ramped up their interest in settling design issues.
https://bugs.webkit.org/show_bug.cgi?id=159775
dependencies are getting attention. Note also who is assigned to some of the recent ones: JF Bastien, formerly of Google (long-time PNaCl team member).
I may also have been unwilling to put people I know at Apple, with whom I'd spoken about WebAssembly in person at CurryOn in Prague (July 2015), on the spot. But suffice to say they're keen on WebAssembly and everything looks as on track as it can be, for a stealthy prima-donna company like Apple!
Apple's "courageous" willingness to enforce their own agenda and disappoint those with other priorities does not inspire confidence that Apple is fully on board with this wide-open web app platform, and that "no comment" is just how they express their enthusiasm.
But maybe they really are enthusiastic, and maybe they can hardly wait to announce their support for progressive web apps, too. Since I'm not in the smoky back rooms, I'll just have to wait and see.
But you and others who are working toward making these things happen, not just creating the tech but also working on the politics, should know that you're doing a valuable thing for the world, and lots of us appreciate what you do.
https://news.ycombinator.com/item?id=9736138
I don't think that counts as caps-lock shouting, as it's not all caps-lock. :-/
But whatever you call it, sorry about that. Re-reading it, I still think you seemed a bit over-aggro re: Apple, hence my mocking (again, sorry) -- but who knows? You could be right and they'll slow-roll or cripple WebAssembly.
I doubt it, based on what I know, but it is all speculation until they ship. Only thing to do is carry on and do what we can to up the competitive pressure.
But you've answered my real issue ("how serious are they, really?") as far as you possibly can at this point, and I'm more optimistic than before, while still reserving a bit just in case....
And I really hope that more of the "extensible web" enabling technologies will follow sooner rather than later. Good luck and thanks.
We'd like to say that we're incredibly excited to keep moving WebAssembly forward, and that's in large part due to the amazingly collaborative model that all of the vendors have put together through interpersonal relationships and shared vision.
Please scrutinize and comment on the design, bang on the tools, and give us feedback! Maybe try writing a codegen or tinkering with the existing tools. Try porting an app or a game. If all goes well, this is what the vendors have agreed to ship at the beginning of next year, so we want to be absolutely sure that it's something solid that others can build on top of.
This is also not the end of the evolution for WebAssembly, since there is a pipeline of features planned that go beyond the MVP (minimal viable product), well into next year and after. The web and the working group is the place to experiment with and perfect those details going forward.
It's an exciting time for the future of the web!
Thanks, - TL on the V8 side
I know this is marked as "future", but is there any progress on exposing the DOM? That's something I'm personally really excited for.
Logos should never be created by the community. The community should always appoint a logo dictator and either accept their selection or overthrow them and appoint a new dictator.
But first, I'd like to know what you all think about my choice of shoes. Are they the right shade of brown?
We can have a round table meeting to discuss it next Friday.
Now you've lifted the problem from bikeshedding over the logo to bikeshedding over the dictator.
Also, the "negative space" logo is incredibly slick, and I'd love to see it used on some project even though the HTML5-style shields are more practical for WASM.
Fogaccio's binary-inspired WA ligature looks really professional, too.
I like it when design has a real sense of personality, and having the logo be retrofuturistic would be cool :-)
- Why the chose stack-based VM, rather than register-based one?
- I see the docs mention Float128 type, is this a real possibility? What it their opinion on having Float128?
- there doesn't seem to be any support for ADC instruction ("add with carry") which would be very useful for implementing multi-precision numeric types. Are the plans to support ADC and the like or not? How to implement, say BigInt, with WebAssembly?
- maybe I misunderstood but when adding two integers result in an overflow, does it trigger the "trap"? I mean, lot of time (e.g. modular arithmetic) one does what fast "wrap around" (i.e. modulo 2^INT_SIZE) in integer types. Is this behaviour (of C) going to stay in WebAssembly?
For information on the semantics of WebAssembly arithmetic, see
https://github.com/WebAssembly/design/blob/master/Semantics....
For other information about WebAssembly start here
Like if everything goes well, how do you imagine it will affect the web in 5-10 years? What are we going to be able to do with it?
Existing, widely-used C libraries can be used in front-end applications if desired, and libraries in varying languages can all seamlessly interact with both each other and the DOM.
1. You will not see obfuscated (a.k.a.) uglified JavaScripts anymore. Everything will be compiled into bytecodes.
2. But don't worry, you will see bunch of webDisAssembly tools.
3. You will not see blog posts "How bad is that JavaScript" anymore.
4. But do expect to see "How bad is WebAssembly" though.
5. "Vanilla JavaScript" camp may have "Vanilla WebAssembly" banners on some tents.
6. You will not see anymore those ugly attempts to write Ray Tracer in JS.
7. Each framework will finally have its own programming language. Most advanced of them will change language on month basis, like Angular35 will use Rust build 3234.23.400. Moving asymptotically close to the Web Holy Grail.
8. Browser API will be decomposed to bare-bone state,
8.1 you will see immediate mode drawing a la WM_PAINT drawing style. Finally.
8.2 you will see CSS extendedable by custom layout managers and properties.
8.3 CSS modular system will reach its eternal ideal. Instead of them writing specs for us each our site will have its own CSS modules.
At the end: each team will write their own browser - FF, GC, IE will just provide WebAssembly loader means. Everything else will be just loadable.
So at the end you will get good Java Applet idea with User Agent exposing pure AWT alike primitives. With the browser as such a ClassLoader thing.
I realize the initial wasm spec doesn't seem to be aiming at that level of complexity, but I'm curious if/why repeated extensions of it won't move us in that direction.
Personally I see WASM as a potential way to speed up technology evolution and acceptance.
Like from CSS 1.0 era authors were struggling with flexible layouts on HTML pages. In 2008 work on flexbox module had started in CSS workgroup at W3C. And at 2015 we've finally got something. 7 years and very far from ideal at the end to be honest. If CSS would have an open architecture and with something like WASM in place + an ability to hook up that almost native code in rendering tree creation and composition process ... We would have significantly better results and significantly faster.
That's just an example. May be that's too optimistic of course. In any case if web browser, that we all rely upon, would be an open platform/technology it will be better for all of us. Can WASM be the way to that? I wish to hope.
Java was supposed to be key to that goal, but it didn't match the capabilities of the network and processing speed of the time. As painful as HTML, CSS, and JavaScript are to use, they actually worked.
Compile-to-JS, NaCL, and asm.js culminated in a realistic blueprint for how to build a low-level network-oriented runtime. Combined with increases to network speed (the average webpage is the size of the original DOOM) WASM is finally doable.
On the plus side, holy shit we can do (almost) anything! WASM will also mean outside money pumped into improving the browser runtime, such as Ethereum's migration to WASM.
Some of the parent comment is tongue-in-cheek, but you can already see one downside: fragmentation. Any good API gets screwed up in committee, so we end up with the most bare-bones and verbose implementation possible (WebComponents, IndexedDB, etc). Since they are so painful to use we end up importing 3rd party libraries which entails incompatibility. The content itself also becomes more opaque, as we can't just parse HTML to figure out the contents of the page.
That being said, holy-shit we can do anything!
The original vision for the browser was as a vehicle for browsing through interlinked documents. Web apps were an afterthought.
<script type="text/javascript" src="js-code.js"></script>
<script type="application/wasm" src="ray-tracer.wasm"></script>
As far as I understand the main goal of WASM is to have bytecode that is 1:1 mapable to current CPU architectures. JS source is quite hard to JIT due to typeless nature of JS (as an example of one of problems).
This http://sciter.com/htmlcss-ui-in-medicine/ is an example of such a hybrid application that uses HTML/CSS/script with native code (C++) responsible for low level data processing and filtering. In some cases native code there is generating image fragments for rendering. That application uses http://sciter.com engine where it is possible to mix native code with HTML/CSS/script.
I laughed so hard on this. "finally" omg
- Idapro/radare for web debugging
1. WebAssembly isn't an assembly format in the traditional sense, it's a compressed AST.
2. IIRC the plan is to develop a human-readable form of WASM that can be read directly from the browser. Basic debugging can be done directly in the browser.
Search for WebAssembly on https://trac.webkit.org and you can see that there is a lot of work happening.
The most recent commit being "WebAssembly API: implement Instance" - https://trac.webkit.org/changeset/207929
So yeah it looks like it is not finished. But it also looks like they are investing a lot of engineering time in this feature as we speak.
It's a huge undertaking. There are just a ton of library calls to support. Here's the list of AS3.0 classes: http://help.adobe.com/en_US/FlashPlatform/reference/actionsc...
And a whole lot of games are still in AS2 - game developers never really embraced AS3.
It really isn't going to happen, I'm afraid.
EDIT - Maybe it's possible to compile the C++ sources for the Flash Player to WebAssembly? Then you wouldn't have to re-implement the libraries.
I don't know the state of these compilers, but there was a Mozilla post about it a while back: https://hacks.mozilla.org/2015/12/compiling-to-webassembly-i....
Adobe hasn't open sourced the Flash Player, so it would have to be them.
SWF specification is here http://wwwimages.adobe.com/content/dam/Adobe/en/devnet/swf/p... It is definitely shorter and simpler, than e.g. PDF file format.
Today, we have PDF.js, emulators of gaming consoles, or even emulators of a whole x86 computer, which can run Windows OS. I believe that "SWF interpreter" in Javascript can run pretty fast. The specification is free available online.
The only problem I see is, that in Flash, you can create TCP / UDP sockets, which is not possible in a web environment.
You can send it to a backend via WebSocket, tough TCP/UDP proxy.
(1) Full screen: https://developer.mozilla.org/en-US/docs/Web/API/Fullscreen_...
(2) Camera + Microphone: https://developer.mozilla.org/en-US/docs/Web/API/MediaDevice...
Does anybody know how much of the Flash plugin AA runs on CPU vs GPU? Obviously the older versions were CPU-only, though I'm not sure how much of actual Flash object rendering has moved to the GPU in recent years, especially as a ton of it is bezier based. If it is still fully CPU-based, with GPU just doing blits & blends, then wasm should allow fast enough use of a proper .swf AA renderer without going through canvas's forgetful AA.
That is why I made IvanK.js http://lib.ivank.net . It is a library for doing graphics (including rewritable text fields), mouse and keyboard events in a "Flash way". I was able to rewrite my flash games to JS in a couple of hours, it was just a "mechanic" rewriting of ActionScript 3 to Javascript. If you want to port your flash projects to the web, it may be extremely useful to you :)
It's probably safest to assume that history will more or less repeat itself with web assembly.
Caveat, Google, Mozilla and Microsoft each have differing WA implementations. For Chrome, WebAssembly gets fed into the V8 TurboFan JIT:
https://ia601208.us.archive.org/16/items/vmss16/titzer.pdf
JITs are a security hole. In particular, Apple won't allow your JIT on their iOS. They've only just recently allowed you to use their Core JIT on iOS:
https://www.blackhat.com/docs/us-16/materials/us-16-Krstic.p...
What you can do to Turbofan inside of the Chrome sandbox, you could probably do with WA.
The fundamental security challenge of iOS is that there exist things called "private APIs" - Apple-authored code that lives in the address space of a developer's application that the developer is not permitted to call directly. It exists so that "public APIs," a different set of Apple-authored code that is technically indistinguishable from private APIs (mapped in the same way, with the same memory protection, etc.), can use the private APIs in their implementation, and so that developers can call public APIs in turn.
In order to enforce this, Apple does static analysis and manual inspection of binaries uploaded to the App Store, and signs every page of executable code that can execute on an iOS device. (It's not very good static analysis. I've had an app rejected because it used a third-party framework that happened to share a symbol name with a private API, and I've had an app accepted and shipped that, at runtime, disassembled the code of a public API to find the offset of a private API, and did questionable things to the private API's static local variables.)
The ability of the app to generate code at runtime would completely defeat Apple's ability to do static analysis or manual review worth anything. It could, for instance, download a function from the developer's website and then execute it. For this reason, Apple has technical means to prevent you from running code that it did not sign. As a side effect, this prevents you from implementing a JIT.
The attacks described in that Black Hat presentation you link are about gaining "arbitrary code execution" with the permissions of the app, no more. In any other OS design, this isn't an exploit, this is how apps work. If you download a Windows .exe and run it, the .exe gets to supply arbitrary native code. If you download an Android .apk and run it, the .apk gets to supply arbitrary native code. If you go to a website, the website gets to supply arbitrary JavaScript (though not native code). Nobody is reviewing that JavaScript to figure out what it does; the JavaScript simply executes on a platform that restricts the abilities of all possible JS. That's how application distribution works.
Apple has chosen this very different model on iOS where apps are reviewed in advance to limit what code can run; under that model, being able to run arbitrary code is an exploit. But that doesn't mean that JITs, which necessarily require being able to run arbitrary code, are a security hole under any other model.
It's perfectly permissible under App Store rules to use an interpreter which is functionally equivalent to a JIT in its ability to obfuscate code, or invoke or manipulate private APIs (e.g. can read/write arbitrary addresses, run dlsym, whatever). You aren't allowed to download bytecode for that interpreter from the internet, but again, that's a policy restriction, not a technical one.
An app might have a buffer overflow bug. Allowing all or some of the writable memory to be executable makes it easier for an attacker to exploit such a bug. (An attacker can still exploit the bug without arbitrary native code execution, but it's harder.)
The apps are still protected from one another, so this restriction mainly protects app developers from their own mistakes.
Its usefulness can be debated, since ROP and other techniques are powerful enough for a motivated attacker to go a long way without actually executing code, but it's not fundamentally invalid as an exploit mitigation technique. In fact, PaX implements something similar:
https://pax.grsecurity.net/docs/mprotect.txt
Of course, Apple evidently thinks the speed benefits of JIT are important enough for Safari to be worth letting the browser process not just remap RW to RX but actually map RWX pages - despite the browser process probably being the biggest target of all for exploits. I personally think iOS should allow apps to opt in to doing the same, but that's just my opinion.
Maybe I'm confusing this with some other system?
Edit: Looks like WebAssembly is more low level than asm.js, and is actually closer to real assembly, whereas asm.js is more akin to C.
For a simple example...
i = i|0;
Yup! Thats the plan for web assembly! Write in what you want, compile to browser-supported format, deploy.
It is intended for C and C++ developers to be able run their code in a performant way on the web.
[1] http://teavm.org/ [2] https://www.reddit.com/r/programming/comments/5899ln/teavm_j...
Users don't care which one you use, so it won't make sense to switch to WebAssembly until there's a significant performance benefit and the code size issues are solved.
Which can be useful, but it can also be bad if your languages model doesn't map perfectly to JS's (this is an issue already with JS-hosted versions of a number of languages that introduces incompatibilities with non-JS-hosted implementations.)
Unless you go 100% no-js you are still going to need to interact with it, and even if you do completely remove JS in your stack, the DOM APIs are still geared toward JS, and work in ways that make sense to JS.
AFAIK WASM literally aims to be a "universal web bytecode", and they hope to eventually add multi-threading, GC and DOM access. Of course the exact implementation details might differ from e.g. your local Java runtime vis a vis GC and threading timings and such.
But for example in a distant future each browser's JavaScript runtime could be just an interpreter that internally emits WASM. And there should not be any reason why you could not compile most Java / C# code to WASM once threads and GC are added.
No where does it say that it's intended to be a universal bytecode.
There's a whole Wiki page dedicated to GC: https://github.com/WebAssembly/design/blob/master/GC.md
Sounds like they aim to implement only GC primitives to allow emulating a wide variety of different VMs.
You can get rid of JS's shortcomings for years now with compilation. That's not really the goal here. What I see here is low level access for raw power. Most of the JS apps don't really need it.
Edit: I take it back. According to this note, I don't see what would stop anyone avoiding JS at all. http://webassembly.org/docs/gc/#webidl-integration
Once you can reach the DOM API directly from WA code, JS is redundant for you can use for example C# to build apps.
I hate to sound alarmist, but we might look back at 2012-16 as the years when frontend tooling was easy :)
As a hardcore JavaScript developer I welcome this tech for a couple reasons. For one thing, it's undeniably a significant step forward for Web Platform as a whole. For another, now people can struggle with the peculiarities of the said Web Platform with their own languages. The legitimate grievances associated with JS over the years were due to the browser APIs and first of all DOM, which wasn't designed for JS to begin with and later just accumulated problems for the sake of backwards compatibility.
On an upside, with WASM browsers can potentially save a snapshot of the compiled code to speed up re-runs. I recall the idea was promoted back when Dart was expecting to get its own VM, and one of the things that it would be capable of was this snapshot using.
Even if you can get everyone to agree on one canonical CDN (you can't), you also need to get everyone to agree on one version of the file at the CDN.
Plus cache sizes on most platforms are laughably small (a heavy page can completely blow out your cache on mobile devices).
IIRCthere was a "study" while back that found by using the most common CDN at the time to host jQuery, you only got like a 5% cache hit rate. This was because of multiple CDNs, multiple versions, multiple ways to reference the version (1.2.3 vs 'latest'), and http/HTTPS.
In my past experience, we had more trouble with people blocking our CDN via corporate networks or something.
The firewall issue is always going to be a problem on corporate networks. I don't think we're ever realistically going to get away from having to self-serve dependencies if you want to ensure that things are going to work, particularly if it's software that is deployed in on-premise, internal servers.
And while updates every 6 weeks might seem crazy to you, unless we just don't version the links (which seems like a terrible idea), even simple bugfxes blow the whole system.
Plus CDN hosted systems come with a bunch of other downsides. Lack of http2 pushing, tree shaking and bundling doesn't work, being able to compile with your own settings, and more.
CDNs aren't the solution here, something like using service worker and/or an "install" process for web apps will solve all of these and more.
First of all, it's dangerous because you could "probe" the user's cache cross-domain by offering files with a specific checksum and seeing if they take it or not. Letting evil-example.com figure out if you have visited pornhub recently by offering up their javascript file with the subresource hash attached and seeing if you download it is a massive privacy violation and can cause issues much worse than just knowing you were on pornhub.
Second, Cache sizes are already too small, and while a content-addressable-cache might help with that a bit, it won't really change all that much. You'll still have 100 versions of jquery out in the wild at any time, you'll still have 10,000 different versions of react bundled with other things. You'll still have the version with a UTF-8 BOM and one without, or one with \n and one with \r\n.
Finally, (and this one is just my opinion) it's a solution that encourages worse behavior. It's going to be easier to include that 300kb of jquery when you think that your users will have it cached already. And that just "loosens the belt" around an area where we should be cutting back. Now users that are arriving for the first time will get a significantly worse experience, and that is the starting to go against a fundamental strength of the web, that you can get the same experience on any device, anywhere, any time, whether it's your computer, your cousin's desktop, your friend's phone, or your damn car. Making devices that don't have that in their cache download a massive "basically binary" blob before they can use it is against what the web is, and content-based caching really encourages the behavior of including entire libraries (so they'll be cached) instead of compiling down only the code you need.
While most of this can be mitigated, this just isn't something that's sorely needed. There is an MDN document floating around somewhere that they were talking about something like this, but I can't seem to find it right now.
Of course, we move from the beauty of no-install software on the web back to runtime installing but...maybe it would be better?
Obviously it can be nice for organization, but that should really fall more on the individual to decide than the spec.
Back to the question:
Traversal: Historically we had 4 methods to get an element: by its id, name, tag, and class; yet there was no general method to get an element by value of its attributes until Selectors API brought querySelector. IMO it was one the most important things that pushed the community towards jQuery back in the day.
Manipulation: Up until recently one couldn't remove an element without referencing its parent, that is, you have to use removeChildNode, or replace, or innerHTML, or other methods of the parent. Now they added .remove() that is only supported in the evergreen browsers. Replacing or inserting nodes operates on the same principles and is a hell of its own that makes people opt for re-generating nodes instead of shuffling the existing ones.
Generation: For years now we have been relying on non-standard innerHTML for element generation because the only way DOM allows to do it is to create each element with createElement and then set attributes one by one. It's a ridiculously low level api considering our use cases. Hence, we got the whole templates/jsx movement today.
Modularity: Ain't there. In order to truly "componentize" our apps we have to wait for something like Shadow DOM because there is no way to guaranty that one part of the page won't affect the other in today's DOM.
All in all, DOM wasn't meant for what we are trying to use it today and for a long time it has been playing catch with browsers implementing ad-hoc solutions to new problems.
Because I look at all the GUI toolkits out there (and in the last twenty years I've used a LOT of different ones), and none of them are idealistically "good". I don't see anything particularly special about other toolkits that makes DOM look particular bad. In fact, I tend to think of DOM as being pretty good in comparison, if only for the fact that it works on everything.
"createElement and then set attributes one by one" is no different than any other toolkit. They pretty much all have a simple, static editor syntax for doing bulk element creation and attribute setting, and then a verbose API for dynamic element creation. It's low level because your use case is not the only use case it needs to support. I've seen--and built--a bunch of systems that have tried to simplify it and it always loses something in translation.
So maybe you're complaint isn't with DOM. Maybe you just don't like user interface programming in general.
That's because my whole point was to elaborate on the statement I made in the first comment:
>The legitimate grievances associated with JS over the years were due to the browser APIs and first of all DOM,
People who were complaining about web dev and JS over the years were mostly doing it because of the browser APIs and DOM, hence my recollection of recent history. And of course I do point out what was fixed, and I said from the start that it's far better now than it was before. I'm rooting for VanillaJS after all.
I cannot comment on other GUI toolkits since I don't work with them. You may be right that they too are low level, and I wholeheartedly you're right about DOM being better, because I hope DOM with Web Platform replaces them all one day. That doesn't exempt DOM from criticism though.
Technically DOM still doesn't have API for bulk element creation since innerHTML/insertAjacent comes as a separate API which is still a working draft. But that's just details.
There is another problem somewhat related to DOM being low level. Although it has to do with the browser implementations rather than the standard, it's still a problem for the end user, and the user is going to blame it on the web/JS being bad in general. That is performance. As it was mentioned here, DOM is separated from JS engine in browsers. Calls to DOM from JS are a lot more expensive than calls inside the engine. This gave rise to the whole Virtual DOM movement we see taking over the web dev. It's not just the verbosity of low level DOM that pushes people towards React and such, but the fact that at the end of the day their approach of mimicking DOM in the engine and limiting the DOM calls turns out to be more performant that the low level manipulations we do directly on the DOM.
Consider the following scenario. You have two handlers on an event that both change the DOM and may result in cancelling each other. With the "raw" DOM you'll end up calling DOM at least twice (and changing it twice if no debouncing is used), whereas Virtual DOM both times calls to, well, its "virtual" DOM (which is a lot cheaper) and by the time it gets to its next cycle of updating the "real" DOM it may not need to change anything or do it once. These optimizations are hard to implement without resorting to a virtual DOM of one sort or another.
Sort of. Calls to DOM from JS are a few dozen machine instructions for the call itself in modern browsers; a little more if lots of arguments are involved. The slowness is what the DOM implementation actually has to _do_ as a result of the call. If you write a loop in which you repeatedly modify styles and then ask for geometry information, then the only options an implementation has are to provide stale geometry information (the virtual DOM approach!) or end up with that loop being a lot slower than asking for all the geometry information up front and then doing your modifications.
We can have a useful discussion about whether it should be possible to ask for stale geometry information, but that has nothing to do with calls from JS into the DOM per se; a DOM implemented in JS but exposing the same API as the current DOM would have _exactly_ the same problem in that regard.
What got me first thinking about the cost of DOM calls were benchmarks we did back when we were building polyfills for IE6-IE8 to support new HTML5 APIs. One example in particular--mimicking data attributes. Our lib would hold a mapping between DOM elements and attached data attributes (as simple objects) and it would be significantly faster than using native element.dataset. While dataset isn't as simple as plain JS object, it's not much complicated either, and to my knowledge changing it doesn't cause reflows or repaints, so I expected it to be slower but not very much; hence, I concluded that the additional speed came from avoiding the DOM call itself. Since then I've been cautious about DOM and tried to cache whatever came from it and was supposed to be used repeatedly.
So you have to implement it as a Proxy, so it can capture arbitrary property assignments, including for properties it doesn't have yet, and do the corresponding setAttribute calls. Unfortunately, once you're a Proxy your gets end up somewhat slow too. Partly this is because JITs haven't optimized proxies that much, and partly it's because they're rather hard to optimize in the best of circumstances.
I expect that the actual implementations of dataset are not as fast as they could be if they used scripted and inlinable proxy handlers _and_ the JITs had implementations for those. But there's still a lot more work involved in dataset than a plain object, especially if you have a small number of property names in practice so the plain object doesn't have to convert to dictionary mode or anything like that.... Even if dataset were implemented on top of a pure-JS DOM implementation (which exist), it would be a lot slower than just a simple object, unfortunately.
[1]https://jsperf.com/dataset-vs-getattribute-and-setattribute/...
But note that in microbenchmarks you are likely to get some confusing effects. For example, in Firefox this microbenchmark:
document.getElementById('test').getAttribute('data-set')
1) getAttribute is known to be side-effect free when called with a string argument, its return value is not used, the call can be dead-code eliminated.
2) getElementById is known to be side-effect free when called with a string argument, its return value is not used after step 1, the call can be dead-code eliminated.
3) The get of the "document" property is known to be side-effect free, its return value is not used after step 2, the get can be dead-code eliminated.
So in the end the microbenchmark is measuring how fast the browser can increment a loop counter, and that only because we haven't bothered to try dead-code eliminating that. That's why you get numbers in the billions of operations per second range (comparable to the CPU clock speed; always a dead giveaway that your thing got optimized out). ;)
Note that Firefox will also perform loop-hoisting on all of the above if possible, so even if the return value were assigned somewhere that would not matter: the whole thing would just get hoisted out of the loop.
The setAttribute and "dataset.set = stuff" benchmarks don't have these problems, because those operations are clearly not side-effect free. A sufficiently advanced JIT might be able to determine that earlier iteration assignments are dominated by later ones and eliminate them, but now we're talking quite hard work on the part of the browser.
While we are on the subject, can I ask if there are any performance advantages of using data attributes over custom attributes for storing data in an element? In other words, can adding non-standard attributes to an element cause any deoptimizations? I know that JS engines use hidden classes/object shapes to optimize JS objects, I assumed something similar might be the case for DOM elements, in that case adding non-standard attribute must mean deoptimization.
Every node has a reference to it's parent.
What's the problem with node.parentElement.removeChild(node)?
Being counter-intuitive and verbose. It's but one example of such peculiarities that makes DOM hard to grasp for beginners.
It's node.parentNode.removeChild(node). And the fact that this is even a mistake that can be made, and is made by people all the timem is part of the problem!
"node.remove()" is a lot harder to screw up.
EDIT: Some more clarification, apparently this is enabled by an official add-on (called "Valence") which is shipped by default on Firefox Developer Edition: https://developer.mozilla.org/en-US/docs/Tools/Valence
Valence is an protocol adapter that adapts CDP to FDP, so Firefox DevTools (using FDP) can be used with iOS (which uses WDP)
[0]: http://webassembly.org/docs/future-features/#source-maps-int...
It summarizes the discussion so far between various stakeholders. I've since moved on to other things, and I don't know where the effort currently stands.
[1] DWARF2 et al.
https://www.youtube.com/watch?v=RByPdCN1RQ4&feature=youtu.be...
https://github.com/WebAssembly/design/blob/master/TextFormat...
The downside is that translating goto constructs in languages like C can be tricky and sometimes computationally very expensive. Even supporting multi-level "break" can be tricky. And constructs like "computed goto", which are often used in C, Fortran, etc to improve the readability (easier to read state machines) or performance (faster state machines for bytecode interpreters) cannot be supported by WebAssembly directly, which means instead of always being faster they'll always be slower.
But the downside is mostly irrelevant for people concerned by decompiling WebAssembly to readable source code.
Or will it be more of a GopherJS to WebAssembly?
Thanks
In asm.js/WASM the execution stack is not inspectable from code.
"Targetting WebAssembly (wasm) is the next step, but not yet ready. It won't be GopherJS"
https://dmitri.shuralyov.com/talks/2016/Go-in-the-browser/Go...
Why?
You cannot access the browser APIs from WASM so there is no tight coupling with the browser environment. I think non-browser use could make definately sense.
Do you have a reference? I'm confused about why you wouldn't want to access browser APIs.
WASM code can call external functions defined per module, and the external code can be JS code that interacts with browser APIs. So indirect use of browser APIs is possible.
https://github.com/WebAssembly/design/blob/master/HighLevelG...
TL;DR: compilers written for the JIT use case are designed to minimize latency (compilation times) while still producing above-average code, so having such an alternative backend would be a boon for regular users of compilers with heavyweight backends (e.g. LLVM, which produces excellent code but at the cost of very large compilation times, even in unoptimized builds). Additionally, a compiler built to process WASM is more security-aware than your typical compiler, and thus won't include optimizations that attempt to exploit undefined behavior (thus losing out on potential optimizing opportunities, but hopefully producing code that's a bit more bulletproof).
The current way to do the equivalent would be to use Binaryen's asm2wasm tool.
You can now simply do
node --expose-wasm
> buffer=fs.readFileSync('test.wasm')
> WebAssembly.compile(buffer)
Edit: link: https://github.com/WebAssembly/spec/tree/master/interpreter
But I'd rather that this OCaml program was _the_ spec. I found it enjoyable to read the other day when I was trying to figure out WebAssembly verification semantics. Much better than reading an English description of a verification algorithm.
Which has some nice capabilities such as the ability to call functions with arguments from the command line
wavm ../Test/spec/fac.wast --function fac-iter 5
stdin/stderr/stdout is also supported for pure command line applications all while being sandboxed.
node --expose-wasm
> buffer=fs.readFileSync('test.wasm')
> WebAssembly.compile(buffer)
So, at the very least there's support for C, C++, and Rust at the moment, though of course since the standards aren't yet finalized and the toolchains are evolving how well it works at any given moment may vary. I'm sure there's work going on for other languages to compile down to WASM, just not sure of the status of any other languages at the moment.
That said compiled languages should work if compilers add support for generating WebAssembly.
I'm working on a compiler for Clojure, which also runs in cljs, and would love to attempt to make a back end for it that runs in the browser.
If you want to also optimize the code, then binaryen can do both (wasm-opt to optimize, wasm-as to convert to binary).
Since this is for a compiler backend, then the optimizations are probably relevant for you.
However, from searching around, it looks like I'll have to emit bytecode directly, at least for the near future. Which isn't the end of the world I guess!
Yeah, I think it would have been nice to have text format input support in browsers, but the decision was against that.
But you do have other options than emitting binary wasm yourself. You can use a compiled version of wabt or binaryen, here's an example of binaryen.js,
https://github.com/WebAssembly/binaryen/blob/master/test/bin...
edit: actually it looks like the test doesn't cover WasmBinaryWriter, which is what would be needed for this, we should improve that
It uses the code from here: https://github.com/WebAssembly/wabt/tree/master/demo
It seems to be that until you get lower level network capabilities and some form of file system access, you're just too limited.
JS doesn't give you those things either but would you call it limited?
I think its a very early preview and we can expect a lot of limitations removed as the technology progresses.
But if you're building an app that doesn't depend on the network, you find yourself way more limited in most cases. The solution for many people is to go for Electron, but that takes you completely out of the web sandbox.
I understand that it's incredibly challenging to get multiple vendors to agree on anything, and I'm sure we'll get to a good place eventually, but I guess I'm just feeling a bit frustrated with the state of things.
What does this initial release of wasm enable? I've heard that game developers are expected to be the initial target audience. Do we provide adequate APIs for storing game assets? As an example, I think the latest Doom game is 50GB.
I guess I'm a bit concerned that all of this incredible work will get done and released, but nobody will be able to make use of it? Is this a legitimate concern or am I being irrational? I guess I'd have a bit more peace of mind if there were some examples of concrete use-cases that are expected to be solved by this work. Maybe these use-case examples already exist and I haven't seen em? I'll admit I haven't looked around much.
This is a concern I've had with regular web APIs as well. Sometimes I'll read about a new spec that's being developed, but maybe due to my poor understanding or lack of knowledge, I'll end up confused as to the purpose of those APIs.
http://webassembly.org/getting-started/developers-guide/
web assembly lets youvwrite web apps in C?
I hope this becomes the standard interface for server hosting, not just the browser.
noob here on web assembly.
Why does a function I pass into an Ajax query need a call statement?
Why does 'this' have so many interpretations depending on its context?
Other languages approach these in simpler ways. Functions inherit the scope in which they are executed and 'this' applies to its parent object.
Also, whats up with nested asynchronous statements?
I know ES6 and 7 are working on it but new languages would be ideal with new takes on solving some of the tough parts of web development.
Hmmmmmm...
WASM is much simpler. It's just a standard bytecode format that the JS engine can handle. It's much easier to secure.
http://vps2.etotheipiplusone.com:30176/redmine/projects/emsc...
I wouldn't recommend it.
As counterexamples, here are several binary formats that are very open: ELF, DWARF, PNG, tar, gzip, Ogg and all its subformats, FLAC, JPEG2000.
On the other hand, you have something like OOXML, which while technically open/standardized, is so incredibly complicated that it is extremely difficult to implement well. Just because something is text-based does not make it simple.
Webasm will be almost identical to minification when it comes to decompiling. And minification is already extremely common.
And you can be a skeptic, but one of the biggest reasons for webasm was to reduce parsing overhead which is currently the bottleneck (in terms of startup time) to most JavaScript heavy applications. Plus needing to keep the original source around bloats memory. IIRC some of their test applications would take 30+ seconds JUST TO PARSE on mobile devices. That's a HUGE amount of overhead that this will cut out.
It is compilation in just about every sense of the word (especially when combined with a compiler like babel or typescript)
Yes, it's not obfuscation, but neither is webasm.
FWIW, the "demo" from that site takes about 40 seconds to load on my mobile device when using the asm.js version.