But that's just a browser, right? I'm pretty sure my browser in 2005 could display dozens of gifs. There must have been a series of decisions by devs to do it in some super convoluted way. I can see each emoji being an iframe with a full react app doing the animation. But even that should be fine? Maybe?
It's "just a browser" in the same sense that the Linux kernel and GNU are "just an operating system".
It's one of the most complex pieces of software - perhaps even human designed systems - ever to exist and we're using it to render a few polygons and drop shadows because the C++ committee made a bunch of mistakes decades ago so now our webdevs are mortally afraid of CMake and Qt/QML. Or GTK. Or whatever. Pretty much the only people that seem to put out native GUI tools in any significant quantity are Apple developers.
The tradeoffs that Blink and V8 engineers have made to support the entirety of the internet and the morass of web development precludes efficient use of resources for simpler purposes, like rendering an animation. After all, there a billion React hooks and ad tracking scripts to optimize, otherwise bounce rates will increase.
> precludes efficient use of resources for simpler purposes
Strong disagree. If it were an animated gif then the browser will be astonishingly efficient because of crazy good optimisations.
The underlying reason is that developers are limited to the techniques/toolbox they know. The performance costs are unpredictable because of:
(1) the declarative style (using imperative solutions would have other costs),
(2) debugging browser performance regressions is difficult (SQL EXPLAIN is more learnable).
Browsers enable developers. I could design that animation in CSS even though I'm a developer, plus I understand the article fully. I couldn't design an animated gif because I am totally unfamiliar with any tools for achieving that.
I think the Blink and V8 teams do an exceptionally good job when choosing compromises. HTML/CSS/SVG/JS and Chromium are winning the UI wars because they deliver practical and efficient enough solutions. Other UI solutions I have experienced all have other downsides. Browsers are magical.
Animated gifs are probably not an issue anymore. In the case of the equalizer icon, the OP used CSS animations that made the browser work in a very non-optimal way. Same thing probably applies to the animated emojis.
Part of the problem is that because it's "just a browser", devs have to come up with browser-friendly ways to implement some functionality that would be very simple if it were a native app. Sometimes resulting in bugs like https://github.com/microsoft/vscode/issues/22900 ("VS Code uses 13% CPU when focused and idle, draining battery ... due to the blinking cursor rendering").
Note that this isn't even a case of whoever implemented that cursor "doing it wrong"; to quote another comment on that bug from a Chrome dev:
> Powerful* text editors built on the web stack cannot rely on the OS text caret and have to provide their own. In this case, VSCode is probably using the most reasonable approach to blinking a cursor: a step timing-function with a CSS keyframe animation. This tells the browser to only change the opacity every 500ms. Meanwhile, Chrome hasn't yet optimised this completely yet, hence http://crbug.com/361587.
So currently, Chrome is doing the full rendering lifecycle (style, paint, layers) every 16ms when it should be only doing that work at a 500ms interval. I'm confident that the engineers working on Chrome's style components can sort this out, but it'll take a little bit of work.
While that's part of it, it's also that there's simply little focus on performance; developers trust the system they build on top of, and animations are a solved problem in terms of performance, right?
Electron.