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

Making WebAssembly a first-class language on the Web

hacks.mozilla.org

Post reply on HN
Print view View original

271–280 of 287 posts

Re: Making WebAssembly a first-class language on the Web

#271

Post by tzs »

u1hcw9nx wrote: post #266
tzs wrote: post #258

Earlier quoted context omitted.

The early 2000s were too early for that for Java. Before Java 6 in 2006 JVM wasn't a good target for dynamically typed languages. In Java 6 they added some support but it wasn't very efficient. In 2008 they started serious work on fixing this, and that work went into Java 7 in 2011. The .NET CLR on the other hand was designed from the start to be a good target for all types of language and was superior to JVM at this…

Before 2006 there was very little demand for dynamically typed languages. So it was not an issue. Dynamic typing was even accepted thing for general purpose programming. It was just a curiosity. It's strange how mainstream programmers are always stuck into fads and superstition.

There was very little demand for Perl, PHP, Python, Ruby, and JavaScript before 2006?

Re: Making WebAssembly a first-class language on the Web

#272

Post by bvisness »

bloppe wrote: post #257
davexunit wrote: post #47

Earlier quoted context omitted.

I am excited by the prospect of booting Wasm binaries without any JS glue, but when I've looked at the documentation for the component model and WIT it says that resources are references passed using a borrow checking model. That would be a serious downgrade compared to the GC-managed reference passing I can do today with Wasm GC. Do you know if there are any plans to resolve this mismatch?

Relevant: https://github.com/WebAssembly/component-model/issues/525 In my experience people are often disappointed by the shared-nothing architecture of the component model. I guess that shared-nothing architecture makes it impossible to properly share GC objects across component boundaries. But they can still be shared across core module boundaries.

A lot of the time I think you just won’t want to use multiple components. It’s nice to be able to compose them together, I guess, but in general it seems to me that a toolchain will typically just want to generate a single big component so that everything can interact without limits internally.

Re: Making WebAssembly a first-class language on the Web

#273

Post by bvisness »

NohatCoder wrote: post #241
steve_adams_86 wrote: post #11

The WASM cliff is very real. Every time I go to use it, because of the complexity of the tool chain and process of going from zero to anything at all, I feel like I'm already paying a cognitive tax. I worry that I should update my tooling, look into the latest and greatest, understand the tooling better, etc... It would be incredible to see that improved. The difference in perf without glue is crazy. But not surprisi…

The whole WASM thing just went sideways from the start. It feels like the property of being practically unreadable and unwritable for humans was a design criterium, it is certainly the primary "feature" enabled by the stack approach. Then there is the single array of memory that makes modern memory allocators not really work, resulting in every WASM compiler scrounging up something that mashes the assumptions of the…

The “single array of memory” is not the problem; that’s what all these languages already expect. The problem is the lack of meaningful memory APIs, e.g. virtual memory capabilities. I am co-champion of a proposal to fix this but have not been able to prioritize it for a while, unfortunately: https://github.com/WebAssembly/memory-control/blob/main/prop...

Re: Making WebAssembly a first-class language on the Web

#274

Post by bvisness »

TheLNL wrote: post #245
zeratax wrote: post #207

Earlier quoted context omitted.

I don't follow? when you write userscripts you modify the dom not the already running scripts usually, no?

Wouldn't there be a point where the mainstream approach is to just have compiled blobs write directly to the canvas, say a point where someone compiles a qt application and hosts it on their website. What can you even modify there, when all the structure is flattened into a single layer

You can already make apps that write directly to a canvas today, and almost nobody does because they want what the DOM provides for them. Wasm changes nothing about the APIs available to web apps.

Re: Making WebAssembly a first-class language on the Web

#275

Post by troad »

leptons wrote: post #270
troad wrote: post #261

Earlier quoted context omitted.

> Web Bluetooth, Web NFC These are things that literally everyone but Google thinks are terrible ideas. Why don't you flip the conspiracy around and ask yourself why Google, the world's largest advertising agency and data hoover, wants browsers, a category dominated by Google, to have unmediated access to ever more user, system, and local network data?

