3 ms·
The problem I have with this is the same I have with all public js CDNs: Your project doesn't just use public js files. You are almost guaranteed to also have c
by lerouxb 13y ago
The problem I have with this is the same I have with all public js CDNs: Your project doesn't just use public js files. You are almost guaranteed to also have custom javascript (which could itself be opensource or not. irrelevant), css, possibly fonts, images, etc.
You can't put your static files on that public cdn. So either you have to serve it up yourself or you have to put it on your own CDN (either one you run yourself or a managed one).
So you have an additional point of failure (because your static files are coming from at least two places rather than one) which multiplies the chances of something going wrong for little benefit in my opinion.
Deployments are likely to be much more complex too, etc.
And before someone mentions the limit of how many concurrent requests a browser will make to a host: That's also irrelevant. I'm not arguing that you should have loads of little files. You should still be combining things with build tools. In fact if you host those "vendor" files on your own webserver or cdn you actually have more flexibility around how to combine them. And you can still have multiple subdomains and ip addresses or whatever pointing to the same CDN to try and optimise around that if you want.