Have you checked out SASS and Coffee<https://github.com/xpaulbettsx/SassAndCoffee>? We just started using that a few weeks ago and it seems to do a good job in both the bundling and coffee script compilation departments. We've tried using SASS just to see if it works, but haven't bothered converting all our existing CSS to SASS yet.
As for development mode vs. production mode, we only refer to most of our javascript in one layout page where we conditionally include a debug bundle with the debug versions of jquery, knockout, etc., when we are in a debug build, otherwise we include a production bundle. SassAndCoffee knows when source files change and automatically rebundles them for us. --c On Sat, Oct 29, 2011 at 14:33, Frank Schwieterman <[email protected]>wrote: > To me it seems that .Net developers don't have a best practice > managing web resources like javascript files, css, and image files. > This includes bundling and minifying the files to send over the > network. There are libraries out there things like minification, LESS > and coffeescript compilation, but they don't fit together in a > consistent manner. > > Do people share this view? If not, I'd appreciate your view on how > js/css/etc type resources are best managed in an application. > > With this problem in mind, I've been thinking about/refining how I > include my own javascript and css in projects. I have a vision of an > open-source library I would build to improve the situation, and I'd > like to ask the community for their feedback and/or assistance. Its > really not that big of a library, but I'd hate to build my own > solution to this over and over rather than reuse something thats > already out there. I'd also like to get the opinions of people who > have more experience with non-.NET platforms. > > I will try to describe the vision below. Let me ask: are there > existing tools techniques I should be using instead? If their is use > for the below solution, how would you change it? Last, would you be > interested in helping out? (preferably via remote pairing, mostly on > the weekend) > > The general idea is that as part of some web application (including > any ASP.NET application, or anything else that can host NancyFx) a > bundle specification can be included describing what > javascript/css/tec files need to be bundled, and how they are grouped. > > The specification might look something like this: > https://gist.github.com/1324940. In this sample, various third-party > libraries are used (jquery, jquery-ui, blueprint css, etc) to be > included in the bundles alongside application specific code > (projects\common, projects\main). Dependencies are honored by > including files within the specification in their dependent order, > sometimes calling out individual files so they are included before an > entire path. > The developer can put their source files where ever they want, as > long as they are referenced by the bundle specification. Files can be > referenced by path, so adding new source files typically doesn't > require updating the bundle specification. > Initially, the bundles would include javascript, css, and html > templates (compiled as javascript includes). Compiled languages like > coffeescript and less could also be supported. > Within the specification, the files are grouped into different > bundles. Besides grouping bundles by filetype, bundles might also be > split based on where they are referenced in the page (header, footer, > print only, browser-type only, etc). Tests are also bundled so they > can easily be included within a client-side test runner. > Essentially, The developer is able to edit and manage all the files > separately, while the application is allowed to include them all with > a few bundle references. > > The bundling modules execute in two modes, one for development and > one for production. > > In development mode, the resource module runs as a webservice as > part of an existing ASP.NET [MVC] project, or other web application > supported by nancy. Whenever a bundle is requested, static files are > reloaded. This allows a developer to try their changes without > rebuilding. The developer only has to reuild if the module C# code > changes. > > For production, the bundles are read as files from whatever content > delivery system you choose to do. As part of build or deployment, a > command-line app is invoked against the resource module to write all > bundles to disk. Those files can then be copied to any content > delivery network. > > Long-term, I'm looking to support things like: > LESS/SASS/CoffeeScript support > Caching the bundle results based on file changes > Image sprite building > Allow Nuget packages to be referenced directly > > Thoughts? Questions? Feedback? > > -- > You received this message because you are subscribed to the Google Groups > "Seattle area Alt.Net" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/altnetseattle?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Seattle area Alt.Net" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/altnetseattle?hl=en.
