Angular and RequireJS

[Dave Smith]

I've heard grumblings from people that Angular reinvents or does not work with RequireJS.

Then I saw this:

http://weblogs.asp.net/dwahlin/archive/2013/05/22/dynamically-loading-controllers-and-views-with-angularjs-and-requirejs.aspx

How does this tickle people's fancy? Thumbs up, down, sideways?

--Dave

[Sean Clark Hess]

It's cooler. I think it makes more sense to make something that dynamically loads scripts with the same name as the dependency. It doesn't seem like it would be that hard to write, and would be simpler.

RequireJS is useful for two reasons. 

1) it helps you think about your script dependencies clearly, avoid gobals, etc

2) it loads files dynamically / on demand. 

For the majority of apps, #2 doesn't matter. Performance in production is fine if you have a program that puts all your app code into a single js file. Angular does a good job with #1, so I don't think RequireJS adds much. 

If your app is big enough to NEED loading scripts on demand, you have the resources to write something by hand (and in fact, you probably want to load entire modules dynamically, not individual files. Like major sections of the app). 

--
Group meets on the 1st Thursday and 3rd Tuesday of each month. See http://utahjs.com/location/ for more info.
---
You received this message because you are subscribed to the Google Groups "Utah JavaScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email to utahjs+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/utahjs?hl=en-US.
 
 

[Aaron Hardy]

How are you guys handling all the scripts in your dev environment? For example, do you manually add a script tag to your html each time you have another JS file to include? Or do you use a file watcher that concatenates your files during any change thereby allowing you to only maintain a single script tag in your html (but also forcing you to deal with a single concatenated file when debugging in the browser)? Or do you have an automated task that dynamically adds a script tag to the HTML each time you save a new JS file? Something else?

[Sean Clark Hess]

I use typescript, and it concats the files when I compile. I was super annoyed when I had to put script tags by hand. 

I would either use a file watcher to concat, or write a quick file loader thing that read the module names and imported them (it doesn't have to be robust, it's just for dev). 

[Randall Bennett]

Rails asset pipeline. :) It'll auto add script tags for you, and then when you deploy, you can compile the assets into individual minified files.

@aaron: What's serving your biz on the backend?

rb

[Clint Berry]

I use yeoman, so when I create a new controller or directive it adds the file to my index.html for me. It's been pretty nice.

[Merrick Christensen]

I disagree with your assessment Sean. Angular is kind of terrible at dependency management. Sibling dependencies can potentially collide with each other forcing you to use string based namespacing. Require.js uses file system namespacing which makes it enforces. Require.js also provides plugins and a build system (and static analysis tools), also a great side effect of using the filesystem for your namespaces is that you know exactly where your code is coming from at any given time.

While Angular's dependency injection is dope, I feel like its dependency management is horrible. Prefixes for namespaces? Are you kidding? Didn't we decide this was a bad idea forever ago?

</rage> 

[Ryan Florence]

While Angular's dependency injection is dope

I lol'd

[Merrick Christensen]

Function argument parsing aside, its pretty rad. 

[Dave Smith]

On May 23, 2013, at 3:29 PM, Merrick Christensen wrote:

 Prefixes for namespaces? Are you kidding?

Can you give an example of this?

--Dave

[merrick.c...@gmail.com]

Absolutely…

angular.module('MyApplication', ['Feature1', 'SomeVendor', 'Feature2']);

angular.module('Feature2', []).controller('ListCtrl', function() {

});

// Yup I will totally nuke Feature2 ListCtrl, looks like I am going to have to ghetto namespace...

angular.module('Feature1', []).controller('ListCtrl', function() {

});

angular….controller('f2ListCtrl', function() {

});

All namespacing is done via string prefixes, think ng(a-ZA-Z0-9)…

M

--
Group meets on the 1st Thursday and 3rd Tuesday of each month. See http://utahjs.com/location/ for more info.
---

You received this message because you are subscribed to a topic in the Google Groups "Utah JavaScript" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/utahjs/jz-6Zwe3pkU/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to utahjs+un...@googlegroups.com.

[Merrick Christensen]

This is further complicated by the argument parsing because you can't use paths in your namespacing if you wanted to...

