Live data from Hacker News

Compiling to WebAssembly: It’s Happening

hacks.mozilla.org

141–150 of 225 posts

Re: Compiling to WebAssembly: It’s Happening

#141
post #119

Earlier quoted context omitted.

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 (f…

> In fact I'm pretty sure you'll see more opening for C++ developers on the front-end than Javascript ones.

I would be happy to take a bet that this will not be the case.

The fact is that JS is much easier to learn than C++, has a broader ecosystem in the browser, is faster to write than C++ due to memory safety among other considerations, and is fast enough for app logic.

Think about it. C++ code has been supported for years on mobile. Yet Java/Dalvik is king on Android, and Objective-C is king on iOS. JS is faster than both (in the case of Objective-C, JS property access is faster than Obj-C virtual method dispatch due to ICs). So I see no reason why this will not be true on the Web as well. Web Assembly is very needed and important, but JS won't be going away.

Re: Compiling to WebAssembly: It’s Happening

#142

Cool, but why not just use, you know, Java bytecode? Existing toolchains, compilers, runtimes, virtual machines could all be reused I'm sure. Actually there are a hundred different great virtual machines that could be used... Why, yet, another?

All the compiler backend/code generation is using LLVM, and the VMs are all pre-existing (JavaScript with some extensions), so there is a huge amount of existing code being used here.

Re: Compiling to WebAssembly: It’s Happening

#143

Earlier quoted context omitted.

> 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 mul…

> The open web has nothing to do with "view source". It never did. "View source" just makes debugging easier.

This is about as true as the idea that the only use of seeing source code is debugging (or building/deploying your own version of the app).

Which, of course, every developer here knows is not true.

Reading source code is useful for figuring out how to do something you didn't know how to do. It's useful for discovering idioms you didn't know, even if you already knew another way. It's very useful if you're trying to do bookmarklets/extensions/mashups or even more significantly engineered interop.

I don't know if there's a formal gatekeeper out there with a list of all the things that capital-O Officially make the The Open Web(TM) great, so I guess there's no way to settle what's on it.

But I don't know how anyone could argue that these things weren't significant bullet points in a much longer list of reasons why the web has seen faster and broader adoption than any of the competing VMs and why it was/is often more useful and nice to work with despite more limited capabilities.

And I think it goes almost without saying that list is much bigger than the "no single gatekeeper" point.

> you're fighting against WebAssembly because you are ideologically against black box software

I am neither fighting against WebAssembly nor ideologically against any kind of black box software. My earlier comment makes it clear I think WebAssembly has a place (and, more generally, that transpiling does) as well as its hazards.

I am stepping in to point out that Flash and WebAssembly have significant things in common, some of which are tradeoffs against things that have made the Web an effective and proliferating medium.

> [JS] some important deficiencies with respect to typing and static analysis

See my aside about Elm. Given the fact that dynamic languages (including maligned ones like JS and even PHP) seem to be about as equally successful in terms of shipped software as statically manifest typed languages, whether or not even something like TypeScript is really going to give engineering teams an edge seems like far from a settled question to me. But I'm interested to see what happens where we're talking significantly augmented capabilities rather than the largely aesthetic differences that something like CoffeeScript represents.

(Speaking of which: "TypeScript, Flow, Dart, CoffeeScript"... at least one of these things is not like the others if you're invoking static analysis and typing as reasons for transpiling.)

> You say that other people's problems with JS are "superficial", but that's exactly how I see your problems with WebAssembly.

I can't tell exactly what you're saying here, but at a close approximation, it sounds like you might be suggesting that the readability of WebAssembly is going to be on the same order of difficulty that an experienced Python developer has reading idiomatic human-written JS (ie, aesthetic). This is potentially possible, I guess, in a world where everyone writing compilers that target WebAssembly is conscientious at/above the level that the CoffeeScript developers were (CS output is really fairly readable, arguably more so than minified JS). But then again, that's not what the name suggests WebAssembly is for. In practice, most of the time it's probably going to read... a lot like assembly language dressed in C-like syntax.

Re: Compiling to WebAssembly: It’s Happening

#144

Web browsers are turning into giant, poorly designed operating systems. My current operating system can already run binaries, this is reinventing the wheel in a massively over engineered way.

And I don't understand why. Take the two most popular mobile platforms, iOS and Android: people there routinely download and install new applications and typically never interact with Facebook, Twitter, Gmail or Instagram via their browsers. Why should the situation be different on the desktop? I feel that the efforts should not be going into making the browser into an OS that can run general-purpose software, but ra…

> Why should the situation be different on the desktop? I feel that the efforts should not be going into making the browser into an OS that can run general-purpose software, but rather getting a packaging system that is cross-platform and easy for users to use.

Cross platform is a red herring. The iOS and Android app stores are not cross platform. Ease of use is also increasingly a red herring. The Windows and Mac app stores have been around for a long time and are quite easy to use. Yet they have not ushered in a shift away from Web apps on the desktop.

I think we should be looking at why Web apps have been successful on the desktop rather than pretending they have no advantages.

Re: Compiling to WebAssembly: It’s Happening

#145

Earlier quoted context omitted.

And I don't understand why. Take the two most popular mobile platforms, iOS and Android: people there routinely download and install new applications and typically never interact with Facebook, Twitter, Gmail or Instagram via their browsers. Why should the situation be different on the desktop? I feel that the efforts should not be going into making the browser into an OS that can run general-purpose software, but ra…

I think you are right, this is a high technical debt solution for letting lay persons install software more easily. App stores already did a pretty good job at this anyway, and have the added benefit of curation. The number of layers of in our software stacks grow faster than Moore's law can handle.

> App stores already did a pretty good job at this anyway

Then why isn't the Mac App Store (to name an example) a runaway success?

Re: Compiling to WebAssembly: It’s Happening

#146
post #6

Earlier 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.

Sorry to say, but the web isn't about writing apps in the language of your choice. If it's beyond plain, passive HTML, it's about running applications on foreign hosts/resources without a well specified license to do so. Scripting languages provide both audible code and a small load as compared to binary object code (which is, why we had them on servers and clients in the first place). If we turn the web into an anyt…

Probably solve it the way we do with the rest of shared libs and open computing:

Require the source. Download compiled code from trusted sources.

Download a nuget package; dll's. Download an apt package; binaries and so's. This won't blow up web.

Re: Compiling to WebAssembly: It’s Happening

#147
post #29

Earlier quoted context omitted.

Mostly. The initial target is C++ and similar languages, and it will not have DOM access, but using suitable libraries (libc, SDL, etc., for example emscripten's) you can write a normal C++ program and have it run in the browser. You can also run Ruby and Python in the browser by just compiling their C or C++ VMs. But that won't still work "like JavaScript" - their objects won't be native VM objects in the browser, i…

Its worth pointing out that it would hardly be practical to expect users to download the code for the entire Ruby VM (and libraries) when they visit your web page.

Caching is hard because we serve the same code from so many different servers. IPFS fixes that by referring to files by a hash of their content. Commonly used binaries will be cached on your browser, and every app will refer to them the same way.

Re: Compiling to WebAssembly: It’s Happening

#148

Earlier quoted context omitted.

And I don't understand why. Take the two most popular mobile platforms, iOS and Android: people there routinely download and install new applications and typically never interact with Facebook, Twitter, Gmail or Instagram via their browsers. Why should the situation be different on the desktop? I feel that the efforts should not be going into making the browser into an OS that can run general-purpose software, but ra…

> Why should the situation be different on the desktop? I feel that the efforts should not be going into making the browser into an OS that can run general-purpose software, but rather getting a packaging system that is cross-platform and easy for users to use. Cross platform is a red herring. The iOS and Android app stores are not cross platform. Ease of use is also increasingly a red herring. The Windows and Mac ap…

> I think we should be looking at why Web apps have been successful on the desktop rather than pretending they have no advantages.

I think there is a perception of "try before you buy" with web apps that is appealing. Even when apps/programs are free, you feel like you are giving something away by installing them.

Re: Compiling to WebAssembly: It’s Happening

#149

Web browsers are turning into giant, poorly designed operating systems. My current operating system can already run binaries, this is reinventing the wheel in a massively over engineered way.

And I don't understand why. Take the two most popular mobile platforms, iOS and Android: people there routinely download and install new applications and typically never interact with Facebook, Twitter, Gmail or Instagram via their browsers. Why should the situation be different on the desktop? I feel that the efforts should not be going into making the browser into an OS that can run general-purpose software, but ra…

> people there routinely download and install new applications and typically never interact with Facebook, Twitter, Gmail or Instagram via their browsers. Why should the situation be different on the desktop?

Er, because that would be really silly.

I like reading HN from time to time. I would never install an app, because I don't use it frequently enough. I definitely would never go through the pain of installing a HN app every time I wanted to read HN. I really doubt I'm alone or even abnormal in that regard.

That's the beauty of a browser: I can be reading HN in under a second when I want to, with no cluttering of my desktop just so I can read HN from time to time.

Re: Compiling to WebAssembly: It’s Happening

#150
post #119

Earlier quoted context omitted.

> 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 (f…

> In fact I'm pretty sure you'll see more opening for C++ developers on the front-end than Javascript ones. I would be happy to take a bet that this will not be the case. The fact is that JS is much easier to learn than C++, has a broader ecosystem in the browser , is faster to write than C++ due to memory safety among other considerations, and is fast enough for app logic. Think about it. C++ code has been supported…

If you're dissatisfied with objc_msgSend performance, you can write C or C++ seamlessly - or use that other language that's partially designed to address the dynamic dispatch nightmare.

If you're dissatisfied with JavaScript call performance, you have no choice.

Post reply on HN