[HN Gopher] Skypack - A new kind of JavaScript delivery network
___________________________________________________________________
Skypack - A new kind of JavaScript delivery network
Author : bryanbraun
Score : 19 points
Date : 2020-07-13 21:31 UTC (1 hours ago)
(HTM) web link (www.skypack.dev)
(TXT) w3m dump (www.skypack.dev)
| lilyball wrote:
| Does this support subresource integrity?
| billyhoffman wrote:
| 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.
| ss3000 wrote:
| 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. Curious where I could read more about the architecture
| behind Skypack?
| 1f60c wrote:
| 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/
| pier25 wrote:
| 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?
| flaque wrote:
| Why the rename?
| 1f60c wrote:
| I'm curious about this as well, and the search box still refers
| to Pika.dev
| cosmotic wrote:
| Oh, it's modern? What does that mean =/
| fxtentacle wrote:
| 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.
| blaisio wrote:
| 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.
| Quekid5 wrote:
| > 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?
| blaisio wrote:
| 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.
___________________________________________________________________
(page generated 2020-07-13 23:00 UTC)