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.
Related
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.
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 have made a backbone app but the entire code is in one page. I want to separate out the views and collections and the templates in separate files. I'm not using require.js nor any other boiler plate. Is there any method by which I can separate the code in files ?
The main purpose of MV* architecture is to keep code and UI separate.
Yes, there are many ways to do this. I prefer coding each module as a CommonJS/node style file and using browserify to resolve dependencies and concatenate files to send to the browser.
Another choice would be RequireJS, which is among the most popular at the moment, although the community is still mostly undecided/unspecified/many-options mode.
Probably the other popular option is using a build tool (rails asset pipeline, gulp, grunt, etc) to combine separate files into either one big file for the whole app or one big file for each major portion of the app.
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.
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.