Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Compiling to WebAssembly: It’s Happening

hacks.mozilla.org

Post reply on HN
Print view View original

171–180 of 225 posts

Re: Compiling to WebAssembly: It’s Happening

#171

Post by moistgorilla »

gnuvince wrote: post #135
andrewchambers wrote: post #132

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?

Because users want it to be. Whenever there isn't a significant performance hit people will always choose the browser solution. The only reason people download apps is because of performance and data limitations. Take those away and people will use the web based version.

Re: Compiling to WebAssembly: It’s Happening

#172

Post by zurn »

azakai wrote: post #90
ezy wrote: post #62

Earlier quoted context omitted.

The issue with this is that if you care about speed, you need to be using SIMD -- and wasm doesn't seem to want to support it -- stating a "minimum viable" standard from the year 2000.

SIMD.js is in progress for JS, so JS VMs are already working on it. It is on the roadmap for being added to WebAssembly, likely with a similar API.

Is there a technical restriction why JS JITs don't transparently apply SIMD to existing loops like normal compilers (=autovectorization)? Or is it in the cards to build it on top of SIMD.js?

Re: Compiling to WebAssembly: It’s Happening

#173

Post by Sanddancer »

c0nfused wrote: post #92
modeless wrote: post #7

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

You're missing category 3: Code that runs in more than a browser. If I have code written in Fortran that already solves my problem, why should I have to rewrite it? If I'm more comfortable in C#, why should I be forced to use Javascript for writing front-end code? WebAssembly fixes the mistake that the web should be a monoculture, and allows people to use the best language for the job.

Re: Compiling to WebAssembly: It’s Happening

#174

Post by catnaroek »

pcwalton wrote: post #141
aikah wrote: 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…

I have no idea what you mean by JavaScript being "easier" to learn than C++. My experience has been the exact opposite.

C++ is a giant beast, but most of it was relatively easy to learn after I internalized the general principles that guide the language's design. These principles were the first coherent account I ever found of how programs manipulating ephemeral resources should be written. [I am aware that Rust improves on C++, but it builds on, rather than replace, the general principles established by C++.]

On the other hand, in JavaScript I have never found anything even remotely close to methodological guidance for writing programs. JavaScript seems to make sense of anything as long as it is syntactically valid - a very low bar. As a result, I felt like I had to navigate a really huge space, hoping to eventually find a correct program somewhere.

JavaScript's ability to run in the browser is, as far as I can tell, its only advantage over C++.

Re: Compiling to WebAssembly: It’s Happening

#175

Post by zurn »

andrewchambers wrote: post #138
gnuvince wrote: post #135

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.

Mobile app stores are junkyards with terrible discoverability and they have a captive audience.

Re: Compiling to WebAssembly: It’s Happening

#176

Post by modeless »

kuschku wrote: post #82
modeless wrote: post #7

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

That now we can’t read the source of webpages at all anymore? The whole "anyone can look at it, learn from it" part is gone? We’re steering towards more proprietary code. Say, for example, if I want to run Google’s "Star Wars" easter egg in Firefox. With JS, I could grep through the de-uglified and de-obfuscated code quickly, and find that its useragent detection would work if I’d just append "AppleWebKit Chrome/45.0…

You can't read the obfuscated code directly. You have to use tools to deobfuscate it. With Web Assembly it will be the same. There will be tools to help you read the code. You may proclaim that they won't work as well but I think it's premature to say that. Web Assembly is not machine code.

Re: Compiling to WebAssembly: It’s Happening

#177

Post by [deleted] »

andrewchambers wrote: post #148
pcwalton wrote: post #144

Earlier quoted context omitted.

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

[deleted]

Re: Compiling to WebAssembly: It’s Happening

#178

Post by andrewchambers »

aboodman wrote: post #165
andrewchambers wrote: post #132

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.

Your current (desktop) operating system allows these binaries to run with your full user privileges. Any software you download and run has complete access to all of the data from your user account, no matter which software created it. Software can interfere with other software (spyware), can affect anything on the account (malware), and can even harm the system itself (e.g., by consuming resources). Worst of all, bec…

It seems like the real solution is to have proper sandboxing in the OS's, though it would take much more coordinated effort to accomplish.

I see no reason why each domain couldn't have a chroot for example, the browser doesn't need to implement those things.

Re: Compiling to WebAssembly: It’s Happening

#179

Post by yoklov »

zurn wrote: post #172
azakai wrote: post #90

Earlier quoted context omitted.

SIMD.js is in progress for JS, so JS VMs are already working on it. It is on the roadmap for being added to WebAssembly, likely with a similar API.

Is there a technical restriction why JS JITs don't transparently apply SIMD to existing loops like normal compilers (=autovectorization)? Or is it in the cards to build it on top of SIMD.js?

Autovectorization is hard and fragile in the best of times -- tight stable loops with no (or few) branches and little/no memory access that may be aliased, etc.

For a dynamic language JIT this is pretty much infeasible (as I understand it). Every loop might have branches for guards/bailing out due to deopts, and at least in JS, TypedArrays are allowed to alias eachother.

Re: Compiling to WebAssembly: It’s Happening

#180

Post by etiene »

corysama wrote: post #112
etiene wrote: post #45

YES 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. https://kripken.github.io/lua.vm.js/lua.vm.js.html

ohh!! I know this project! I thought it had nothing to do with web assembly, thank you for the heads up
Post reply on HN