6 ms·

> Both Javascript and the DOM are slow, there's no changing that. The DOM isn't slow. Adding or removing a DOM node is literally a few point swaps, which isn't

by devjab 3y ago

> Both Javascript and the DOM are slow, there's no changing that. The DOM isn't slow. Adding or removing a DOM node is literally a few point swaps, which isn't much more than setting a property on an OOP language object. What is slow is "layout". When Javascript changes something and hands control back to the browser it invokes its CSS recalc, layout, repaint and finally recomposition algorithms to redraw the screen. The layout algorithm is quite complex and it's synchronous, which makes it stupidly easy to make thing slow. Frameworks like React with virtual DOMs help you by redrawing on every state change, which will typically both speed things up significantly and also carry you through a lot of things that would break if you were using non virtual DOM frameworks like JQuery. You can get smooth and quick animations with JavaScript and the DOM, however, but only if you build things to limit what your application can do in a frame to operations which can be performed on the GPU. I can understand if that's not exactly an option for the author of this article, but I'm not convinced you couldn't get Electron (or similar) to work as a GUI framework for a DAW. I suspect Electron specifically might actually be a pretty good framework for DAW's, considering what Microsoft is doing with VSC. I also think that the downside of frameworks like Electron is that you need to be, not only Microsoft, but the Microsoft VSC team (and not the Microsoft Teams team) specifically, to bend them to your way. That being said, I think this will likely be one of those things where you'd need to create a GUI framework (or bend one to your will) to really get DAWs to work for you. Because I think the author is spot on about the "state" of GUI frameworks in general.

sirsinsalot 3y ago
> I also think that the downside of frameworks like Electron is that you need to be, not only Microsoft, but the Microsoft VSC team (and not the Microsoft Teams team) specifically, to bend them to your way. I am not sure this is true, Discord as one example is pretty good. As is Slack's desktop app* *By "good" I mean, perform the task in a stable way and appear fairly 'native' in terms of UX (but not UI design of course)
- skrebbel 3y ago
  It could be argued that in this sense, the Discord frontend team “is” a VS Code team (and not a MS Teams team)
- thorncorona 3y ago
  Discord and Slack are both nicely optimized web apps but they're not very fast compared to native apps. You can tell that there's a noticeable lag between when you type into discord versus the terminal.
  - sirsinsalot 3y ago
    I didn't realise the bar latency had to get over was a comparison to a terminal! I best throw every ide or tool I've ever used in the bin!
    - alpaca128 3y ago
      FYI, most terminals are more on the slower side. For example intelliJ has a much lower input latency than most terminals. So it's not really an unreasonable expectation, many apps are just really damn slow.
    - izacus 3y ago
      We can start with something basic like a native chat app - e.g. Telegram is a nice example of an app that doesn't lag like ass when chatting. Or an IRC client - see for example Textual.
      - MSFT_Edging 3y ago
        Despite some recent issues I've had with the telegram client on a certain rolling release distro, it is still by far the gold standard of cross platform native apps in my mind. IIRC its all/mostly CPP. Runs natively, can handle all sorts of weird desktop configs easily. Its just very snappy and a pleasure to use even on fairly low-end systems. I've installed it on a 32-bit laptop from 2004 and it was very usable. People make some statements about it being Russian owned, and at the end of the day I don't talk about anything important on there, if a Russian team wants to make a world-class cross platform native chat app that I can direct friends/family to and know they won't have any issue getting started, I'm happy to support it. I hate the web-appification of every desktop app with a burning passion.
    - 3y ago
- cozzyd 3y ago
  The slack desktop app often lags when I type...
- izacus 3y ago
  > I am not sure this is true, Discord as one example is pretty good. As is Slack's desktop app* I think you actually need to try out an actual good native app just to see how much of a ridiculous claim that is.
  - yamtaddle 3y ago
    We did some pen & paper gaming over the pandemic in Discord and its most notable feature was draining any battery you threw at it in like three hours flat—best case. All I can figure is it was sitting there calculating digits of Pi in a hot loop, or mining Bitcoin or something.
