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

111–120 of 172 posts

Re: Bringing the web up to speed with WebAssembly

#111

Post by lj3 »

amelius wrote: post #105
lj3 wrote: post #65

Earlier quoted context omitted.

Canvas is too slow and handles text rendering poorly. If browsers really want to take another step in that particular direction, they're going to have to expose a lower level API for graphics and text rendering.

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.

Re: Bringing the web up to speed with WebAssembly

#112

Post by slededit »

jfbastien wrote: post #103
slededit wrote: post #91

Earlier quoted context omitted.

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.

I'd honestly just start with musl libc. The one Emscripten supports mostly just imports the same syscalls as Linux, with some ugliness to be able to do some DCE. If you clean that up your embedder will only need to implement those syscalls.

I am working with musl, however not the one with emscripten. That one is heavily modified farming out significant parts to the javascript runtime. It is a goal to provide a minimal surface area for embeddors and part of that is not requiring a JS runtime.

Re: Bringing the web up to speed with WebAssembly

#113

Post by kuschku »

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…

You are lucky, Java 9 was just released.

Now you can ahead-of-time compile any JVM project into a single executable, it will run on all platforms, and it will have nice UI toolkits (JavaFX is quite awesome).

Even better, with Truffle + Graal in Java 10 also native interoperability with basically every other language is coming, so you can basically combine this with every language.

Re: Bringing the web up to speed with WebAssembly

#114

Post by kuschku »

gbuk2013 wrote: post #56
wlesieutre wrote: post #34

Earlier quoted context omitted.

I've said the same, but you just know somebody comes along and says "If we render our entire site into a it'll make ad blocking more difficult," and then poof there goes the last 20 years of work on accessibility.

Good luck for that site getting indexed by Google ;)

Just like with AJAX sites, Google will simply support it.

But writing third-party search engines will become even more impossible.

Re: Bringing the web up to speed with WebAssembly

#115

Post by Rusky »

weinzierl wrote: post #70
AnIdiotOnTheNet wrote: post #43

Earlier quoted context omitted.

We had that in the 90s. We called it Java.

I'm quite excited about WASM (as I was, admittedly, about Java Applets in the 90s), but this is a question that haunts me. I wish someone with better understanding of WASM and Java than me could write up why byte code delivery to a sandboxed VM in the browser failed in the 90s and why we should believe it will succeed now, or what exactly WASM brings to the table that Java didn't.

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.

Re: Bringing the web up to speed with WebAssembly

#116

Post by Rusky »

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

This wouldn't help at all. Kernels (micro or no) can only implement preemption with the help of hardware timers (and, if you want parallelism, hardware cores), which Webassembly cannot access. (The C library does not implement threads; it merely wraps the kernel's implementation of them.)

So at some level WebAssembly itself must provide some sort of primitive for threading, or else at best you'll get cooperative coroutines/an event loop.

Re: Bringing the web up to speed with WebAssembly

#117

Post by amelius »

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.

In any case, it should be hierarchical. It should be simple and efficient to move an object and all its children around.

Re: Bringing the web up to speed with WebAssembly

#118

Post by Rusky »

tannhaeuser wrote: post #83
batmansmk wrote: post #42

Yet, almost one year after its release, nobody makes money directly or indirectly with wasm... despite the beauty of its engineering, I'm starting to worry. Who will continue funding it if nobody uses it?

Exactly. WASM stories always bring up wild fantasies of platform world domination, when in reality there aren't APIs for even the most basic things, let alone practical apps. In a heretical way, I've got to ask why not just use JVM byte codes, an incomparably more established platform at this point with several mature VMs and sophisticated API ecosystem, albeit not necessarily in the graphics space? Why did we want t…

Java doesn't provide a sufficient security model for running arbitrary C/C++-like code, which is the entire purpose of WebAssembly. Drop that and all the new use cases will just go back to asm.js instead.

Re: Bringing the web up to speed with WebAssembly

#119

Post by ryacko »

catdog wrote: post #107
weinzierl wrote: post #70

Earlier quoted context omitted.

I'm quite excited about WASM (as I was, admittedly, about Java Applets in the 90s), but this is a question that haunts me. I wish someone with better understanding of WASM and Java than me could write up why byte code delivery to a sandboxed VM in the browser failed in the 90s and why we should believe it will succeed now, or what exactly WASM brings to the table that Java didn't.

I think it mainly failed because Sun basically abandoned it. Security was not the issue I think (Flash was the same, maybe worse, still widely used) but the UX was quite terrible and never really improved: You had the jvm with its long startup times which was more than noticeable in the 90s and early 2000s. Applets always felt very alien inside a Website and using the applet simply to call into optimized code from JS…

Virtual machines tend to take a while to initialize, for Java in part to verify the code.

Re: Bringing the web up to speed with WebAssembly

#120

Post by amelius »

lmkg wrote: post #27
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 have the suspicion that one possible future of HTML is to be a legacy delivery wrapper for WASM code and a element.

Yes, and there will be a default WASM code that interprets and renders the rest of the HTML! (in case anybody still wants to use HTML as W3C defined it).
Post reply on HN