431–440 of 520 posts
Earlier quoted context omitted.
wasm 3 has the JavaScript string built-in now according to TFA
That's a different thing. There is still no string type. JS string built-ins are a kludge for web targets only.
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?
Hot take alert > When is WASM finally going to be able to touch the DOM? Coming from a web background, and having transitioned to games / realtime 3D applications... Fuck the DOM dude. The idea that programming your UI via not one but TWO DSLs, and a scripting language, is utter madness. In principal, it might sound good (something something separation of concerns, or whatever-the-fuck), but in reality you always end…
This is what Flutter does. It works well, but you do lose some nice things that the browser/DOM provides (accessibility, zooming, text sizing/selection, etc). There’s also a noticeable overhead when the app + renderer is initially downloaded).
Earlier quoted context omitted.
This. And it feels so frustrating, people keep defending w3c... I'm feeling let down by specs that instead of giving me a graphic, accessibility and input api, tells me where I should use vs or whatever useless stuff
I'm glad I'm not alone with these feeling. I was there when Macromedia took JS as their scripting language for animating GIFs. People soon started doing silly things and everyone realized it was not fit for the task. We had AS2 which added some syntactic sugar and was the exact same thing as early Typescript - an escape hatch that allowed you to use OOP while the resulting code was still just plain old JS. But meanwh…
Earlier quoted context omitted.
It's WASM. WASM runs in a sandbox and you can't have UB on the hardware level. Imagine someone exploiting the behavior of some browser when UB is triggered. Except that the programmer is not having nasal demons [1] but some poor user, like a mom of four children in Abraska running a website on her cell phone. [1]: http://catb.org/jargon/html/N/nasal-demons.html
The UB in this case is "you may get another value in the sandboxed memory region if you dereference an invalid pointer, rather than a guaranteed trap". You can still have UB even in a sandbox. Seems like they got overly attached to the guaranteed trapping they got on 32-bit and wanted to keep it even though it's totally not worth the cost of bounds checking every pointer access. Save the trapping for debug mode only.
Maybe. Bugs that come from spooky behavior at a distance are notoriously hard to debug, especially in production, and it's worthwile to pay for it to avoid that.
Earlier quoted context omitted.
We have, but not by choice, I miss my native apps, even though ChromeOS Platform pays the bills.
> booked tickets for a flight or bought a home or a car or watched a cat video Would you install a native app to book a flight? One for each company? Download updates for them every now and then, uninstall them when you run out of disk space etc I can ask the same question about every other activity we do in these non-native apps.
But for some reason this takes 20M lines of code, which creates a moat that prevents browser competition.
> Garbage collection. In addition to expanding the capabilities of raw linear memories, Wasm also adds support for a new (and separate) form of storage that is automatically managed by the Wasm runtime via a garbage collector. Staying true to the spirit of Wasm as a low-level language, Wasm GC is low-level as well: a compiler targeting Wasm can declare the memory layout of its runtime data structures in terms of stru…
I'm not familiar with WASM. Can someone explain why this is a good thing? How does this work with languages that do not have a garbage collector, like Rust?
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…
There's been various attempts to build "Internet operating systems" that are little more than a browser (that's what Chrome OS was intended to be in the beginning I thought) but Windows and it's pre-internet legacies are so entrenched in PCs and corporate life that nothing's ever gonna change there until Microsoft makes the entirety of Windows an app.
Earlier quoted context omitted.
Not sure what the Rust situation is like, but last I checked (and compiled a non-trivial personal application) WASM supported the pthreads API and it seemed to work reasonably well. Have you encountered stumbling points porting a heavily MT Rust program to WASM?
That's supposedly WASI, an interface specifically designated for system programming use, and that's where it implements part of the POSIX support including pthread. OTOH you still need to start a wasm runtime first, then import the WASI module into the wasm host. P.S.: used to tinker with wasmtime and wasmi to add wasm support to my half abandoned deno clone ;) I learned this the hard way
Earlier quoted context omitted.
I'm not familiar with WASM. Can someone explain why this is a good thing? How does this work with languages that do not have a garbage collector, like Rust?
Non-GCed languages will continue to manage memory themselves. Previously, GCed languages that wanted to run on WASM had to have an implementation of their runtime including GC compiled to WASM. The idea or hope here is that those languages can use the built-in GC instead and slim down the amount of WASM that needs to be delivered to run the application to only include a minimal runtime. The current scenario is closer…
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…