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

Bringing the web up to speed with WebAssembly

blog.acolyer.org

Post reply on HN
Print view View original

141–150 of 172 posts

Re: Bringing the web up to speed with WebAssembly

#141

Post by gwbas1c »

zach43 wrote: post #18
whoisthemachine wrote: post #8

WASM has the potential to change the world... a thought: while WASM will initially appear in compute-intense functions in web apps, it has the potential to be a true "Common Language Runtime". It may become the future platform that native, dekstop apps run on. This could be a good thing, if done correctly: 1. Desktop apps have a common, safe runtime upon which they run, and the packages can be easily distributed (and…

I am also very interested in learning more about using WebAssembly as a primary deployment target for desktop applications. Recently when I was working on a cross-platform C++ application using Qt and boost, a major pain point was in understanding the different packaging conventions of the operating systems. If WebAssembly takes off, and is available on Windows, macOS, and Linux, would it be possible for me to build…

Write once, run everywhere always has various tradeoffs. The closer you get to fundamental differences in operating systems, the more platform-specific code you need.

UI, for example, is hard to make platform independent if your application needs to look and feel native; or needs to plug into platform-specific features.

What would be useful is a way to easily call WebAssembly libraries from native applications. This way common business logic can be written cross-platform; but the parts of an application that need to remain native are left native.

Re: Bringing the web up to speed with WebAssembly

#142

Post by gwbas1c »

grondilu wrote: post #41

This is probably hand-waving but : instead of implementing threads directly into the WebAssembly language, would it make sense to compile a known micro-kernel to WebAssembly and then compile the C standard library (which, IIRC, implements threads)?

I'd rather see something like async/await before true threads. So much of web programming is network IO bound; that what we really need are primitives that make async programming easier.

Threads can come later.

The problem is that when async programming is hard due to language or framework difficulties, threads are the easier choice. But then, older code is locked into patterns that are hard to refactor to async/await.

Re: Bringing the web up to speed with WebAssembly

#143

Post by gwbas1c »

pedrocr wrote: post #20

We spent a long time wishing for a VM for the web that could be targetted by any language and being told that wasn't possible. WebAssembly will finally deliver that and it seems to be done by the same people/organizations. What changed?

It's called the CLR. (Common language runtime, which is what C# runs on.)

The problem is that the CLR forces you into a "one-size-fits-all" garbage collector. It's good for what it does, but if your application needs are different, than the CLR just won't work.

Re: Bringing the web up to speed with WebAssembly

#144

Post by mwcampbell »

slededit wrote: post #91
jfbastien wrote: post #22

Earlier quoted context omitted.

In theory, yes, but WebAssembly current has put little effort on standardizing packaging and ABIs. That work is in progress here: https://github.com/WebAssembly/tool-conventions but is still very early. You'd then need each of these platform exposing a standard set of imports to WebAssembly binaries because from the compiler's perspective WebAssembly looks like an OS with a virtual ISA, so these embedder imports are…

I'm actually working on an effort in this space. Specifically we're at the point where it's time to stand up a libc in a non web embedding. If anyone is interested in the effort they should let me know.

Please contact me privately. My email is in my profile. Thanks!

Re: Bringing the web up to speed with WebAssembly

#145

Post by wtetzner »

primeblue wrote: post #98
vbezhenar wrote: post #67

Earlier quoted context omitted.

Java bytecode is 100% portable.

Java 8 still has syntactic sugar for generics?

What does syntax sugar have to do with binary portability? Generics information is available in the bytecode, and you can access it through reflection (it's available on methods and fields).

Re: Bringing the web up to speed with WebAssembly

#146

Post by Rusky »

dikaiosune wrote: post #128
Rusky wrote: post #115

Earlier quoted context omitted.

Along with the other responses, the JVM imposes its own object model on any language implemented on top of it. WebAssembly does not, so it is vastly simpler and more flexible. For example, you had to rewrite your apps to run as Java applets. You do not have to rewrite things to run on WebAssembly- all the existing C, C++, etc. code is compatible, up to the platform API.

This is of course assuming that the WASM GC proposal doesn't require a specific object model to get host GC interop.

So far it doesn't look like it will: https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...

But either way, I'd still take "use this object model for host GC interop" over "use this object model or leave the platform."

Re: Bringing the web up to speed with WebAssembly

#147

Post by naasking »

pjmlp wrote: post #32
lmkg wrote: post #27

Earlier quoted context omitted.

I have the suspicion that one possible future of HTML is to be a legacy delivery wrapper for WASM code and a element.

Same here. I am beting once WebAssembly gets mature enough, we will get the revenge of plugins.

Nothing intrinsically wrong with plugins that are instantly available on every platform.

Re: Bringing the web up to speed with WebAssembly

#148

Post by pjmlp »

naasking wrote: post #147
pjmlp wrote: post #32

Earlier quoted context omitted.

Same here. I am beting once WebAssembly gets mature enough, we will get the revenge of plugins.

Nothing intrinsically wrong with plugins that are instantly available on every platform.

Hope you keep being positive when Flash, ActiveX, Java, Silverlight get reimplemented in WebAssembly.

Re: Bringing the web up to speed with WebAssembly

#149

Post by pjmlp »

lj3 wrote: post #111
amelius wrote: post #105

Earlier quoted context omitted.

Yes, something like OpenGL.

Maybe. OpenGL has a lot of history and baggage. I'm pretty sure the current browser engines don't use OpenGL for 2d graphics. I think they still use Skia (Chrome) and Cairo (WebKit). It could be as "easy" as allowing calls to be made directly to those graphics libraries in WebAssembly.

Skia makes use of OpenGL, DirectX or Vulkan.

Re: Bringing the web up to speed with WebAssembly

#150

Post by pjmlp »

weinzierl wrote: post #96
otakucode wrote: post #57

Earlier quoted context omitted.

My first thought reading the specification was '6 months before there's silicon that runs the bytecode directly.'

No really. WASM is based on a stack machine and not a register machine. On the other hand there was PicoJava [1] and there is Jazelle [2]. So, maybe... [1] https://en.wikipedia.org/wiki/PicoJava [2] https://en.wikipedia.org/wiki/Jazelle

Stack machines used to be common in mainframe hardware, back in the day.

http://www.retrocomputingtasmania.com/home/projects/burrough...

http://datamuseum.dk/wiki/Rational/R1000s400

Post reply on HN