samwillis 3y ago
> Frameworks like React with virtual DOMs help you by redrawing on every state change, which will typically both speed things up significantly and also carry you through a lot of things that would break if you were using non virtual DOM frameworks A virtual DOM based framework will not be faster than manual DOM manipulation with either vanilla JS or even JQuery. It certainly makes development easier, and massively reduces the risk of bugs. But there is no magic to a VDOM and speed, technically you are usually doing more work, building a VDOM and diffing it. Edit: Rich Harris of Svelte has a good post explaining: > Virtual DOM is pure overhead. Let's retire the 'virtual DOM is fast' myth once and for all https://svelte.dev/blog/virtual-dom-is-pure-overhead https://svelte.dev/blog/virtual-dom-is-pure-overhead
- p-e-w 3y ago
  > But there is no magic to a VDOM and speed There absolutely is. If you are using standard DOM APIs and are first changing the text of a <span> element, then changing it back to what it was before (which can easily happen if your application logic is sufficiently complex, with multiple piecewise state changes impacting the UI), the browser will have to re-render the element twice, which means two full re-layouts unless the element is absolutely positioned or something. By contrast, VDOM-based frameworks will detect that the DOM hasn't actually changed, and as a result, the browser doesn't have to do anything (other than update the VDOM). That's indeed "magic", and makes a tremendous performance difference with complex applications in practice.
  - samwillis 3y ago
    No, in a correctly implemented pure DOM manipulation app you would update the DOM once to match your state, that's faster than building a VDOM and diffing it. Modifying the DOM twice, with an unintentional reflow and redraw between, would be a bug in your code. Yes, "if your application logic is sufficiently complex, with multiple piecewise state changes impacting the UI" is what a VDOM helps with from a developer perspective. But it isn't magically "faster". Personally I'm a fan of reactive frameworks such as Vue that do use a VDOM, but also by using a reactive state can do fine grain partial rendering of that VDOM for efficiency. Would I build an app without a (probably VDOM based) framework, no I wouldn't. Also note that the "fastest" frameworks, such as Solid, don't use a VDOM, they track state changes and do fine grade DOM manipulation to match it.
wg0 3y ago
I don't know about the performance but web is THE most capable platform that itself is cross platform. As for performance, text editor with dozens of plugins and syntax highlight is no joke either and I have no issues on my MacBook Air with only two cores from few years ago - abandoned Jet Brains IDEs for a web based text editor (VScode) and works pretty well even on large code bases.
- trollied 3y ago
  I think you have failed to comprehend what a DAW actually needs to do/render, quickly.
  - wg0 3y ago
    You're not wrong to assume so. I think I should have said that minus the DAW and otherwise generally speaking for let's say 95% of the use cases, the web is pretty OK. So instead of editing the comment above, I'd agree with your underlying point about DAW and complexity of the UI. It is no trivial. As a backend engineer, the progress on web platform certainly is dazzling from Web Assembly to Web GPU, Flex, Grid, Container queries and lately view transitions.
  - yurishimo 3y ago
    Can you share some examples where a DAW/plugin would need to update that much visual data onscreen with almost zero latency? I'm genuinely asking someone who used to make music with orchestral/Pianos/Drum VSTs a ton a few years ago. I agree that the underlying audio should be as fast as possible, but I don't see why the UI couldn't "lag" behind by a few extra milliseconds for on screen rendering. Especially as a plugin. Again, not trolling; genuinely curious!
    - bandrami 3y ago
      Live manipulatable waveforms. Think DJ decks, etc. It tends to be one of those "tearing is better than stuttering" situations so it goes against a lot of compositing assumptions.
    - 3y ago
