Live data from Hacker News

WebAssembly’s post-MVP future

hacks.mozilla.org

151–160 of 207 posts

Re: WebAssembly’s post-MVP future

#151

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.

WinForms or WPF? I can throw together a (terrible) HTML page faster than I can remember how MVVM is meant to work.

MVVM is meant to work the same way as Angular bindings work.

In any case you aren't obliged to use MVVM in WPF, it is just a best practice for easier unit testing and composability. Then again Web Components are only now starting to be a thing.

Re: WebAssembly’s post-MVP future

#152

Earlier quoted context omitted.

I’m not impressed by wasm yet. One of the reasons JS is so good is because it can manipulate data without doing a full page reload, and wasm will do that, but another important reason is how productive modern JS is. I’m not a UXer, never was, and I moved into management long before programs even got pretty so I’ve never even had to pick up. Yet I can make a pretty web application with vue with minimal efforts. Add st…

> another important reason is how productive modern JS is Some people will argue on this, but I'm actually in agreement. That said, it is important to realize WHY the JS productivity is so important: We're iterating a LOT. Web is so young, web interfaces are so young, the problems we are trying to solve on web are ever changing, and the devices we use to interface with web are changing almost as fast. We have to iter…

I was iterating a lot with Smalltalk, Caml Light, Prolog, Oberon, Delphi and C++ Builder during the 90's.

Re: WebAssembly’s post-MVP future

#153

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…

Why is it such a bad thing for a browser to act as an OS?

Re: WebAssembly’s post-MVP future

#154
post #116

Earlier quoted context omitted.

Because it effectively solves the distribution problem in a way which includes non-technical people. If you think your solution does that, meditate on what "non-technical" means.

Having the URL system also makes them so much better for sharing. Imagine being able to share a link that someone could click and it would open up your shared image inside of photoshop.

Android, iOS and UWP do that with deep links.

Re: WebAssembly’s post-MVP future

#155
post #117

Earlier quoted context omitted.

You can access web APIs and access DOM in wasm today (from your comment you seem to be unware of that?). I just wrote a tiny web app in Rust with wasm-bindgen, and it’s pretty good already. With wasm-bindgen interfacing is pretty manual at the moment — you need to declare the APIs you need in Rust by hand, but an app without dependencies that modify the DOM generates a wasm file that’s only a few KB. My app pulls in…

I know wasm-bindgen exists, and I presume it works. But it's black magic. Near as I can tell, it serializes everything through the linear memory; this would have a huge impact on the performance of both ends, would it not? (Particularly if you wanted to do DOM manip w/ it.) I believe this is what the article means here, > You need to pass values into the WebAssembly function or return a value from it. This can also b…

I only spent about an hour on the rust + wasm app for fun, so I treated wasm-bindgen and wasm-pack as black boxes and didn't really try to understand the inner workings. You're probably right about serialization, but I'm not sure it has to copy huge buffers around.

Look, the supported types in wasm-bindgen are somewhat restricted. The full list is here [1]. Other than "atomic" types like numbers and pointers (I assume the opaque types are treated as pointers too), the interesting one are str/String (basically &[u8] under the hood) and number slices. It's apparently not great if you have to copy these around, but since these are well-aligned, why can't you just pass the starting address and length? Again, I don't know enough about wasm or its current state to say if this is doable. Maybe it doesn't like "someone else's memory" at the moment.

(By the way, wasm-bindgen allows you to access pub fields of structs from JS, but they have to be Copy. That is to say, the opaque types are not completely opaque, but I'm not sure if the pub field access is achieved through implicit getter methods or serialized in the first place.)

Anyway, the frictions might be a big problem if you're doing React-style DOM re-renders all the time, but in my app, I'm only running the computation heavy and memory sensitive tasks in wasm, and communications are few and far between, making it a non-issue.

[1] https://rustwasm.github.io/wasm-bindgen/reference/types.html

Re: WebAssembly’s post-MVP future

#156
post #149

Earlier quoted context omitted.

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/

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 arms race or else extreme anti-copying measures.

Re: WebAssembly’s post-MVP future

#157
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…

Basically it is Flash all over again, just now it is built-in in the browser.

Re: WebAssembly’s post-MVP future

#158

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…

I’m not impressed by wasm yet. One of the reasons JS is so good is because it can manipulate data without doing a full page reload, and wasm will do that, but another important reason is how productive modern JS is. I’m not a UXer, never was, and I moved into management long before programs even got pretty so I’ve never even had to pick up. Yet I can make a pretty web application with vue with minimal efforts. Add st…

> I’m not impressed by wasm yet. One of the reasons JS is so good is because it can manipulate data without doing a full page reload, and wasm will do that, but another important reason is how productive modern JS is.

You don't need a jet engine to make paper airplanes. Gluing jet engines to paper airplanes would indeed be counterproductive.

> and wasm looks so ridiculously old aged before it’s even born.

Wasm is about achieving near native level performance. For libraries and such. Stuff that your pretty high level js frameworks might use.

Re: WebAssembly’s post-MVP future

#159

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.

Re: WebAssembly’s post-MVP future

#160

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…

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 what language can you just “compile 4 times” to target android, iOS, windows, linux, macos and any future platform?
Post reply on HN