Dealing with third-party libraries
In Do you know where your third parties are going? we discussed part of the problem: How to measure the additional impact these scripts have on our site's performance when they add more scripts that may block rendering?
This post will cover some additional concerns I have with third-party scripts.
We need to evaluate third-party libraries for use in our applications. This doesn't mean to only look at the code and decide which one you like best but it also means to test the code in your application and see which library or script works best in your specific situation.
I first start by researching what others have said about the libraries and how they've compared them. There's been plenty written about the libraries and their differences:
- momentjs vs date-fns
That's just a starting point, I will then run tests to validate the opinion I formed from reading other people's research. I may have constraints that are not present for the people who wrote the articles I read and vice-versa.
Some of the questions I would ask, based on research and needs.
- Does the library affect performance due to size? The larger a library is the longer it'll take to download and parse before it can be used
- Is there a way to reduce the size of the library without using bundlers? Lo-Dash and Date.fns also provide modules for individual properties for use with common.js require statements
- How easy is it for a bundler like WebPack or Rollup to tree shake the library to remove unused code from this package?
- Am I required to use modules and/or transpiler to make the library work?
- Am I already using modules or bundlers?
- Do I have to support browsers that don't support modules or imports?
- Is there an existing API in the ECMA 262 specification that does what I need?
- Is the proposal part of the ES262 spec? Meaning has it already been published or is at stage 4 waiting for the next version of the spec?
- If it's not at stage 4 then what stage? What browsers have implemented the proposal before moving to stage 4?
The last point is important. As ECMAScript continues to evolve, new proposals will appear that will provide native support for the feature only in browsers that support the feature when it reaches stage 4 in the TC39 development process and becomes part of the annual specification.