PaulHoule 3y ago
The DOM is fast for the kind of applications that most people create with React: sign-up forms, shopping carts, blogs, and other web sites that people used to be able to create before React using HTML directly but that web developers now look at like Stonehenge or the Egyptian Pyramids.
cmrdporcupine 3y ago
I spent some time last year building out a UI framework for VSTs based on embedded HTML/JS, after being frustrated with the terrible VST3 GUI package from Steinberg. I think it showed promise, but I'm unable to continue to make progress with it: https://github.com/rdaum/vstwebview https://github.com/rdaum/vstwebview It's not Electron, but it's Electron-like. And it was totally fine, performance wise. Remember this is the UI layer, not the audio rendering layer. On a multicore system, these are two different threads of execution that should not be impacting each other, if you do it right. It'd be great if somebody were to run with it. I feel I made good initial progress. These days, I have to concentrate on my paying work (in Rust, not C++, and not in the audio domain) instead. Rant: HTML/JS UIs are not intrinsically slow. V8 is highly tuned. Rendering in Chromium is highly tuned. I worked on a team @ Google (Nest "Home Hub") that got Chromium running with decent performance on very low-spec ARM SoC devices with very acceptable rendering performance. So many hundreds of thousands of developer hours have been spent on improving browser rendering performance that it's preposterous and dangerously dogmatic to insist that some homegrown solution will be intrinsically superior, performance wise and still be robust and feature complete and offer... luxuries... like accessibility or keyboard shortcuts, etc. Do I personally like writing web UIs? No. Do I want to write my own UI toolkit from scratch? Oh, that'd be neat, sounds fun. Do I trust anybody, including myself, to do that right? No. In particular I don't trust e.g. Steinberg to do this.
- redeeman 3y ago
  so an incalculable effort was spent making chromium just tolerable, but rest assured, still far far far from any kind of random native application, in both speed and memory usage. simply opening a chromium tab with an empty html page uses more ram than my amiga had 30 years ago, and funnily enough, I was able to run applications on that maybe i will be impressed if they manage to get the chromium abomination down to a more reasonable size, compared to its 1.7GB compressed size the source is now (how is it even possible?????).. I wonder, how big was khtml when webkit forked? how big was webkit when google forked? this shit is totally out of control, and pretending anything else is something that is quite a feat to do with a straight face, and for that, you have my admiration
  - 3y ago
crazygringo 3y ago
> What is slow is "layout". Right. My understanding is that, as long as you're limiting lots of graphical updates to fixed-size areas, the DOM isn't really a problem. When you resize the window it will be slow. But if you're just animating a single knob being dragged, it's totally smooth. Similarly, if you're blitting a bit array to a canvas, it's plenty fast. The stuff someone needs to do with a DAW interface strikes me as quite perfectly suited to the DOM actually, precisely because the layout is extremely modular. You're not dealing with long strings of text that keep unpredictably wrapping and pushing elements and therefore recalculating the entire layout. It's pretty ideal, really.
jcelerier 3y ago
> I suspect Electron specifically might actually be a pretty good framework for DAW's, considering what Microsoft is doing with VSC VSC always feels noticeably slower to me than GTK / Qt / Win32 apps

by devjab 3y ago

sirsinsalot 3y ago

> I also think that the downside of frameworks like Electron is that you need to be, not only Microsoft, but the Microsoft VSC team (and not the Microsoft Teams team) specifically, to bend them to your way. I am not sure this is true, Discord as one example is pretty good. As is Slack's desktop app* *By "good" I mean, perform the task in a stable way and appear fairly 'native' in terms of UX (but not UI design of course)

skrebbel 3y ago
It could be argued that in this sense, the Discord frontend team “is” a VS Code team (and not a MS Teams team)
thorncorona 3y ago
Discord and Slack are both nicely optimized web apps but they're not very fast compared to native apps. You can tell that there's a noticeable lag between when you type into discord versus the terminal.
- sirsinsalot 3y ago
  I didn't realise the bar latency had to get over was a comparison to a terminal! I best throw every ide or tool I've ever used in the bin!
  - alpaca128 3y ago
    FYI, most terminals are more on the slower side. For example intelliJ has a much lower input latency than most terminals. So it's not really an unreasonable expectation, many apps are just really damn slow.
  - izacus 3y ago
    We can start with something basic like a native chat app - e.g. Telegram is a nice example of an app that doesn't lag like ass when chatting. Or an IRC client - see for example Textual.
    - MSFT_Edging 3y ago
      Despite some recent issues I've had with the telegram client on a certain rolling release distro, it is still by far the gold standard of cross platform native apps in my mind. IIRC its all/mostly CPP. Runs natively, can handle all sorts of weird desktop configs easily. Its just very snappy and a pleasure to use even on fairly low-end systems. I've installed it on a 32-bit laptop from 2004 and it was very usable. People make some statements about it being Russian owned, and at the end of the day I don't talk about anything important on there, if a Russian team wants to make a world-class cross platform native chat app that I can direct friends/family to and know they won't have any issue getting started, I'm happy to support it. I hate the web-appification of every desktop app with a burning passion.
  - 3y ago
