Live data from Hacker News

WebAssembly’s post-MVP future

hacks.mozilla.org

131–140 of 207 posts

Re: WebAssembly’s post-MVP future

#131

Maybe a stupid question but why does the browser itself need to do compilation? Why can’t WebAssembly developers compile ahead of time and just serve the binary?

Because they don't know what they're compiling to. The browser could be running in a wide variety of hardware.

Right, seems obvious now, thanks

Re: WebAssembly’s post-MVP future

#132
post #49

I'm a bit concerned by the addition of Garbage Collection to WASM. Is there a way to implement those without favouring some type of language? It seems to me that GC tuning and memory models are very language-specific. A purely-functional language like Haskell or Closure can make different assumptions about the memory regions but also generate a lot more young generation items compared to OOP languages.

Aren’t they adding gc to node.js/js or some part (I read somewhere) and/or multithreading/parallel processing? Not really me, but it seems the market is demanding that functionality if it’s coming up?

Re: WebAssembly’s post-MVP future

#133

Earlier quoted context omitted.

I work with some people who are working on Iodide [1] which is a Jupyter style notebook thing that runs entirely in the browser, they've already ported Python to WebAssembly [2][3] so you can use it as a language. [1] https://iodide.io/ [2] https://github.com/iodide-project/pyodide [3] https://iodide.io/iodide-examples/python.html

Nice. I've been watching efforts to port Lua to WebAssembly (the official VM looks simple enough, but luajit won't be easy) because I want to have an app that shares code with the browser, and it would be awesome to play with WebAssembly as the plugin system of choice on the backend. I'm also super excited for nebulet[1], which is a micro-kernel experiment using WebAssembly in Ring 0, which is pretty neat. I'm really…

> I'm really excited to see where WebAssembly can go. I know many of these projects will peter out, but it's exciting nonetheless.

Absolutely. On the Lua front someone made a PoC to add Lua as a language for Iodide [1] using Fengari [2] which (while I haven't used it yet) definitely looks interesting. Hadn't heard of Nebulet before but will definitely be following it now. Cheers!

[1] https://groups.google.com/d/msg/iodide-dev/ahc4fg8_JLg/llkHS... [2] https://fengari.io/

Re: WebAssembly’s post-MVP future

#134

Earlier quoted context omitted.

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

"better environment" - worse is better. Its explained in the comment above you about entrenched interests. Whether js and html are worse in the browser is one thing but I think you could argue strongly that they are worse on the desktop. As a user, the experience for me is pretty bad.

Is electron really worse though? I use VS and VSC professionally and VSC is the best ide I’ve ever used.

VS is great too, but it’s performance is really, really, terrible when your documents and settings directory is on one network drive and your codebase is on another. Not exactly VS’s fault, but it’s an ide for enterprise that can’t function with the most basic enterprise drive setup?

VSC, the electron app on the other hand doesn’t give two shits.

People usually tell me VSC is the one off unicorn. But isn’t discord better than team speak and ventrilo? Isn’t slack excellent?

I don’t think sunk cost is a negative when people are building better tools with it.

Re: WebAssembly’s post-MVP future

#135

Earlier quoted context omitted.

Yes.

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.

Re: WebAssembly’s post-MVP future

#136

Earlier quoted context omitted.

Meh, the issue with Electron is performance. The actual dev environment is decent, like how trivial it is to bring your own abstractions like React. Being able to inspect element and use Chrome's debugger. Being able to use whatever text editor you want. Using a compile-to-JS language. etc. I'm certainly not using Xcode + Cocoa + the MVC abstraction for iOS/macOS apps because it's the superior way to build software.…

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.

Re: WebAssembly’s post-MVP future

#137
post #80

Earlier quoted context omitted.

Because many don't know any better.

Meh, the issue with Electron is performance. The actual dev environment is decent, like how trivial it is to bring your own abstractions like React. Being able to inspect element and use Chrome's debugger. Being able to use whatever text editor you want. Using a compile-to-JS language. etc. I'm certainly not using Xcode + Cocoa + the MVC abstraction for iOS/macOS apps because it's the superior way to build software.…

I do native across multiple platforms and Web, being coding since the mid-80's, so the experience is not constrained to a single pet.

Re: WebAssembly’s post-MVP future

#138
post #132
post #49

I'm a bit concerned by the addition of Garbage Collection to WASM. Is there a way to implement those without favouring some type of language? It seems to me that GC tuning and memory models are very language-specific. A purely-functional language like Haskell or Closure can make different assumptions about the memory regions but also generate a lot more young generation items compared to OOP languages.

Aren’t they adding gc to node.js/js or some part (I read somewhere) and/or multithreading/parallel processing? Not really me, but it seems the market is demanding that functionality if it’s coming up?

JavaScript has always had garbage collection; it's a dynamic scripting language with no support for manual memory management.

Re: WebAssembly’s post-MVP future

#139
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.

Re: WebAssembly’s post-MVP future

#140

Earlier quoted context omitted.

Wasm isn't really for pretty apps you can quickly make in Vue. It's more for those heavy duty apps, games or libraries that most people run natively because of performance and because they're written in languages like C++, Rust, or even Fortran (scientific computing libraries). Also, JS isn't the best tool for all programs, and programmers would like more of a choice when it comes to things that are more than just yo…

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

I don’t think it’s horrible, could you point me to something better?

We used to work with, first WPF then web forms and later MVC with razor, and we very quickly bought Telerik because the standard UI components in .Net are horrible.

Aside from that I’ve worked with JAVA I can’t recall what we used before FX but both were terrible.

In the JS CSS environment I can literally make an interface that doesn’t look like ass by simply using the standard setup in a front end with very few lines of code.

I guess a think like Blazor.net might make wasm competitive, but unlike JS, that requires Microsoft not to drop it in a year because they don’t have the OS movement JS does.

I understand why people dislike the package he’ll of modern JS, but so far, it’s proven itself to be just as trustworthy as any curated library.

On the other hand you’re not tied down in JS. When Microsoft made entity they wanted people to use it, even though it’s fucking awful. In JS you can very easily replace a component if something better comes along. That’s a great strength.

Graphql has been really instrumental for us for instance. We operate apps in low connective environments, so being able to only transfer what is needed is really great.

Graphql isn’t JS only, but it takes very little time and effort to setup an Apollo, graphql and vue app, and it’s got very few issues. The .Net integration of graphql is still a 3rd party library that doesn’t really work that well and isn’t easy to use.

That’s the thing with JS, it’s just really productive in the real world.

Blazor.net looks really productive, but it’s only productive when you don’t need it to do something Microsoft hasn’t thought of, and it’s the only WASM integration that I’ve seen that is even remotely competitive with JS.

Post reply on HN