Programming

22740 readers

71 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 2 years ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

MaungaHikoi@lemmy.nz

UlrikHD@programming.dev

Help Us Raise $200k to Free JavaScript from Oracle | Deno (deno.com)

submitted 1 day ago by lena@gregtech.eu to c/programming@programming.dev

18 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] 30p87@feddit.org 24 points 1 day ago (1 children)

How about we free the World from JavaScript instead.

[–] lena@gregtech.eu 13 points 1 day ago (2 children)

I wish wasm had access to the DOM

[–] 30p87@feddit.org 17 points 1 day ago (1 children)

My wet dream is Segmentation fault in Firefox

[–] lena@gregtech.eu 18 points 1 day ago (1 children)

Better than undefined or "[object Object]"?

[–] 30p87@feddit.org 4 points 1 day ago

Tbh, yes

[–] spartanatreyu@programming.dev 4 points 1 day ago

I'll repost my comment yesterday about this very thing (link: https://news.ycombinator.com/item?id=45279384#45283636)

It's also too early to worry about DOM apis over wasm instead of js.

The whole problem with the DOM is that it has too many methods which can't be phased out without losing backwards compatibility.

A new DOM wasm api would be better off starting with a reduced API of only the good data and operations.

The problem is that the DOM is still improving (even today), it's not stabilized so we don't have that reduced set to draw from, and if you were to mark a line in the sand and say this is our reduced set, it would already not be what developers want within a year or two.

New DOM stuff is coming out all the time, even right now we two features coming out that can completely change the way that developers could want to build applications:

being able to move dom nodes without having to destroy and recreate them. This makes it possible so you can keep the state inside that dom node unaffected, such as a video playing without having to unload and reload a video. Now imagine if that state can be kept over the threshold of a multi-page view transition.

the improved attr() api which can move a lot of an app's complexity from the imperative side to the declarative side. Imagine a single css file that allows html content creators to dictate their own grid layouts, without needing to calculate every possible grid layout at build time.

And just in the near future things are moving to allow html modules which could be used with new web component apis to prevent the need for frameworks in large applications.

Also language features can inform API design. Promises were added to JS after a bunch of DOM APIs were already written, and now promises can be abortable. Wouldn't we want the new reduced API set to also be built upon abortable promises? Yes we would. But if we wait a bit longer, we could also take advantage of newer language features being worked on in JS like structs and deeply immutable data structures.

TL;DR: It's still too early to work on a DOM api for wasm. It's better to wait for the DOM to stabalize first.