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

131–140 of 225 posts

Re: Compiling to WebAssembly: It’s Happening

#131

Post by TeMPOraL »

klodolph wrote: post #17
c0nfused wrote: post #3

Web assembly always makes me a little sad. It feels like we are going back to flash only it won't be bad this time, I promise, no really. I always feel like the most obvious use for it is to start writing truly hateful and abusive code. I'm sure this is because I'm getting old.

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…

> WebAssembly is Unix, JavaScript is a Lisp machine.

Isn't this an argument against WebAssembly? We've already made the mistake once.

Re: Compiling to WebAssembly: It’s Happening

#133

Post by andybak »

wtetzner wrote: post #121
Scaevolus wrote: post #55

Earlier quoted context omitted.

HTML5 _still_ isn't able to deliver the quality interactive experiences (Games) without applying a lot more effort. Even "simple" things like cross-browser low-latency sound effects are still difficult. Flash presents a single platform with a single vendor that can innovate as quickly as they like. The web platform is inevitably cumbersome and slow in comparison -- over a decade later they're still playing catch-up.…

> I'm looking forward to WebGL ads that eat battery life with excessive shaders. As opposed to flash ads that eat battery life and bring the browser to its knees?

I think that was his point.

Re: Compiling to WebAssembly: It’s Happening

#134

Post by TeMPOraL »

1ris wrote: post #68
kalsk wrote: post #64

This sounds like an odd question, but I honestly need somebody to explain this to me...what is the motivation behind the modern trend to put everything on the web? Is there something you get by running your program from a browser that you don't get from downloading and running an elf or a text file, or is this entire trend based around appealing to users who don't actually know how to use their computers?

It's the current fad. But nothing new. Since the beginning of computing the tides go from thin-clients and fat-clients back and forth. Currently fat-clients are en-vouge.

Are they? The current trend is to have everything done server-side, thus making sure the users get minimum value possible out of software they use.

Re: Compiling to WebAssembly: It’s Happening

#135

Post by gnuvince »

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 rather getting a packaging system that is cross-platform and easy for users to use. My own preference would be something based off of Nix so that you can avoid many problems related to library versions and whatnot, but anything where a user could be pretty much guaranteed that if he clicks "install", he'll be able to use his application in the next couple of minutes.

Re: Compiling to WebAssembly: It’s Happening

#136

Post by frame_perfect »

shurcooL wrote: post #44

I'm very interested in compiling Go to WebAssembly. Based on what I read, it seems that so far you can primarily try it with C/C++ code. If one were to build a Go -> WebAssembly compiler, what are good routes to take? I can see there's going to be multiple possibilities.

Will be a huge pain in the ass. Go's compiler uses Plan 9, and WebAssembly uses LLVM.

Re: Compiling to WebAssembly: It’s Happening

#138

Post by andrewchambers »

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…

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.

Re: Compiling to WebAssembly: It’s Happening

#139

Post by icebraining »

_cbsz wrote: post #12
saosebastiao wrote: post #5

Does anybody know if there are plans for an API for garbage collection? The WASM spec as it currently exists seems to be only useful for non-GC languages, and it would be a shame if we ended up shipping a new GC implementation for every page that we load. Perhaps something that would allow compilers to tap into the native JS GC?

What would the GC scan? What do pointers look like? At the assembly layer, you have the flexibility to not have a C runtime (and therefore no C stack), and you might be doing fun things like having tagged pointers that the GC would have to know about. In short, the WASM layer is IMO the wrong layer for GC. I think the closest-layered applicable solution is caching & pinning guarantees for common libraries, which may…

The GC would scan whatever the program told it to scan, by using its API, like the Boehm GC library: https://en.wikipedia.org/wiki/Boehm_garbage_collector

I think it only makes sense, seeing as interaction with the native JS VM will be inevitable for a long time.

Post reply on HN