I have an application, that uses Backbone.js,Jquery,Mustache and PHP as backend.
I have implemented micro-templates from underscore.js, which I currently define in my header-page.
I'm a bit dubious as to how I should organise the templates. Is there any efficient way to organise all templates in files and load them as required?
I use the exact same setup as you. Backbone, jQuery, mustache (for initial page render), and PHP (are you a SlimPHP fan? :-) I'm sure there are many ways to do this but one really great tool you might consider using is require.js.
With require, basically you code your Backbone client-side app as a series of AMD modules. Models, Collections, Views are their own modules that define dependencies with one another. The nature of AMD modules is that all modules are loaded asynchronously. So when your first page loads, only the code necessary to get that page going executes. When you leave the page and go to another, then that code is executed including all the dependencies that code has defined.
The nice thing about require is that it has a plugin that allows you to separate all your HTML code into html files. You simply define which views need those files as dependencies and it imports them as text to be used in the underscore templates.
Once you're ready to go live, you can use require.js' optimize feature to minify and combine all your js scripts + html templates into one file. Bang.
For big projects, a tool like this is pretty nice.
RequireJS
Related
I started using AngularJS not long ago and am practice to keep the Controller slim. My understanding of AngularJS' dependency injection is that it makes external JS code available in the controller.
I am also new to RequireJS, for I want to reduce loading time. I have done some reading but I am still confused. My impression is that AngularJS' dependency injection works similarly to RequireJS - loading functions on the fly when I need them.
Am I on the right track or am I completely wrong?
No, they are quite different. Angular DI involves components. Examples of Angular components are factories, directives, and filters. Angular provides several ways to inject a component into something else, but is not concerned about how to load these components or where they are stored. They could be all stored in a single .js file, in multiple files, or inline in the HTML document. The general assumption is that each component is loaded at page load, but that might not be the case.
RequireJS is a file and module loader. Each individual module is in it's own file. RequireJS uses ajax methods to load modules on demand as required.
Where Angular is more concerned with the IOC portion of the DI picture, RequireJS is more focused on file loading, data transfer, and memory conservation portions.
It is possible, and common, to use RequireJS to enhance the DI functionality of Angular, but unless it's a large scale app with hundreds of script files, it's normally not necessary.
As a ASP.NET MVC developer, I am trying to wrap my head around JavaScript AMD modules and libraries like RequireJS.
What is the relationship between ASP.NET MVC ScriptBundles and RequireJS?
In a large site with lots of JavaScript, should I be using both? Or one of them?
Should I integrate RequireJS with Bundles using IBundleTransform?
I wouldn't see using the two of these together. With Bundles you would have all your JavaScript loaded, ideally into just one or two bundles, on your layout controller. In production it would be optimized (combining into one file, minimised, cached and compressed etc).
RequireJS the way I see some of it is if you are being more granular about what JS is loaded and then you can use it's terse syntax to ensure a certain file is loaded before invoking some of that file's JavaScript.
I would recommend using Bundles since you are working with asp.net-mvc. They are pretty to use and work very well. I had used a similar pre mvc4 framework called Combres which was similar and this approach works very well for apps I think. It may be different for read only web sites.
I've been getting into Backbone.js lately and I'm enjoying it so far. All the examples tend to be simple to-do lists, so it's been a little difficult extrapolating code organization and file structure for a larger/more robust single page application.
I've come to a crossroad:
Should I use something like Yepnope.js to load models and views as I need them or,
Combine and minify into fewer files and front-load it all.
Some combination of both?
Any advice would be appreciated!
It depends of the size of your app. If you have a bunch of different views its definitely worth to start with a loader, where you can start the app with minimal feature set and load other views when needed. I can't tell anything about yepnope, but it seems the focus is more about polyfills then to structure your app with modules. We use requirejs for our app, and it works really well. You have to write a bunch of boilerplate code for the AMD modules but its really worth it.
I use Smarty to handle my views. To maximize code reuse, I split up my view files into small segments and just include them where ever they are needed. This works well as it keeps my markup consistent when rendered on the browser.
The problem is that I also have JS that will do certain DOM manipulations. It means that my JS needs to have an awareness of the mark up structure, etc. And in a lot of cases, the JS is forced to maintain an identical copy of the mark up that already exist in the Smarty template files.
This is going to become a maintenance nightmare as any changes to the mark up must be done in the Smarty template files and possibly in the JS mark up.
Any suggestions on how to handle this elegantly? Or do I just accept this as a necessary evil?
I split up my view files into small segments and just include them where ever they are needed
Do the same with your JavaScript. Think modular and make modules instead of pages. Any module would include HTML(Smarty in your case), JavaScript and CSS. Any page that needs that modules should require those three files. Or you can bundle all together to make including modules easier. When you create module then you will edit modules not pages. That way you won't break things by editing JavaScript or CSS/HTML.
A module could be anything that can have independency of other modules in a page. Of course modules could talk to each other but you need to define a consistant API for your module system.
This approach would make maintenance easier but the downside is you have to almost rewrite your entire app to make it modular.
I'm building a fairly large-scale JavaScript Backbone.js app with this folder organization:
app
index.html
libs
underscore
jquery
[...]
src
utils
modules
[...]
The index.html file basically loads up all the Backbone.js Routers etc. and instantiates AMD modules etc.
Often however, I find the need to create small applications that basically share dependencies with the Big app.
Suppose I need to create 3 small experiments (separate pages) that all load the same usual suspects (underscore, backbone and a couple of util libraries and modules I've written).
They may though differ in: 1) how they extend these JavaScript libraries, 2) what gets instantiated and 3) markup and interaction.
How do I keep this experimentation DRY?
How do I set up this "extendable Template"?
In my opinion, this is where having a good build system comes in. The more complex your setup, the more useful it is to be able to set up configuration files that can keep your dependency management consolidated in one place. This becomes particularly important when:
You need to load the same sets of dependencies on multiple static pages, but your dependency lists change often during development.
You need to be able to easily create compressed versions of the dependencies for a production version. I find this is pretty important with Backbone, because the uncompressed versions are really big but quite useful during development.
I've generally used Apache Ant for this, but there are lot of build systems out there. What I've done in the past is:
Set up an index.tmpl.html file with the core HTML markup and placeholders for JS scripts, CSS files, and underscore templates.
Make a build.properties file that defines my dependency lists. You can group them in different ways under different property names, e.g. lib.scripts.all or util.scripts.all.
In my build process, create a new index.html file, based on index.tmpl.html, with <script> and other tags to load my dependencies. I have different targets to load the raw files or to compress everything into a production-ready single script file.
You can see an example of this setup in this Github project.
If I understand your requirements, you could set up a similar build file with a few tweaks to allow you to set a) the HTML template to use (your default index or another with experiment-specific markup), b) the output file, c) the specific sets of dependencies to load, d) additional dependencies to load, e.g. experiment-specific modules or initialization scripts. You could set these properties up in a specific target (if you think you'll reuse them a few times) or just specify them on the command line when you invoke ant, via the -D flag.
This would allow you a great deal of flexibility to re-use different portions of your code, and has the added benefit of making it easier to move an "experiment" into your core production code, just by including it permanently in your build process.