So in the end, their hosted copy might be much larger than if you had hosted an optimized copy yourself.
Using their service, it is also impossible for you to merge small dependencies and your application logic into one file to reduce the number of HTTP requests. The resulting higher number of gets might well make it slower than not using their CDN in the first place.
The number of HTTP requests really does not matter much these days, because of HTTP2. And again for people who use this service and get a speedup from it, it doesn't matter because it is cached.
I was under the impression that parsing (etc.) time matters as well, not just raw download time/latency?
But you could upload your optimized copy to their platform right?
The net result is a service that can't pay for itself—because such a small percentage of users require the paid features—leading to the service shutting down (breaking every site linking it), demanding money later (breaking most sites linking it), or getting acquired by a company that might inject unscrupulous code into packages.
Charge _something_. Anything.
Cloudflare has managed to build a massive business on the back of giving away a lot more bandwidth.
Even if they charged $1/mo, they'd be infinitely better off than where they are now. Giving away something that's cheap is not a good business model, especially when the thing that's cheap doesn't hit meaningful economies of scale until well after it's not cheap anymore.
Hopefully they've calculated the growth cost of their premium tiers and how much they can give away for free...
Otherwise, it's great for side projects!!
So the question I think is: is it cheaper for the customer to upgrade to a paid account or switch to another provider that only has paid accounts?
There are a lot of Dark Patterns around this. I'm not sure we should be supporting that behavior. Objectively, it's better for me to have a paid account at a place that charges $10 a year to entry level customers.
An alternative could be to add limits to the free tiers.
While I appreciate the free service, I work in the web performance space. I've seen third party widgets from big name companies like Optimizely, Tealium, Pubmatic, and Adobe have slow response times for critical content, delaying the entire waterfall for major sites. Its hard for the big companies to whom you actually pay money to get this consistently right in a way that doesn't slow down the page.
We've had a ton of people taking cracks at this. From Google and Microsoft with their "Ajax" CDNs a decade ago, to unpkg and Cloudflare. And yet I still have not seen any of these special JavaScript-specific CDNs ever beat a vanilla CDN dumbly serving JS packages that you yourself have bundled and optimized under normal site traffic.
Coincidentally jspm.dev, a similar ES modules CDN in this space recently released a new version as well: https://jspm.org/jspm-dev-release
Their release post had a lot more technical details (including their strategy for code splitting which is critical for the production use case) so I'm inclined to trust them a little bit more for production use cases. Curious where I could read more about the architecture behind Skypack?
e.g to load lodash's es6 defer module (targeting a specific commit): https://cdn.jsdelivr.net/gh/lodash/lodash@898b378f06/defer.j...
^^ to be used in an import statement or <script type="module">
[edit: example]
edit to add: I don't disagree with anything you wrote. :)
> Skypack (Previously: Pika CDN) has already served over 2,000,000+ JavaScript packages across 4,000 unique domains, powering websites around the world.
[0]: https://www.pika.dev/I wouldn’t even see it as an issue if Skypack decide to throttle free plans at some point because their costs are too high. I mean you get what you pay for!
Why is nobody hating on CloudFlare for their free plan? On Heroku for their free dynos? On AWS for their numerous free tiers? The list is soooo long!
Let the guys be, let them try a few things until they find a niche and a business model that fits them.
While I mostly agree with your statement, the answer to this question is quite simple: The free tiers are limited in resources and they have enterprise tiers that pay for the actual service and grant you all features. You know what you are getting upfront. If Skypack will - as you suggested - throttle plans in the future (or whatever they come up with) that's not the same product anymore you started with. You most likely need to adapt your own product to this changes, which is usually paired with costs on your side. You won't have that happening on CloudFlare, Heroku or AWS. Also there are exit strategies, contracts, SLAs and so on. Something like Skypack may go offline tomorrow and that's it.
So people might just wake up one day, only to find out this service just disappeared because they ran out of money. I would say this would be bad, even for an indie developer or a small company, but any larger company wouldn't even take this risk.
You will deploy ES5, ES6, and ESM and then Skypack will decide what to deliver to the browser?
This was not really true back when browsers allowed sharing caches between domains because of different versions and fragmentation of CDNs, and is definitely not true now when a.com and b.com would not share a cache for skypack to avoid fingerprinting.
If it were a FOSS library that really provides some value, there are thousands of ordinary developers who would convince their managers to throw a piece of their budget at supporting the maintenance of it. I doubt most of the developer-focused tools we sponsor through my company would make it on their own with a full-blown SaaS model (could you imagine webpack as a service?).
Github’s sponsorship model looks especially promising and is what I’ve been recommending to other people I know who are making niche developer tools.
Oh God please no.