I'm sorry, but I'm not following. What's the problem this is supposed to solve?
Compiling to WebAssembly: It’s Happening
111–120 of 225 posts
Re: Compiling to WebAssembly: It’s Happening
#112YES YES YES!!! OMG! THANK YOU <3 <3 <3 I've been waiting so long for this! Maybe my dream of running native Lua on the browser will come true? Will I already be able to run Lua's interpreter now? :D :D Gonna look deeper into this as soon as I have time, omg so excited <3
The Lua interpreter was one of the earliest test cases for the C++ to JS compiler.
Re: Compiling to WebAssembly: It’s Happening
#113Earlier quoted context omitted.
Web assembly doesn't add new APIs or capabilities to the web platform. It only makes code run faster and makes porting C++ code easier. What about that is hateful or abusive?
Sorry, my intent was not to imply that web assembly was hateful or abusive but that the code I might write using it falls into two categories 1. Performance critical code 2. Sneaky stuff I really don't want the user to be able to read. Category two seems like the sort of thing that I would absolutely want to be able to write binary code that executes without user interaction. It seems like right now the focus is quit…
> 2. Sneaky stuff I really don't want the user to be able to read.
The user is already going to have a hard time reading the unuglified JS. If they are looking for "phoning home" they have to search for WebSocket sends and ajax calls. Both of those will have well defined APIs that will be just as easy to spot in dissembled webasm as they are in unuglified JS. I bet they'll be even easier to spot.
Re: Compiling to WebAssembly: It’s Happening
#114Hi Alon, thank you for sharing. I am a Computer Science Master student and i would like to contribute to the development. The git looks really full and i don`t know where to start.
Which area were you interested to contribute to? For Binaryen specifically, this bug could be a good starting point: https://github.com/WebAssembly/binaryen/issues/2 Other issues in the tracker there as well. Bigger topics are to make progress on wasm2asm, and to start an implementation of the current binary format (link is in the design repo), which Binaryen needs to support.
ok. Thanks, i'll have a look.
Re: Compiling to WebAssembly: It’s Happening
#115Earlier quoted context omitted.
What makes WebAssembly like Flash? Please elaborate. You already can't just read someone's JavaScript code if they're using a transpiler or uglify or something like that, it looks like line noise and you basically have to go through a lot of work to reverse engineer it. WebAssembly is no worse. The JavaScript environment on the web reminds me of the "walled gardens" that were Lisp machines back in the day, that force…
> What makes WebAssembly like Flash? Please elaborate. It's pretty straightforward. Both tend towards the Big Binary Blackbox Blob. It's true that WebAssembly has advantages Flash, Java, and Silverlight didn't really have in terms of being freely reimplimentable and (potentially) native to the browser. And it's probably a good thing that a browser can be a VM via a target-intended subset of JS. BBBB may be the right…
I'm sorry, this is going to be a rant. Feel free to ignore if you don't care about my opinions on the subject.
The open web has nothing to do with "view source". It never did. "View source" just makes debugging easier, it's a technical solution to a technical problem. It's why we use JSON or XML instead of ASN.1 for our daily work.
The open web is a web where no company is the gatekeeper. It's a web where we have multiple browsers, competing JS engines, et cetera. No one company can hold the web hostage. This is exactly why Flash, Java, ActiveX, and Sliverlight failed. Every one of those technologies was owned by a single company. Every one of those technologies failed because it's impossible for one company to be the gatekeeper for a technology that is supposed to run on billions of heterogenous devices.
So the lessons of Flash are this: don't put all of your eggs in the Adobe basket.
Meanwhile, you're fighting against WebAssembly because you are ideologically against black box software. Getting rid of WebAssembly does not actually achieve that goal. It's like you're fighting against condoms because they encourage promiscuity. The promiscuity is already there, and condoms just make it a better experience for everyone involved.
----
Footnote: JavaScript is on par with Python/Ruby/Lisp in a lot of ways, but there are some important deficiencies with respect to typing and static analysis, deficiencies which cause actual bugs in real world problems and cost developers time and money to deal with. It's why we've been inventing TypeScript, Flow, Dart, CoffeeScript, et cetera. You say that other people's problems with JS are "superficial", but that's exactly how I see your problems with WebAssembly.
People are going to write code in C++ because they can hit performance targets on platforms where they ship native code, and WebAssembly means a lot to the folks working with Unity, Unreal, or thousands of other existing projects which the new open web. The new open web, with WebAssembly, is an open web with more diversity than ever before, rather than a JavaScript monoculture.
Re: Compiling to WebAssembly: It’s Happening
#116Earlier quoted context omitted.
Then you're not writing JavaScript, which was OP's concern. TypeScript is fine (although Elm, Swift, and Haskell are more interesting, IMO).
Look at purescript. In order to install this madness you need to install not less than 5 package managers, but you might like it.
The situation has improved since cabal install was required.
npm install -g pulp purescript
should be enough now.
Re: Compiling to WebAssembly: It’s Happening
#117I see WebAssembly this way:
WebAssembly is to JavaScript what WebGL is to Canvas
Re: Compiling to WebAssembly: It’s Happening
#118Earlier quoted context omitted.
We will eventually come to terms with the fact that Flash was 15 years ahead of everything else on multiple fronts and we ought to have been just chastised the terrible developers doing awful and horrendous things with pretty technically sound software.
How would that have fixed Flash’s horrible CPU cost, chronic security vulnerabilities, awful touch support, or constant prone to crashing, even in the hands of competent developers?
Performance-wise flash wasn't that bad on Windows. Probably because Adobe put in a decade's worth more engineering into Windows than Mac. And of course they were caught off guard by the iPhone, like the rest of the industry.
Re: Compiling to WebAssembly: It’s Happening
#119Earlier quoted context omitted.
The important use case is to allow people to write web applications with their language of choice, instead of horrible javascript. And get near full performance.
I can't believe people still bash JavaScript. I've used a lot of different languages including Java, C#, C++, AVR Assembly, Python and others but JavaScript is my favourite and I would not want to go back. I think its a shame that some people just didn't seriously try JavaScript. It's a very powerful, expressive language. Also, testing with JS is amazing - Especially unit testing on Node.js. It lets you do stuff like…
> I can't believe people still bash JavaScript.
Can you believe you can satisfy every programmer out there with a single language? of course not. Why did you have to use all the languages you listed? Because some made sense in a specific context, other didn't.
> Also, testing with JS is amazing - Especially unit testing on Node.js. It lets you do stuff like redefine entire objects, properties or methods at runtime (for stubbing). Also, JS is great for writing asynchronous logic.
Testing with Python is also amazing. It doesn't matter how amazing it is if I hate writing Python code.
No, the reality is that, in 5/10 years, javascript skills wont matter, only a good knowledge of the DOM and WebAPIs. In fact I'm pretty sure you'll see more opening for C++ developers on the front-end than Javascript ones.
Re: Compiling to WebAssembly: It’s Happening
#120Earlier quoted context omitted.
What makes WebAssembly like Flash? Please elaborate. You already can't just read someone's JavaScript code if they're using a transpiler or uglify or something like that, it looks like line noise and you basically have to go through a lot of work to reverse engineer it. WebAssembly is no worse. The JavaScript environment on the web reminds me of the "walled gardens" that were Lisp machines back in the day, that force…
> What makes WebAssembly like Flash? Please elaborate. It's pretty straightforward. Both tend towards the Big Binary Blackbox Blob. It's true that WebAssembly has advantages Flash, Java, and Silverlight didn't really have in terms of being freely reimplimentable and (potentially) native to the browser. And it's probably a good thing that a browser can be a VM via a target-intended subset of JS. BBBB may be the right…
> It's pretty straightforward. Both tend towards the Big Binary Blackbox Blob.
A huge part of the project is to ensure decompilation to asm.js