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

WASM 3.0 Completed

webassembly.org

Post reply on HN
Print view View original

441–450 of 520 posts

Re: WASM 3.0 Completed

#441

Post by giancarlostoro »

pjmlp wrote: post #331
wyldfire wrote: post #265

Earlier quoted context omitted.

> ... document browser ... document reader ... I'm going to assume you're being sincere. But even the crustiest among us can recognize that the modern purpose for web browsers is not (merely) documents. Chances are, many folks on HN in the last month have booked tickets for a flight or bought a home or a car or watched a cat video using the "document browser". > If we think we need a more thoroughly virtualized machi…

We have, but not by choice, I miss my native apps, even though ChromeOS Platform pays the bills.

I have wanted to try Chrome for the longest time but I cant justify overspending (you need a lot of memory for the modern web) and not being able to install half the Linux apps I would want OOTB (out of the box is a big deal for me).

I am still shocked Google has not rubbed two brain cells together and built a serious Google ChromeOS version for developers with a real desktop environment and real access to Linux, and keeping the browser as sandboxed as they have. I would spend top dollar on such a laptop. Heck it could come with an easy way to install Android Studio, and native apps for things like Hangouts or whatever they call it now.

Re: WASM 3.0 Completed

#442

Post by flykespice »

norman784 wrote: post #391
jenadine wrote: post #354

Earlier quoted context omitted.

That's true. But without the DOM we also loose the browser native accessibility support and text interaction and so on.

I know nothing about how accessibility supports works in the browser, but could they offer a way to use the accessibility API with your custom UI rendered in WebGL/WebGPU?

There doesn't exist a way to infer the individual elements of a rendered frame in canvas because it just encodes the pixels. You can't know which pixels make up a text or button, that information is lost, unlike a DOM tree.

Re: WASM 3.0 Completed

#443

Post by davexunit »

aag wrote: post #9

Does anyone know whether the exception handling implementation supports restartable exceptions like Common Lisp's and Scheme's?

Scheme doesn't have restarts as a core concept like Common Lisp, but it does have continuations. For the Scheme implementation I worked on [0], the exception system is built on top of the continuation system. In other words, Scheme exceptions are not Wasm exceptions. However, we did find a use for Wasm exceptions in the implementation of the runtime. We realized it would be useful to mark the entry point into Scheme with a Wasm 'try' block for re-entrancy reasons. Programs might call from Scheme to JS back to Scheme and on and on. When we suspend the current continuation we throw a Wasm exception and find the correct entry point for doing our stack tomfoolery, re-throwing until we find it. I don't know if my explanation makes any sense but that's how we're using Wasm exceptions.

[0] https://spritely.institute/hoot/

Re: WASM 3.0 Completed

#444

Post by benji-york »

the_duke wrote: post #411
jsheard wrote: post #104

Earlier quoted context omitted.

The comedy option would be to use the new multi-memory feature to juggle a bunch of 32bit memories instead of a 64bit one, at the cost of your sanity.

