cfpb / capital-framework

The Consumer Financial Protection Bureau's user interface framework
https://cfpb.github.io/capital-framework/
Creative Commons Zero v1.0 Universal
55 stars 29 forks source link

CDN for Captial Framework #124

Closed awolfe76 closed 8 years ago

awolfe76 commented 9 years ago

Just wanted to gauge the interest in having the framework be available over a URL, like a CDN.

This would allow anyone, or any team, to simply include the Framework in their project by doing something like:

<link rel="stylesheet" href="https://cdn.cfpb.gov/cf-framework/x.x.x/cf.min.css">

and/or

<script src="https://cdn.cfpb.gov/cf-framework/x.x.x/cf.min.js"></script>

This could help people/teams who want to use the framework quickly, it removes the need to build it themselves. Maybe really useful for prototyping.

The URL pattern also allows for several versions to be hosted. Governance could be created around the number of versions we would be ok with (requiring sites/apps to update at some point to prevent getting to out of sync). Some analytics around it would be really useful in determining who is using what version to help communicate the need to upgrade.

cmc333333 commented 9 years ago

+1 "quickstart"

ascott1 commented 9 years ago

Hey @awolfe76 and @cmc333333 -

Right now I think next step is to include a downloadable zip file in the documentation for that quick start (see #117). It wouldn't be for production applications (at least at CFPB), but could be really helpful for anyone who wants to throw together demos and prototypes with CF.

I like the idea of a CDN (especially the analytics bit), but since we want to encourage the use of build tools in production applications, I think it would be pretty far down the roadmap. The downloadable assets should work out ok in the interim. What do you think?

Thanks!

awolfe76 commented 9 years ago

Thanks @ascott1

Makes perfect sense to me. I think the downloadable assets is a great next step.

You guys have thought through this, so this is just curiosity about the:

we want to encourage the use of build tools in production applications

It makes sense, just wondering why that vs the CDN-like solution?

Thanks.

ascott1 commented 9 years ago

I think that the two biggest benefits a build tool provide are in reducing file size and http requests. If we only include the portions of the library we need in our builds, we can cut down file size and by bundling and minifying our files we can reduce the amount and size of http requests. CDN caching may help with both of these thing and I'd love to see performance comparisons. But what I want to avoid is each micro site requesting the Capital Framework JS & CSS files, other library files from a CDN, and custom JS and CSS.

awolfe76 commented 9 years ago

Cool. That all makes sense.

I saw the CDN solution as a quick way to get people going, possibly even into production for those that aren't ready to have a build process. That may not be a problem here, so I don't want to create one. (It would have been a problem in some past jobs.) But almost a best, better, last resort scenario; 1) build it into your existing process, 2) use the CDN, 3) something else.

Thought it could have been useful in other cases too. A simple example is for image assets, like the Directors photo. One official source for it in the CDN. Or for some other vendor library, like D3.js for example. Or do you guys recommend using external CDN's for things like that?

I'm definitely good with the way things are. Don't mean to stir things up my first week here, just being curious. :smile:

ascott1 commented 9 years ago

Please, stir away! I think in some respects we do have some of these things. Let's chat when we're all together in a couple of weeks!

awolfe76 commented 9 years ago

Sounds good to me. Looking forward to it!

himedlooff commented 9 years ago

Also, Capital Framework is constantly evolving and the CDN would constantly be lagging behind. That could be frustrating. Imagine there's an issue with cf-buttons and you make a pr and fix it. You'd then have to wait until it gets merged into the compiled zip and pushed to the CDN. It's faster to rerun bower install to pull in the updates you made. You can even point to your fork of cf-buttons if you can't wait for your pr to get reviewed and merged. This flexibility is pretty important.

himedlooff commented 9 years ago

And to clarify, I like the idea! I have no idea how one would implement it but I think it would be a good thing to provide, especially once the framework is a little more stable.

awolfe76 commented 9 years ago

I definitely have a few thoughts on how to handle some of those problems. I was thinking the CDN would be mostly (if not entirely) for internal CFPB use; built with our branding/colors. So anyone building a site/app here could simply do the includes and go. We could provide one for external users with a different branding but not sure if it's worth it, yet anyway.

I can go over some more thoughts here but maybe sometime from the 25th - 30th we can all get together for a bit? Would be great to meet you all anyway!

himedlooff commented 9 years ago

Chatting in person sounds great :boom:

contolini commented 9 years ago

This sounds like a great thing to launch with a 1.0.0 release.

contolini commented 9 years ago

CDNJS accepts PRs: https://github.com/cdnjs/cdnjs#adding-a-new-or-updating-an-existing-library

contolini commented 9 years ago

Bumping this to v1.1 due to amount of work it would involve.

jimmynotjim commented 8 years ago

Is this still a concern? I think every newer project has moved to npm installation and packaging with project code. Speak now or stay closed forever.