To unsubscribe from this group and all its topics, send an email to utahjs+unsubscribe@googlegroups.com.

[Dave Smith]

Yup, that's crap. Indeed, that's not namespacing at all, since for example, no two modules can *ever* declare the same service name if callers are going to use both services. For controllers it's a lot less important, since controllers are usually written at the application layer. But for services that's crap. Total crap.

You heard it here first folks. Dave Smith said that something about Angular was crap. Thats' the only time I've done that. Well, that and the Angular date filters. Well, that and non-nestable ng-views[1]. But that's it. Really.

Everything else is really great though. It really is. In fact, I wrote a bunch of Angular code this very day. And I loved it. Thoroughly loved it.

I hope the Angular team doesn't read this, because I really do love their framework. I really do. It's awesome.

--Dave

[1] And at least this one is getting fixed with https://github.com/angular-ui/ui-router

You received this message because you are subscribed to the Google Groups "Utah JavaScript" group.

To unsubscribe from this group and stop receiving emails from it, send an email to utahjs+un...@googlegroups.com.

[merrick.c...@gmail.com]

Thanks for being rational about it. That was incredibly refreshing.

[Dave Smith]

A pinch of rationality with a pound of hyperbole. Just what you wanted?

--Dave

On May 23, 2013, at 3:53 PM, merrick.c...@gmail.com wrote:

> Thanks for being rational about it. That was incredibly refreshing.
>

[Sean Clark Hess]

Fair enough. You're right. I just feel like RequireJS doesn't quite have it right either. 

I wish people would write more specific tools that did one job really well instead of writing monolithic things that were incompatible with each other. 

On Thu, May 23, 2013 at 3:53 PM, <merrick.c...@gmail.com> wrote:

Thanks for being rational about it. That was incredibly refreshing.

[Dave Smith]

The root of all these problems, in my opinion, it that JavaScript doesn't have a module loader built into the language. Name one other modern language that lacks this feature. And no, the browser's <script> element does not count as a module loader. And no, C++ does not count as modern and #include is not a module loader. Not even close. Though it's a little better than just concatenating a bunch of files together and calling that a "build".

Even node had to build their own loader.

--Dave

[Clint Berry]

Another example of namespacing:

https://github.com/angular-ui/bootstrap/blob/master/src/carousel/carousel.js

