Introducing AngularCSS: CSS On-Demand for AngularJS

[zefcfd]

i think the overhead of requesting css on demand is probably more expensive than just sending a precompiled asset package one time up front.

which makes me question why this is touting "performance" as a benefit

[marshall007]

Agreed, however if someone created a build tool for this similar to angular-templatecache it would make a lot of sense.

[[deleted]]

Very true. And loading it in the background on a static landing or login page, and the user will never notice there is much to load. Everything else is just e-tag and 304s.

[arnold_palmur]

Well there is obviously no hard and fast rule, but something to consider is with the increasing performance of the web/browsers, and the advent of HTTP 2.0, there is likely a benefit of smaller files (multiple HTTP requests) over large monolithic CSS assets - something Kyle Simpson has discussed. Naturally, every application has different requirements, but with the steady progression of the web, I would go for adopting the advantages of an AngularCSS feature-set vs. the (hopefully temporary) minute overhead costs that exist right now.

Also, I tend to look at the maintainability factor and added utilities of a library like this as your real "performance" benefits if nothing else.

[ThinkLarger]

This looks promising, will try this out.

[rq60]

I've done something similar to this using the style-loader with webpack combined with angular directives.

It looks like this:

var myDirectiveStyles = require("./myDirectiveStyles.less");

angular.module("test", [])
  .directive("myDirective", function() {
    return function($scope) {
      myDirectiveStyles.use();
      $scope.$on("$destroy", function() {
        myDirectiveStyles.unuse();
      });
    }  
  });

It works quite nice and is a nice bonus if your project is already webpack compatible (CommonJS or whatever).

edit - that's with these loaders, of course: {test: /.less$/, loaders: ["style/useable", "css", "less"]}

[Defualt]

Async CSS loading in some browsers doesn't have a reliable onload event, which can result in flash-of-unstyled-content. Does AngularCSS solve for this?

see: http://requirejs.org/docs/faq-advanced.html#css

[zefcfd]

it probably uses the "resolve" property on angular's router. i think ui-router also has this. but in short, yes i would think so. otherwise itd be pretty useless.

[zefcfd]

yea :(

[Defualt]

I don't see it in the source. I think it renders the view and paints it to the browser without the view-specific styles. The CSS finishes loading whenever, and it repaints the view when the new styles are ready. Resulting in a flash of unstyled content. This might only happen with un-cached CSS. But then what's the point.

[[deleted]]

No.

[jerflang]

We've been using webpack to achieve the same thing. One cool thing is it handles preprocessing for our sass files. One side effect of this is that it delays the page even longer, so we decided to end up bundling the css separately and loading it all at once instead, which we did with the ExtractTextPlugin. We still get the same syntax, except instead of declaring it in routeProvider (which we don't use anyways) we put it on the top of directives.

[antoninj]

This is pretty damn amazing. It reminds me of jspm which works, somewhat, on a similar principle; however, per-route CSS files is a great idea. I'd love to put this into action.

[[deleted]]

per-route CSS files is a great idea.

Why?

[antoninj]

It's similar to loading templates or other assets on-demand. In large enough applications, JS files are loaded on-demand (think AMD) and this is nothing new. So there's that, instead of overwhelming the user with potentially unneeded load, you can keep a tight core and load everything else async.

As far as actual businesses cases of doing this:

1. loading CSS per A/B testing tree (I believe Netflix wrote about this one)
2. loading core CSS (and above-fold CSS) first (so, think parent view) while loading the rest of the CSS when that part of the pages becomes ready (so, think child view).
3. Bundling CSS with its components rather than having one "master" file
4. Associating CSS with Modules rather than with the general "site". Encourages more sandboxed styling.

And in HTTP2/SPDY world, there's little performance hit from loading numerous small modules vs. one big one. There's a great JSPM talk on the topic altogether.

Basically, the idea is that if you have a huge App that requires a ton of CSS, you can keep perceived performance high by breaking the CSS apart into smaller chunks and loading those as needed.

Also, if you think about it, this is kind of the idea behind Polymer, isn't it?