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

141–150 of 207 posts

Re: WebAssembly’s post-MVP future

#141

Post by jholman »

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?

You might similarly ask why app stores on iOS and Android are such a big deal, and why Steam is even a thing.

It's because deployment is a harder problem than development (at least, it's harder for developers, because deployment is a social problem). The web is a pretty poor development target (though it keeps getting better), but it's a damn terrific deployment medium, and that's a winning tradeoff.

Re: WebAssembly’s post-MVP future

#142

Post by pseudalopex »

edflsafoiewq wrote: post #70
marcosdumay wrote: post #34

Earlier quoted context omitted.

> Wasm isn't really for pretty apps you can quickly make in Vue. Why not? Developing pretty apps in Vue (or anything in JS-land) is an horrible experience, why shouldn't we use WASM to port some better environment into there?

If there's some better environment to be found in non-JS-land, why is Electron and its ilk so popular?

Electron is popular among developers who mainly know JavaScript. It's popular when someone already has a web app or has to build one anyway. It's popular among people who think it's better for their app to look the same on every platform than to integrate well. It seems to be pretty unpopular among people who have experience writing native apps.

Re: WebAssembly’s post-MVP future

#143

Post by jholman »

azernik wrote: post #139
jholman wrote: post #17

Okay, I've only done the over-breakfast skim of this, and I hate to be that guy who comments without having fully read TFA, but here I go anyway... I don't see any explicit mention of what I understand to be the killer feature: the ability to directly access the browser's WebAPIs, from Accelerometer to Document to MimeType to XPathExpression. Start with modifying the DOM, and go from there. Of course fast WASM/JS int…

Native support for WebAPIs is blocked on garbage collection - WASM code will need to claim a reference to garbage-collected DOM/JS objects, and will need to be able to hand off GCed objects and callbacks to JS APIs.

Yes, we know that, and I even said that in my comment, which I'm sure you read.

But many things that were discussed in TFA are blocked on other things that were discussed, and yet still got hundreds of words of article space.

Re: WebAssembly’s post-MVP future

#144

Post by azernik »

jholman wrote: post #143
azernik wrote: post #139

Earlier quoted context omitted.

Native support for WebAPIs is blocked on garbage collection - WASM code will need to claim a reference to garbage-collected DOM/JS objects, and will need to be able to hand off GCed objects and callbacks to JS APIs.

Yes, we know that, and I even said that in my comment, which I'm sure you read. But many things that were discussed in TFA are blocked on other things that were discussed, and yet still got hundreds of words of article space.

GC is listed under a section "Small modules interoperating with JavaScript", which talks about general access to JavaScript code. Web APIs are a subset of that usecase.

Re: WebAssembly’s post-MVP future

#145

Post by azernik »

jholman wrote: post #17

Okay, I've only done the over-breakfast skim of this, and I hate to be that guy who comments without having fully read TFA, but here I go anyway... I don't see any explicit mention of what I understand to be the killer feature: the ability to directly access the browser's WebAPIs, from Accelerometer to Document to MimeType to XPathExpression. Start with modifying the DOM, and go from there. Of course fast WASM/JS int…

(Hoisting to top level from a comment farther down.)

The section "Small modules interoperating with JavaScript", talks about general access to JavaScript code. Web APIs are a subset of that usecase.

Re: WebAssembly’s post-MVP future

#146

Post by FascinatedBox »

mr_toad wrote: post #63
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…

> Developers need laptops to run their development environment in. Not strictly true. I spent a bit of time using Cloud 9 and found it to be quite a useable experience. It’s certainly very handy to be able to access a dev environment from web browser wherever you happen to be. https://aws.amazon.com/cloud9/

c9 helped when I was back in college. The desktops there were locked down with preinstalled tools. c9 was better than what the college had, and I didn't have to worry about saving my work. Once I was home I could sync the changes.

Re: WebAssembly’s post-MVP future

#147

Post by fbender »

tannhaeuser wrote: post #98
kllrnohj wrote: post #41

Earlier quoted context omitted.

WebASM really only makes sense in the context of embedding untrusted code, which outside of the browser is a concern that largely doesn't exist. Otherwise you are severely crippling yourself for no real gain. You're going to lag the hardware features by years if not decades, you're not going to get arch-specific optimizations as readily, and you're going to have huge startup costs. You're also stuck with sandbox rest…

In addition, WASM lacks bindings to the browser environment (or any API for that matter), as its original pitch was improving performance-critical code paths in browser apps; but like you said, it won't be able to reach native ARM ISA speeds nevertheless. At most, in a couple years, it could hope to do what JavaScript has been doing for over a decade. But the browser rendering model and WebGL will just be the same. A…

I think nobody is saying WASM is better than a „native platform API/ABI“ at solving all problems. It‘s simply a (potentially) viable alternative for scenarios that are way more common than everyone thought at first. And in some situations, it‘s the only solution (e.g. you won‘t get native APIs on the Web).

Re: WebAssembly’s post-MVP future

#148

Post by bayesian_horse »

I'm looking into building a state-management system for React with Pyodide. Yes, it might add 3mb to the downloads, but that should be acceptable. It will probably use some kind of asyncio work-alike which will use Web-Apis to perform what asyncio normally does.

Re: WebAssembly’s post-MVP future

#149

Post by pjmlp »

edflsafoiewq wrote: post #128
int_19h wrote: post #113

Earlier quoted context omitted.

Because all the better environments are not sufficiently portable. That said, even then, I'll take Qt over Electron any day of the week.

If they're not even portable between established systems, how are we going to port them to a comparatively exotic wasm+DOM target?

Because it is actually WASM + Canvas, DOM doesn't matter.

http://example.qt.io/qt-webassembly/quickcontrols2/gallery/g...

https://playground.platform.uno/

Re: WebAssembly’s post-MVP future

#150

Post by pjmlp »

eksemplar wrote: post #136
thrower123 wrote: post #107

Earlier quoted context omitted.

Every time I start doing anything moderately complicated in JS, I rage at how much more difficult it is compared to slamming together a UI in .NET.

Really because WPF, web forms or razor all seem very inferior to me than VUE or react. Hell when we were still building interfaces in .Net we paid a subscription to use Telerik on the frontend because the standard .net stuff is absolutely terrible.

Where is Blend for Vue or React?

I never used Telerik, and we only bought ComponentOne once for a Windows Forms project, started before WPF even existed.

Post reply on HN