> 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.
> 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
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.
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.
VDOM isn't the equivalent of memory safety - such as using Rust over C, its much more similar to using a garbage collected high level language - such as Python or Ruby - over C.
I do not use any frameworks for browser based JS/HTML front ends. Just plain JS and some domain specific libs when needed. No problems so far and the resulting GUIs are fast.
> 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 ... the browser will have to re-render the element twice
As far as I understand, not if this all happens within a single browser layout/paint cycle [0]
You wrote this later and I apologise for bringing it up here:
> 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
Bur that is sort of my point. Maybe I could have been clearer about it, but my intend was to say that the VDOM frameworks are faster (or perhaps safer is the right word) for people who aren’t doing things correctly. Which among others is also me.
No worries, and the rest of your comment (DOM actually fast, render+reflow slow, Electron good choice) is good. It just bugs me when people repeat the myth that VDOM is faster at rendering than native DOM (or not clearly explaining otherwise), it encourages people to reach for a tool they don't necessarily need.
As I have said in other comments, VDOM based frameworks are good, people should use them, but not because they are "magically" faster.
Huh? You're not doing any of this, the framework does it automatically. The virtual DOM and DOM change reconciliation makes it faster. DOM changes are really slow. The reconciliation makes sure only the parts are re-rendered which have changed. Failing that, the full screen is re-rendered.
If you're doing manual VDOM building you're doing something very wrong.
> If you're doing manual VDOM building you're doing something very wrong.
Rendering a React or Vue component is building a VDOM, that's what I'm referring to. Your code is explicitly building a VDOM.
> The reconciliation makes sure only the parts are re-rendered which have changed.
Yes, and that makes development easier.
That reconciliation is only "faster" if your alternative non-VDOM code is poorly written, throwing away chunks of DOM and rebuilding from scratch.
I'm not advocating for not using VDOM frameworks, I use them, I'm advocating for understanding they are not faster than the DOM. that is a myth, and results in people misunderstanding the tools or how the DOM and browsers work.
Yeah I definitely agree with VDOM doesn't necessarily speed up anything on its own. There are many frameworks that benchmark better than react, for example - svelte, lit - these don't have VDOM at all.
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.
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:
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.
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
I too from from that era of computing. That ship has sailed. There is no comparison in terms of the architectural complexity between then and now. You can decry all the layers of abstraction, and they have indeed brought amplification on the amount of memory and cycles necessary to do "simple" tasks. But they've also brought with them capabilities so far beyond what we did then.
I worked in the Chromium source tree. It is indeed massive and complicated. But I can assure you that none of us were ever "wooo let's just chew memory and CPU cycles" -- it is written with efficiency in mind all over. It's just cumulatively quite complicated what it is doing.
Can you write a GUI toolkit which throws away 99% of that cruft? Yes. But it will lack so many creature comforts that we've become used to. What we had back then.. it lacked vector fonts, it lacked GPU acceleration, it lacked transparencies, it lacked multiple DPI support, aliasing, subpixel rendering, etc.. It lacked accessibility. It lacked multiple keyboard layout support. It lacked proper multiple language support, it all predated unicode and nobody even thought about right to left text flow, etc.. Obviously no touch screen and gesture support. Hell, the Amiga widget kits barely had standardized components of much variety at all.
And that's not even bringing up the VM that runs JavaScript. Which you can bitch all you want about it -- but back then many of us salivated over Smalltalk-80 (another garbage collected dynamic late-bound OO language) but our machines could not handle it. Turns out to do that kind of system well and at scale, you need resources far beyond 80s and 90s computers. We're there now, but it took a long time.
All of this costs in software complexity.
Finally, memory usage is also a lot more complicated than it used to be. Firstly, we have so much more of it than before so we can do a lot more trading off memory for speed than we did back then, when memory was stupidly expensive. Secondly, buffer management and allocation can have all sorts of subtleties esp in the context of virtual memory. Something can show in top as using X memory, but the actual mount of memory pages in physical use and currently paged into the application may not be anywhere close to that. In a virtual memory system, memory accounting is a tricky subject.
Shit is not out of control. It's just a lot more complicated on the surface than you're willing to admit.
the khtml to webkit to chromium expansion is NOT in any way defensible in contrast to amount of features. I sincerely hope that it is done due to not caring even the tiniest amount about efficiency, because the alternative is not pleasant to think about.
funnily enough some software cares greatly about efficiency, namely those where it isnt just possible to buy a bigger cpu and more ram to make it "tolerable", they manage to care about practically every single instruction, and what do we get for it? great quality of software
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.
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.
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.
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.
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.
> 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)
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.
I have used more complex native applications on Windows 95 that had less latency than Discord does, on a 10900k 20-thread CPU.
Modern terminals are quite slow compared to how fast the CPU itself it, because of the myriad of layers it sits upon.
And Discord is extremely slow it's not even funny. Having one single frame of additional lag between click and action, with modern PCs probably means billions of instructions being executed. For a glorified IRC client, to render a screen?
The problem is we all have become complacent and lazy, so we are used to software which is utterly inefficient and slow. You should throw all your IDEs in the bin, if only there was one that felt as snappy as Turbo C++ did 30 years 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.
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.
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.