Requiring vs. Browserifying Angular(developer.telerik.com)
developer.telerik.com
Requiring vs. Browserifying Angular
http://developer.telerik.com/featured/requiring-vs-browerifying-angular/
8 comments
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.
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
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...
example backbone app: https://github.com/ivanistheone/backbone-and-browserify-phon...
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?
Does the order of files concatenating matter with angular modules?
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"
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 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.
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.
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-...
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.
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?
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?
Your front-end application shouldn't be tied to what back-end technology you've chosen.
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.
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.
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
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.
I think it depends on the framework.
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?