novagenesis

I've known a lot of people burned by those deals.

The feeling you get is "I can prove my way in!" but the facts are usually related to which budget columns to drop you in...and if that's the case, budgeting is tough at that company, and the "contract-to-hire" is a huge gamble.

If someone wants you full time and refuses to hire, you HAVE to just treat it as a contract gig...and if the price is not contract-gig priced, you should probably move on.

Perhaps, but using Databinding comes at a price.

The moment you databind, you can't use nearly as many other libraries as easily or safely. This means you want as fully-featured a databinding library so you don't need other stuff.

There's tons of articles about providing Angularjs updating support when you use jQuery..it's (or used to be) just painful.

#2 is the killer.

Databinding is a lock-in feature. Annoying as hell, but true. There's no databinding library that I've seen that does not reduce your ability to use other libraries. I've never seen one that jives at ALL with third-party client templates (like dustjs).

If that logic is on the server, you wouldn't use Angular for it...

But from a strict MVC standpoint, it seems smart for that logic to be on the client. The server provides a getter API: /api/schools_by_state/CA for example. The client does an ajax call if you choose "California" to get the schools list, which it can do in under 100ms on a fast enough world...then it can cache California schools on the client side, so it doesn't need to fire that call again.

And of course you want that calculation to happen on the client, for 2 reasons:

1. In sparse-use sets (like pick a state, then pick a city, then pick a district) you will only really need to use 10% of the data, you can save a ton on bandwidth here.

2. In situations where the render patterns get complicated, it's really just a PRESENTATION issue. The server may validate that you're not using noncompatible dropdowns, but it otherwise should not care what happens in the browser related to that.

If you think it's oversold, you've probably only seen a bunch of stupid tutorials about neat features with it.

What Two-way data-binding gives you is a structurally-controlled presentation layer.

You can represent the page's state as objects with properties, and it "just renders". You can have a "readonly" property, and it makes everything readonly. You can have a "show edit box" property...bang. A "loading" variable, etc.

The idea is that you can treat the front end html like everyone else has always treated their world: as a finite state machine.

Since I am primarily a back-end developer (with more middle-tier experience than I originally would've wanted to admit), this jives really well to me. Instead of jumping in and hacking at the DOM every time data gets updated, I just use Angular for pages that are "that dynamic".

I really don't want to have to render new DOM elements (even with a template engine like Dustjs) and overwrite them into the page, just to represent a small state change.

With a data binding library, I don't have to. I don't use Angular for many things, and I sure don't use the "SPA routing" functionality... but when I need to do constant rapid-fire AJAX requests for growing subsets of a huge dataset (say, schools/programs by region and proximity), Angularjs saves you a lot of code: code that's generally quite ugly.