Page performance is a function of 1) queuing requests, 2) waiting for the browser to connect to the network, and 3) waiting for requests to complete and transfer data.
More network requests made from the browser create a higher potential for network-level latency, race conditions, callback queuing, render thread resource blocking, etc. We try to absolutely limit the number of requests. Our inital javascript payload is just a single request. That single request will then make a single request to render the autocomplete widget, and a single request to render the results widget. If you have selected to enable quickshop for product results, that will result in just a single additional request of 4K. In addition to these requests, we have a few images requested here and there for icons and such. That's it!
This is a generalization, but a safe generalization. Let's use use JQuery as an example. It is a browser library on top of bare javascript that saves developers an incredible amount of development time. It's really great. But...it's an extra 30k of data to the browser. Furthermore, it prioritizes ease of use over performance in certain cases. The closer you can get to the core language, the faster you go.
Furthermore, by using libaries to abstract code intent, there are pockets of poor performance or lazy patterns that go unnoticed by the developer.
Javascript animations are expensive in three ways, 1) they require almost 10x the amount of code, 2) they require more memory and processing power from the browser window, and 3) the user is conditioned to wait for animations to end before taking action. More animations in code can drastically affect the page load and severely impact rendering performance (particularly in low-memory/low-CPU environments). More animations slow down the browser. More animations slow down the user. Slow is bad!