4 ms·

Here's the part that makes me confused/angry: this is a flat style icon with maybe 4 or 8 colors displayed on a static flat green background. I could have built

by xp84 1y ago

Here's the part that makes me confused/angry: this is a flat style icon with maybe 4 or 8 colors displayed on a static flat green background. I could have built this 25 years ago with a single GIF with about 6 frames, that was a couple of kilobytes and would be performant on the (relative) potato computers we had then. With CSS you can easily make that GIF a background image and position it correctly in the <button> or whatever. Do it at 2x and scale it for retina sharpness. But modern "web designers" feel the need to spend how long carefully crafting that CSS animation which adds dozens of lines of code to the codebase and burns a ton of CPU...why? Just because you can, I assume? The same reason the same people use embedded <svg> documents inside the HTML for simple icons like "edit pencil" or "close", wasting bandwidth instead of at least putting them into asset files that can be cached. Frontend web "advancements" of the last 10-15 years, at least the way they are used, are mostly cancer in my opinion. I will allow for the usefulness of display: flex, and that's about it.

nawgz 1y ago
Yes you're right, most users LOVE barebones and classic websites, that's why HN is so popular and Reddit hardly has any users. For that matter, do we really need colors? Just ship it with browser default styles.
- seemaze 1y ago
  Exactly this! I wish the entire web was easier to read on my e-ink device.
- LastMuel 1y ago
  I hear your snark, but Reddit isn't exactly a beauty contest winner.
  - makapuf 1y ago
    Yeah I was thinking "but..." ah but yes I use old.reddit.com. well, case in point.
- deleted 1y ago
  [deleted]
- xp84 1y ago
  I think it's funny that you think sites can't be attractive unless they include many megabytes of complex JS and CSS on every page. Craigslist lasted and was dominant a whole extra generation of the Web until Facebook Marketplace unseated it without even bothering with colors and certainly no animations. And FBM didn't win on clever animations and React UI complexity, it just won based on the fact that it was easier to detect Nigerian scammers since you can see when the buyer's FB account was created and a few other cues. Users don't care how clever your programmatic animations are. They hate how slow your site is. Look how much Jira sucks now. It's more sluggish on an M4 Pro than it was on my Core i5 in 2013 because of how much frontend bloat they've added in the meantime.
- filleduchaos 1y ago
  This seems like a rather knee-jerk response to someone arguing that they can build the same UI with less.
jakubmazanec 1y ago
GIFs don't scale well (including 2x version is not enough); with CSS (and SVG) you get crisp graphics at any scale. And of course you can use asset SVG files that are cached [1]. [1] https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/Element/use https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/E...
- xp84 1y ago
  Citation needed for 'GIFs don't scale well' (in terms of dimensions. They certainly don't scale well when abused as idiotic versions of videos.) Is this the frontend developer's version of "Postgres doesn't scale. Mongo is Webscale"? Here's a 640x640 GIF. Scales just fine for me, to half-size or to 100px. I'm using a "Retina" screen. https://cdn-icons-gif.flaticon.com/6172/6172533.gif https://cdn-icons-gif.flaticon.com/6172/6172533.gif
  - Sharlin 1y ago
    That GIF weighs one third of a megabyte. You could literally fit a fully featured bespoke 2D/3D rendering engine in the same space. Now, it could probably be optimized, but an aPNG would likely be vastly smaller. And these days aPNG is even reasonably widely supported! That said, an animated SVG would likely be the best option.
    - xp84 1y ago
      What is your point? The random first GIF I found is enormous in pixel size and many frames, thus large in filesize, but a few dancing green blobs would be tiny. You don't need that one's 640px size to scale, and 2x will work perfectly fine.
  - supermatt 1y ago
    I’m looking at that on an iPhone, and if I scale (in either direction, pinch or zoom) it I can see a semitransparent halo around it, I would assume from the antialiasing. So that certainly isn’t scaling well for me.
  - beejiu 1y ago
