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

121–130 of 172 posts

Re: Bringing the web up to speed with WebAssembly

#121

Post by lj3 »

amelius wrote: post #117
lj3 wrote: post #111

Earlier quoted context omitted.

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.

I think you're missing the point. An object and child hierarchy is too high level for what I'm suggesting. Just expose the graphics library and let the programmers handle the rest. If you want something hierarchical that's simple and efficient to move an object and all its children around, great. You write that for your applications. Make it into a framework if others want to use it. But if somebody wants to use a different approach for their application, they should be able to do so.

Re: Bringing the web up to speed with WebAssembly

#122

Post by amelius »

lj3 wrote: post #121
amelius wrote: post #117

Earlier quoted context omitted.

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

I think you're missing the point. An object and child hierarchy is too high level for what I'm suggesting. Just expose the graphics library and let the programmers handle the rest. If you want something hierarchical that's simple and efficient to move an object and all its children around, great. You write that for your applications. Make it into a framework if others want to use it. But if somebody wants to use a di…

Well, I'm all for a low level approach. But going a little higher allows the GPU to handle a lot of things. Or do you propose to incorporate something like CUDA/OpenCL into WASM?

Re: Bringing the web up to speed with WebAssembly

#123

Post by ern »

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?

It hasn’t got a big installed base yet[1], so it’s hard to justify the investment. Also, remember that experience with Applets/Flash/Silverlight has burned developers, and probably made them fearful. I expect that once a big player makes a move, momentum will build.

[1]https://caniuse.com/#search=Wasm

Re: Bringing the web up to speed with WebAssembly

#124

Post by kuschku »

jfbastien wrote: post #101
AnIdiotOnTheNet wrote: post #61

Earlier quoted context omitted.

And how long do you think that'll last? As developers stubbornly persist in trying to make desktop applications on the web, they'll demand more and more access to the host, and browser developers will give it to them in an effort to one-up each other. If anyone had actually cared about security on the web we wouldn't be where we are now.

Your phrasing leads me to believe that you distrust how web standards organizations approve new features? If that's not the case then I invite you to join the W3C Community Group and help avoid insecure additions w3.org/community/webassembly/

That doesn’t help, as the browser vendors ignore the W3C entirely anyway, and just do stuff in the WHATWG.

And we already have a bluetooth stack for the web, USB drivers in JS, etc.

Re: Bringing the web up to speed with WebAssembly

#125

Post by Asdfbla »

Really interesting paper. When I first heard about what WebAssembly was trying to achieve, I naively wondered why people didn't just slap some existing interpreter for bytecode into browsers (JVM, .NET, maybe even adapt LLVM?) and go with that. I knew people had been burned by Java applets, but I was still curious why they invented something new again instead of possibly adapting existing stuff.

Of course I accepted that they surely had some good reasons for doing it the way they did, but the paper has some interesting specific points in favor of the Webassembly and against existing stuff like the JVM (easier verification of the bytecode etc.).

Re: Bringing the web up to speed with WebAssembly

#126

Post by goatlover »

marcosdumay wrote: post #36
RubenSandwich wrote: post #31

Earlier quoted context omitted.

I hope not as HTML has accessibility built in while canvas doesn’t. No need to take a step backwards on this. I’m okay with rendering to canvas but long as accessibility is taken into account. (Hint: most of the time it is not.)

HTML is also much a more convenient encoding for content than writing on the canvas. It's fully declarative¹ and everything. Yet, plenty of people already prefer to send you a black page and manually write everything on the DOM's document. I certainly do not understand them, but they are way too common. 1 - You just write your content, and it's there. There isn't more declarative than that.

HTML isn't great for application code. That's the issue, and anyone targeting WASM and canvas would be looking to recreate desktop apps on the web, not traditional websites.

Re: Bringing the web up to speed with WebAssembly

#127

Post by [deleted] »

Rusky wrote: post #116
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 coro…

[deleted]

Re: Bringing the web up to speed with WebAssembly

#128

Post by dikaiosune »

Rusky wrote: post #115
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.

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.

Re: Bringing the web up to speed with WebAssembly

#129

Post by jfbastien »

kuschku wrote: post #124
jfbastien wrote: post #101

Earlier quoted context omitted.

Your phrasing leads me to believe that you distrust how web standards organizations approve new features? If that's not the case then I invite you to join the W3C Community Group and help avoid insecure additions w3.org/community/webassembly/

That doesn’t help, as the browser vendors ignore the W3C entirely anyway, and just do stuff in the WHATWG. And we already have a bluetooth stack for the web, USB drivers in JS, etc.

That is entirely incorrect for the WebAssembly CG and WG.

Re: Bringing the web up to speed with WebAssembly

#130

Post by krallja »

dang wrote: post #66

Url changed from https://blog.acolyer.org/2017/09/18/bringing-the-web-up-to-s... , which points to this. acolyer.org's glosses on papers are excellent and I like reading them myself, but sometimes it's a bit of a struggle knowing where to situate them on HN given the original source rule ( https://news.ycombinator.com/newsguidelines.html ). Edit: changed my mind. Like I said, a bit of a struggle.

I think you made a good choice: acolyer.org posts provide enough additional analysis, comparisons to previous posts, and meta-commentary to stand on their own.
Post reply on HN