[PaulDavisThe1st]

The web does not start with the DOM, that was exposed later when web devs started insisting on being able to do things not possible with HTML+CSS directly.

And yes, some native devs are looking at wasm as "it's just a big canvas with its own bytecode interpreter and access to 95% of the system API that I need". There's one and only one reason for that: the simplicitly of distributing software to users when it is "in the browser".

I don't want a DOM when I'm porting my DAW to the browser, and I'm pretty sure you don't me to use that way either.

[jemmyw]

> I don't want a DOM when I'm porting my DAW to the browser, and I'm pretty sure you don't me to use that way either.

Actually we do want you to use the DOM. Use the DOM for everything except the parts that are highly graphical, i.e. rendering waveforms where it makes sense to use cavas. Most of a DAW is just normal controls and we want those to be accessible, readable, and potentially extendable.

[PaulDavisThe1st]

normal controls? they might look like normal controls, but they frequently do not act like it. trivial example: tri-state buttons. the UI interaction model for most audio app controls is typically a lot richer than is found in desktop and web development. a more major issue: MVC confusion, which is hard enough in native. Example: dragging something in the UI, but the model is too heavyweight to update directly, which requires the UI to no longer represent the model (for a while, at least).

As for the waveforms, those are just images too (they have to be, to make rendering efficient enough, even for native).

Apple understood the differences: almost none of their creative software (for desktop) is written using standard Apple toolkits (and no, it's not just because they purchased Logic from Emagic and Emagic had been bad).

[jemmyw]

A tri-state button is hardly an unusual design to find in web software

[PaulDavisThe1st]

You're right, but I wouldn't really consider this sort of thing to be a "normal control". I get that you can implement it "only" with HTML+CSS+JS, which is probably better than as a canvas thing, but there's really no basic concept for such a thing without JS hacking, at least not as far as I could tell.

[jemmyw]

Yes what you say is true and lamentable, although I don't consider using JS to be hacking it up. At this point JS is really embedded in the model of the web rather than just a sprinkle on the top.

I had hopes for webcomponents. They do work OKish, but it's harder to make and distribute a webcomponent than make a similar thing in React and that sucks.

So yah, I can see your view, but I'm still not OK with the idea of canvas based apps replacing DOM ones. I think its like the old macromedia flash model, a part of the app you cannot interactive with the same, no text selection if the dev decides to not implement that, no content blocking so we'll get ads shoved down our throat again, poorer accessibility, closed frameworks. All that kind of jazz.

[PaulDavisThe1st]

Well, I've spent 23 years developing an open source, cross-platform DAW, and so my interest in such things has nothing to do with ads or any of that stuff.

But yes, that's certainly is a risk of creating a mostly non-viewable VM inside the browser, even if that does effectively create a new platform for development that will ultimately have little or nothing to do with traditional webdev.