I can see how creating a calendar with hundreds of little interactive elements could be challenging in any UI framework. Like Angular with its digest cycles and React with its DOM reconciliation.
Look at any AAA game. 10s of millions of textured polygons every 16ms. A render graph with several thousand nodes should not be visibly slow on any modern hardware.
I’m always disappointed that people are willing to accept the immense performance penalty of modern frameworks and libraries. Having just finished installing Windows XP on a 2.4GHz P4, its sad to be reminded how wasted current hardware is.
I just updated my ultra-fast, ultra-expensive, magical ARM M1 MacBook Pro 16" to Ventura and it takes 2+ seconds to change a tab in Settings. Two. Frigging. Seconds.
> But at what cost? 100% CPU and GPU usage, tons of system/video memory.
Games use lots of CPU/GPU resources because they're rerendering all the time. You don't do that in GUI apps. You also don't have huge swaths of 3d assets.
> Also, rendering text with full capabilities (arbitrary font/size/color, emoji, ...) is much more complicated than drawing a textured polygon.
That's exactly how text is rendered: Glyphs cached into textures that are blitted. Filling the cache is a little more involved, but you're not doing that all the time.
> And how easy is to use a modern 3D engine versus HTML/CSS?
You don't need to use a game engine; traditional GUI toolkits did this stuff out of necessity due to much slower hardware available at the time.
Modern computers are incredibly fast. We're just used to layers upon layers of inefficient abstractions. The GPU can animate many millions of vertices per second, the CPU can crunch GB/s of data, but on the high level it ends up so absurdly inefficient that 365 boxes sounds like a lot.
AppKit + CALayers makes this trivial (performance wise) on the Mac. It only gets challenging when you have no granular control over the UI framework. If it forces you to make every little interactive element its own view ... well, good luck optimizing performance.
It's very different due to how the languages work. In React, you're creating JS objects. Naively, each of those is a heap allocation and a bunch of initialisation. With Swift on the other hand, you're creating Views which are structs, which are value types, allocated on the stack, don't have much if any initialisation to do, and are much cheaper to work with.
I say naively, because JS interpreters are probably doing smart things to try to minimise the impact of this sort of allocation of many small objects, but they still come at a cost that just isn't present in Swift.
