Currently our templates are in html files, while the build does minify them (with htmlmin)
It appears there are two approaches to optimize templates loading in angular.
using $templateCache as explained here. Which means putting the minified templates into a js file, probably with this grunt plugin.
Inlining the template,which means using them with angular script directive, probably using this grunt plugin
from npm usage stats I can judge that the first option is more popular, but I'm not sure why, what are the tradeoffs between the two options and which gives better performance.
Thanks!
To say anything more about performance it would have to be measured. But from the theoretical point of view (1) should be more performant since with (2) templates are ending in the $templateCache anyways, and using the <script> directive means additionally:
* having those <scripts> in the DOM tree
* processing <scripts> tags during the DOM compilation with this directive:
https://github.com/angular/angular.js/blob/master/src/ng/directive/script.js
In short: it looks like using <scripts> directive means more runtime processing in a browser. Should be confirmed with some performance testing, but I would assume that one won't see dramatic performance difference.
Related
I have an AngularJS module defined in a single HTML file. Unfortunately, I cannot refactor it into separate files.
I need to add unit tests with angular-mocks and jasmine, and I need to run the unit tests with Node.JS (i.e. npm jasmine). I would like to leave karma out of the picture.
I looked at the angular-seed project but all the controllers and views are nicely separated, which is not my case.
How can I reference the AngularJS module in my single HTML files from my spec files?
Unfortunately, unless you roll your own preprocessor to do something like this, it will not be possible.
I also would definitely NOT recommend trying to avoid using Karma to test your angularJS applications, it provides an out of the box solution to test your code in a browser. Otherwise you'll have to do this all on your own and there is really no benefit to that unless you've already done this work.
You can and should separate your JS/HTML files out, it might be work now, but it will create a lot less headaches down the line.
I've done a lot towards optimisation of one part of my application, due to huge amount of elements in DOM. I implemented lazy loading, watched for every digest cycle to be as small as possible, etc.
Now my question is, if anyone else has encountered, that the initial compiling and rendering is slower than rendering for the second time(like navigate to different app location and back again).
Is angular caching somehow and if so, how can I force to cache it in advance?
$Routing in angular is done using $templateRequest which in turn utilizes $templateCache. That's why all consequent template changes looks faster.
Tools like gulp-angular on yeoman.io for example automatically will build your application and place your HTML files in the $templateCache for you. It will also concatenate and minify all of the scripts.
Ultimately what you are looking for is for the html snippets to be all included in that single javascript file so that there arent individual HTML GET requests for each one.
I can use ng-include to include a partial inside an angular view or I can use server side partials to do it on the server. I'm thinking about using server side partials instead of angular partials and then ng-include (with the script tag) because I read somewhere that angular partials create new scopes and this can hurt performance on $digest.
Is there any validity to this. What is the effect on performance when using angular includes
ng-include will create a new scope and register a watch (on a path expression used by ng-include) on a scope where the ng-include is used. While this incurs some additional processing it is still JavaScript-objects based and as such is very fast. The effect of a new watch plus an additional scope should be totally negligible in most cases.
The only real difference I can see is that ng-include will include / render your partial asynchronously, so you might see a bit of delay, especially when fetching partials over the network (but this can be mitigated by pre-loading partials as described here: https://stackoverflow.com/a/12346901/1418796)
In short: in most cases the effect of ng-include should be negligible if partials are pre-loaded.
One last comment: "premature optimization is the root of all evil". Don't start micr-performance adjustments until you measure performance of your application and determine that ng-include is a bottleneck.
I saw a similar question on the Google groups and also here on Stackoverflow. Both times the question was not answered. The code in this file doesn't make it very clear about what exactly it does and how it is used. Also it's not clear from the Angular documentation.
Can someone explain how this is used. Also can this be used along with Require.js?
Angular loader allows your angular scripts to be loaded in any order.
As angular-seed project shows us, Angular loader does not have any specific api, you just put it at the top of your index file (so that it's executed first) and then proceed to load your application files anyway you prefer.
But, the most important thing for your use case is that you don't really need angular loader at all. RequireJS also allows your files to be loaded in any order, but it also provides you with many other features that angular loader just isn't made for.
So, yes, you may use it with RequireJS, but you don't need to, because it becomes redundant.
Angular modules solve the problem of removing global state from the application and provide a way of configuring the injector. As opposed to AMD or require.js modules, Angular modules don't try to solve the problem of script load ordering or lazy script fetching. These goals are orthogonal and both module systems can live side by side and fulfil their goals.
http://docs.angularjs.org/tutorial/step_07#anoteaboutdiinjectorandproviders
It allows for you asynchronously load files when bootstrapping your angular application. A good example is the angular-seed project that has an index-async.html file that does this.
index-async.html
This is useful for using other libraries that load in modules asynchronously.
See angular-async-loader:
https://github.com/subchen/angular-async-loader/
To async load following components:
List item
controller
services
filter
directive
value
constant
provider
decorator
I made a simple app using backbone.js and require.js. Earlier i used to have just one index.html file and used to dynamically render/hide different views. Now with require.js, i still have index.html file but i have created separate html files for each of my four views in the app, and i put them all in templates folder. Main point is, these four html files don't have the <!DOCTYPE html></html> tags, just the <div> tags for the view.
I'm not sure this is the right way to do it using require.js. Should i integrate all html code into just one index.html and using <script> tags for templating?
You shouldn't put your templates into one big html file, require.js and Backbone.js are the perfect combination to have everything in highly flexible modules, loaded only when neccessary.
With only a few modules you may not notice their advantages, but trust me, if you write more complex, dynamically growing high speed web applications, you save yourself hours of debugging and refactoring, and your code will be very simple to read and modify.
You have several ways to handle templates with Backbone, e.x. this.$el.html( _.template(template, this.model.toJSON() )) if you loaded your template into a template variable.
It won't affect speed, templates are only a few kilobytes. Comparing to the fact that your page is likely to already load a dozen files(many icons, a few images, css-es, js-es) even without BB.js or Require.js and modules, a new few-kilobyte-big file will not be noticable. Also, you can cache templates after first load if you use Require.js to load them.
Depends...
Mostly I would separate them because it fells more organized and easier to maintain, but... if you have too many of them (lets call them "Tiles") it can make your site slow because you will be doing several server trips to draw the site, I've read somewhere that when the browser have to make more than 4 request HTTP at the same time you will be punished for it with a slower performance, I will try to find the source and post here.
If your tiles are always together, I think putting everything in a single HTML with is ok, so you can fetch all of them with a single HTTP request, but the down side is that when you update a single template the client side cache of all templates goes to hell.
Another solution is to have them in separate files so they are more organized and using a build tool you create a big minified template file that you use on production, but that will require some work.
So you got to find the best way for your site.
P.S:Are you using a templating mechanism ? I find them really helpful in this situations.