they use 'ui.bootstrap.carousel' in that example. That does kinda suck. :-(

[Ryan Florence]

> RequireJS doesn't quite have it right either

AMD is the only JS module implementation that is a workable target for ES6 modules in the browser.

So ...

[Dave Smith]

On May 23, 2013, at 3:58 PM, Clint Berry wrote:

Another example of namespacing:

https://github.com/angular-ui/bootstrap/blob/master/src/carousel/carousel.js

they use 'ui.bootstrap.carousel' in that example. That does kinda suck. :-(

But Clint, that's an example of the very problem we're discussing. Sure, the prefix "ui.bootstrap.carousel" is kinda ugly, but ugliness doesn't even begin to approach the problem.

What if the module "ui.bootstrap.carousel" contains a service called "myService", and then I create a new module called "ui.dave.module", and it also contains a service called "myService", which one of these two services would get injected into my controller:

function MyController($scope, myService) {

// What is myService? Did it come from "ui.bootstrap.carousel" or "ui.dave.module"? No one knows.

}

So that just means that your services have to be *additionally* namespaced beyond just the name of the module that contains them.

--Dave

[merrick.c...@gmail.com]

Yeah I longingly await ES6 modules. Sharing code is a language level problem.

[Sean Hess]

Has the spec been finalized? If so let's write a future layer for ES6 modules and be done with this nonsense. 

—
Sent from Mailbox for iPhone

On Thu, May 23, 2013 at 4:04 PM, merrick.c...@gmail.com <merrick.c...@gmail.com> wrote:

Yeah I longingly await ES6 modules. Sharing code is a language level problem.

[Dave Smith]

On May 23, 2013, at 4:04 PM, merrick.c...@gmail.com wrote:

> Yeah I longingly await ES6 modules. Sharing code is a language level problem.

Agreed. I haven't looked over the ES6 module spec, but I'll probably be retired before I can use it due to slow browser adoption (which is getting faster, but still).

--Dave

[Jamison Dance]

The spec is still in flux as far as I know. Aaron Frost could probably shed some light on that.

[Ryan Florence]

The ES6 module syntax isn't finalized, but its behavior is quite clearly defined. As a member of the TC39 once said to me in IM: "ES6 modules are basically AMD at the end of the day". (see attached image)

but I'll probably be retired before I can use it 

Every browser is now evergreen but safari. We will see it soon. The world is changing for the better in that regard.

AMD is identical, identical to commonjs aside from AMD's ability to load the dependencies async and its id strings (instead of relative paths). Since its so ugly its hard to see, but the syntax is just upside down.

Assignment on the left, dep on the right:

var foo = require('foo');

var bar = require('bar');

Dep on top, assignment in the params:

define([

  'foo', 

  'bar'

], function(foo, bar){});

So if you think that AMD's semantics "has it wrong" then you necessarily think commonjs has it wrong, too--unless your argument is that async loading is bad for the browser.

[merrick.c...@gmail.com]

Well, there are certain things AMD just can't do by nature of running at the JavaScript layer… ES6 is gonna give us some delicious aliasing and the ability for the consumer to decide what is imported rather than the module. (Using from syntax.)

ES6 > AMD. But its no secret I believe AMD is the best we have right now.

<Screen Shot 2013-05-23 at 4.17.34 PM.png>

--
Group meets on the 1st Thursday and 3rd Tuesday of each month. See http://utahjs.com/location/ for more info.
---

You received this message because you are subscribed to a topic in the Google Groups "Utah JavaScript" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/utahjs/jz-6Zwe3pkU/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to utahjs+un...@googlegroups.com.

[Aaron Hardy]

PHP is serving up the data for the most part.  We use node for our client-side build process.

I've tried all (?) the methods that have been listed: auto-concatenating on file save (ugh, then I have to look at the concatenated file in Chrome dev tools and make sure the watcher is running), using yeoman or another tool to auto-add script tags (I still find myself manually managing tags and having to realize when I'm no longer using a file anymore to remove it), using RequireJS rudimentarily alongside AngularJS (it yearns to accomplish so much more). I've come to the same conclusion as some others that dependency management is pretty much an afterthought in AngularJS. I love what I've used of Angular including the dependency injection, but I miss a lot of AMD and RequireJS. I may have heard that this was going to been a focus in the near future from the dev team or something? Maybe I'm just spreading rumors...

By the way, anyone interested in working at Adobe in Lehi?  I'll probably post something later when openings are official, but if you're interested and skilled in the art of JavaScript, hit me up.  It's likely you would get to drive new development an Angular.

Aaron

[Sean Clark Hess]

What about Angular + CommonJS?  maybe it wouldn't hurt as much to use them together since CommonJS doesn't do as much as RequireJS :)

I'm sure there's a nice dynamic CommonJS loader / compiler somewhere. 

Oh, another option it seems you haven't tried: create a middleware or PHP route or something that concats the js when /js/main.js is called (or whatever it is). Then you don't have to remember to have the server running. In production, just have apache sitting in front serving the static /js/main.js and your dynamic route won't get hit. 

[Dave Smith]

On May 23, 2013, at 9:55 PM, Sean Clark Hess wrote:

> Oh, another option it seems you haven't tried: create a middleware or PHP route or something that concats the js when /js/main.js is called (or whatever it is). Then you don't have to remember to have the server running. In production, just have apache sitting in front serving the static /js/main.js and your dynamic route won't get hit.

This is what we do. We have Django middleware that, in development mode only, builds our <script> tags for us and injects them into the page. One per file. That way, our scripts are always up to date, and the files stay separate so line numbers in the browser match those in the files. We specify which scripts belong in each bundle in a config file. The downside is that adding a new script file means updating this config file. I think it's worth it for the ease of development and deployment.

In production, the same code that injects <script> tags instead concatenates the script files into one big file and injects a single <script> tag into the page. This only happens once, so we aren't doing it at each request, like the development middleware I mentioned above.

--Dave

[Sean Clark Hess]

I'd just bundle everything in certain folders into the file, to make it easier for development. That way you don't have to remember to update the config file. 

