Closed awolfe76 closed 8 years ago
+1 "quickstart"
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!
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.
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.
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:
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!
Sounds good to me. Looking forward to it!
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.
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.
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!
Chatting in person sounds great :boom:
This sounds like a great thing to launch with a 1.0.0 release.
CDNJS accepts PRs: https://github.com/cdnjs/cdnjs#adding-a-new-or-updating-an-existing-library
Bumping this to v1.1 due to amount of work it would involve.
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.
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:
and/or
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.