Caching

[Untit1ed]

Just wondering if you have any plans on adding caching support to the handler?

[darrenkopp]

Are you using the handler exclusively? I hadn't considered adding caching as it's usually only used in the debugging scenario, but I guess it's possible people are using it directly.

[Untit1ed]

No, not exclusively, it would be just nice to have some caching even if optimizations are disabled/debug mode, since it might take some time to compile bigger style-sheets (custom bootstrap theme in my case).

[darrenkopp]

So, the biggest difficulty here would be knowing if the file was still good or not when you are using partials because unfortunately we don't know what's going into the output css file. I'm gonna say this probably isn't feasible at this time.

[Untit1ed]

Well it doesn't have to depend on partial files, it could also be something like app.scss?v=UM624qf1uFt8. But I'm not sure if it's even something that can be done with System.Web.Optimization when EnableOptimizations is set to false

[aviatrix]

As of Beta-6 (not it nuget) the time needed to compile scss (foundation by zurb in my case) is up to 2-3 seconds. a huge slowdown occurs when the IIS process is restarted ( due to recompile or web.config change). When this happens an IIS app pool & site process restart is recommended. i'm still investigating as to why is this happening. So, All in all, caching won't be needed when @darrenkopp fixes the appveyor build & publish stuff :)

[timkishkin]

I would greatly appreciate caching feature as I'd like to use the handler in production. My project should support dynamically adding and modifying scss files without restarting the server, so having static preprocessing is not not a good option. Bundles are also not the best solution, as modifying imported files does not trigger bundle update. I see caching in the handler as the only elegant solution, or would you suggest something else? Thanks!

[timkishkin]

I think caching could be implemented using built-in ASP.NET HTTP cache by providing System.Web.Caching.CacheDependency for all imported files, this way cache would be automatically reset if any of the files are modified. Similar approach is used in dotLess. The list of imported files can be retrieved through SassResult.IncludedFiles. What do you think?

[aviatrix]

@timkishkin this should have been fixed in latest versions of the library.

[timkishkin]

The slowdown you've mentioned above is apparently fixed, right. But the caching is still missing, I think. I've checked the performance on a bootstrap scss, and the handler takes about 270ms in average to serve the main file. That is good enough, but still way slower than serving static file. It certainly doesn't cache the output, and such handler cannot be used in production, where I would like to use it (see explanation above).

[darrenkopp]

Are you using the handler directly, or are you using the bundling stuff? I think it's probably possible to add cache watching like that in general for development purposes. things get more complicated with doing something like that automatically for release builds as there can be issues when people run off a network share and exhausting unc resources from file watchers.

[timkishkin]

Yes, I was planning to use handler directly in production, for reasons I've explained above. The absence of caching prevents me from doing that.

there can be issues when people run off a network share

To be honest, I didn't think about it. Are you sure it would be an issue? I thought that ASP.NET bundling uses file watchers as well, as bundles are auto-updated after source file modifications (I might be mistaken, of course). Anyway, I'm not planning to use network paths in my case. I think caching might be a good option for me and other people with the same use case.

[aviatrix]

In what kind of scenario do you want to use the caching?

1. generate once & cache until redeployment?
2. re-generate every X hours/days
3. cache until a file (.scss) changes

My ideas :

1. use bundling and minification
2. use bundling and minification
3. this can be quite tricky if you have lots of .scss files in different .css outputs and lots of nested imports , and best case would be to store the user's .scss somewhere in a db or a file and regenerate the output file manually when your system has detected/triggered change. Basically implement this yourself because that will suit your situation better than relying on a generic solution from us that won't quite work for you.

[timkishkin]

My scenario is the 3rd one. OK, I will consider implementing the cache by myself when I have more time. Thank you for the explanation!

[darrenkopp]

there can be issues when people run off a network share

To be honest, I didn't think about it. Are you sure it would be an issue? I thought that ASP.NET bundling uses file watchers as well, as bundles are auto-updated after source file modifications (I might be mistaken, of course).

definitely an issue that i've run into before. in general with sass, you end up having a file watcher on maybe like 1 - 2 files (root level scss) which is less of an issue, but once you start adding multiple watchers for single files (referenced by many includes) etc things start getting dicey.

it's probably a non-issue right now though because i forgot that libsass still doesn't work with windows network paths 😄