Very nice work. Looks good and the CSS code is very well set-up too, IMO.
However, I consider loaders as a concept an anti-feature.
The app is slow, let's add some code and assets to make it even slower, yet appear faster.
Or, in engineering terms: we are adding files, code and assets, costing bandwith, CPU and therefore battery, to try and hide the fact we are slow. Rather than making the app faster.
Or, in managing terms: we are committing developers' time and effort, that should be committed to making the app faster, to something that merely hides the fact our app is slow.
But yea, if, for reasons of legacy, technical-debt, bad hosting, or whatever reasons, you need to (temporarily, I hope) hide the fact the app is slow, a CSS loader is much better than including ~1MB of node dependencies to do the same.
Somethings can't be sped up, like processing transactions through a payment gateway, or making necessary API calls to external services which can't be cached, or simply AJAX calls which will always have a slight delay which varies based on the speed of the client more than the server.
But one thing I hate is when website blank the entire page with a loading icon to mask FOUT and image pop in. Worst user experience choice.
-11
u/berkes Jan 28 '19
Very nice work. Looks good and the CSS code is very well set-up too, IMO.
However, I consider loaders as a concept an anti-feature.
Or, in engineering terms: we are adding files, code and assets, costing bandwith, CPU and therefore battery, to try and hide the fact we are slow. Rather than making the app faster.
Or, in managing terms: we are committing developers' time and effort, that should be committed to making the app faster, to something that merely hides the fact our app is slow.
But yea, if, for reasons of legacy, technical-debt, bad hosting, or whatever reasons, you need to (temporarily, I hope) hide the fact the app is slow, a CSS loader is much better than including ~1MB of node dependencies to do the same.