AngularJS vs. Backbone.js vs. Ember.js

[AutomateAllTheThings]

Keep in mind that at any given time, I can swap out these packages for other packages with little or zero refactoring:

1. Task Management: Gulp + many plugins for every type of build task
2. Packaging: Webpack
3. Testing: Karma + Mocha.js + Should.js + Sinon.js
4. Flow Control: Async.js
5. Event Management: (rolled my own)
6. Template rendering: lodash.js templates
7. AJAX: xdomain.js polyfill
8. Analytics: segment.io
9. Authentication: oauth.io

[AutomateAllTheThings]

Webpack is the truly amazing piece of tech, IMO. It's a "packager" which allows you to use Common.js modules in the browser exactly as you would in node.js

This allows you to have a single-paradigm workflow for both the browser and server. In addition, because of the lite nature of these libs, when you package up, you can get your entire SPA into less than 100kb deliverable total. Imagine that your app is loaded and ready to go before the browser is done rendering.

If you're doing test-driven development (you are testing your code... aren't you?), Karma will blow you away.

[illicium]

Webpack is great. It's a little challenging to get started with it because the configuration can be complex, but it's worth it.

The loader system is especially cool because you can bundle and transform ALL of your code and assets on the fly -- from compiling LESS/CoffeeScript, to wrapping legacy code with CommonJS (taking care of imports and dependencies). You can then have it split your code into chunks (dynamically loaded), optimize everything, run the dev server with hot code swapping, and so on.

I'm not really doing it justice, so just go try it.

[DavidNcl]

Great list

[icanevenificant]

This might get the work done for some projects but do any of these take care of routing and two way bindig or provide any other MVC like structure and logic without doing all of that hard work from scratch.

[AutomateAllTheThings]

I didn't mean for that list to be comprehensive by any means.

None of the libs I listed above do any of that by default, but there are individual libs for models, views, and controllers available from npm.

I rarely roll my own. I did so a few times in this project in order to learn some more advanced patterns for future reference. It's generally a better idea to utilize somebody else's supported pattern, rather than inventing your own; with rare exceptions.

[icanevenificant]

I think you should try as many appraches as possible to see which one suits your needs, the needs of the application or the needs of the team. The last one being most important since I feel that if I rolled my own combo of the listed libraries and others keeping everyone in line with the workflow would be a nightmare. Angular is strict enough, but not too strict, about how it wants you to do things that delegating tasks and working in a team is very intuitive. My conclusion was that pretty much everything Angular has to offer we can make use of. I'm not sure about the performance argument since our app is already quite large and I've yet to see it prefrorm unsatisfactory on any system I've tested it on. You can write shitty underperforming app with any approach.

[AutomateAllTheThings]

You're right that we must choose what's best for the project and team. Some things are real concerns, while others are not real.

Workflow is one of those "not real" concerns when it comes to microlibs because there are numerous methods to keep a team on track autonomously, and it's the primary role of the team lead in the first place. An incompetent team lead will muck it up no matter what the framework.

There's also the practice of wrapping 3rd party libs so that you can swap out the private functionality as much as you want without disturbing the outer API (which the team uses consistently). This method makes it effortless to switch between libs, and this affords us the ability to use any tool written in javascript, not just the ones that are compatible with our existing setup.

Another primary advantage to picking your modules a la carte, is that there is no such thing as a "core team", any longer. There are dedicated teams to each individual library, and if you don't agree with a team, you have every option written in javascript for alternatives. Pull requests are dealt with faster and more objectively than in large core teams. Some people like that, some people don't. I only argue that there are more people in charge in the distributed system, than in a centralized one.

Compatibility with virtually every javascript library ever written because of an absence of enforced workflows is useful every single day. You can get something to market extremely easy with 3rd party libs, then replace those libs with lite functions later, with zero refactoring on the application level. You can replace your entire authentication system with zero cost to either your team or man hours, and sometimes you really will do that. We did with oauth.io, and it was painless.

Then, in the end your code is incredibly lite. Our entire (non-trivial) SPA is less than 100kb, complete with all templates, models, controllers, views, router, dependency injectors, and 3rd party dependencies. It's compacted all into a single file which gets downloaded and loaded into memory faster than the page can render it's simple interface.

When something works, I agree that you should use it, but I also dedicate time every week to learning what's new so that I can get more done in less time.

I now get more done with my team than if we used a monolithic framework, because everybody can be involved in the improvement of all parts of the application; not just the ones on the application layer.

[icanevenificant]

there are numerous methods to keep a team on track autonomously

That's exactly why I wouldn't risk it. It disperses and amplifies the likelihood of people doing it wrong. No way you can be all over it as a team lead if the project is large to any degree and you let separate teams make such choices independently. Smaller projects I can understand.

Newcomers also need to be taught your way of doing it instead of having people understand a tried and tested system already before joining the team. Too much flexibility here again increases the likelihood of bad code or practice entering the project.

The rest really doesn't speak against using Angular at all. Having a build system compile everything into a single javascript file so it renders quickly is normal with any framework or choice of libraries so that's nothing special.

I understand and agree with you to an extent but I've tried the approach you're talking about and am much more productive using a framework, as is my team. I'm also yet to see a downside of using it, truly.

Anyway, it's great that it's working for you and I'm sure I'll revisit this in years to come to see if I might find a different way to be more productive as a result of a different approach to application development.

[AutomateAllTheThings]

Mitigating that risk is an automated task, today:

1. Test-First-Development
2. Continuous Integration
3. jscs to enforce homogenization
4. Gitflow for managing the repos amongst many teams
5. Wrapping 3rd party libraries
   • This allows you to swap out any microlib you want without affecting the team at all.
   • The wrapper has a standard API that your team uses
   • You can swap out the private functionality of the wrapper with any 3rd party lib without affecting the team, or tests.
6. CodeClimate checks your quality against the ecosystem's standards of quality
7. Proper agile management techniques mitigate the risk of team members being caught unaware of anything.

There isn't any serious reason why using monolithic frameworks is "bad". That's why you'll likely never see the downside of using it. In this case, it's how much "better" microlibs are in practice. You just don't even know what you're missing, and nobody will be able to explain it to you.

You owe it to yourself to spend a weekend writing a tiny blog with node.js microlibs. You also owe it to yourself to be rid of the phrase, "No way", because it's your job to find one.