3 ms·

Love it. I've been thinking [0] about this a lot lately. My rule of thumb these days when tempted to introduce a new dependency is try to build it from scratch

Love it. I've been thinking [0] about this a lot lately. My rule of thumb these days when tempted to introduce a new dependency is try to build it from scratch first. I might spend 1 hour or 1 day, depending on my estimates of the costs/savings in the long term. I often find I just don't need the dependency. Sometimes I do, but after trying to build it myself I can fully justify why (to myself and others), and also understand how to use the dependency better. A few months ago I wanted to add an issue reporter to the help page of our open source genetics data visualization tool https://bam.iobio.io https://bam.iobio.io. I threw something together in less than 100 lines of code [1]. It doesn't even include any rate limiting or security measures. A couple weeks back I ran into a slight wrinkle that brought into question whether to keep using the tracker. I quickly analyzed the number of issues that had been submitted (including a recent influx of layman users), and simply removed it. Email support works fine for us based on our usage data. The decision was made easier because I didn't invest a bunch of time up front integrating with some external service, or building a 100% solution the first time around. > It certainly didn't help, that our former A/B testing tool emphasized short-term wins. When we added a huge sales overlay, it appeared to bring more conversions — since the return visitors were ready to take action. The new visitors probably hit the back button as soon as they arrived. This is great. All of your analytics insights are completely dependent on a) measuring the right thing and b) interpreting it correctly over the long term. EDIT: I do want to mention that these articles always point out downloaded code size as a primary factor in the decision, but I rarely see any data showing how the reduction in code size translates into an improved user experience, based on the principles of human perception. In my experience, the really big gains come from techniques like background fetching. Not that code size isn't important, but I think the main point should be the reduction in complexity that comes with it. That pays dividends in developer time and avoiding bugs, which translates directly to an improved user experience. [0] https://anderspitman.net/11/dependencies/ https://anderspitman.net/11/dependencies/ [1] https://github.com/anderspitman/issued https://github.com/anderspitman/issued

ratww 7y ago
> I do want to mention that these articles always point out downloaded code size as a primary factor in the decision, but I rarely see any data showing how the reduction in code size translates into an improved user experience, based on the principles of human perception. In my experience, the really big gains come from techniques like background fetching. Size is a huge factor when you're on a limited data plan. Maybe one website won't make a difference, but it adds up.
- anderspitman 7y ago
  Not saying you're wrong, but again I never see these claims backed by data. My guess is most people eat their data plan with video and Spotify, not overweight JS.

ratww 7y ago

> I do want to mention that these articles always point out downloaded code size as a primary factor in the decision, but I rarely see any data showing how the reduction in code size translates into an improved user experience, based on the principles of human perception. In my experience, the really big gains come from techniques like background fetching. Size is a huge factor when you're on a limited data plan. Maybe one website won't make a difference, but it adds up.

anderspitman 7y ago
Not saying you're wrong, but again I never see these claims backed by data. My guess is most people eat their data plan with video and Spotify, not overweight JS.