

Requiring vs. Browserifying Angular - remotesynth
http://developer.telerik.com/featured/requiring-vs-browerifying-angular/

======
aikah
> 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?

------
warfangle
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.

------
ericclemmons
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](https://github.com/ericclemmons/grunt-angular-modularize)

------
ivan_ah
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...](https://github.com/ivanistheone/backbone-and-browserify-
phonecat/blob/commonJS/src/init.js)

~~~
burke_holland
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?

~~~
anton-107
Does the order of files concatenating matter with angular modules?

------
matdes
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"

------
vkjv
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.

------
latchkey
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.

~~~
diff_sky
browserify can create source maps, either within the file or externally:

[https://github.com/substack/node-browserify#external-
source-...](https://github.com/substack/node-browserify#external-source-maps)

~~~
latchkey
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.

------
ahuth
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?

~~~
jaredmcateer
Yes it does, plenty of options in fact, but as far as I can tell there is
nothing in this article tying it to a particular backend

~~~
burke_holland
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.