panic 1y ago
Won’t the GIF also burn a ton of CPU? I’m not convinced it would actually be more performant than sliding textures around.
- xp84 1y ago
  Try it yourself. Here is a 640x640 gif: https://cdn-icons-gif.flaticon.com/6172/6172533.gif https://cdn-icons-gif.flaticon.com/6172/6172533.gif That tab is using 4-5% CPU on my M1 Pro, and I also have a "GPU process" in my task manager, which is showing about 8% in the "CPU" column when it's onscreen. So, no, using a 64x64 GIF (1/100th the area of my example) you'd need to do this animation would absolutely not use any significant CPU or GPU. Which is why those worked very effectively to animate small icons with zero lag on the potato computers we had in 2000.
- wetpaws 1y ago
  [dead]
MITSardine 1y ago
The app taking "only" 6% of a $3k laptop's CPU to show two lines of text and a little 2D animation also gave me pause, but maybe this is just how it is. Still I wonder how people were squeezing pacman out of prehistoric machines, and we're using an 80's supercomputer worth of CPU power (not that far given they were in the ~ 1 GFLOP range) to animate three green bars today.
- xp84 1y ago
  They actually knew how to code back then. I fancy myself someone who cares about performance and take a great effort to not do wasteful stupidity like those CSS animations for a decorative element, but compared to 80s programmers, I'm actually a complete fraud, because I do everything in interpreted languages that do 10,000 things behind the scenes for every line of code I write. I could never make an Atari computer or NES work. There are of course a few who do, they all either work on embedded systems or making homebrew for retro computers. So much respect for that level of skill!
  - Varelion 1y ago
    I aspire to be one who cares about performance, but I would like to address: "I do everything in interpreted languages that do 10,000 things behind the scenes for every line of code I write." Is it even possible to create a modern website, or product, without this? How long would the development cycle take, if everything is to be written in C? I'd wager that replicating a "minimalist styling" for a react-based website with a dozen or so components would take dozens of times longer to produce.
    - drdec 1y ago
      > How long would the development cycle take, if everything is to be written in C? Once upon a time I worked on a website backed by C. Development times were not appreciably longer. We had a in-house templating language for generating HTML (also written in C). That implementation got to the complexity point to where even the original devs did not want to touch it to add anything. But in terms of add a new screen collecting fields x,y,z it was fine. This was a job board, allowing search, applications, saved resumes, bulk opening uploads, i.e. there was some real functionality there.
sampullman 1y ago
Why the embedded SVG hate? A simple icon should be just a few hundred bytes, is reusable, and styleable with CSS. It's not the right fit 100% of the time, but I think it's a very nice feature to have.
- zdragnar 1y ago
  They're generally static documents that could be served independently, and thus cached, like an image. Many times, though, they're served up inline in the JavaScript code that templates the html, and thus is cached less aggressively, especially if the FE is deployed frequently.
  - makapuf 1y ago
    Wasting hundreds, well maybe a thousand of bytes in the process ! (I understand it's better to cache and things can go out of hand fast. But we're talking about small animations here.
    - zdragnar 1y ago
      I don't disagree at all. There's way bigger fish to fry when it comes to maximizing network efficiency in websites. I'm just pointing out the rationale of OP since someone asked, and I've worked with people who've made this and similar arguments before. It's been awhile, though- the ones I'm thinking of would treat code golf as a best practice for CSS (only slightly exaggerating).
      - makapuf 1y ago
        Of course, we both agree.
    - xp84 1y ago
      Believe me, a few kb on every icon on every pageview adds up to a lot of wasted bandwidth and not everyone is on a gigabit connection at all times, even fancy iPhones are on shitty connections a lot more than you think. Inside parking garages, on deprioritized LTE, etc.
ajkjk 1y ago
This contempt is misplaced. It is obviously better in one sense to generate an animation on the fly using a short program instead of encoded its literal pixels in a much larger amount of data even after compression. The ecosystem has largely moved towards that abstraction because it scales better for virtually every purpose, particularly for rendering in different formats. Now web developers are brought up inside the abstraction and so don't even think to go outside of it by default. Which would be fine, except that the abstraction isn't designed very well: the browser is massively underpowered at building applications in an foolproof way. Part of that is historical cruft and part of it is (imo) a lack of vision--there should have been a (not-backwards-compatible) replacement for html/js/css years ago which solves its fundamental abstraction problems. But anyway the present is still much better than the past. You must be nostalgic for the era when all monitors were the same size and websites weren't expected to do anything without reloading the page.
- bobthepanda 1y ago
  The problem is that everyone (browsers + developers) need to agree on a replacement, which is notoriously hard to do. Chrome got laughed out of the room with Dart/Flutter.
  - ajkjk 1y ago
    Well they don't really. What ought to happen is someone just makes a new browser (or adds support in an existing browser) unilaterally on an experimental basis. If it's good enough I imagine it would catch on. The limiting factor is presumably that that's a lot of investment for an experiment, but getting anyone else on board without a successful experiment is going to be impossible. (well, also, you have to have a good enough plan to be worth switching. I don't think dart/flutter was that.) A nice starting place would be if one of the major browsers added an easy to use extension point for swapping out languages. (at least I'm not aware of this existing, nor that I've looked)
    - lmm 1y ago
      > A nice starting place would be if one of the major browsers added an easy to use extension point for swapping out languages. (at least I'm not aware of this existing, nor that I've looked) What would that actually mean in practice that would be different from how Dartium did it?
