1- With WASM, would developing for the web become similar to how desktop apps are written? For example, could I use C# and design a UI in xaml, compile to WASM for the web?
If speed is not an issue, and it's purely by choice of the user, i think there will be a lot of interesting changes to the web in the coming years.
Hell, for many applications i'd even be willing to accept a speed loss to use "my preferred language". And, in the event that certain tasks are indeed too slow, perhaps i'll be able to pass data back and forth between my WASM and JS to let JS deal with the performance critical DOM.
Regardless, i'm quite excited, and hope to see something fruitful from it.
It's not actually the nightmare many make it out to be with ES6. I actually enjoy writing it quite a bit (I have mainly a functional background)
On the web it's.. well, just JS. Some languages that transpile to JS.. but ultimately they're all pretty much just JS.
I think the community of people who want tyoe safe languages is large, and this will the a target for them.
I just hope for Dom bindings through the WASM ABI.
Writing glue code sucks.
Define an ABI for interacting with the DOM. And allow WASM compilers to target it.
I certainly would have picked up whatever language the browsers were pushing, where DOM access was a requirement.
(This is not a criticism of wasm, by the way. It's merely motivating potential future GC extensions to the spec.)
As an aside, JS is standardised by Ecma, as ECMAScript: the W3C doesn't have anything to do with it.
That’d be finally a solution.
Or require source maps by law.
EDIT: Why the downvotes? The only way to preserve the right to modify and decompile in the long term is by creating technical or legal measures enforcing it. JS was one technical measure, so now we need alternatives.
> That’d be finally a solution.
No, it wouldn't. You'd end up with sites shipping "source maps" that map every function to a randomly generated identifier.
What's a "valid" source map anyways?
Furthermore, debugging with sourcemaps is suboptimal. WebAssembly wants to support much better debug information than this.
It’s also intended to allow them to modify it for their own purposes, and provide the modifications to others who have a license to the original product.
Especially on the web this was finally possible, and now you’re suggesting to take this away again?
At most they legally protect someone who decides to run a disassembler or decompiler on a binary from prosecution or lawsuits (but only in as much as you don't use the result to violate copyright or other restrictions).
See Article 6 on http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:...
And "copying the decompiled source of the part of MS Word that reads .doc files" counts as covered, so, it's quite a lot.
Especially with websites, where you might want to interact with, or write addons interacting with, WASM threatens those rights.
No need for the DOM anymore... (not saying it's a better approach, but it is technically possible).
There's the next full stack paradigm right there. I give it two years, and it will be called rustic-asm framework...
It's still very early, and there's other avenues as well: an LLVM backend, for example.
More excitingly, I presume it will one day be possible to compile a mobile app into wasm and execute it in a browser, achieving instant parity between mobile web and apps.
Indeed, taking those away would be breaking the web rather than improving it...
The binary and text representation sections still lack almost anything. This really seems like an early prototype.
There are experimental implementations in Firefox, Chrome and Edge. See https://webassembly.github.io/demo/.
There's more information about the current binary format here: https://github.com/WebAssembly/design/blob/master/BinaryEnco...
There's a prototype spec interpreter here:
There's a build waterfall testing multiple tools here: https://wasm-stat.us/console, including the experimental LLVM toolchain, the emscripten-wasm toolchain, binaryen, and sexpr-wasm.
WebAssembly is still under development, but I don't think it's fair to call it an early prototype.
[disclaimer: I'm a WebAssembly contributor]
.wast is actually just a testing file format that's currently serving the purpose of a text format in the absence of a real one. It isn't expected to be part of typical user workflows.
Sorry for the snark, but watching this slow-motion trainwreck plow into the Open Web that I love is excruciating.
Pre-edit to respond to the inevitable "But you already can't read and debug minified JS": yeah, you actually can if you're good enough. I do it all the time... my complaint is that the bar for "good enough" is being moved from "can read and debug scripting language" to "can read and debug Assembly"... which I know you can do, but geez. I guess what I'm saying is the Open Web should only run on (reasonably) readable languages. Hate JS? Stand in line, but if you want to replace it on the web, replace it with something a normal person could interpret without a compiler.
If you're strongly opinionated about WebAssembly having a readable format for the Open Web (and it would seem that many are with the volume of comments like this), then subscribe to this pull request. You'll have an opportunity to see the text format take shape and provide input on it. Developers are not oblivious to the number of subscribers on a PR or issue, so you'll also be making it known that it's important enough for you to be looped in on.
Please check out the Text Format pull and related links so that you can be informed about this issue.
What kind of language target would you prefer for running optimized numerical algorithms? Or do you just think we should keep computational photography, natural language processing, physics simulation, 3d graphics rendering, game AIs, etc. off the web?
Remember, to make their code run at full speed, developers need the ability to use a variety of numeric types and processor-specific instructions (e.g. SIMD), implement low level data structures, precisely manage memory, etc.
I'm sorry, and with all due respect, your argument is hilarious, NIMBY, and goes against the Open Web movement's goal of "...a special role for public, cooperative, and standard World Wide Web communications", which you claim to love, and I assume, support (as do I). Wasm has a required text format in the spec itself, expressly for individuals such as yourself, so wasm is still for the Open Web.
How about "but you already can't read and debug minified Emscripten output"?
Although I can't disagree that debugging js directly in browser tools is a nice experience.
This isn't conducive to a civil discussion on the subject. Please don't.
I mostly write C and C++ code, and if someone tries to give me hand-written assembly they better have a good reason (and sometimes they do!). Same goes for wasm: it's meant as a compiler target, not something humans write by hand. That's no different from all the compile-to-JS languages, asm.js, or any assembly.
Sure Joe Schmuck can still get stuck with angry assembly, but we haven't made the world a worst place in that respect.
And I'd argue wasm is making the world better in many other ways. :-)
If some company works with C# making GUI apps and then leaves on a deal, and the only thing left is a binary of the app.. no source code.. no sane person is going to touch that. Same thing for WASM.
Though, there is a text spec, but ignoring that of course.
It has a culture of people viewing source and tinkering. Minification etc. limit that, but do not eliminate it.
And the web is a medium for transmitting and running other people's code on your machine in a safe way, and that includes not just sandboxing but also being able to inspect it.
It's important that the wasm text format be as readable as possible, to continue these traditions, even if wasm is a compiler target.
Back on earth though, all those things don't make sense, and are so rare as to be statistically insignificant.
In any case, not a valid argument to make against a new language/delivery format, any more than "what if someone drops it off some building and kills passers by" is an argument against pianos.
>If nothing like that ever happened to you... well I hope it never does, friend.
And if something like that ever happened to you, then maybe consider it an outlier experience, and don't extrapolate on that?
It's like an airplane accident survivor going on about how flights should be banned.
Yeah, hardly a real world use case.
And if a company ever has it, this would point that they have far bigger problems than being left without the source code for their service...
Why would you not have the source code to your site that you're debugging?
Even if you "do it all the time" there's like zero motive to do it for third party sites and services.
Does anyone (for the statistically significant meaning of "anyone", e.g. more than some lone outliers) seriously debugs and/or monkeypatches third party sites?
And of course for your own site, you already have the code.
So I'm not sure what you're losing here.
And from their FAQ:
>Will WebAssembly support View Source on the Web?
>a specific goal of the text format is to allow developers to write WebAssembly modules by hand for testing, experimenting, optimizing, learning and teaching purposes. In fact, by dropping all the coercions required by asm.js validation, the WebAssembly text format should be much more natural to read and write than asm.js.
Now I didn't mean to come off as snippy and for that I do apologize, but I find it frustrating when people attack a project without understanding what it is they're criticizing. If you had asked "Does this pose a threat to the open web?", I think this would have been a much more productive exchange.
If you succeed in derailing Web Assembly, then you'll just have people shipping Emscripten output, and "View Source" will be worse off.
What would you like to see happen here? Maybe you should give them your input.
I'm so lost, why on earth are you reading binaries? You keep citing examples of cleaning up after other people for a job. Why don't you have their source code?
If your job was with any other language, you would have the source code - you would not be given a Go binary and told to "fix what those previous morons did" - you would demand the source.
As for "I'm so lost, why on earth are you reading binaries?"
Consider every Perl/Haskell`/Smalltalk/COBOL developer for a moment. Do you think it's more likely that when this becomes a production standard they are going to say to themselves "You know what, I feel bad for the guys that will have to maintain this I'm just going to learn JS so at least it can be maintained in the same language the rest of the web is"... because I think it's probably more likely that they will immediately start transpiling binaries from COBOL etc, into WASM to run the web. Great for them, really but that's what leaves us with binaries to deal with.
Now, about having other languages compiled to the web, we already have that. Looking at specifically Haskell, we have GHCJS, and it (thankfully) works pretty well.
You may not like the idea that there will be new web projects using technologies that you lack proficiency in, but this is no different then how the rest of the software world works. For example, Google's Go language is picking up steam - in fact, I use it at work. If I didn't take the time to learn Go, I simply wouldn't be employed to work on that project. Similarly, I know people who are enjoying an incredible competitive advantage in their market by using Haskell for their web development (both backend with GHC and front end with GHCJS). If you don't learn Haskell, you won't be hired for those jobs. I do, however, guarantee that they'll still have the source on hand.
> You keep citing examples of cleaning up after other people for a job. Why don't you have their source code?
If you were working in C/Java/etc I'm sure your first reaction to the same problem wouldn't be "C is broken because I can't debug a compiled executable easily!".
It's a long list: https://github.com/jashkenas/coffeescript/wiki/list-of-langu...
Also, ultimately, there will be code that you can't maintain because you don't understand it. That might be because it's written in a language you don't know, but it might also be because it's written in a style you don't understand, or with a framework you've never used, or because it's about a topic that you haven't spent time with. That's OK. You don't need to be able to do everything.
Also - thanks for taking the time to make a thoughtful reply instead of just suggesting I'm a complete ignoramus and downblasting my response because we have a marginal disagreement about the Open Web Platform - made my day!
Right now, if you are a frontend "web developer", you can pretty much assert what you know from the title alone. The title implies the toolset.
I mean, it's no different than most other development in that regard.. but the web certainly will go through a change when this day comes.