Requiring vs. Browserifying Angular

> That means no lazy loading of code.

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?

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.

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.

[1]: https://github.com/ericclemmons/grunt-angular-modularize

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!

example backbone app: https://github.com/ivanistheone/backbone-and-browserify-phon...

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"

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.

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.

Well written article.

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?