beejiu 1y ago
An engineer could build that much faster than it would take to build an animated GIF in an editor. (For a start, it's a much more complex animation than 6 frames.)
- xp84 1y ago
  Does it need to be more than 6 frames to serve its purpose? It's 3 wiggling bars to be stuck into a 1/4 inch spot inside a button to serve a purpose of communicating a boolean state (sound happening or not?). The artist who actually designed that probably spent an hour plus getting it just right, wasting a ton of time before the engineer even wrote the "clever" GPU-destroying CSS, and then he had to rewrite the second version after discovering how resource-wasteful the first version was.
pixl97 1y ago
Embedded doesn't require a new tcp connection to the server and can be a speed up depending on a number of factors.
- xp84 1y ago
  An icon served from an <img> is going to be served from browser cache (disk or even RAM) after the very first time it's encountered. Unless you're building something designed to be used for one visit ever (maybe a promotional landing page?) it's better to have a few more requests (HTTP2 especially makes this a non-issue anyway) and have a cache full of assets than to make your dynamic webpages bloated.
deathanatos 1y ago
> I could have built this 25 years ago with a single GIF with about 6 frames, that was a couple of kilobytes and would be performant on the (relative) potato computers we had then. […] But modern "web designers" feel the need to spend how long carefully crafting that CSS animation which adds dozens of lines of code to the codebase and burns a ton of CPU...why? Just because you can, I assume? The animation (which is not suppose to be constant/static) conveys whether audio is being picked up by the application. I.e., it's VU meter.
- efilife 1y ago
  Hey, grammar police here. The animation is supposeD, like in "watcheD" not "watche". Its meter, not "it's". Its means possession, it's is a contraction that means "it is"
- xp84 1y ago
  I can't use the app in question, but I haven't seen any proof it doesn't just "dance when receiving audio". If it tracks amplitude and pitch, I'd still say it's overengineered, since in practice no one can discern anything useful except 2 or maybe 3 states (silent, quiet, not quiet).
  - deathanatos 1y ago
    True, the article didn't say that it for sure isn't being used as a glorified GIF, but … why not just give the benefit of the doubt that it UI element is doing the thing the UI element ought to do? Then, "Here's how that turned into a performance problem" followed by the rest of the article. > I'd still say it's overengineered, since in practice no one can discern anything useful except 2 or maybe 3 states (silent, quiet, not quiet). For most use cases … that's all that's necessary? It helps confirm that the audio equipment and various software layers are working. … like I use these UI elements all the time, because Bluetooth has decided that "nah, I'm not going to connect, even though every device reports as connected".
    - xp84 1y ago
      We agree that 2-3 states is all we need to discern -- I was just saying that if it's actually wasting even more CPU by truly analysing both the amplitude and frequencies in the audio, I'd chastise whoever decided to do that for wasting time when "sound" "quiet sound" and "loud sound" serves 100% of the use cases for this widget. And the above is a separate question unrelated to implementation. A true VU meter in CSS animation is the most overengineered, a glorified GIF built as a CSS animation is somewhat overengineered, and a couple of simple GIFs is the simplest.

by xp84 1y ago

nawgz 1y ago

Yes you're right, most users LOVE barebones and classic websites, that's why HN is so popular and Reddit hardly has any users. For that matter, do we really need colors? Just ship it with browser default styles.

seemaze 1y ago
Exactly this! I wish the entire web was easier to read on my e-ink device.
LastMuel 1y ago
I hear your snark, but Reddit isn't exactly a beauty contest winner.
- makapuf 1y ago
  Yeah I was thinking "but..." ah but yes I use old.reddit.com. well, case in point.
deleted 1y ago
[deleted]
xp84 1y ago
I think it's funny that you think sites can't be attractive unless they include many megabytes of complex JS and CSS on every page. Craigslist lasted and was dominant a whole extra generation of the Web until Facebook Marketplace unseated it without even bothering with colors and certainly no animations. And FBM didn't win on clever animations and React UI complexity, it just won based on the fact that it was easier to detect Nigerian scammers since you can see when the buyer's FB account was created and a few other cues. Users don't care how clever your programmatic animations are. They hate how slow your site is. Look how much Jira sucks now. It's more sluggish on an M4 Pro than it was on my Core i5 in 2013 because of how much frontend bloat they've added in the meantime.
filleduchaos 1y ago
This seems like a rather knee-jerk response to someone arguing that they can build the same UI with less.

jakubmazanec 1y ago

GIFs don't scale well (including 2x version is not enough); with CSS (and SVG) you get crisp graphics at any scale. And of course you can use asset SVG files that are cached [1]. [1] https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/Element/use https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/E...

xp84 1y ago
Citation needed for 'GIFs don't scale well' (in terms of dimensions. They certainly don't scale well when abused as idiotic versions of videos.) Is this the frontend developer's version of "Postgres doesn't scale. Mongo is Webscale"? Here's a 640x640 GIF. Scales just fine for me, to half-size or to 100px. I'm using a "Retina" screen. https://cdn-icons-gif.flaticon.com/6172/6172533.gif https://cdn-icons-gif.flaticon.com/6172/6172533.gif
- Sharlin 1y ago
  That GIF weighs one third of a megabyte. You could literally fit a fully featured bespoke 2D/3D rendering engine in the same space. Now, it could probably be optimized, but an aPNG would likely be vastly smaller. And these days aPNG is even reasonably widely supported! That said, an animated SVG would likely be the best option.
  - xp84 1y ago
    What is your point? The random first GIF I found is enormous in pixel size and many frames, thus large in filesize, but a few dancing green blobs would be tiny. You don't need that one's 640px size to scale, and 2x will work perfectly fine.