That's nonsense. There's plenty of people that want those APIs that don't work at Google. And it does not give Google "unmediated access" - you have to explicitly opt-in to allow the browser to use them when a website requests access to these APIs. But of course, don't let the facts get in the way of your fanboyism for Apple.

And when it's normalised for firmware updates to happen via WebHID and WebUSB? Saying no will seem as fringe as browsing the web with NoScript. It's already the main way to upgrade keyboard firmware for a lot of mechanical keyboards, and it only works on Chrome. Thrilling developments for Google.

>> But of course, don't let the facts get in the way of your fanboyism for Apple.

Mate, I didn't even mention Apple. You're the one with the fixation here. Mozilla/Firefox is also deeply opposed to these anti-features.

Re: Making WebAssembly a first-class language on the Web

#276

Post by pmkary »

fzzzy wrote: post #218
pmkary wrote: post #216

Not only are they a decade late while everyone expected WASM to liberate us from JS, and it ended up being a useless toy in JS whose improvements would have been crushed by having to send all progress to JS to apply it, but then giving it access to DOM is also something you'll realize wasn't enough a decade later. Flutter doesn't need DOM; it has all of its own engine. The browser should give the whole viewpoint to t…

And it would be 100% inaccessible.

Basically this has been the only way to stop anything from happening. But major systems all have accessibility like web and if someone wants to support accessibility they will do it there. Those who don't, won't even do it on web. If something like I say happens, not only accessibility will be lost, but so much more will be lost too. But then if you need it you'll either implement it or use web. Figma, SketchUp, and Google Docs have their software rendered on a canvas. For them this would have made things much faster. It is giving people options. Personally I hate web. It is horrible to write software by manipulating DOM and having to work with CSS. Every time I touch html/js/css I think why can't it be a nice system? Why I have no control over rendering? At least I would have loved to have an alternative the whole web and dom, and would have killed for writing web pages like a flutter app.

Re: Making WebAssembly a first-class language on the Web

#277

Post by leptons »

troad wrote: post #275
leptons wrote: post #270

Earlier quoted context omitted.

That's nonsense. There's plenty of people that want those APIs that don't work at Google. And it does not give Google "unmediated access" - you have to explicitly opt-in to allow the browser to use them when a website requests access to these APIs. But of course, don't let the facts get in the way of your fanboyism for Apple.

And when it's normalised for firmware updates to happen via WebHID and WebUSB? Saying no will seem as fringe as browsing the web with NoScript. It's already the main way to upgrade keyboard firmware for a lot of mechanical keyboards, and it only works on Chrome. Thrilling developments for Google. >> But of course, don't let the facts get in the way of your fanboyism for Apple. Mate, I didn't even mention Apple. You'r…

>Mozilla/Firefox is also deeply opposed to these anti-features.

Mozilla is irrelevant, and they don't have a hardware platform where they forbid all other browser engines from it like Apple does.

If Apple weren't total assholes and didn't forbid Chrome from actually being Chrome on iOS, then I wouldn't care, I'd simply tell users to install Chrome. But Apple forces all browsers on iOS to use Safari, which they have intentionally crippled and refuse to let other browsers use their own engine.

If you don't think that's abusive business practices and deserves the DOJ lawsuit, then you're just another Apple shill.

Re: Making WebAssembly a first-class language on the Web

#278

Post by troad »

leptons wrote: post #277
troad wrote: post #275

Earlier quoted context omitted.

And when it's normalised for firmware updates to happen via WebHID and WebUSB? Saying no will seem as fringe as browsing the web with NoScript. It's already the main way to upgrade keyboard firmware for a lot of mechanical keyboards, and it only works on Chrome. Thrilling developments for Google. >> But of course, don't let the facts get in the way of your fanboyism for Apple. Mate, I didn't even mention Apple. You'r…

>Mozilla/Firefox is also deeply opposed to these anti-features. Mozilla is irrelevant, and they don't have a hardware platform where they forbid all other browser engines from it like Apple does. If Apple weren't total assholes and didn't forbid Chrome from actually being Chrome on iOS, then I wouldn't care, I'd simply tell users to install Chrome. But Apple forces all browsers on iOS to use Safari , which they have…

