So could someone theoretically make flash or silverlight work via this?
WebAssembly: a binary format for the web
51–60 of 164 posts
Re: WebAssembly: a binary format for the web
#52can you go back to source code from WebAssembly binary? I dont want a web that serves me obfuscated binary blobs.
I fail to see how obfuscated textual blobs are any better. It's not like I can get any useful information from thousands of lines of gibberish JavaScript. As a sibling pointed out, WA supports textual representation.
Re: WebAssembly: a binary format for the web
#53Earlier quoted context omitted.
Except with C++ instead of Java and the DOM instead of Java API's.
That doesn't sound like an improvement.
Well, considering it was:
- isolated (outside of DOM) - non standard (not everywhere) - third party (proprietary) - alien (uncanny value of different UI style) - bloated (even compared to the web stack, Spring was an over-engineered badly designed mess of a GUI API) - insecure (full of exploits to this very day, tons of them closed just last year)
it does sound as a great improvement. Except in case you weren't there and can't remember.
Re: WebAssembly: a binary format for the web
#54If the new way forward allows everyone distribute unreadable binary instead of readable, or de-obfuscatable, JavaScript, I think this definitely bad for open source and bad for innovation which depends upon stuff like: "oh, now I see how that did that. I think I can apply that technique to something else". Of course, people can release their js, python, java, et al that compiles down to WebAssembly, but because you a…
>If the new way forward allows everyone distribute unreadable binary instead of readable, or de-obfuscatable, JavaScript, I think this definitely bad for open source
What "open source"? Open Source is dead in web services, because everybody can just hide the source behind the server. Even with SPAs, you could have 90% of the actual functionality on the server side, behind REST APIs and the like.
Re: WebAssembly: a binary format for the web
#55I haven't looked at WebAssembly in Detail, but my feeling and worry is that this is a can of worms for security issues.
Javascript wasn't designed with security in mind and it has taken us decades to understand what implications that had (and we haven't really fixed them yet). The security implications for WebAssembly will be different, but I'm almost certain there will be a lot. (pnacl already introduced some quite unexpected issues, e.g. allowing control over cache flushes and thus making rowhammer attacks easier.)
Given that neither the linked text nor the FAQ they have does even mention and discuss that I'm even more worried.
Re: WebAssembly: a binary format for the web
#56Earlier quoted context omitted.
So far, not much. Clojurescript, Elm and most others assume that JS is taking care of garbage collection for them. Meanwhile, WebAssembly so far does not include GC support. If someone were to implement a custom GC for Elm on top of wasm's "here's a big array of bytes" memory model, it would be very interesting indeed. But, at the moment wasm is primarily a target for C/C++.
That's rather weak. How do you interop with the DOM? Explicit FFI? Are there plans to make WebAssembly catch up with the last several decades? There's no reason we can't have a proper IL like .Net or even Java at worst.
Yep, FFI. GC/DOM/Web API integration is in the eventual plans. https://github.com/WebAssembly/design/blob/master/GC.md
You want .NET on bare metal? Implement it on x64, ARM, MIPs and maybe PPC. You want .NET in the browser, implement it on wasm. You want Java in the browser, implement it on wasm. You want BEAM in the browser, implement it on wasm. You want Parrot in the browser, implement it on wasm. What you are not going to do is to get Google, Apple, Mozilla and Microsoft to all agree on any of those ILs.
Re: WebAssembly: a binary format for the web
#57Earlier quoted context omitted.
Because they shackle implementations too much. Every time you increase restriction glanularity, you make someone else's life harder. With every restriction or policy you introduce, you've actually increased the implementation's own attack space: you can't stop worrying about validation mechanisms further down the stack, but you now also have to maintain a new set of validations. That's a lot of extra work; given that…
> Because they shackle implementations too much I disagree on one count, and on the other count I don't understand, so I'm requesting clarification. First, the current fashion in programming languages is to allow an implementation to do anything (in Python, "import" takes no arguments, neither "require" in node.js) I think life could, in fact, get easier. Today applications do not regulate the code they load. It just…
> Saying that any effort to regulate the source code of loaded extensions amounts to "shackling" is throwing FUD on the whole idea
No amount of vitriolic words or technical nitpicking will change the fact that there will be more work to be done, both by application developers enforcing policies and by extensions having to oblige them.
> the current fashion in programming languages is to allow an implementation to do anything... I think life could, in fact, get easier.
Easier for whom? Not for the lib developer, who will have to follow more rules ("import" mechanisms already have some, by the way), nor for the runtime developer, who will have to enforce them. Easier for the final user who executes runtime and lib? Maybe, but then you cannot expect any serious traction from developers (whose life you're making harder). Trade-offs and all that.
Re: WebAssembly: a binary format for the web
#58Why does everything about WebAssembly make such a big deal about it being AST based rather than a stack or register machine? Sure this is a meaningful technical difference but I don't see why it's really a "selling point".
Re: WebAssembly: a binary format for the web
#59Earlier quoted context omitted.
No, but one of the goals of WebAssembly is to have a textual representation, so in theory you could still View Source. Not sure how that'll work out in practice, though.
In practice, I think most browsers won't include a "disassembler", under the justification that most users won't need it; I can see "View Source" unfortunately going that way too. What's wrong with that argument is the fact that although most users don't need it, it's an excellent way for those interested to explore into and find out how things work, and essentially get into web development with nearly no effort. If…
> I think there will be very few, if any, web developers who started out of their own interest and exploration instead of solely thinking of it as a profession
If that were the case, why do people get interested in programming in any non-interpreted language without thinking about it as a profession? I have trouble seeing this as a big step backwards in this regard since there are plenty of non-interpreted languages that kids in high school have gotten interested in themselves, even when there wasn't nearly as many good resources for learning them online.
I also don't see a huge difference between Web Assembly and minified javascript. Sure, with the later you could in theory piece through it without a disassembler, but if that is your introduction into the language I doubt you'll learn much at all (or want to). The gap grows even smaller when you take into the account the fact that Web Assembly is desired to replace asm.js, which was already incredibly obfuscated.
> Computing systems are becoming more closed and proprietary, and this will be a big step backwards in terms of openness of the Web that lead to its growth and freedom in the first place.
Web assembly was developed publicly from pretty much the very beginning on GitHub. We live in a world where the biggest closed-source players have open sourced implementations of their programming languages/platforms, compilers and all (e.g. OpenJDK, .NET Core, Roslyn, Swift). There are no popular languages around now where the leading implementations aren't open source. If this is what "becoming more closed and proprietary" looks like, then I can't say I'm opposed.
Re: WebAssembly: a binary format for the web
#60can you go back to source code from WebAssembly binary? I dont want a web that serves me obfuscated binary blobs.
I don't see how but the OP mentions 'something similar to map files' for debugging. So the map files are like pdb for (msvc) C++.
I wonder if it hadn't been easier if we'd just gone with sandboxed, auto-updated native applications rather than taking a 15-year detour through html, dhtml, 'ajax' web 2.0, spi w/ 'compiled js' and now this...