Modern Web Tooling

[btford]

@simpulton: What are your thoughts on using a tooling based on Bower, Grunt, and Yeoman?

I'm a bit jaded as someone who works on this stuff.

Pros

• Make releases, testing, etc easier.
• Show an AngularJS app used in a larger context.
• Tools written/config'd in JavaScript/JSON. Should be familiar to a web dev.

Cons

• Potentially more intimidating.
• Higher barrier to entry.
• Not everyone will want to use these tools.
• Tools still somewhat in flux.

[simpulton]

How tightly coupled are we going to be to the tooling?

I am all for showing AngularJS in a realistic and larger context but I do not want to force developers hands.

I think we should do a straw poll and see what people think.

[btford]

How tightly coupled are we going to be to the tooling?

Not at all, really. You won't need any of these tools to run/use the app. They are just there to make repetitive things easier.

• Bower just downloads dependencies. We will still check the dependencies into Github, so you won't need to worry about it at all. Bower will also make it easy to update to new versions of jQuery, AngularJS, etc. Independent of the other options, I think this is an obvious choice.
• Yeoman makes it easy to setup the project and quickly add new routes and stuff. Again, users need not be aware of using Yeoman. Yeoman also helps setup a build process through Grunt. Using Yeoman to do this means that if something improves in the build process, we can get those upstream improvements easily into our app. Right now, all we'd have to do to "support" Yeoman is restructure the files a bit.
• Grunt is basically an automation tool. For this project, that basically just means a build tool. The only thing this adds to the app is a Gruntfile.js that is pretty readable, and just lists the configurations for a series of steps needed to build the app for production (think SASS, minification, concatenation, etc). I assume we were going to cover building AngularJS apps anyway, and this is a good choice since it's written in JavaScript.

I do not want to force developers hands.

My concern exactly. I want readers to come away from the app feeling like they can apply what they learned to an existing app regardless of tooling.

I think we should do a straw poll and see what people think.

Sounds good!

[dconnolly]

I like having an example of modern, cutting-edge development practices, especially in the context of a fully realized dev/project workflow. So I'd say go for it, while also describing each tool's purpose in the workflow and how it could be replaced by something else if one chooses to.

[necolas]

Could you hedge your bets and start with simpler examples that don't rely on tooling, but then be realistic and include use of your full tool-chain it gets serious?

[jessegavin]

I think you should keep the AngularJS one focused on Angular, but ALSO write a book about Yeoman/Bower/Grunt.

[orestes]

Maybe you could come up with a chapter dedicated to Angular JS integration with other tools, but making it optional. I love learning new languages and frameworks, and what works best for me and most of my colleages is learning how to build things from the ground up, even the tedious parts, and later learning about workflows and tooling. @johnlindquist does something similar in his Egghead.io screencasts and I think they work out really well.

[sbegaudeau]

I think that it would be a great idea to have more details on those tools as creating an application is not just about the code. I personnaly use yeoman, grunt, etc for some AngularJS projects (code generation, unit tests, code coverage, lint) on Jenkins and more information and/or best practices on the subject would be great.

[btford]

Thanks everyone for your comments and insights!

I did some more thinking, the main restrictions to using these tools is just the folder layout. For example, Yeoman puts controllers in app/controllers/someCtrl.js, and Bower installs 3rd party libs to app/components/AngularJS/angular.js.

So what if we built the app initially without any mention these tools, and they just "happen" to use the same file/directory conventions? This way, you can decide to use the tools later without any additional work, and if you choose not to, you haven't done anything unnecessary. We can have a chapter or appendix dedicated to using these tools, and make note in the book.

[btford]

but ALSO write a book about Yeoman/Bower/Grunt.

@jessegavin I'm already considering it. :) You could definitely do a book on just these tools alone. Focus on this book definitely should and will be on AngularJS, but I'd like to at least get readers started using some of these tools because I think you get some huge productivity wins out of them.

[necolas]

Just an FYI, Bower is likely to use bower_components as the default install dir going forward. You can configure it to use a different dir name if you want.

[btford]

@necolas: good point. Added to cons: Tools still somewhat in flux. (I don't think this is that much of a con because most changes will be backwards compatible, or configurable to be so)

[sindresorhus]

@btford Tools are still in heavy dev. Focus on Angular, and mention tools.

[simpulton]

I am inclined to agree with @sindresorhus I think it is hard enough to write about one moving target but to tie in a few other tools that are in transit could REALLY blow up.

I vote we just adhere to the tooling conventions and then have an appendix or chapter about the tooling around it.

[cironunes]

I think that if you really wants show the "in-action" world you MUST write about:

• testing
• deploying
• maintaining
• best pratices

and mainly tools

[0x-r4bbit]

First of all: Thanks for writing a book about AngularJS. I'm using Angular for a long time now, so my claims to learn something new in angular or just something like how-to-do-things-right, are pretty high.

Nevertheless there're beginners who just needs a getting started guide or so. IMHO a beginner should learn how to do things from scratch and by hand. It's like someone who want to learn HTML. This guy should use a simple text editor at first and after enough practice, he should consider using a full-featured HTML-Editor. So it would be a tragedy if someone knows how to do things with tools which do the job for you, but doesn't know how to do it without the tools.

In addition to that, the current Yeoman angular generator is structured by layer, not by feature. Which isn't actually a good practice. So teaching readers to use Yeomans generator to get a boilerplate as application startup, also teaches readers to do it in a way it shouldn't be done anymore.

So don't get me wrong, I'm a big fan of bower. And I also would consider using Yeoman if the generator-angular follows Josh' ngBoilerplate proposal. But as long as there are also beginners under the readers, using these tools should not be a requirement.

I think I'd be better to just use git to clone one or the other repo and do that across the whole book. And then there could be a chapter for tools, to show how things could be done easier.

And again, there are also peeps who already have good experiences with angular and would like to learn some nitty-gritty stuff. Since there are a lot of ways to solve a problem, it'd be great to pick some of these and show how to solve them right.

You guys are great.

My 2 cents.

[zmilan]

I vote for include/use it in book examples, but without spending too much space on how to configure it and rest of their specific topics. Just in book source include what is need and point us to online docs for read more.

[cburgdorf]

+1 for @PascalPrecht 's comment

[devpaul]

Focus on Angular. You could write an entire book on Yeoman/Grunt/Bower.

More interesting to me would be a best practices book for continuous delivery with node and stand-alone browser projects. Something that touches upon combining node, Vagrant, Puppet, private npm repositories, git, yeoman, bower, Jenkins/Travis, Heroku/AWS/cloud, with Grunt automation!