We Keep Coding

Meteor and Bootstrap admin

I would like to use meteor with a bootstrap admin, i.e. a bundle including several bootstrap plugins, script and everything typically made as a kind of framework for developing a web application.
Usually those bundles comes with a lot of dependencies, such as external links for fonts, IE hacks as well as their own shipped file of bootstrap, jQuery and other stuff. If we were in a regular php-like framework it would have been fine.
But in order to make such a template be "native" on meteor, I thought to refactor it in such a way that local dependencies (script and css basically) are stored into folders and not loaded via a <script src="…"></script> tag (otherwise the local path would not be found) but I doubt it is really the best practice, this is why I do consider 3 options:
To use the project/public folder in order to store all the bundle's dependencies (as if it would have been in php for example)
I might refactor the bundle's code by removing any script or style tag aimed to import the js or css into the page and add the corresponding js file aside so that meteor will dynamically load it during at runtime
Like in option 2 but instead of using the bundle's jQuery source files I would install the official jQuery's package for meteor (if existing).
The first (1) option should be the quickest one to get something running but it would not be very meteor native. The advantage however would be to keep the code near to the original one and being able to upgrade once a new version of the bundle would be released.
The 2 other options would be much more elegant (especially the third one) but it would involve a lot of refactoring and induce the risk of introducing bugs I did not expected.
My preference for now is the first option one but I'm afraid of not seing the drawbacks of this approach. Does someone have any experience in importing manually the CSS and JS files the "old fashion way" in meteor ? What is the risk of such an approach compared to using the "place in folder to include" way of meteor ?

Is it possible? Combine all JavaScript into one file

everyone. I got a dump question , please help.
I create a single page web-app, with marionette , require.js , and the backend is nodejs+mongodb. On the front end , I split the app as one view per file, one model per file and so on. As the app grow big, I got 50+ JavaScript files for this app. Which means, every user hit my site first time will have to down load them with 50+ http requests, this is crazy, isn't it?
So here comes the idea, I want combine all of these files into one, and make it through the google closure compiler, let user's browser relax a bit. But , all dependencies are managed by require.js , so I don't know is it possible to make this real happened.
Any ideas?

RequireJS ships with support to combine/optimize modules into a single file and has support for Closure Compiler. This [optional] optimization step is one of the claimed advantages of using RequireJS and is provided tooling. It can further be paired down with Almond.
RequireJS has an optimization tool that does the following
Combines related scripts together into build layers and minifies them via UglifyJS (the default) or Closure Compiler (an option when using Java).
Optimizes CSS by inlining CSS files referenced by #import and removing comments.

Can you use multiple .JS files when developing a complex Javascript application?

Coming from a C# background where every class is (best practices) stored in its own individual file, it makes development quite clean. I've never written anything complex in Javascript in the past, but I am starting to learn HTML 5 and I want to write a complex game using the HTML 5 canvas.
Putting all of my functions and code into a single .js file seems very messy. Is there a way to split it up, or a tool/IDE that lets you develop using separate files and compile them into a single one for deployment?
I guess I am looking for some best practice advice. Questions like this generally seem to get closed, so here are my specific questions to adhere to the SO FAQ that demands practical, answerable questions:
Does complex JS development usually involve all the code being in a single JS file? Eg. you're writing space invaders, do you just have spaceinvaders.js or do you have ships.js, logic.js etc.
Is it possible to split up your JS (whether using multiple script tags or pre-compiling to a single JS file) or to just put it all in a single file?
What's the industry standard? Does the HTML 5 spec make any recommendations?

There two possible ways.
Personally, I would use a build tool to simplify working with multiple files.
Using a build tool
Grunt
My favourite tool to keep up with complex js applications is grunt. With grunt you can develop in as many files as you want and use its plugins watch and concat to automatically concat them on save. You can do a lot more but this is the basic use case which may be helpful for you.
Grunt requires nodejs and takes some time to setup. But once you are ready with your Gruntfile setup it really speeds up your development process.
To make your project ready for production use you can also minify your scripts with some configuration and a single command.
A lot of the major javascript libraries are using grunt, easily recognizable based on their Gruntfile: jQuery, AngularJS, Twitter Bootstrap etc.
Grunt is also part of the development toolset yeoman.
Brunch
Brunch is another build tool which allows you to do similar things like grunt does.
Loading only the needed files
If you are developing a huge single page application and are concerned about the startup time of your application, one single file may not be the best solution. In this case you can use a javascript module loader.
Require.js
Therefor require.js is a goot fit. It allows you to only load the actual needed files on the current page. Though setting up require.js is a bit more work than setting up grunt.

Of course you can use more than one javascript file. How else would libraries like jQuery or Knockout function?
One thing to keep in mind, though, is that one of the things you want to do to keep your pages feeling snappy is to reduce the total number of http requests per page load. Adding a bunch of javascript files that are loaded separately causes an additonal request for each extra file. Therefore, you might want to experiment with a system for your build that stitches your javascript files together into a single item that you can use at deployment. There are a number of solutions out there that will do this for you in an automated way.

you could consider using requirejs - a very nice libray to split your javascript to modules.
it also provide a tool that you can "combine" all modules to a single file.

You can use as many javascript files as you want. Just add a link to them in your html code:
<body style="background-color: black" onload="main();" >
<!-- Your HTML body contents -->
<!-- Your scripts (here, I used HTML5 BoilerPlate to setup, and the links to jquery are provided) -->
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="js/vendor/jquery-1.9.1.min.js"><\/script>')</script>
<script src="js/main.js"></script>
</body>
Then you can hookup your main.js to listen for the main() function call:
function main() {
//here you can do your basic setup or delegate the control of the app to a different .js file.
}
or the jQuery document ready callback:
$(document).ready(function() {
//here is a good spot to hookup other jQuery listeners
});

MVC Bundles vs Javascript modules

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.

Organize DRY template for JavaScript experiments?

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.