I just had an interesting idea from you mentioning "new specs"...
What if there was a new attribute introduced. Something like "remote". Following something like the subresource integrity specificiation [1] draft. So you could declare the remote attribute on an import. So *if* the remote source is already cached then use that. If it isn't, try to pull it from there. If a link can't be established, then fallback to using your hosted version. Adds some extra time to the request if the CDN can't be hit, but would allow shared resources with a fallback in a simple way. Possibly even could be coupled with an integrity check to verify the bits are right. [1] http://w3c.github.io/webappsec/specs/subresourceintegrity/ On Fri, May 2, 2014 at 10:21 AM, Alex Komoroske <[email protected]>wrote: > Hi, Garbee! Great to see you! :-) > > > On Fri, May 2, 2014 at 6:40 AM, Jonathan Garbee <[email protected] > > wrote: > >> When Alex was answering my moderator question in the All About Polymer >> gathering at the SFHTML5 event he mentioned that the components are/can be >> cached locally. This made me think two things. First, this is fantastic >> since instead of using a backend to generate the same structure of code >> over-and-over again to send across the internet, you can just generate a >> few tags and push down far fewer bits overall on your site. Which is just >> fantastic for overall performance, especially on mobile networks. >> >> However, that led me to another thought. What about sites sharing the >> same components? Developers are being urged to make their components >> generic so anyone can easily pick them up and integrate them. Would it be >> beneficial to provide a CDN for components to be hosted from? That way >> sites that are using the same components but aren't modifying them could >> then save some resources by using the same CDN hosted copy. This not only >> saves more data going across networks but also decreases the overall cache >> size on clients. >> > > We've explicitly thought about something like this. We've also slightly > crazier solutions that would require new specs but allow more clever > caching strategies. All of the solutions get complex relatively quickly, > for different reasons. > > At this point our goal is that tools like Vulcanizer help us, at the very, > very least, be as good as the current best practice status quo. However, I > think that as the web components ecosystem takes off this will be a very > interesting topic to dive into in more depth. > > >> >> Does anyone have any thoughts on the benefits and drawbacks of a Web >> Components CDN? Or is there a discussion of this before around that I >> missed in searching? >> >> Thanks, >> -Garbee >> >> Follow Polymer on Google+: plus.google.com/107187849809354688692 >> --- >> You received this message because you are subscribed to the Google Groups >> "Polymer" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/polymer-dev/3cb1ca5a-32e7-40a3-9ec0-8615836b772d%40googlegroups.com<https://groups.google.com/d/msgid/polymer-dev/3cb1ca5a-32e7-40a3-9ec0-8615836b772d%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups "Polymer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CANQy2y3S3cD4GcU3uFntuWZfZ0X3SPf_7NcdVvrZLx%2BoQ76h4g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