- supermatt 1y ago
  I’m looking at that on an iPhone, and if I scale (in either direction, pinch or zoom) it I can see a semitransparent halo around it, I would assume from the antialiasing. So that certainly isn’t scaling well for me.
- beejiu 1y ago

panic 1y ago

Won’t the GIF also burn a ton of CPU? I’m not convinced it would actually be more performant than sliding textures around.

xp84 1y ago
Try it yourself. Here is a 640x640 gif: https://cdn-icons-gif.flaticon.com/6172/6172533.gif https://cdn-icons-gif.flaticon.com/6172/6172533.gif That tab is using 4-5% CPU on my M1 Pro, and I also have a "GPU process" in my task manager, which is showing about 8% in the "CPU" column when it's onscreen. So, no, using a 64x64 GIF (1/100th the area of my example) you'd need to do this animation would absolutely not use any significant CPU or GPU. Which is why those worked very effectively to animate small icons with zero lag on the potato computers we had in 2000.
wetpaws 1y ago
[dead]

MITSardine 1y ago

The app taking "only" 6% of a $3k laptop's CPU to show two lines of text and a little 2D animation also gave me pause, but maybe this is just how it is. Still I wonder how people were squeezing pacman out of prehistoric machines, and we're using an 80's supercomputer worth of CPU power (not that far given they were in the ~ 1 GFLOP range) to animate three green bars today.

