Pika CDN – A CDN for Modern JavaScript

https://www.pika.dev/cdn

by vvoyer • 7 years ago

222 97 7 years ago

itsbits• 7 years ago

When I mention url like that in import, will bundlers like Webpack automatically downloads the js modules?

From what I understand, the idea is that you don't use a bundler, but let the browser download all the modules that your app needs - hence some features like the "differential serving" (a.k.a. polyfills added if necessary with UA sniffing).

djxfade• 7 years ago

No. But browsers with native ES module support will be able to import it. (You dont need a bundler if you target browsers with native support)

manigandham5• 7 years ago

The primary purpose is to serve packages as JS files in ES module syntax that browsers can use natively: https://www.pika.dev/blog/pika-web-a-future-without-webpack

bufferoverflow5• 7 years ago

So how is that different from any other CDN?

CDNJS is actually orders of magnitude more likely to have a cache hit than this new offering.

falsedan• 7 years ago

So how is that different from any other CDN?

I struggled to see the value-add, I think it does automatic bundling & inserts polyfills based on UA strings. The whole pika project looks like a rewrite/alternative to the npm servers, kind of like MetaCPAN is for perl's CPAN+search.cpan.org

I struggled because the landing page & about were very light on the project/product's overview, too details-focused for me and I suppose anyone else who wasn't already aware of it.

manigandham5• 7 years ago

