Scott Hanselmann has a post that identifies some tools for
minimizing/optimizing web resources:
http://www.hanselman.com/blog/TheImportanceAndEaseOfMinifyingYourCSSAndJavaScriptAndOptimizingPNGsForYourBlogOrWebsite.aspx
-----Original Message-----
From: Frank Schwieterman
Sent: 10/29/2011 5:33 PM
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.