>> Mozilla is irrelevant, and they don't have a hardware platform where they forbid all other browser engines from it like Apple does.

>> If Apple weren't total assholes

>> Apple forces all browsers on iOS to use Safari

>> you're just another Apple shill.

I've still not even mentioned Apple once.

You seem extremely fixated on Apple.

I'm not aware of any major corporation, group, standards body, or OSS project that would agree with Google's attempts to extend the browser so deeply beyond the web. The general consensus is that it is deeply reckless.

Google failed to get stuff like WebHID into the standard - because everyone thinks it's a terrible idea - so they've just rolled it out on their own anyway, using their browser monopoly to force facts on the ground. Facts favourable to Google, unsurprisingly.

When Microsoft did this sort of thing, we used to call them out on it. I have no idea why you seem so adamant to defend this. I can only suspect that you've let yourself become completely partisan in some grand Google-Apple war that you've imagined, which is why you keep bringing up Apple out of nowhere?

Re: Making WebAssembly a first-class language on the Web

#279

Post by lyu07282 »

troad wrote: post #278
leptons wrote: post #277

Earlier quoted context omitted.

>Mozilla/Firefox is also deeply opposed to these anti-features. Mozilla is irrelevant, and they don't have a hardware platform where they forbid all other browser engines from it like Apple does. If Apple weren't total assholes and didn't forbid Chrome from actually being Chrome on iOS, then I wouldn't care, I'd simply tell users to install Chrome. But Apple forces all browsers on iOS to use Safari , which they have…

>> Mozilla is irrelevant, and they don't have a hardware platform where they forbid all other browser engines from it like Apple does. >> If Apple weren't total assholes >> Apple forces all browsers on iOS to use Safari >> you're just another Apple shill. I've still not even mentioned Apple once. You seem extremely fixated on Apple. I'm not aware of any major corporation, group, standards body, or OSS project that wo…

You are missing the initial point here, the accusation is that apple doesn't want the web as a viable platform to develop fully fledged cross platform applications that circumvent its own moat. You just repeat the maximalist position that the web shouldn't "extend the browser so deeply beyond the web". Many people disagree with that, its the best shot we have for true cross platform applications that would force Apple to open their platform, we say the reason apple doesn't want that is for purely profit driven reasons.

Also doesn't this argument apply to WebAssembly and other standards (like WebGPU) as well? Why should I be able to render a video game in the browser but have no way to manage input devices (like multiple controllers) to make it a suitable platform for fully-fledged video games in the future? Like I understand why Apple (OR Microsoft for that matter) doesn't want Stadia-like services to suddenly run on all their devices without any cut in monetization, so naturally they sabotage such efforts in Safari...

Like here is my own reason to support that effort: I use Linux, and there are a ton of proprietary applications that if there were developed on the web platform would become accessible to me.

I understand the privacy concerns with some of those APIs, but the argument isn't that the user shouldn't have agency over those features, do you see how that's a separate conversation?

So now: Why are you against it?

Re: Making WebAssembly a first-class language on the Web

#280

Post by laughinghan »

flohofwoe wrote: post #199
laughinghan wrote: post #192

Earlier quoted context omitted.

You seem to be implying that these goals were optional, but I don’t understand how #2 cross-lang interop could ever have been optional. Isn’t running non-JS languages the entire point of WebAssembly? Given that, do you really think goal #1 non-Web APIs really added much additional delay on top of the delay necessitated by goal #2 anyway?

> but I don’t understand how #2 cross-lang interop could ever have been optional This problem hasn't been solved outside the web either (at least not to the satisfaction of Rust fanboys who expect that they can tunnel their high level stdlib types directly to other languages - while conveniently ignoring that other languages have completely different semantics and very little overlap with the Rust stdlib). At the cor…

The WIT types don’t seem random or Rust-centric to me, they’re basic types common to every major current-generation language, not just Rust but also Swift, Kotlin, even Zig. It’s true that languages with type designs from the 90s can’t take full advantage of WIT types, but WIT does seem perfectly capable of representing types from older languages, which seems like the only possible sensible design to me—older languages are supported, but that support needn’t burden interop between modern languages.
Post reply on HN