The first question is... why?
In the current web app world saving time and network when a user enters into our webpage means a higher ch...
For further actions, you may consider blocking this person and/or reporting abuse
Really really well-written
Thank you so much Ben!
Hello Sebastian!
First of all thanks for taking your time to read the article.
You are totally right when you say that a difference of 2.3kb shouldnât be taken as a con. What I was pretending when I wrote the article was give visibility to the fact that different approaches for a similar problem end up with an increase of bundle size.
But theres nothing wrong at all into an increase of only 2.3kb
Thank you for your time sebastian!
Hey Carles! You demonstrated a firm and relying approach to analyzing existent solutions available on
the marketnpm registry.I'm thankful that now I have a reasonable article I can share with developers (especially, juniors lacking experience in the matter you explained).
I'd also like to share a few cents from my experience on criteria that are used for selecting a library.
Stars - I suggest weighting this metric as the least important when going through library selection process. People tend to use stars as a sign of popularity and thus a basis that the library can be dependent upon - while popularity and trustworthiness may overlap, the first is not the guarantee of the second.
I would rather recommend relying on a library with only 400 stars having good PR merging trend and up-to-date tests than on a library with 4k stars having a couple of tests altogether and only rare visits to the issues from maintainers.
I believe, Carles implied this in the article but because It didn't get enough attention, I decided to elaborate.
Tests - when selecting a library, check whether there are any tests and whether they are green. You can simply clone the repo and run
npm run test. It is not 100% coverage I usually looking here for, but rather a number of tests the prove the main functionality is working (sometimes worth checking on different platforms) and that you can actually read and understand the tests well.This way (when there are tests and they clearly understandable), you may fix an issue if it is ever found in your project, without discarding the library altogether (which in some cases may require to re-write a lot of code and may cost quite a few resources of your team).
Even if the library maintainers do not respond to the pull request, you can still bring the fork to your company's npm register (if available) or create your scoped npm package (e.g.
@your-name/lazysizes).Hopefully, these few points will be useful to engineers bringing new packages to their projects.
Thanks again for the article, learned quite a few things myself. Never went as far as diving into an engine implementation details myself, but will sure try this out đ
Hey Vitaly thank you so much for your explanation it will be helpful for alot of people too.
Yes, Star number on a repo is not the most important metric to look for when deciding which library should we use but is ok to have a look to it. As a funny history about why stars are not that important... Iâve been working with react for more than five years and I realised THIS YEAR that I wasnât starred the repo yet đâïžđ€Šââïž
Glad to have your feedback Vitaly!
Awesome article Carles!
Thank you! Hopefully it will help people in the future! :)
Share that article if you feel that can be helpful to other people!
Anytime! And yes for sure đ
Thank you! This is really interesting đ€©
Thank you for taking your time to reading it!
đ saved me a ton of time here, I was about to start looking for info. Outstanding.
Hey Adam! Happy to hear that. If you need any help during lazy load implementation ping me here or at twitter @carlesnunez :)
I'm using native for a long time, had no complains. And what is great with native is that it is native, and will be improved across the time, like all other native features.
Hello Pawel! Thanks for your comment.
Different point of view and probably need for a webapp between your cases and mine.
Native lazy load will be a thing but IMHO is not enough mature yet to adopt it at least in my scenarios.