With Rails, though, you don't need to worry about any of this. Just define your modules and add controllers/services/directives/whatever to them as needed using as many files as you want, and it just works. No module loading required.
Sorry for my ignorance, but does Node have something similar to Sprockets/The Rails Asset Pipeline?
Somebody commented about ASP.NET MVC having a bundler that you can just point at a directory. Seems like that would be enough to do it and you wouldn't need CommonJS or AMD.
Sprockets is incredibly primitive compared to something like RequireJS or Browserify -- all it does is concat.
One might argue that Browserify is that JS bundler for Node. The issue is that using it with Angular seems superfluous because Angular has its own module system that works well when you just concat everything.
My first attempt at using both Angular and RequireJS in the wild was on the same project.
It was enough to turn me off from RequireJS, permanently.
It was enough to intrigue me about Angular, but be wary about using it due to the amount of time needed to twist your brain into thinking in an Angular way.
In comparison to RequireJS, Browserify just works. No complicated config file with shims. Same module style I'm used to from Node. Hell, I can even concat ascii text files into my packaged codebase with brfs.
I've started using browserify + gulp for my frontend code and I must say it is a very powerful combination for structuring code. One might even say civilized!
I'm starting to think that module systems on Angular's modules is a bad idea. Maybe I'm overthinking this. Should we just grunt-concat (or whatever Gulp does) and move on with life?
The primary problem I see with the browerify approach that was outlined is that it makes it much harder to debug your code in the webconsole.
By concatenating everything into a single file and loading that into the browser, you have to do the math in your head to figure out which file the code in question is in. Also, if you have a huge project, the watchify process really starts to slow down development as you are constantly waiting for it to do the concatenation.
I go with the requirejs/r.js approach. During development, requirejs effectively adds script tags to the specific files into your dom and loads your source code directly. No need for a watchify process. When you have a javascript error, the webconsole shows you exactly what file the issue is in. For deployment into production, r.js does the concat and I just load a single file. This unfortunately makes it harder to debug production, but that's the tradeoff. =(
Neither approach is perfect, but it is the best we have right now. I'd love to see someone come up with something that solves all these problems, is well documented and easy to work with.
I'm sorry, but that's a lot of overhead to just get to the right line in the file. Now you're talking about generating even more files every time you save. For a large project this doesn't scale.
Generally, when browserifying angular, the first thing you want to do is create an `./app.js` that exports your app. That way you can push the actual registering of controllers and such to the controller itself instead of a massive glue file.
The browserify transform `bulkify` can also be handy to allow you to require a bunch of files based on a glob.
While attending @ ng-conf, I wrote this [grunt-angular-modularize][1] which would, based on file path, automatically wrap your Angular files with RequireJS/AMD or Browserify/CommonJS code.
The end-result gets ran through RequireJS or Browserify based on your preference, and you don't have to wrap your code.
Maybe Angular needs to take a more constricted approach and integrate naturally with something like browserify.
You are correct that you should be writing your actual angular code in those separate files. And doesn't it make sense that the export of a controller file is an injectable controller? None of this "dependency injection via a string which gets turned into a reference to real code later"
19 comments
[ 5.4 ms ] story [ 51.4 ms ] threadWith Rails, though, you don't need to worry about any of this. Just define your modules and add controllers/services/directives/whatever to them as needed using as many files as you want, and it just works. No module loading required.
Sorry for my ignorance, but does Node have something similar to Sprockets/The Rails Asset Pipeline?
One might argue that Browserify is that JS bundler for Node. The issue is that using it with Angular seems superfluous because Angular has its own module system that works well when you just concat everything.
It was enough to turn me off from RequireJS, permanently.
It was enough to intrigue me about Angular, but be wary about using it due to the amount of time needed to twist your brain into thinking in an Angular way.
In comparison to RequireJS, Browserify just works. No complicated config file with shims. Same module style I'm used to from Node. Hell, I can even concat ascii text files into my packaged codebase with brfs.
And then you lose the main advantage of requirejs over browserify.
People came up with techniques to "lazy load" angular components,but as some point one has to ask,is all that complexity worth the effort?
example backbone app: https://github.com/ivanistheone/backbone-and-browserify-phon...
By concatenating everything into a single file and loading that into the browser, you have to do the math in your head to figure out which file the code in question is in. Also, if you have a huge project, the watchify process really starts to slow down development as you are constantly waiting for it to do the concatenation.
I go with the requirejs/r.js approach. During development, requirejs effectively adds script tags to the specific files into your dom and loads your source code directly. No need for a watchify process. When you have a javascript error, the webconsole shows you exactly what file the issue is in. For deployment into production, r.js does the concat and I just load a single file. This unfortunately makes it harder to debug production, but that's the tradeoff. =(
Neither approach is perfect, but it is the best we have right now. I'd love to see someone come up with something that solves all these problems, is well documented and easy to work with.
https://github.com/substack/node-browserify#external-source-...
The browserify transform `bulkify` can also be handy to allow you to require a bunch of files based on a glob.
The end-result gets ran through RequireJS or Browserify based on your preference, and you don't have to wrap your code.
[1]: https://github.com/ericclemmons/grunt-angular-modularize
You are correct that you should be writing your actual angular code in those separate files. And doesn't it make sense that the export of a controller file is an injectable controller? None of this "dependency injection via a string which gets turned into a reference to real code later"