cozzyd 3y ago
The slack desktop app often lags when I type...
izacus 3y ago
> I am not sure this is true, Discord as one example is pretty good. As is Slack's desktop app* I think you actually need to try out an actual good native app just to see how much of a ridiculous claim that is.
- yamtaddle 3y ago
  We did some pen & paper gaming over the pandemic in Discord and its most notable feature was draining any battery you threw at it in like three hours flat—best case. All I can figure is it was sitting there calculating digits of Pi in a hot loop, or mining Bitcoin or something.

samwillis 3y ago

> Frameworks like React with virtual DOMs help you by redrawing on every state change, which will typically both speed things up significantly and also carry you through a lot of things that would break if you were using non virtual DOM frameworks A virtual DOM based framework will not be faster than manual DOM manipulation with either vanilla JS or even JQuery. It certainly makes development easier, and massively reduces the risk of bugs. But there is no magic to a VDOM and speed, technically you are usually doing more work, building a VDOM and diffing it. Edit: Rich Harris of Svelte has a good post explaining: > Virtual DOM is pure overhead. Let's retire the 'virtual DOM is fast' myth once and for all https://svelte.dev/blog/virtual-dom-is-pure-overhead https://svelte.dev/blog/virtual-dom-is-pure-overhead

p-e-w 3y ago
> But there is no magic to a VDOM and speed There absolutely is. If you are using standard DOM APIs and are first changing the text of a <span> element, then changing it back to what it was before (which can easily happen if your application logic is sufficiently complex, with multiple piecewise state changes impacting the UI), the browser will have to re-render the element twice, which means two full re-layouts unless the element is absolutely positioned or something. By contrast, VDOM-based frameworks will detect that the DOM hasn't actually changed, and as a result, the browser doesn't have to do anything (other than update the VDOM). That's indeed "magic", and makes a tremendous performance difference with complex applications in practice.
- samwillis 3y ago
  No, in a correctly implemented pure DOM manipulation app you would update the DOM once to match your state, that's faster than building a VDOM and diffing it. Modifying the DOM twice, with an unintentional reflow and redraw between, would be a bug in your code. Yes, "if your application logic is sufficiently complex, with multiple piecewise state changes impacting the UI" is what a VDOM helps with from a developer perspective. But it isn't magically "faster". Personally I'm a fan of reactive frameworks such as Vue that do use a VDOM, but also by using a reactive state can do fine grain partial rendering of that VDOM for efficiency. Would I build an app without a (probably VDOM based) framework, no I wouldn't. Also note that the "fastest" frameworks, such as Solid, don't use a VDOM, they track state changes and do fine grade DOM manipulation to match it.

wg0 3y ago

I don't know about the performance but web is THE most capable platform that itself is cross platform. As for performance, text editor with dozens of plugins and syntax highlight is no joke either and I have no issues on my MacBook Air with only two cores from few years ago - abandoned Jet Brains IDEs for a web based text editor (VScode) and works pretty well even on large code bases.

trollied 3y ago
I think you have failed to comprehend what a DAW actually needs to do/render, quickly.
- wg0 3y ago
  You're not wrong to assume so. I think I should have said that minus the DAW and otherwise generally speaking for let's say 95% of the use cases, the web is pretty OK. So instead of editing the comment above, I'd agree with your underlying point about DAW and complexity of the UI. It is no trivial. As a backend engineer, the progress on web platform certainly is dazzling from Web Assembly to Web GPU, Flex, Grid, Container queries and lately view transitions.