--Dave

[Dave Smith]

On May 23, 2013, at 9:59 PM, Sean Clark Hess wrote:

> I'd just bundle everything in certain folders into the file, to make it easier for development. That way you don't have to remember to update the config file.

We considered that, but we appreciate the flexibility that the config file gives us to include certain files and not others. One thing we did not do that we should have is support file globbing in the config file. That way, you could do what you propose and more, without the hassle of ever updating the config file when adding new Javascript files. One day I'll get around to adding this. One day.

--Dave

[Sean Clark Hess]

Do it now dave. What are you doing, watching TV? Hanging out with your family? For death and glory! For Rohan!

--Dave

[Dave Smith]

On May 23, 2013, at 10:08 PM, Sean Clark Hess wrote:

Do it now dave. What are you doing, watching TV? Hanging out with your family? For death and glory! For Rohan!

Rewriting another huge portion of our UI in Angular. For Rohan.

That's literally what I was doing before I paused to write this email. I suspect that's what I'll resume doing as soon as I send this email, but I can't promise.

--Dave

[Sean Clark Hess]

For people using node, I just started playing around with browserify. The middleware works great - I just use CommonJS and it bundles it all together for me automatically, with source maps. 

https://github.com/substack/node-browserify

https://github.com/ForbesLindesay/browserify-middleware

[Aaron Hardy]

FWIW, we've started taking this middleware approach with PHP. In development, PHP gathers the JavaScript files and generates script tags on the fly. In production, it points to the built file.  It works but there are pain points. For example, we really want our templates built into our production JavaScript file to reduce HTTP requests. However, in development, we want the templates to be loaded in individually and dynamically for easy debugging. It seemed logical to use grunt-html2js (https://github.com/karlgoldstein/grunt-html2js) for building templates into JS for the production version, but using html2js requires that our main app module depend on a templates module.  For example:

angular.module('main', ['templates-main'])

That templates module is what's built by grunt-html2js, so in development it doesn't exist yet. To avoid errors during development, we've created a dummy templates module that doesn't have anything in it.  It's lame-sauce but at least we're able to load files individually in development and can avoid having to have a watch running while developing.  Still looking for a better alternative.

Aaron

[Dave Smith]

Has anyone here considered doing a production-like deploy of JavaScript in your local development environments (e.g.: single minified JS file), but with source maps[1] for debugging?

This approach seems to be the best of all words:

1. Your dev environment and production are very similar, so you find problems sooner.

2. You have line numbers and file names.

3. It's still nice and fast (at least it should be).

4. It applies to CSS as well as JS IIRC.

I've never done it, so looking for opinions.

[1] http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/

--Dave

[Ryan Florence]

Yes, I'm working on this for ember-tools (minus minifying).

For @sourceUrl to work, it has to eval your JS. It's pretty straightforward. Your build tool wraps each file in `eval(src+'\n@sourceUrl='+filename)` and then concats them all together. The browser will now report them as separate files.

I'm not sure how minifying + source maps fits into the eval nonsense.

[Trevor]

I tried this using Browserify, and when I require Three.js, it takes about 10 seconds to compile everything—much too long. Using commonjs-everywhere was faster, but it still takes long enough that I can switch to my browser and refresh the page a couple of times before it finishes building.

https://github.com/krisnye/browser-build promises to be faster, but is much more complicated and not maintained as well. http://stackoverflow.com/a/16291054/711902 suggests that Browserify should be able to be made faster; I'll have to look into it.

The other inconvenience is that you have to have some process continually running to watch for changes.

I still think it's the ideal way to develop for the reasons you outline. Source maps worked great with both Browserify and commonjs-everywhere and made debugging as easy as they promise.

https://github.com/timwhitlock/php-commonjs looks interesting to me. A good Browserify-like tool written in PHP could help some of us who are married to PHP.

[Jason Dobry]

At work our build uses r.js to bundle everything into one file. This one minified file is loaded by default in production. However, our index.html has one little piece of code that looks for a "?debug=true" in the url, and if it finds it it changes the require.js baseUrl to point to the un-minified/un-concatenated individual files and loads those instead. So during development everyone just keeps a "?debug=true" in their url. No need to do a build to see changes or even use a watch process. 

