Skypack – A new kind of JavaScript delivery network | Hacker News Reader

Skypack – A new kind of JavaScript delivery network

skypack.dev

122 pointsbryanbraun47 comments

I really dislike that this is free by default, and the paid version is done in the style of NPM (free for everything except private packages, custom subdomains, support). Bandwidth is not free on a global CDN. All it takes is one guy linking a dozen packages from his insanely popular WordPress theme or a poorly-built site ending up on the front page of Reddit to drive costs through the roof. Even if you managed to build out your own DIY CDN, you'll need big pipes to avoid choking every morning when folks open their browsers. Good caching headers won't save you.

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.

It seems the goal is for 'Premium users' to subsidise the costs of 'free users' many popular companies do this including; Github, npm, gmail etc.

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!!

But that subsidy shows up as higher prices for people who want to switch to a paying account.

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.

especially for subscription services, I have the feeling that the jump from $0 to $10 /mo is far, far higher than the jump from $10 to $50 /mo, and the difference between $0->$10 $0->$50 is fairly low, in terms of how people approach payments. Ofc, I have nothing legitimate to back this up.

But if I'm correct, and that people are more payment-adverse than they cost-conscious, for online subs, then it's generally correct to follow the subsidy-model rather than anything else. Subsidization is anyways far superior to the advert-model -- though it can be abused when taken to the extreme, e.g. gaming whales + gambling mechanics, but in a corp-to-corp setting I'm not seeing to much risk there. The other side of it is that enforces monopolistic structures -- essentially forcing global market share by leveraging your enterprise weight -- which is more concerning to me but seems to be generally inevitable (gov intervention is really the only thing stopping monopolies from existing, because really by all right its a perfectly valid market strategy)

I'm assuming I'm correct because companies keep implementing/switching to this model (and this is the best reasoning I can think of), but maybe its just part of a non-intelligent fashion trend (signalling difference from LEGACY software model to MODERN)

The payment averse bit is some learned helplessness due to a codependent relationship.

Some people in the business world see money as a form of control and they like it. It doesn't matter if you want $10 or $5 million. They get to decide if you get it.

I don't think open source would have gotten as far as it has if not for this misbehavior. "Hey I'm using this new tool." "Well I'm not going to pay for it [so no]." "Oh that's okay, it doesn't cost anything, seeya." "..."

We shouldn't have to submarine things into a company and then say, "we have been getting for free then we have to pay money or you have to explain to all of these stakeholders why we have to take their toys away". It's extortion, and we are debased by having to do it.

I don't know that I have a solution, I just think that pretending it isn't happening makes us accessories or at least enablers.

Bandwidth is not that expensive. Cloud providers have brainwashed people that basic egress should be 10c/gb or more. In reality, volume pricing and sustained use drops that massively.

Cloudflare has managed to build a massive business on the back of giving away a lot more bandwidth.

CloudFlare also lost a lot of money by giving away the bandwidth, but they consider it an important marketing tool. It still is a loss leader to them, at least according to their S-1 last year.

Even if it was an order of magnitude less than what AWS charges, it's still not free. I pay $4k/mo to Cloudflare for an amount of bandwidth I can easily see Skypack pulling down, and I'm able to pay for that with a sizable base of paying customers.

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.

Kind of agree.

An alternative could be to add limits to the free tiers.

They claim a high availability, but no data on P90 or P95 response times. There is no SLA on their free plan.

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.

Yeah, I think a service like this might be very useful for quick prototyping and proving out an MVP thanks to the native es6 modules, but I personally wouldn't rely on it for anything critical.

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?

Not that code-splitting is generally an issue with prototyping, but you can easily use native es6 modules straight from github (or npm) via services like jsdelivr.

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]

hey Billy. I run CDNs @ Optimizely. If you ever see something, please reach out. (My Twitter is in my profile if you want to DM.)

edit to add: I don't disagree with anything you wrote. :)

Hot damn! Will do

Thanks!

I thought "hmm, this seems a lot like Pika[0]!", only to find out it is Pika:

> 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 find this funnier than I probably should, but e I just finished going through the same discovery process. I'm excited to see Rollup support so I can use it with Svelte.

Amazing. I was just about to ask how this is different from Pika This sounds great.

I see so much hate in this thread. Do you know how many indie developers and small companies in the world rely on free plans and free tiers? I leave in Thailand where the average salary is $450/month, I can assure you a bootstrapped startup here won’t be paying for any SaaS service.

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.

I think that part of the hate comes from the fact that this is a fairly unknown service, and unlike Cloudflare, Heroku or AWS, they don't seem to have any other source of income.

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.

> 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!

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.

What they fail to mention is that you lose the ability to remove unused code, for example when you would otherwise import only some Bootstrap components' JS.

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.

You lose the ability to remove unused code, but for people using this, it doesn't matter, because it is cached anyway.

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.

> You lose the ability to remove unused code, but for people using this, it doesn't matter, because it is cached anyway.

I was under the impression that parsing (etc.) time matters as well, not just raw download time/latency?

Yes that's fair, with less code you have less to parse. Parsing time is ideally a negligible amount of time, especially because it can normally happen asynchronously, but for very large libraries I could see it being an issue.

"ideally"

You assume I can use HTTP/2. I've pleaded with my upstream service owners to no avail. Since they control network traffic, I have no choice.

What do you mean by upstream service owners? All you need for HTTP2 is for your browser to support it as you download from the CDN domain.

In my organization, someone else controls the traffic that arrive to servers that host things like CDN assets. And it's all HTTP 1.1.

Well yes and no, this will depend on how you build and serve the dependency graph. If they did their diligence with the production build you should be able to Optimize re-usability of common imports as well as optimizing modules to only import the bare minimum of what’s needed. Now granted as far as I can tell from a technical perspective in absolute terms you will always get the best builds tuning your builds locally, however it’s not all or nothing either

> So in the end, their hosted copy might be much larger than if you had hosted an optimized copy yourself.

But you could upload your optimized copy to their platform right?

I wouldn't be surprised if Skypack eventually supported the ability to remove unused code: that's a core concept in Snowpack, an unbundled development tool, also built by Pika CDN.

[1] https://www.snowpack.dev/#using-npm-dependencies

There are lots of libraries that don't really support dead code removal via stuff like tree saking anyway. React, moment.js, Bluebird, etc

> As more and more sites join, cache hits become more likely, making all sites load faster as a result.

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.

It’s a great idea, but using an unproven third party for something as critical as a CDN is likely untenable to most tech managers. Even if this is a magical remedy to site performance, it would require the clout of a big name like AWS to get real buy-in from decision makers.

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.

Someone please correct me if I’m wrong but wouldn’t this also allow for caching across sites? Meaning that once one site requests react@16.13.1 the browser should cache it so that once the user goes to another site that asks for the same version then the browser should serve the cached version. This would be an acceptable trade off for me as far as the lack of code splitting and tree shaking goes.

Why the rename?

I'm curious about this as well, and the search box still refers to Pika.dev

Oh, it's modern? What does that mean =/

It means it is due for a rewrite next year to keep that modern adtag.

Hah! We've been calling ourselves modern for the better part of 7 years. It's all in the eye of the beholder.

e.g. It's happy hour somewhere in the world. Bottom's up!

Does this support subresource integrity?

That's a browser feature.

It's a feature that requires baking the hashes of the resource into the HTML. This JSDN talks about optimizing the resource separately for different browsers (e.g. adding polyfills where necessary), which means it doesn't just serve up a single resource. Subresource integrity support would require the ability to ask the JSDN for the hashes of all possible representations of the file, as well as the assurance that these hashes won't change (e.g. the polyfill won't get updated to a new version).

So once there are bundler plugins, what is going to happen here?

You will deploy ES5, ES6, and ESM and then Skypack will decide what to deliver to the browser?

Ah, I think this is where Snowpack [snowpack.dev] would come in

> A new kind of JavaScript X

Oh God please no.

Reply on news.ycombinator.com