xp84 1y ago
They actually knew how to code back then. I fancy myself someone who cares about performance and take a great effort to not do wasteful stupidity like those CSS animations for a decorative element, but compared to 80s programmers, I'm actually a complete fraud, because I do everything in interpreted languages that do 10,000 things behind the scenes for every line of code I write. I could never make an Atari computer or NES work. There are of course a few who do, they all either work on embedded systems or making homebrew for retro computers. So much respect for that level of skill!
- Varelion 1y ago
  I aspire to be one who cares about performance, but I would like to address: "I do everything in interpreted languages that do 10,000 things behind the scenes for every line of code I write." Is it even possible to create a modern website, or product, without this? How long would the development cycle take, if everything is to be written in C? I'd wager that replicating a "minimalist styling" for a react-based website with a dozen or so components would take dozens of times longer to produce.
  - drdec 1y ago
    > How long would the development cycle take, if everything is to be written in C? Once upon a time I worked on a website backed by C. Development times were not appreciably longer. We had a in-house templating language for generating HTML (also written in C). That implementation got to the complexity point to where even the original devs did not want to touch it to add anything. But in terms of add a new screen collecting fields x,y,z it was fine. This was a job board, allowing search, applications, saved resumes, bulk opening uploads, i.e. there was some real functionality there.

sampullman 1y ago

Why the embedded SVG hate? A simple icon should be just a few hundred bytes, is reusable, and styleable with CSS. It's not the right fit 100% of the time, but I think it's a very nice feature to have.

zdragnar 1y ago
They're generally static documents that could be served independently, and thus cached, like an image. Many times, though, they're served up inline in the JavaScript code that templates the html, and thus is cached less aggressively, especially if the FE is deployed frequently.
- makapuf 1y ago
  Wasting hundreds, well maybe a thousand of bytes in the process ! (I understand it's better to cache and things can go out of hand fast. But we're talking about small animations here.
  - zdragnar 1y ago
    I don't disagree at all. There's way bigger fish to fry when it comes to maximizing network efficiency in websites. I'm just pointing out the rationale of OP since someone asked, and I've worked with people who've made this and similar arguments before. It's been awhile, though- the ones I'm thinking of would treat code golf as a best practice for CSS (only slightly exaggerating).
    - makapuf 1y ago
      Of course, we both agree.
  - xp84 1y ago
    Believe me, a few kb on every icon on every pageview adds up to a lot of wasted bandwidth and not everyone is on a gigabit connection at all times, even fancy iPhones are on shitty connections a lot more than you think. Inside parking garages, on deprioritized LTE, etc.

ajkjk 1y ago

This contempt is misplaced. It is obviously better in one sense to generate an animation on the fly using a short program instead of encoded its literal pixels in a much larger amount of data even after compression. The ecosystem has largely moved towards that abstraction because it scales better for virtually every purpose, particularly for rendering in different formats. Now web developers are brought up inside the abstraction and so don't even think to go outside of it by default. Which would be fine, except that the abstraction isn't designed very well: the browser is massively underpowered at building applications in an foolproof way. Part of that is historical cruft and part of it is (imo) a lack of vision--there should have been a (not-backwards-compatible) replacement for html/js/css years ago which solves its fundamental abstraction problems. But anyway the present is still much better than the past. You must be nostalgic for the era when all monitors were the same size and websites weren't expected to do anything without reloading the page.

bobthepanda 1y ago
The problem is that everyone (browsers + developers) need to agree on a replacement, which is notoriously hard to do. Chrome got laughed out of the room with Dart/Flutter.
- ajkjk 1y ago
  Well they don't really. What ought to happen is someone just makes a new browser (or adds support in an existing browser) unilaterally on an experimental basis. If it's good enough I imagine it would catch on. The limiting factor is presumably that that's a lot of investment for an experiment, but getting anyone else on board without a successful experiment is going to be impossible. (well, also, you have to have a good enough plan to be worth switching. I don't think dart/flutter was that.) A nice starting place would be if one of the major browsers added an easy to use extension point for swapping out languages. (at least I'm not aware of this existing, nor that I've looked)
  - lmm 1y ago
    > A nice starting place would be if one of the major browsers added an easy to use extension point for swapping out languages. (at least I'm not aware of this existing, nor that I've looked) What would that actually mean in practice that would be different from how Dartium did it?