[Jamison Dance]

We do something similar to Jason. We use r.js to minify and concatenate, but only run this process when deploying to prod. By default in development nothing is minified and concatenated, so you don't have the wait for build steps between every code change. That seems like awful nonsense to me in development.

[Jason Dobry]

On Thu, Jun 6, 2013 at 10:54 AM, Jamison Dance <jerg...@gmail.com> wrote:

We do something similar to Jason. We use r.js to minify and concatenate, but only run this process when deploying to prod. By default in development nothing is minified and concatenated, so you don't have the wait for build steps between every code change. That seems like awful nonsense to me in development.

--

Group meets on the 1st Thursday and 3rd Tuesday of each month. See http://utahjs.com/location/ for more info.
---

You received this message because you are subscribed to a topic in the Google Groups "Utah JavaScript" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/utahjs/jz-6Zwe3pkU/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to utahjs+un...@googlegroups.com.

Visit this group at http://groups.google.com/group/utahjs?hl=en-US.
 
 

--

Jason Dobry

801.369.6248

jason...@gmail.com

NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

[Jason Dobry]

Right, it's nice to just need to refresh your browser.

On Thu, Jun 6, 2013 at 10:54 AM, Jamison Dance <jerg...@gmail.com> wrote:

We do something similar to Jason. We use r.js to minify and concatenate, but only run this process when deploying to prod. By default in development nothing is minified and concatenated, so you don't have the wait for build steps between every code change. That seems like awful nonsense to me in development.

--

Group meets on the 1st Thursday and 3rd Tuesday of each month. See http://utahjs.com/location/ for more info.
---

You received this message because you are subscribed to a topic in the Google Groups "Utah JavaScript" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/utahjs/jz-6Zwe3pkU/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to utahjs+un...@googlegroups.com.

Visit this group at http://groups.google.com/group/utahjs?hl=en-US.
 
 

--

[Clint Berry]

Reload your browser? You need this: https://github.com/gruntjs/grunt-contrib-watch#optionslivereload

You received this message because you are subscribed to the Google Groups "Utah JavaScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email to utahjs+un...@googlegroups.com.

[Aaron Hardy]

I used to do the same with RequireJS+Backbone but haven't figured out how to appropriately merge the concept with AngularJS. In development I would point Require to my main.js (or whatever the root file is) and since main.js required other modules it would go request them asynchronously.

When you mention you're using r.js and Require, are you using them with Angular?  If so I can see two ways of doing this:

(1) Maintaining a list of all the app's angular files in main.js. Main.js just loads in all the files and that's that. It seems this would require the list of files to be manually maintained.

(2) Leveraging AMD by wrapping the contents of each Angular file in define(), specifying dependencies appropriately on a module level, etc. Then main.js requires one or two of the core dependent AMD modules and the loading cascades down according to the dependency tree created through AMD.  Using RequireJS/AMD+Angular seems like it could present an awkward setup due to confusion as to where dependencies are coming from (RequireJS or Angular's DI).

Are you using one of those options or something different?

Aaron

On Thu, Jun 6, 2013 at 10:54 AM, Jamison Dance <jerg...@gmail.com> wrote:

We do something similar to Jason. We use r.js to minify and concatenate, but only run this process when deploying to prod. By default in development nothing is minified and concatenated, so you don't have the wait for build steps between every code change. That seems like awful nonsense to me in development.

--

[Jason Dobry]

Using option #2

[Ryan Florence]

In ember-tools (similar problem) I maintain a "main.js" that loads my application modules so that my application modules explicit dependencies (non-app) don't seem weird.

Scripting the main.js file has helped me to not worry about it anymore. I also makes adding new modules as simple as creating a new file in the project.

Does your application require your modules or do your modules require your app?

I like to think my application requires my modules since its the one creating instances of them all.

[Jason Dobry]

My app requires my modules.

[Seth House]

On Thu, Jun 6, 2013 at 2:30 PM, Ryan Florence <rpflo...@gmail.com> wrote:
> Scripting the main.js file has helped me to not worry about it anymore.

I've been playing around with dynamicly generating parts of my main.js
lately and I'd be interested to see what you're doing. Are you able to
pastebin an example?