Hacker News new | ask | show | jobs
by CoastalCoder 792 days ago
This is one thing I never understood about web development.

I would have thought the risks from 3rd party production dependencies would make devs do all in their power to minimize them. But IIUC it's a somewhat common practice.

Is there something about the market dynamics that make this a reasonable tradeoff? E.g., the problems are rare and this somehow allows faster time to market?

(Asking as a systems programmer, very much not a web developer.)

7 comments

> But IIUC it's a somewhat common practice.

I don’t have any data but I really don’t think it actually is that common. I definitely heard it used a lot more in the 2000s jQuery era but not really today. Browsers even have isolated storage these days so the benefits really are infinitesimal.

I think it's fairly common. I was reviewing an implementation of a phone number input component last month. It looked great, changing the country code automatically showed the correct country's flag or vice versa select your flag and the country code updated, plus a bunch of useful phone number validation logic was provided, you just add the NPM package and use the resulting component and magic happened. But open up dev tools and you see that all the flags are being brought in from a CDN. The only fix is to fork the library and change asset paths in their code to self host. Many libraries are like this, icon collections, design system web components, whatever. If you're not vigilant it's easy to lazily include CDN hosted assets without explicit intent.
This is wild. I don't think this is very common.
Part of it is just because it's easier. There's a bootstrap theme I've used that relies on a Google font. Rather than package the font, which would require extra work on the webdev's part to serve locally, they just stuck a CDN URL in the css.
But the webfont is not crucial to website UX as a blocking 3rd-party <script src="..."> without async/defer in <head> is.
> I would have thought the risks from 3rd party production dependencies would make devs do all in their power to minimize them.

Tell that to any developer (not just web) that outsources everything these days e.g. authentication, storage, analytics, database, etc - you name it.

They think it's less risk (and this includes managers and directors in larger companies). Apparently in-house would take forever, cost more and be unable to maintain anything these days.

I don't get it either but it's the current train of thought / trend and is not tied to individual developers.

> the problems are rare and this somehow allows faster time to market?

Yep. Entire teams work on these products. You have a couple of options:

1. Use them

2. Make it internally with less staffing, resulting in an inferior product

Option 2 is viable if you really only need a small subset of features/deep customization, but if you run into the edges the problem space will explode on you. At that point, you either have to throw more resources at it or go 3rd party.

I'd imagine for many developers, the probability of something like Google's Hosted Libraries (https://developers.google.com/speed/libraries) going down or being hacked is far, far lower than the probability of their own site hosting having a problem.
Personally if I'm going to rely on someone to host it, I check if my hosting provider does it for me already. I believe Microsoft pre-hosts some JS packages. Google hosts fonts and such as well.

I also miss being able to host random CSS and assets on Tumblr.

Otherwise, it should be on my own CDN. Especially for enterprise sites.

It is because the data (web logs containing web pages, timestamps, ip addresses, cookies, etc) can be sold.
It's also because the big reputable third party CDNs are more reliable hosts with better uptime and SLAs than many of the sites that use them.
Nonsense. Your site is obviously running if it served the page that wants the fonts, so there's absolutely no way they're more reliable than the site that uses it.

Meanwhile, that third-party is effectively paying your bandwidth bill: You might want to trade some reliability in exchange for a lower bandwidth bill, but you should wonder why exactly that third-party is willing to pay your bandwidth bill at all.