I have about 10 directives and they are pretty complicated. Today I use one file only directives.js.
Is there some performance penalty if I'll put each directive to separate file for better maintenance?
Thanks,
JavaScript itself doesn't care where the code comes from. But JavaScript code has to be loaded by the browser. Making 10 HTTP requests to load 10 files is obviously slower than making 1 HTTP request to load the equivalent code.
But that's not a good reason to put everything in a single file. You should make one file for each component to make the code maintainable and easy to find. But the build procedure of your application should concatenate and minify the JavaSript files into a single file for production, so that a single file is used by the actual application.
Grunt and Gulp are two good build tools to do that, and much more.
Yes, there is a performance penalty for the client if it has to load every file individually. There are, however, server-side techniques to mitigate this, such as ASP.NET's script bundling, Grunt's building and many many more, that bundle several JavaScript files into one file for the client.
Yes, you should put your directives in separate files. This will cause performance degradation if used as is, however by using build tools like Grunt you can concatenate and minify whole of your app into a single JS file.
Related
I'm working in an AngularJS app that uses webpack for bundling the resources. Currently we are creating a single app.js file that contains the CSS as well. The size of the app.js is around 6MB. If we break the app.js into multiple chunks does that improve the page performance. My colleagues convinces me if we break the single JS file into 2 or 3 then the page load time will increase twice or thrice. Is that really true? I remember reading some where having a single file is better than multiple. I don't really remember the reasons now. Do I really need to break the app.js file for page performance? or what other options I can apply here?
A single file is better because it requires fewer connections (means less overhead), but this is really negligible when talking about < 5 files. When splitting parts of your file you do gain the ability to cache the files separately, which is often a great win. Therefore I'd recommend splitting the files in logically cachable sections (like vendor code and custom code).
Also note that if the client and server support http/2, the fewer connections reason is also gone since http/2 supports connection re-use.
Note that there is no real difference for the initial load time, since in that case all files will need to be downloaded anyway.
A single file will usually mean better performance. You should also ensure that this file is properly cached (on the browser side) and gzipped when served by your webserver.
I did a practical test in Chrome (Mac 54.0.2840.98 (64-bit)) to prove whether there is really a performance gain in breaking a huge JS file into many. I created a 10MB js file and made three copies of it. Concatenated all the 3 copied and created a 30MB file. I measured the time it took for the single file that is referenced using a normal script tag at the page bottom and it's around 1 minute. Then I referenced the 3 10MB script files one after other and it took nearly 20seconds to load everything. So there is a really a performance gain in breaking a huge JS file into many. But there is a limit in the no. of files the browser can download parallely.
I want to know what're the drawbacks of declaring and using ONLLY ONE module in my SPA?
Does it reduce testability?
Does it impact the performance?
Does it make code less readable or maintainable?
assuming that:
It is single page application
I don't share any block of code to another application
I use browserify to pack all files into one big .js file.
Even if I don't pack all js into one bundle file, isn't it true that all sub-mobules will be eventually depended by the root module? And therefore downloaded from server at the very beginning?
I am working on an AngularJS app.
According to a lot of articles in the Web, every file on the project can not have more than 100 / 150 lines of code.
Then, here is where my concern comes up: if I am concatenating/minifying my code, at the end all of the code will be in one very big single file.
So in that case, the rule(good practice) of the 100 / 150 lines of code still applies in this case ?
Kylek is right on about small files being for developers, and big files being for machines. More specifically, if you're interested, read about synchronous http calls and web loading speed. Basically, every separate external resource you have load on the page (a css file, or a javascript file) requires overhead on top of the actual content download, so for maximum speed, you want both a small number of files (accomplished by concatenation) and a small content size (accomplished by minification).
Of course, as a developer, you still don't want to have to worry about this while writing and maintaining code. Check out grunt, specifically uglify and cssmin, which can keep monolithic minified files up to date for you while you work on your source. Regarding angularjs in particular, make sure you're using dependency annotation or minification will break your code.
Keep files small is not a performance good practice but a way to keep things organized for developers and to find quickly what you are looking for, it's not for machines but for humans.
No human will have to develop minified files, so no coding rules apply to minified files. A contrario, minify and concat JS, CSS etc. make your pages load faster. It's a performance good practice.
By the way, do not follow a rule because some one tell you to. Be sure the rule match your case, your project, your team, etc.
I am using backbone.js in a legacy app to rewrite separate pages into individual bits of backbone work.
I am not using any routing and it is not a total single page application.
Only certain pages are individual backbone.js applicaitons.
At the moment I have all my backbone javasript in one file for each page that uses it which is painful to work on.
Would it be wise to use something like requirejs on a page by page basis or is there something better I could do in order to split the page up in development and serve one page in production?
That depends largely on what your existing codebase looks like.
RequireJS is a great tool...if your existing code is set up to support it, or you have a small enough codebase to be able to convert it without breaking everything. However, not all legacy JS code is, especially if it's part of a larger system (I personally ran into this problem with a Backbone project I'm working on). If you can, then by all means, make use of it. The big advantage, as far as I know, with RequireJS is that it doesn't actually fetch and load the Javascript files until you need them. So you can have one RequireJS call that's in all of your pages, and only download what you need, when you need it.
There are other ways, however, to combine your Javascript code at production time, which, again, depends greatly on your setup. Many content management systems include "minify" scripts that handle it automatically for all of your Javascript files. You can also do it "by hand" with Minify, YUI Compressor, or one of the many other minification tools out there. (You can also do it "really by hand", and develop in multiple files and combine them via copy+paste, but that's really more work than is necessary.)
Regardless of how you go about doing it, I highly recommend breaking your projects into multiple files (not only into a file for different projects, but multiple files within the projects, to hold each view and models if they have significant code). It makes it infinitely easier to maintain.
I would like to know your opinion about how you would organize the files/directores in a big web application using MVC (backbone for example).
I would make the following ( * ). Please tell me your opinion.
( * )
js
js/models/myModel.js
js/collections/myCollection.js
js/views/myView.js
spec/model/myModel.spec.js
spec/collections/myCollection.spec.js
spec/views/myView.spec.js
This is how I've traditionally organized my files. However, I've found that with larger applications it really becomes a pain to keep everything organized, named uniquely, etc. A 'new' way that I've been going about it is organizing my files by feature rather than type. So, for example:
js/feature1/someView.js
js/feature1/someController.js
js/feature1/someTemplate.html
js/feature1/someModel.js
But, oftentimes there are global "things" that you need, like the "user" or a collection of locations that the user has built. So:
js/application/model/user.js
js/application/collection/location.js
This pattern was suggested to me because then you can work on feature sets, package and deploy them using requirejs with relatively little effort. It also reduces the possibility of dependencies occurring between feature sets, so if you want to remove a feature or update it with brand new code, you can just replace a folder of 'stuff' rather than hunting for every file. Also, in IDE's, it just makes the files you're working on easier to find.
My two cents.
Edit: What about the spec files?
A few thoughts - you'll just have to pick the one that seems most natural to you I think.
You could follow the same 'feature folder' pattern with the spec files. The upside being that all of the specs are in one place. The downside is that now, much like what you're currently doing, you have to places for one feature's files.
You could put the specs in a 'spec' folder of the feature folder. The upside is that you now have actual packages that can be wrapped up in a single zip file with no chance of clobbering other work. It's also easier to find directly related files for writing tests - they're all in the same parent folder. The downside is that now your production code and test code is in the same folder, publishing it (possibly) to the world. Granted you'll probably end up compiling the production javascript down to one file at some point.. so I'm not sure that's much of an issue.
My suggestion - if this is a large application and you figure you're going to have a few hands touching the files, leave something like a 'package.json/yml/xml' file in the folder. In there, list out the production, spec, and any data files you need for testing (you can most likely write a quick shell script to do this for you). Then write out a quick script to look through your source folder for 'package.whateverYouChose' files, get the test files and then build your unit testing page with it. So, let's say you add another package.. run 'updateSpecRunner' or whatever you name the script, and it'll generate you another SpecRunner.html file (or whatever you named the file your running the specs on). Then you can manually test it in a browser, or automate it using phantomjs/rhino.
Does that make sense?
You can find a good example how to organize your application to this link
Backbone Jasmine examples
It looks more or less like your implementation.