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?
Related
People mention requirejs together with marionette, backbonejs and the like.
requirejs seems an asset loader -- executing your rules on when to load what.
I know the first 'page' of my single-page-app already needs most of the files. If I don't mind loading all files in one go, can I simply ignore requirejs?
Technically yes. Only dependencies for marionette-backbone are
jQuery v1.8+
Underscore v1.4.4 - 1.6.0
Backbone v1.0.0 - 1.1.2 are preferred
Backbone.Wreqr (Comes automatically with the bundled build)
Backbone.BabySitter(Comes automatically with the bundled build)
Further require.js can manage use code structure in a manner which give your code much resource efficient code at the end. From my point of view for simple application which you need simple set of views,models and collection with manageable amount of code it ok to proceed without require.js.
But if your application have complex logic and higher number of resources it's good to go require.js. Because it not good to send 15+ like individual resource requests server at very beginning of your application load. Require can make any number of your resource in to one server resource. That's the advantage.
What I prefer is one request of all css, one for all js, one for sprite image for graphic if things are big to handle which allow to create fast performing application.
Take you decision looking at the amount of resources of the project. It's not essential have require.js form the beginning of your application development.
I am using angular seed project
https://github.com/angular/angular-seed
where should I put the services and directives ?
This is really totally up to you but there are some good recommendations on project structure here: https://docs.google.com/document/d/1XXMvReO8-Awi1EZXAXS4PzDzdNvV6pGcuaF4Q9821Es/pub
Typically my structure looks something like
app\scripts\user.js
app\scripts\todo.js
Where User.js would have a service and possibly multiple controllers in it... if the file gets too large then I break it up into parts.
The problem with grouping all services together and all controllers is that the services and controllers typically have a relationship (functionally). When you want to re-use the service/controller you are typically going to use them together, when editing one you usually need a reference to the other. This makes it easiest to find things and not have 1000 js files to include and manage in the dependencies and script inclusions.
Also when it comes time and you want to make a bower component out of one of the sections it's easier to see which parts need to be pulled out.
You can make a folder for each under app, so your project tree will look like this:
app/directives
app/services
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.
i am developing a very extensive AngularJS application and for make it extensible and maintenance I use a modular arquitecture like:
cart/
CartModel.js
CartService.js
common/
directives.js
filters.js
product/
search/
SearchResultsController.js
SearchResultsModel.js
ProductDetailController.js
ProductModel.js
ProductService.js
user/
LoginController.js
RegistrationController.js
UserModel.js
UserService.js
The file structure above is an example of modular structure in angular.
The Question
Exist a generator for Yeoman that work with this structured?. The most popular, generator-angular, use a simple structure.
With all the js files under scripts folder, you can use requirejs via grunt-bower-requirejs to manage each modules own dependencies.
Grunt/yeoman need to be aware of all the modules, but you still get the abstraction and decopuling that you are expecting out of this.
You can simply arrange files like this on your own.
Angular generators will stop working properly (which is not a big deal IMHO), but all other stuff available in Yeoman will be unaffected.
Take a look at this commit.
Essentially it changes * to ** in Gruntfile and moves appropriate files.
Additionally MODULES.coffee file is introduced in some of the later commits. It gathers AngularJS modules creation in one place in a module-folder. It's a custom convention invented for my projects' needs, I don't know if it's a community-acclaimed standard.
It's still not perfect: templates and scripts for the same feature-based module reside in 2 separate directory trees - they should be in the same place.
EDIT: Good news!
It is planned, for the project structure generated by Yeoman to be feature-based.
Source: https://docs.google.com/presentation/d/1OgABsN24ZWN6Ugng-O8SjF7t0e3liQ9UN7hKdrCr0K8/edit#slide=id.g2b6b56d19_086
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.