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

WebAssembly’s post-MVP future

hacks.mozilla.org

Post reply on HN
Print view View original

191–200 of 207 posts

Re: WebAssembly’s post-MVP future

#191

Post by tabtab »

mwcampbell wrote: post #180
int_19h wrote: post #114

Earlier quoted context omitted.

Between WASM and modern graphics APIs, we might be able to actually kill DOM altogether. Something like this: http://blog.qt.io/blog/2018/05/22/qt-for-webassembly/

Let's not do that until we have a way to make non-DOM-based web applications accessible to screen readers and other assistive technologies.

Meta-data can be embedded to describe and categorize content. But accessibility is usually not a goal for many "office productivity" applications (per my domain-specific standards suggestion). Usage of DOM alone does not guarantee accessibility either.

As far as Qt, while it may be a good starting point, I don't think direct C++ calls is practical. Some intermediate markup or declarative language should be formed around it: a declarative wrapper around Qt.

Re: WebAssembly’s post-MVP future

#192

Post by kbenson »

fulafel wrote: post #135
colordrops wrote: post #102

Earlier quoted context omitted.

I guess I was hoping for a more informative answer. Are there at least categories of GCs, such that a VM could provide the n main GC types and most languages would be able to choose the appropriate ones? Or is GC very specific to each language?

GCs have a lot of implementation specific quirks and properties, so for example a real-time app would be better served by shipping its own tested GC implementation than giving a "short pauses please" hint to the browser API.

Given the dual needs, it might make sense to have different allocation schemes, one that uses the built-in GC, and which allows sharing/interop outside of WASM (JS, DOM, etc), and one which is entirely manual (or home-rolled GC), which does not (or makes you set a very specific set of flags which alerts the user). Without that, I'm not sure there's a way to really handle memory allocation and deallocation sanely that prevents most memory leaks.

Re: WebAssembly’s post-MVP future

#193

Post by krapp »

ConanRus wrote: post #64

This is all right and all, but I have one question: why the hell it needs to be inside of a browser? To do what exactly? I don't care about browsers, I care about applications. I don't want freaking Photoshop in my browser, because I want a browser to die. This should be a part of the OS, not a freaking browser. Give me a built-in runtime with sandboxing, a delivery method, and an AppStore. Give me next generation Ja…

It doesn't need to be inside of a browser[0], that's just going to be the most common client.

[0]https://webassembly.org/docs/non-web/

Re: WebAssembly’s post-MVP future

#194

Post by mwcampbell »

tabtab wrote: post #191
mwcampbell wrote: post #180

Earlier quoted context omitted.

Let's not do that until we have a way to make non-DOM-based web applications accessible to screen readers and other assistive technologies.

Meta-data can be embedded to describe and categorize content. But accessibility is usually not a goal for many "office productivity" applications (per my domain-specific standards suggestion). Usage of DOM alone does not guarantee accessibility either. As far as Qt, while it may be a good starting point, I don't think direct C++ calls is practical. Some intermediate markup or declarative language should be formed aro…

> accessibility is usually not a goal for many "office productivity" applications

I think I might be misunderstanding you. Are you saying accessibility is usually not a goal for the kind of applications that people need to be able to use to do their jobs?

Re: WebAssembly’s post-MVP future

#195

Post by mwcampbell »

kentonv wrote: post #101
kllrnohj wrote: post #100

Earlier quoted context omitted.

Do you really need embedded code for things like Cloudflare's workers, though? It doesn't seem like it does, seems like each worker can just be its own process using normal process isolation mechanisms. Switching to embedded untrusted code for things like that would actually make a lot of stuff a lot harder - scheduling, resource monitoring, etc... would all need to be re-invented from scratch. Is it really useful to…

Hi. Cloudflare Workers tech lead here. No, process isolation does not work for us, because it does not scale well enough. The point of Cloudflare Workers is to distribute your code across Cloudflare's entire edge network -- 154 locations and growing -- so that you can respond to requests at the closest location to your end user. We want to put every customer's code in every location, rather than forcing you to choose…

Do you see the complexity of V*'s multi-tiered JIT compiler as a security risk? Maybe a simple JS interpreter plus a simple AOT WebAssembly-to-x64 compiler would be safer.

Re: WebAssembly’s post-MVP future

#196

Post by lewisinc »

cm2187 wrote: post #159
skybrian wrote: post #12

I'm reminded a bit of Java's early days when Sun was able to create the illusion that it would take over the world. WebAssembly has had a lot of early success and its limits are hazy, but it seems like they must be out there somewhere? To speculate: On the server side, it seems like docker format has already won. Maybe cpu architecture portability doesn't matter there and x86 is good enough? Although serverless and e…

Docker is hard to use. There is still space for a simple solution to implement cross platform.

There's a learning curve, sure. I don't know if it qualifies as "hard" though - once you've figured it out it doesn't exactly get _more_ complicated.

Well, unless you add Kubernetes on top of that... then yeah, it gets... complicated.

Re: WebAssembly’s post-MVP future

#197

Post by mcl7cdm »

edflsafoiewq wrote: post #156
pjmlp wrote: post #149

Earlier quoted context omitted.

Because it is actually WASM + Canvas, DOM doesn't matter. http://example.qt.io/qt-webassembly/quickcontrols2/gallery/g... https://playground.platform.uno/

Wasm+canvas is an easier target but even if it gets us to the same difficulty as normal desktop targets, portability between normal targets is already a problem. My reaction to using the canvas instead of the DOM is very, very, very negative by the way. Webpages with fake text that is actually pixels rendered to a canvas are currently mostly restricted to dystopian notions of either the end result of the ad-blocker a…

I think the world MUST start to make/tell the difference between (web)apps and web pages. Slack does not need to be written in js/html. Skype does not need to be written in js/html. They do those in electron just to avoid having to maintain X different code bases.

Re: WebAssembly’s post-MVP future

#198

Post by Certhas »

jaipilot747 wrote: post #176
Certhas wrote: post #174

Earlier quoted context omitted.

I wouldn't be suprised with Jupyter notebooks and all that.

Wouldn't that data be held in the language's kernel? When I load a 4GB file into memory in Jupyter, the memory is allocated in the python kernel, not the browser. Although I guess your point would be valid for iodide.io which seems to run everything in the browser.

Good point.

Re: WebAssembly’s post-MVP future

#199

Post by fulafel »

sametmax wrote: post #161
justinclift wrote: post #110

On a semi-related point, TinyGo (a subset of Go for embedded devices) recently added a WebAssembly output target: https://github.com/aykevl/tinygo ) Unlike the current mainline Go's WebAssembly output (min ~2MB file size), the Wasm generated from TinyGo is practical in size. eg ~1kb for the toy examples This is all leading edge dev stuff too, so updates and improvements are happening pretty frequently. :)

Your comment just made me realized that, while using cPython => webassembly for something else than electron would be overkill, this would be kinda neat for microPython.

There seems to be some work on it: (1) https://github.com/micropython/micropython/pull/3575#issueco... (2) https://github.com/matthewelse/micropython/tree/emscripten/e...

Re: WebAssembly’s post-MVP future

#200

Post by fulafel »

bloomer wrote: post #115
dmitrygr wrote: post #106

Earlier quoted context omitted.

It is hard to imagine a tool less suited to working with multi-gigabyte data sets than JavaScript.

Yeah I'm really confused why working with 4GB+ datasets in the browser is a current need. Why does everything end up in web browsers these days? Is it only because developers aren't familiar with anything else?

Non-browser programming platfomrs terrible portability stories when your app needs many features from the platform, like accelerated graphics, networking, security etc.
Post reply on HN