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

Pay attention to WebAssembly

harshal.sheth.io

Post reply on HN
Print view View original

121–130 of 251 posts

Re: Pay attention to WebAssembly

#121

Post by charcircuit »

pie_flavor wrote: post #113
SquibblesRedux wrote: post #83

Reading the article, I felt like I was back in 1996 reading about the Java bytecode compiler and the JVM plugin for the browser. Java had such great promise for web page-hosted code, that would be portable, performant, and safe. Why would one think WebAssembly will succeed where Java failed? (Well, Java did not exactly fail, but its purpose and typical usage radically changed over the years.)

Java failed because - it depended on an installation outside the browser, poorly versioned - and a plugin too, which was extra noise for the user, and not nearly so pain-free as Flash's was - it was not , under any circumstances, performant (this was before HotSpot) - AWT was truly, thoroughly, god awful (this was before Swing) Finally, it was caught between two realms. Clunkier than JS and more difficult to work wit…

>- it was not, under any circumstances, performant

It was performant enough for one of the most popular games of all time, Minecraft, which was originally a game in a Java applet.

Re: Pay attention to WebAssembly

#122

Post by RantyDave »

mdasen wrote: post #81
fancyfredbot wrote: post #5

WebAssembly is full of potential. But so are Java bytecode, SPIR and various others. Why will WebAssembly take off where these haven't?