beejiu 1y ago

An engineer could build that much faster than it would take to build an animated GIF in an editor. (For a start, it's a much more complex animation than 6 frames.)

xp84 1y ago
Does it need to be more than 6 frames to serve its purpose? It's 3 wiggling bars to be stuck into a 1/4 inch spot inside a button to serve a purpose of communicating a boolean state (sound happening or not?). The artist who actually designed that probably spent an hour plus getting it just right, wasting a ton of time before the engineer even wrote the "clever" GPU-destroying CSS, and then he had to rewrite the second version after discovering how resource-wasteful the first version was.

pixl97 1y ago

Embedded doesn't require a new tcp connection to the server and can be a speed up depending on a number of factors.

xp84 1y ago
An icon served from an <img> is going to be served from browser cache (disk or even RAM) after the very first time it's encountered. Unless you're building something designed to be used for one visit ever (maybe a promotional landing page?) it's better to have a few more requests (HTTP2 especially makes this a non-issue anyway) and have a cache full of assets than to make your dynamic webpages bloated.

deathanatos 1y ago

> I could have built this 25 years ago with a single GIF with about 6 frames, that was a couple of kilobytes and would be performant on the (relative) potato computers we had then. […] But modern "web designers" feel the need to spend how long carefully crafting that CSS animation which adds dozens of lines of code to the codebase and burns a ton of CPU...why? Just because you can, I assume? The animation (which is not suppose to be constant/static) conveys whether audio is being picked up by the application. I.e., it's VU meter.

efilife 1y ago
Hey, grammar police here. The animation is supposeD, like in "watcheD" not "watche". Its meter, not "it's". Its means possession, it's is a contraction that means "it is"
xp84 1y ago
I can't use the app in question, but I haven't seen any proof it doesn't just "dance when receiving audio". If it tracks amplitude and pitch, I'd still say it's overengineered, since in practice no one can discern anything useful except 2 or maybe 3 states (silent, quiet, not quiet).
- deathanatos 1y ago
  True, the article didn't say that it for sure isn't being used as a glorified GIF, but … why not just give the benefit of the doubt that it UI element is doing the thing the UI element ought to do? Then, "Here's how that turned into a performance problem" followed by the rest of the article. > I'd still say it's overengineered, since in practice no one can discern anything useful except 2 or maybe 3 states (silent, quiet, not quiet). For most use cases … that's all that's necessary? It helps confirm that the audio equipment and various software layers are working. … like I use these UI elements all the time, because Bluetooth has decided that "nah, I'm not going to connect, even though every device reports as connected".
  - xp84 1y ago
    We agree that 2-3 states is all we need to discern -- I was just saying that if it's actually wasting even more CPU by truly analysing both the amplitude and frequencies in the audio, I'd chastise whoever decided to do that for wasting time when "sound" "quiet sound" and "loud sound" serves 100% of the use cases for this widget. And the above is a separate question unrelated to implementation. A true VU meter in CSS animation is the most overengineered, a glorified GIF built as a CSS animation is somewhat overengineered, and a couple of simple GIFs is the simplest.