It describes it in the first paragraph. It acts as a proxy to serve ESM JS files (for any top-level package that's already in ESM syntax) that modern browsers can use natively without a build/transpile step. Looks like they recently added automatic polyfills for older browsers too.

CDNJS is just a standard CDN that serves up files as they're packaged, but if you want a high hit-ratio then https://jsDelivr.com has the most marketshare currently, and more features.

bufferoverflow5• 7 years ago

"CDNJS" returns 5X more results in Google compared to "jsDelivr", so you're more likely to get a cache hit.

Are you sure it has the most marketshare?

raxxorrax• 7 years ago

The differential serving sounds like a neat idea. Naturally, everyone not using the newest version of Firefox or Safari will go to hell eventually, but until then it could really improve the web for a lot of people.

cjblomqvist• 7 years ago

How many bytes are typically spent on compatibility with older browsers? Have anyone made any research into this?

manigandham5• 7 years ago

It varies a lot depending on the browser features you're using, total script size, minification vs gzip compression, cache hit rate, etc.

My company is in adtech so our final bundles are 14kb (single TCP congestion window) for modern browsers, 30kb for Safari/iOS 10, and 75kb for IE11/IE10. We've seen similar doubling-of-size in other libraries for backwards compatibility, although we can probably drop IE10 soon and cut IE11 down by half.

zimbatm• 7 years ago

Can anyone explain how the differential serving works?

I get that they might have a User-Agent mapping to features. But how do they know which feature are needed by the loaded modules?

atonse• 7 years ago

Probably based on the polyfill dependencies that are included in the packages.

santialbo• 7 years ago

Does it inspect your code for potentially needed polyfills or do you need to specify a list of polyfillable features that you have used?

JasonSage• 7 years ago

It inspects the code for the package a request was made for and polyfills features it used. You get the module + polyfills in one response.

tzfld• 7 years ago

If I would be Google, I would create a service like this, and would slowly inject tracking code in every package served.

mrspeaker2• 7 years ago

Well, that's exactly what every CDN does: if you're a CDN you don't need to inject anything - people give away all their users' browsing histories by making them download files from your servers... the analytics are just your log files.

Lowkeyloki• 7 years ago

This is what the decentraleyes browser plugin is for.

https://decentraleyes.org/

tthisk2• 7 years ago

This is very good development for frontend development. Build systems like webpack were useful technology in earlier days. But they are presenting a big hurdle for newer less experienced developers to enter the frontend development space today. I would love to see a future where we can again run a webserver from a folder to serve a frontend in development.

I do wonder how modular css fits into the picture of es modules though.

giancarlostoro2• 7 years ago

I have been coding frontend, backend and other system things since at least 2007 and the state of web development scares me. I shouldnt need a build tool to get JS on a website. I should be able to just run JS on a website. The web went from extremely simple and usable to "oh my what the hell is this?" It gets worse when you code frontend on proprietary systems that are hard to extend. Ever had to override something in Bootstrap with your own CSS files?

asdkhadsj• 7 years ago

I mean, you don't have to use it, right?

I think the reason it is like that is because there were many problems with JS "back in the day", and so people felt they had to come up with solutions.

Just look at Svelte. It's a library about compiling JS to get back to the "just JS" days. I mean, it's more than that, but it's about reducing runtime complexity. So another way to think about it is that writing "old style simple JS" is so convoluted that the author felt the need to write a translation layer from modern frameworks to old style JS. Sort of a mindblower to me haha (though, I love and agree with Svelte, to be clear).

The great thing though is that you can still use plain old JS, right? Nothing has changed for you if you don't want it. So is there really a problem?

This "modern web" stuff is just people solving problems. Some of these problems are the fault of old JS/web. Some of them are problems of our own making. Remember how amazing modern UI frameworks were? It's because we had PTSD from horrible jQuery codebases. A problem of our own making.

So stick with what you like, and other people can use the more complex stuff. It's a win win, no?

kybernetikos• 7 years ago

You don't need to use these tools if you don't find it worth it. If you want to write the same sort of JS as we wrote in the old days you can still do that. If you want to write modern JS, you'll either need to restrict your audience to the most recent browsers, or you will need tooling to help you.

But it's perfectly possible to write a modern PWA using modern js, modules, and a library like react (loaded from a cdn) without any build step at all. I've done it, and it's not all that hard as long as you don't mind only targeting the latest browsers (and writing out a bunch of file names manually).

jessaustin3• 7 years ago

I don't know your situation, but ISTM you want to override Bootstrap with sass, not css? Also I wouldn't really call npm a "build tool". If you need a build tool, use parcel.

theon144• 7 years ago

I would love to see a future where we can again run a webserver from a folder to serve a frontend in development.

But you can, if you build the project and then serve the "build" directory.

If that's the step that's bothering you, you can just not use Webpack, that's completely possible for all major libraries I encountered.

tthisk2• 7 years ago

The accessibility of the ecosystem is just not good enough for more junior engineers. This used to be a real strong suit of web development, but it has degraded over the years. My believe is that ES modules could reverse the trend, and simplify web development.

ES modules could also bring sanity to dependency management within the ecosystem. It is interesting to see the approach Deno JS is taking here as well.

mtberatwork• 7 years ago

Build systems like webpack were useful technology in earlier days.

Is the JS world trending away from Webpack now? When did this happen?

sergiotapia• 7 years ago

A lot of people are moving to Parcel.

https://parceljs.org/

Webpack's complexity seems born out of necessity since back in the day a lot of things were just not there.

Parcel has no baggage and it shows in it's very lean offering that works without you needing to troll through stackoverflow, old github issues and forum links.

skybrian• 7 years ago

There's a reference to the "browser's shared module cache". Anyone know what that is?

indigochill• 7 years ago

Just a comment on the name: as a Python dev when I saw Pika I immediately thought the RabbitMQ Python package: https://pypi.org/project/pika/

May or may not be an issue for this project. Just bringing it up for visibility.

isubasinghe• 7 years ago

Yeah that is what came to my mind too, but the CDN part helped me realize that this was something else.

devalnor• 7 years ago

Very nice service but how do you manage the CDN subresource integrity (SRI) if the packages are different for each individual user?

It's possible to check subresource with es6 module but only if you know the signature first.(https://stackoverflow.com/questions/45804660/is-it-possible-...).

Even Webpack will not handle it with webpack-subresource-integrity (https://www.npmjs.com/package/webpack-subresource-integrity)

Of course HTTPS is strong but not a foolproof solution against man-in-the-middle attack.

tenaciousDaniel• 7 years ago

I could probably google this but I'm not well versed in security stuff. What would a MITM attack against HTTPS look like?

reaktivo• 7 years ago

Not sure if it can be considered a MITM attack, but without subresource integrity the developers have to blindly trust the Pika CDN to host the same script file on that URL.

SRI might be impossible to implement in this case, not only because of the Differential Serving feature but the fact, based on their examples, that developers should link to the major versions of projects, which would mean that the content under the URL will change.

This is where a reliable IPFS-like CDN would shine.

colde2• 7 years ago

There would be a number of ways to do this:

- Strip SSL by for instance blocking port 443 and hoping they fall back to HTTP.

- Get your own root certificate installed on the equipment of the user you are attacking. This is fairly common in corporate environments for instance.

- MD5 collision attacks (although almost every certificate would be SHA signed these days)

colde2• 7 years ago

SRI doesn't really protect against man-in-the-middle. They protect against somebody having access to manipulate the data on the CDN or a malicious CDN.

If an attacker is in a position to be man-in-the-middle and can already get around HTTPS, they might as well compromise the page loading those resources.

e12e4• 7 years ago

If you serve your start page yourself, or via a different cdn - then Sri would protect against malicious code from other cdns such as pika.

If, say, you serve example.com from one source, and link js via pika.cdn - then if pika is compromised, your site would be too. If using sri, the example.com infrastructure would have to be subverted.

All things being equal, mitm ssl or subverting a well run cdn is hard - but if you double the number of cdns in play, you make compromise of one of them twice as likely/easy. With sri, you get to keep your single point of compromise - but can leverage the benefit of a besboke cdn for your js. If any.

playpause• 7 years ago

Looks great, but I think the homepage should do more to convince me that I can trust it. Who runs it, how is it funded, is there any guarantee they won't run out of money and shut down, etc.

no_wizard2• 7 years ago

My company would buy into this if there were some kind of boilerplate contract you sold to a business/institution vs the Patreon page you have right now.

Just FYI, you're missing out on some dollars because of that. For better or worse, the bean counters at my work place won't approve anything less. I have a feeling I'm not alone.

If you can quickly whip up some boilerplate business checkout with an invoice, you'd make more than a few dollars today.

Spivak• 7 years ago

Forget the bean counters, the technical people shouldn't approve of this without some sort of SLA or business agreement. How would you feel comfortable depending on a 3rd party service you have no actual business relationship or SLA guarantees with?

They're seriously leaving money on the table, businesses would have no problem dropping 50k/yr on a service like this.

no_wizard2• 7 years ago

Thats a good point, actually.

This is something we've been looking for at my job, but we don't have the technical expertise to do it ourselves (a CDN is tricky business, not in our core competency). If an SLA that included support and/or customization as well as had a direct line to high level support for feedback, you could easily net 50K or more.

Seriously. I know my organization would be willing to pay even more than that. If you're reading this Pika founders, you should really give this some thought.

mfer• 7 years ago

What is the business model? Where does the money come to pay for the dev and hosting? This is the question I'm left with.

Nothing is free and I didn't find this in crunchbase.

Something is paying for it. Is it tracking people and selling it?

eternalny1• 7 years ago

It says it right at the bottom of the page!

Love Pika? Go Pro! Pika CDN will always be free, but you can support the project with a Pro Membership donation on Patreon. Get early access to upcoming production-only features.

pier253• 7 years ago

This is wishful thinking IMO.

What if in 5-10 years the volume is too big to be funded by donations? Will Pika sell to a malicious company? Will it shut down and kill everyone that depends on it?

pier253• 7 years ago

This is a great recent talk about this problem by the former NPM CTO in which she tells her story about NPM and proposes a new decentralized package manager:

https://www.youtube.com/watch?v=MO8hZlgK5zc

Roboprog• 7 years ago

Marketing data

The referred by string in the request tells them what page the user is loading which requires a script from this CDN.

They could have other business angles as well, but user tracking is certainly one possibility.

ktpsns2• 7 years ago

https://www.pika.dev/search?q=jquery -- so jQuery is not "modern" any more? That's quite surprising, giving for instance the dependency of the http://semantic-ui.com/ framework on jQuery (https://github.com/Semantic-Org/Semantic-UI/issues/1175)

vijaybritto• 7 years ago

I think what they mean by modern is that every new project nowadays doesn't involve directly manipulating the dom and everyone uses some new library or framework of their choice.

donatj• 7 years ago

All they are implying by "modern" is loadable with es6 modules.

cdata• 7 years ago

jQuery was originally designed and built in a bygone era (on the web / front-end timescale), includes many features that have landed and/or normalized on the web platform and also does not leverage the modern JavaScript module system.

Let's call it "retro"? :)

ktpsns2• 7 years ago

Unfortunately there is still need for libraries like underscore.js, which also covers some jQuery functions (which are not DOM-related).

wcdolphin• 7 years ago

I love the idea of a more efficient CDN for JS (and code overall!), but it isn’t clear to me how this handles the multitude of versions. None of the examples seem to include versioning, which is a huge oversight IMO. A future I see is IPFS for this sort of thing. All objects identified uniquely, but cacheable by multiple entities.

justinrlle• 7 years ago

Well, the first example looks like it includes a version:

    import {Component, render} from 'https://cdn.pika.dev/preact/v8';

youngtaff2• 7 years ago

If you've got a site with decent levels of traffic host libraries yourself rather than use a JS CDN.

Retrieving critical content from a 3rd-party CDN has a number of issues:

- New TCP connection has to be created with added cost of TLS negotiation and it's own slow-start phase

- If you're using HTTP/2 then prioritisation only occurs over a single connection so it can't be prioritised against other content

anderspitman3• 7 years ago

There are tradeoffs either way. For popular modules it might already be in your browser cache if another app used the module recently. Plus being a CDN it's probably being served by a machine closer to the user. And if your whole site is running of a CDN then you're relying on a 3rd party anyway.

Benchmark for your users.

youngtaff2• 7 years ago

Based on https://andydavies.me/blog/2018/09/06/safari-caching-and-3rd... it seems highly unlikely that a popular module will be in the cache

- Safari double keys it's cache to prevent 3rd-parties tracking across sites - Usage of common libraries is just too low for their to be a critical mass

A whole site running on a CDN still involves only one connection, will make use of the throughput growing the TCP congestion window grows, and a decent CDN is likely to be more reliable than the origin

tracker1• 7 years ago

I think that HTTP/2 + Push + EMS will eventually become very interesting. Without push, there's a lot of separate connections that will happen for a lot of users on a lot of sites/systems. I think that there will be some break out platforms to come from this.

mrspeaker2• 7 years ago

This is fantastic - exactly what I've been looking for but didn't know I was looking for it! I've been re-importing libraries by doing something weird like: `import './three.js'; export default window.Three;` so I can use it as a normal module.

I love not having to use build tools for my personal projects anymore - everything feels so light and "old school". Here's my Minecraft-ish clone in native modules and WebGL2: https://github.com/mrspeaker/webgl2-voxels. No dot files, nothin' to build... just view source!

Ruphin• 7 years ago

That's a really neat project! Thanks for sharing

MentallyRetired• 7 years ago

Indeed, thumbs up. This should be a post of its own.

anderspitman3• 7 years ago

I had a similar feeling. ES modules really are a refreshing experience.

symlinkk2• 7 years ago

Their example doesn't work for me - it's just blank. Looks like CORS issues?

https://pika-cdn-example.glitch.me/

codezero• 7 years ago

I suggest you register all the bit-flipped domains. This is a must for all CDNs, given the ability to serve malicious JS from a bitflipped domain.

snug2• 7 years ago

It would be great to make the packages immutable, doesn't allow the maintainer of the package to change code on the website, malicious or not.

z3t42• 7 years ago

I built a repo like this but for require (commonjs), where package dependencies was sent along the first request using http2. Only problem was that browsers didnt cache the preloaded files and re-requestsed them. Hopefully browsers will fix this or latency will be a huge problem with several layers deep dependencies.

anderspitman3• 7 years ago

This is way cool. I recently started a new app and decided to see how far I could get without a build tool. My early impressions left me wanting to write a blog post "ES Modules Make JavaScript Fun Again." The whole development cycle felt clean and simple. Ultimately though I got hung up on dependencies. For a while I was just including things directly from node_modules/. But npm flattens things so that library location is not predictable (this crops up when en ES module dependency tries to look in its own node_modules/ directory for another ES module dependency, but that dependency has actually been flattened to the top level). So you're basically stuck downloading all your dependencies (and their dependencies) manually. This isn't 100% a bad thing. It pushes you to use smaller dependencies with fewer sub-dependencies. You're also stuck using libraries that export an ES module. Pika could be just the ticket to bridge these gaps.

unilynx• 7 years ago

`curl -i https://cdn.pika.dev/preact` redirects me to a dist-es2019 package (I assume because it detects my user-agent supporting that) but isn't showing anything like a `Vary: User-Agent` header.

Won't this break for any situation in which users with different browsers share a proxy server?

(also tried with Chrome, didn't see a Vary there either)

e12e4• 7 years ago

Don't worry - between tls and http2 you don't get to use a proxy anymore anyway... :/

neilv• 7 years ago

Pika CDN seems to facilitate user tracking by the CDN better than the current JS CDNs can (with simple browser privacy features that browsers should be doing already).

Also, wasn't clear to me whether they support SRI or an equivalent supported by the browser. If they don't, it could also be a centralized vulnerability for user-targeted injection.

(Solution: the best sites will pay to serve their own JS.)

Something1234• 7 years ago

Isn't pika where you're eating things you're not supposed to? So by using this cdn your computer is eating things it's not supposed to?

ollerac• 7 years ago

This wouldn't work with a standard React project though, right? Because you still need to transpile JSX. You could use the development version of React, I guess, which is slower, but can understand JSX, but that's not something you want to ship.

I'd love to use something like this for teaching, tutorials, and even small projects, but there's some things I still need a transpiler for.

I also realize I could use the `htm` package instead of JSX, which gives a lot of benefits over JSX, including not requiring transpiling, but, since it's not widely used by the wider ecosystem, I'd be a little hesitant to include it in my projects.

sdegutis• 7 years ago

Check out https://www.pika.dev/packages/htm which solves exactly that problem. Personally I like it so far.

Pika CDN – A CDN for Modern JavaScript

Related Stories