I think what makes thing succeed or not can be subtle (and therefore it's easy to disagree with). Ultimately, I think WASM will succeed because it's a uniting force among communities. Rust people are behind it, Microsoft and C#/.NET are behind it, people in the Go, Python, and other communities are behind it, and the browser vendors are behind it. Java applets were things that were slow to load and didn't interface w…

Java applets downloaded over 56k and were run (not jit'ed) on pentium 2's. In other words if we took Java, replaced the standard library with an interface onto the browser, would we not end up with exactly the same thing? They're even both stack machines.

Happy to support an argument that removing Oracle's influence is worth reinventing an entire runtime for.

Re: Pay attention to WebAssembly

#123

Post by RantyDave »

hankman86 wrote: post #28
anonporridge wrote: post #11

Earlier quoted context omitted.

Not owned by shit for brains Oracle.

Neither was Java at the time when browsers had support Java applets. At a closer look, Java Applets suffered from much of the same problems that plague WebAssembly. Like the inability of interact with the DOM (or other browser APIs) without calling out to JavaScript. Or the fact that you had to split up the code on your side into a JavaScript part (these days, perhaps transpiled from Typescript) and a part that was J…

Java also didn't have to face the fact that, now, Javascript runtimes are really good. There's not that much between Javascript and WASM ... and JS can access the DOM.

Re: Pay attention to WebAssembly

#124

Post by adrianN »

cogman10 wrote: post #58
Jasper_ wrote: post #36

Earlier quoted context omitted.

I have low faith in the current WebAssembly GC proposal. It's been such a daunting task that they've started talking about "mini-mini MVPs". The GC proposal does not do what most people think it does, the current draft is basically impossible for most languages to target, and even contributors are finding it difficult to reach consensus [0]. It might be a while before it becomes useful. [0] https://github.com/WebAsse…

This is the most concerning thing I have about the web in general. It feels like nothing is getting done because everyone is fighting with everyone else about everything. I feel like WASM has just sort of rotted. It feels like so many advancements from threads to GC have been stuck in committee for years now. I feel the same way about WebGPU. Just doesn't feel like anything is getting done when it comes to new comput…

Everyone fighting with everyone else is how every standard is made. Standards evolving slowly is generally a good thing, because it gives people time to understand each standard and learn something before the next standard is designed.

Re: Pay attention to WebAssembly

#125

Post by chubot »

deathanatos wrote: post #53
chubot wrote: post #23

Cross-language interactions suck. We need WebAssembly components and good code generators for a critical mass of languages before people actually start to use Wasm across different languages. Unpopular opinion: Users will eventually realize that the lowest common denominator between languages is ... a BYTE STREAM (e.g. JSON/CSV/HTML), or what I think of as shell / Unix / Web -style composition. IDLs and code generato…

> e.g. Protobufs are very good for C++ C++ communication, but Java and Python users seem to dislike them equally, and even Go users do too. Well, hilariously, when I looked at using it on a project, JSON outperformed protobuf in Python. JSON is implemented in C, Protobuf in Python, and the C decoder for a less efficient format won out. (Now, technically, Protobuf has a C implementation, but at the time I was testing,…

Yup, it is crazy how much optimization these "narrow waist" formats get, and it goes even further with simdjson and so forth [1].

The Python protobuf implementation has a somewhat checkered history (I used protobuf v1 and v2 for a long time, and reviewed v3 a tiny bit).

The type system issue is that protobufs to a large extent "replace" your language's types. It's essentially language-independent type. So that means you are limited to a lowest common denominator, and you have the issues of "winners" and "losers"... I would call Python somewhat of a "loser" in the protobuf world, i.e. it feels more second class and is more of a compromise.

This doesn't mean that anybody did a bad job; it's just a fundamental issue with such IDLs. In contrast, JSON/XML/CSV are "data-first" and there are multiple ways of using them and parsing them. You can lazily parse all of them, DOM and SAX, for example, and you have push and pull parsers, etc. Protobufs have grown some of that but it wasn't the primary usage, and many people don't know about it.

[1] https://github.com/simdjson/simdjson

Re: Pay attention to WebAssembly

#126

Post by jturpin »

maga wrote: post #96
chrismorgan wrote: post #87

Earlier quoted context omitted.

You’re still missing much the point of the article: WASM isn’t for the browser only . WASI, for example, is a full environment you can run stuff in without any such interoperability cost. But even inside something like Node.js or the browser, most of these sorts of benchmark attempts are of converting only small parts of a system, so that message passing or format shifting ends up a comparatively large fraction of th…

> You’re still missing much the point of the article: WASM isn’t for the browser only. WASI, for example, is a full environment you can run stuff in without any such interoperability cost. Of course, but we are not arguing about the point of the article, I'm contesting the exact claim that "WebAssembly is almost always faster than JavaScript". Admittedly, not because it's such a big mistake on the author's part, but…

> I'm a bit irate with the usual flow of discussions about WebAssembly here on HN that take this claim for granted and regurgitate it incessantly.

It is still more honest to regurgitate the claim that Wasm is faster than JS than to try and argue that "JS is about 10x faster than wasm in simple linear regression."

Re: Pay attention to WebAssembly

#127

Post by pie_flavor »

charcircuit wrote: post #121
pie_flavor wrote: post #113

Earlier quoted context omitted.

Java failed because - it depended on an installation outside the browser, poorly versioned - and a plugin too, which was extra noise for the user, and not nearly so pain-free as Flash's was - it was not , under any circumstances, performant (this was before HotSpot) - AWT was truly, thoroughly, god awful (this was before Swing) Finally, it was caught between two realms. Clunkier than JS and more difficult to work wit…

>- it was not, under any circumstances, performant It was performant enough for one of the most popular games of all time, Minecraft, which was originally a game in a Java applet.

Minecraft was started in 2009. Applets were one of Java's flagship features, i.e. released well before the VM became in a performant enough state.

Re: Pay attention to WebAssembly

#128

Post by fsloth »

evmar wrote: post #120
Ecco wrote: post #109

Earlier quoted context omitted.

What do you mean by GPU code? Do you mean some code that calls WebGL?

Yes, sorry! I should've written GL, not GPU, but it's too late to edit it to fix. ...though there are some shaders involved.

FWIW I think GPU is fine as Webgl is the only api browser can use before Webgpu takes off.

Re: Pay attention to WebAssembly

#129

Post by echelon »

astlouis44 wrote: post #85
jackothy wrote: post #84

Earlier quoted context omitted.

Some advantages that Steam will still have: 1. Steam provides a system for user accounts and profiles 2. Steam handles payment securely for both buyers and sellers 3. Steam handles social networks/friend list/multiplayer 4. Steam allows you to have all your games in one place 5. Steam is a platform for reviews 6. Steam has its own internal economy/marketplace

What’s your point? All of that can be done on the web, besides it isn’t really targeting the Steam audience at the end of the day. Think the mobile audience, but on the web. You can do a Sims or PUBG in HTML5 today, and all that’s required is a hyperlink to share it with others. Same strategy that made Wordle go viral and get acquired today for over $1M.

> What’s your point?

Why you expect your Unreal-to-WASM product to succeed when Epic Games can simply build your entire product as a feature of the engine? You are building on their platform and not an open web stack, after all.

Despite having an open web, most people have elected to use platforms. At some point, people will defer revenue for simplicity.

Re: Pay attention to WebAssembly

#130

Post by hectaman »

MR4D wrote: post #119
hectaman wrote: post #13

Earlier quoted context omitted.

This is Liam, co-founder of wasmCloud, founder of Cosmonic, and co-chair of the CNCF Cloud Native Wasm Day. I don't think this is actually as crazy as it sounds - when we designed the messaging around CNCF, container, and WebAssembly we deliberately went with a better together story. Why? In a large enterprises you have huge systems that each represent a variety of concerns - security, compliance, governance, reputat…

Thanks for the comment, Liam. In honesty, I was only thinking about the simple security use cases, but your comment makes it obvious that this will become a huge marketplace very quickly. You are clearly much closer to the puck than I am !

Hey, it's a gigantic tent and their is room for all kinds of approaches. wasm and wasmCloud both work great on their own and can go to a lot of places that k8s can't - non Linux OS's and places where we don't even think in terms of process (ie the browser).

WebAssembly really gives us two degrees of portability: 1. CPU / OS / Execution portability; as standard way to package code. 2. A deny by default _security_ model that works the same across all of these different platforms.

Post reply on HN