The problem with multi-memory (and why it hasn't seen much usage, despite having been supported in many runtimes for years) is that basically no language supports distinct memory spaces. You have to rewrite everything to use WASM intrinsics to work on a specific memory.

Stray thought: the way Zig uses first-class allocators might make it interesting for doing things with multiple memories.

Re: WASM 3.0 Completed

#446

Post by scotty79 »

prewett wrote: post #259
jjcm wrote: post #12

I'm definitely excited to see 64 bit as a default part of the spec. A lot of web apps have been heavily restricted by this, in particular any online video editors. We see a bunch of restrictions due to the 32 bit cap today here at Figma. One thing I'm curious though is whether mobile devices will keep their addressable per-tab memory cap the same. It's often OS defined rather than tied to the 32 bit space.

I guess I’m just a crusty ol’ greybeard C++ developer, but it seems like a video editor is out of place in a document browser. There’s a perfectly good native operating system that nobody uses any more. If we think we need a more thoroughly virtualized machine than traditional operating system processes give us (which I think is obvious), then we should be honest and build a virtualization abstraction that is actuall…

Basically OS developer dropped the ball. Internet caught them by surprise and few decades is apparently too short for them to come up with new appealing abstractions to fit the new environment. So browser developers took over and did just that.

Same way webdevs ate desktop app dev's lunch because they had no idea how to innovate on decade old ideas.

To sum up, no matter how well you are positioned for something on paper, if you won't do it, someone else will.

Re: WASM 3.0 Completed

#447

Post by [deleted] »

wyldfire wrote: post #265
prewett wrote: post #259

Earlier quoted context omitted.

I guess I’m just a crusty ol’ greybeard C++ developer, but it seems like a video editor is out of place in a document browser. There’s a perfectly good native operating system that nobody uses any more. If we think we need a more thoroughly virtualized machine than traditional operating system processes give us (which I think is obvious), then we should be honest and build a virtualization abstraction that is actuall…

> ... document browser ... document reader ... I'm going to assume you're being sincere. But even the crustiest among us can recognize that the modern purpose for web browsers is not (merely) documents. Chances are, many folks on HN in the last month have booked tickets for a flight or bought a home or a car or watched a cat video using the "document browser". > If we think we need a more thoroughly virtualized machi…

[deleted]

Re: WASM 3.0 Completed

#448

Post by halfcat »

jesse__ wrote: post #317
halfcat wrote: post #277

Earlier quoted context omitted.

> DearIMGUI can probably already do like 85% of what modern webapps do I’m with you. Main blocker I’ve seen to “just use ImGui for everything” (which I’d love to adopt), is if I run ImGui in WASM the keyboard doesn’t open on mobile. This seems possible in theory because egui does it. Even though running ImGui on mobile via WASM isn’t the primary use case, inevitably the boss or someone is going to need to “just do a…

I'd say two things about this. 1. Opening the native keyboard and plumbing those events through to the WASM runtime sounds pretty easy. It's probably not cause modern software , but conceptually it should be trivial.. right?? 2. In terms of 'the boss' wanting to do 'that one weird thing' that there isn't a library/plugin/whatever for in DearImgui land. If dev time for everything else gets faster, than the 10x cost of…

> Opening the native keyboard…

I think this is the roadblock, that there isn’t always a way to pop open the keyboard programmatically. Rather, the mobile keyboard only pops up when there’s a DOM input element detected. So it would need a hidden input layered on top of the ImGui WASM app and mapping coordinates, or would need an HTML input element overlayed on top of every text input.

Re: WASM 3.0 Completed

#449

Post by fullstackchris »

Tade0 wrote: post #362
namuol wrote: post #218

Earlier quoted context omitted.

> When can we finally kill JavaScript? If you think JavaScript has problems I have bad news about the DOM…

Wanted to say the same thing. People often conflate JS with the DOM API, but that couldn't be further from the case. You can get rid of JS, but that won't help much because it's just a small language interfacing with a huge, old, backwards compatible to 20+ years ago system that is the DOM.

yep, ive still never understood the fetish of HN folks wanting to eliminate JS completely. you tell them to use TS, they say its overcomplicated... i've never heard a definitive or decent answer to "ok what language WOULD you use for manipulating the DOM?" its infuriating, though i suppose those complaining have probably built like one website once. yes, JS is not your strongly typed Rust / Go / .NET, get over it - go learn TypeScript and be happy

Re: WASM 3.0 Completed

#450

Post by jason-johnson »

cedws wrote: post #180

When is WASM finally going to be able to touch the DOM? It feels like that was the whole point of WASM and instead its become a monster of its own that barely has anything to do with web anymore. When can we finally kill JavaScript?

Maybe some day, maybe never. A different, perhaps more important question is, does it matter?

https://youtu.be/4KtotxNAwME?si=Egu05co4q7-RsanU

Post reply on HN