As I answered in this comment, the purpose of the article was to show that you don't have to use loaders everywhere in SVG files or when plugging in JS dependencies to do the same via Tailwind (especially if it is ALREADY used in the project).
It's not like I'm saying anywhere in the article, "hey folks, install Tailwind to make the loaders animation". No! There was no such thing in the article. Even in the title and description I immediately pointed out that it was Tailwind's built-in features I was going to talk about.
Further, in the article I wanted to share my experience. I do a lot of reviews of different web projects (mostly on UX) and I often see a picture like this:
Files like loader-for-X.svg can be very numerous in the project for each type of content loading (I counted over 25 in one project, for example);
They are not optimized through SVGO;
The size of such files is many times greater than it could be;
Hence this article was born. I in no way meant to hurt the feelings of the true SVG developers (can I call them that?) who move this wonderful technology forward.
Yes, I understand that the flexibility to write your own solutions would be higher, but not many project managers are willing to wait for a frontend developer to implement such a thing on pure SVG or especially JavaScript (which you will then have to maintain). Time-to-market in 2k21 is a king.
I never knew there were these many hurdles in using SVGs. But, I might always use CSS (Normal CSS or Tailwind) than SVGs from now on. Anyways, thanks for the info!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Seems justified from your aspect. But making your own code gives you more flexibility. Either way, we win.
As I answered in this comment, the purpose of the article was to show that you don't have to use loaders everywhere in SVG files or when plugging in JS dependencies to do the same via Tailwind (especially if it is ALREADY used in the project).
Further, in the article I wanted to share my experience. I do a lot of reviews of different web projects (mostly on UX) and I often see a picture like this:
loader-for-X.svgcan be very numerous in the project for each type of content loading (I counted over 25 in one project, for example);Hence this article was born. I in no way meant to hurt the feelings of the true SVG developers (can I call them that?) who move this wonderful technology forward.
Yes, I understand that the flexibility to write your own solutions would be higher, but not many project managers are willing to wait for a frontend developer to implement such a thing on pure SVG or especially JavaScript (which you will then have to maintain). Time-to-market in 2k21 is a king.
I never knew there were these many hurdles in using SVGs. But, I might always use CSS (Normal CSS or Tailwind) than SVGs from now on. Anyways, thanks for the info!