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

351–360 of 520 posts

Re: WASM 3.0 Completed

#351

Post by pjmlp »

adrianton3 wrote: post #343
pjmlp wrote: post #331

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.

I have installed all them on the phone, so yes.

Unfortunely several of them are glorified webviews.

I am old enough to have lived through the days Internet meant a set of networking protocols, not ChromeOS Platform.

And on those days hard disks were still bloody expensive, by the way.

Re: WASM 3.0 Completed

#352

Post by imoverclocked »

pjmlp wrote: post #333
imoverclocked wrote: post #296

Earlier quoted context omitted.

With hypervisors and a Linux kernel doing the heavy lifting, the WASM on bare metal probably just looks a lot like a regular process. I would bet Sun did similar … minus the hypervisor. I do miss the Solaris 10/OpenSolaris tech though. I don’t know anything that comes close to it today.

Solaris is still around, while OpenSolaris forks support Oxide endeavours.

Technically, yes. I built+ported a majority of Debian packages onto Nexenta OS but that effort (and many parallel efforts) just vanished when Oracle purchased Sun. I don't miss SVR4 packages and I never grew fond of IPS. So many open-source folk warned of the dangers of CDDL and they were largely realized in fairly short time. Unsurprisingly, #opensolaris on irc also had a precipitous drop-off around the same time.

dtrace/zones/smf/zfs/iscsi/... and the integration between them all was top notch. One could create a zone, spin up a clone, do some computation, trash the filesystem and then just throw the clone away... in very short time. Also, that whole loop happened without interacting with zfs directly; I know that some of these things have been ported but the ports miss the integration.

eg: zfs on Linux is just a filesystem. zfs on Solaris was the base of a bunch of technology. smf tied much of it together.

eg: dtrace gave you access all the way down to individual read/write operations per disk in a raid-z and all the way up to the top of your application running inside of a zone. One tool with massive reach and very little overhead.

Not much compels me to go back to the ecosystem; I've been burned once already.

Re: WASM 3.0 Completed

#353

Post by goku12 »

Zariff wrote: post #345
j0e1 wrote: post #4

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

The answer was kind of known before hand. It was to enable the use of GCed languages like Python on Ruby to create WASM applications. Meanwhile, non-GCed languages like Rust, C and C++ were supposed to continue to work as before on WASM without breaking compatibility. This is what they seem to have finally achieved. But I needed to make sure of it. So, here are the relevant points from the WASM GC proposal [1]:

  * Motivation
  - Efficient support for high-level languages
      - faster execution
      - smaller modules
      - the vast majority of modern languages need it

  * Approach
  - Pay as you go; in particular, no effect on code not using GC, no runtime type information unless requested
  - Don't introduce dependencies on GC for other features (e.g., using resources through tables)
[1] https://github.com/WebAssembly/spec/blob/wasm-3.0/proposals/...

Re: WASM 3.0 Completed

#354

Post by jenadine »

jesse__ wrote: post #238
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?

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…

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

Re: WASM 3.0 Completed

#355

Post by threeducks »

phkahler wrote: post #295
atroche wrote: post #258

Earlier quoted context omitted.

This is one of the best WASM-based web UIs I've seen! What was the hardest part of getting your desktop build working via Emscripten?

I didn't do the WASM port. It was started by our previous lead whitequark, and some more work done by a few others. It's not quite complete, but you can do some 3d modeling. Just might not be able to save...

> Just might not be able to save...

Oops, I did not read that before going ham in the editor. It seems that the files are stored inside the emscripten file system, so they are not lost. I could download my exported 'test.stl' with the following JavaScript code:

    var data = FS.readFile('test.stl');
    var blob = new Blob([data], { type: 'application/octet-stream' });
    var a = document.createElement('a');
    a.href = URL.createObjectURL(blob);
    a.download = 'test.stl';
    a.click();

Re: WASM 3.0 Completed

#356

Post by swiftcoder »

syndeo wrote: post #294
imoverclocked wrote: post #269

Earlier quoted context omitted.

There are projects to run WASM on bare metal. I do agree that we tend to run a lot in a web-browser or browser environment though. It seems like a pattern that started as a hack but grew into its own thing through convenience. It would be interesting to sit down with a small group and figure out exactly what is good/bad about it and design a new thing around the desired pattern that doesn't involve a browser-in-the-l…

> run WASM on bare metal Heh, reminds me of those boxes Sun used to make that only ran Java. (I don’t know how far down Java actually went; perhaps it was Solaris for the lower layers now that I think about it…)

The Java went so far down that many early ARM cores could be placed in Jazelle DBX mode, which processed Java bytecode in hardware shudders

Re: WASM 3.0 Completed

#357

Post by hollowturtle »

zeroq wrote: post #328

I'm both excited and terribly disappointed. I feel like webdev ecosystem after the fall of Flash took a wrong turn and missed a huge opportunity. For whatever reason people opted for both sticking with JS and backward compatibility. I can clearly see an alternative universe where you have a browser that accepts both a with JS and another, modern language, and it's up to the developer to chose if he wants to transpile…

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

Re: WASM 3.0 Completed

#358

Post by benrutter »

vinkelhake wrote: post #187
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?

You can write a WASM program today that touches the DOM, it just needs to go through the regular JS APIs. While there were some discussions early on about making custom APIs for WASM to access, that has long since been dropped - there are just too many downsides.

I have slightly different question than OP - what's left until it feels like javascript is gone for people who don't want to touch it?

Say I really want to write front end code in Rust* does there just need to be a library that handles the js DOM calls for me? After that, I don't ever have to think about javascript again?

Re: WASM 3.0 Completed

#359

Post by preisschild »

jesse__ wrote: post #238
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?

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…

Couldn't you implement something like HTMX in wasm then and still have locality-of-behavior by specifying the behavior as html attributes?

Re: WASM 3.0 Completed

#360

Post by zeroq »

hollowturtle wrote: post #357
zeroq wrote: post #328

I'm both excited and terribly disappointed. I feel like webdev ecosystem after the fall of Flash took a wrong turn and missed a huge opportunity. For whatever reason people opted for both sticking with JS and backward compatibility. I can clearly see an alternative universe where you have a browser that accepts both a with JS and another, modern language, and it's up to the developer to chose if he wants to transpile…

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 meanwhile Macromedia worked on a whole new thing called AS3. It was codified as ES4 and it's the reason why JS had all these "private", "abstract" keywords reserved.

Heck, we even had redtamarin for running AS as console! And there was Alchemy which is grandfather of WASM.

We were that close to having a compiled JS++.

But times were different, we were still in the middle of browser wars, and the standard was eventually scrapped because noone was interested in JS at the time.

And then Apple decided to kill Flash.

And for some reason the community decided to burn the library of Alexandria and spend the next 10 years on reinventing the wheel.

Sure, V8 is a world wonder, no question about it, the fact that JS can run that fast is just amazing. And people finally wrapped their head around TS and realized that types are useful. Wonderful. But I really think that we've lost 10 years running in circle and producing smart looking docs while tech is slowly getting back where it was 15 years ago.

Post reply on HN