- yurishimo 3y ago
  Can you share some examples where a DAW/plugin would need to update that much visual data onscreen with almost zero latency? I'm genuinely asking someone who used to make music with orchestral/Pianos/Drum VSTs a ton a few years ago. I agree that the underlying audio should be as fast as possible, but I don't see why the UI couldn't "lag" behind by a few extra milliseconds for on screen rendering. Especially as a plugin. Again, not trolling; genuinely curious!
  - bandrami 3y ago
    Live manipulatable waveforms. Think DJ decks, etc. It tends to be one of those "tearing is better than stuttering" situations so it goes against a lot of compositing assumptions.
  - 3y ago

PaulHoule 3y ago

The DOM is fast for the kind of applications that most people create with React: sign-up forms, shopping carts, blogs, and other web sites that people used to be able to create before React using HTML directly but that web developers now look at like Stonehenge or the Egyptian Pyramids.

cmrdporcupine 3y ago

I spent some time last year building out a UI framework for VSTs based on embedded HTML/JS, after being frustrated with the terrible VST3 GUI package from Steinberg. I think it showed promise, but I'm unable to continue to make progress with it: https://github.com/rdaum/vstwebview https://github.com/rdaum/vstwebview It's not Electron, but it's Electron-like. And it was totally fine, performance wise. Remember this is the UI layer, not the audio rendering layer. On a multicore system, these are two different threads of execution that should not be impacting each other, if you do it right. It'd be great if somebody were to run with it. I feel I made good initial progress. These days, I have to concentrate on my paying work (in Rust, not C++, and not in the audio domain) instead. Rant: HTML/JS UIs are not intrinsically slow. V8 is highly tuned. Rendering in Chromium is highly tuned. I worked on a team @ Google (Nest "Home Hub") that got Chromium running with decent performance on very low-spec ARM SoC devices with very acceptable rendering performance. So many hundreds of thousands of developer hours have been spent on improving browser rendering performance that it's preposterous and dangerously dogmatic to insist that some homegrown solution will be intrinsically superior, performance wise and still be robust and feature complete and offer... luxuries... like accessibility or keyboard shortcuts, etc. Do I personally like writing web UIs? No. Do I want to write my own UI toolkit from scratch? Oh, that'd be neat, sounds fun. Do I trust anybody, including myself, to do that right? No. In particular I don't trust e.g. Steinberg to do this.

redeeman 3y ago
so an incalculable effort was spent making chromium just tolerable, but rest assured, still far far far from any kind of random native application, in both speed and memory usage. simply opening a chromium tab with an empty html page uses more ram than my amiga had 30 years ago, and funnily enough, I was able to run applications on that maybe i will be impressed if they manage to get the chromium abomination down to a more reasonable size, compared to its 1.7GB compressed size the source is now (how is it even possible?????).. I wonder, how big was khtml when webkit forked? how big was webkit when google forked? this shit is totally out of control, and pretending anything else is something that is quite a feat to do with a straight face, and for that, you have my admiration
- 3y ago

crazygringo 3y ago

> What is slow is "layout". Right. My understanding is that, as long as you're limiting lots of graphical updates to fixed-size areas, the DOM isn't really a problem. When you resize the window it will be slow. But if you're just animating a single knob being dragged, it's totally smooth. Similarly, if you're blitting a bit array to a canvas, it's plenty fast. The stuff someone needs to do with a DAW interface strikes me as quite perfectly suited to the DOM actually, precisely because the layout is extremely modular. You're not dealing with long strings of text that keep unpredictably wrapping and pushing elements and therefore recalculating the entire layout. It's pretty ideal, really.

jcelerier 3y ago

> I suspect Electron specifically might actually be a pretty good framework for DAW's, considering what Microsoft is doing with VSC VSC always feels noticeably slower to me than GTK / Qt / Win32 apps