When have you ever picked up code that was written as an integral part of an application using a framework (not just a library) and dropped it into another completely different one without a fair amount of re-work?
Unless you're using highly well-established APIs (such as promises), then of course, you'll have to rewrite things to match the new expected syntax.
Portability of knowledge is a different beast. For example, the vast majority of ng-repeat related concepts is completely non-portable (think `ng-repeat-start`, `track by`, `(x, y) in foo`, `$index`, etc). You learn that `ng-repeat="x in foo | filter: bar"` is equivalent to a for loop that displays only some items, but you can't really apply that knowledge anywhere outside of Angular.
You can't reuse your basic knowledge of for loops and if statements coming into Angular, and you can't use your knowledge about the pipe syntax anywhere else when you leave Angular.
In contrast, a framework that employs `.map` and `.filter` might teach you a bit about FP, and this is something you can use in Angular, Ember, React, and even vanilla js.
You are arguing that syntax equals mobility which is incorrect. .map and .filter can have different syntax depending on the language, just as ng-repeat (the equivalent to a for loop) has a different syntax than a for loop in Perl.
Knowledge and syntax are two different things as well.
> You are arguing that syntax equals mobility which is incorrect
No, I'm saying that the knowledge of the concepts of map and filter (as an example) is easily transferable even if syntax isn't. Once you understand those concepts, you can go look up the Ruby/Haskell/whatever syntax and you can reuse your new knowledge of higher order functions, and maybe learn about transducers, or maybe you can go look into point-free style, and the testability benefits of pure functions vs procedural style, etc, etc, etc. Not to mention that by knowing `.map`, you already know a great deal about the template languages for React, Mithril and Mercury.
In contrast, say I've learned about pipe operator precedence in ng-repeat expression clauses. Now I know I can write `x in (foo = (bar | filter: baz))` to memoize a filtered list for use later in that template. But only in Angular template expressions. But not in Javascript. Or Ruby. Or Haskell. And it's a terrible idiom to use in Angular anyways because [insert long rant about a bunch of unrelated topics].
Aside from the knowledge that operators can be recursively composed into god-awful expressions, what part of all that is useful if I migrate to Ember?
Or, say I learn about directives, and transclusion and the ngModel attribute micro language, and $compile and priority and the ngModelController API and ...
These are most certainly not syntax-related concepts. What does learning that get me?
That is a fairly edge/small point - using something like `.map` and `.filter` to generate the DOM itself is pretty ugly, and those functions quickly become useful in other contexts.
Check out Mithril: http://lhorie.github.io/mithril/
Using the regular syntax isn't actually that bad. It's unusual, certainly, but compared to HTML (when you actually think about it, rather than just say, "It's different and I don't like it"), it's alright.
Also, as a framework, it's got a lot less magic than Angular, and lets you write javascript code that's much more like normal JS code than angular does. (IMHO).
Also, the articles by the Mithril main author about JS & development philosophy are really good. I really like his style and approach to front-end development.
What's the long answer? I think it's laughable to say that you can take a part of a monolithic framework and drop it in as a replacement in a different framework.
Actually a short answer will do fine. Ignoring Backbone, name ONE part of a major framework you can do that with?
longer answer - there is rarely drop in replacement, but when framework uses other well designed technologies, instead of reinventing the wheel, knowledge about these technologies way more useful, than knowing details and gotchas of $digest loop.
Examples:
* handlebars templates used in many frameworks. Quite often you can literally copy templates over into new project.
* usage of real promises allows you to use chai async tests without looking back at framework, instead of relying on right timing of firing $apply() (and making sure to not call it twice!)
* not relying on dirty-checking, and instead use setters/getters quite often forces you to think and isolate model code from glue.
* describing state via html (as it is proposed with ui.router - very popular component) can not be easily migrated at all, since most of frameworks define state in code and/or configs. This is paradigm shift.
While I agree, the bigger framework, harder it gets to write portable code, but angular in practice tends to make it even harder in my experience.
So basically, your problem is you like to pick and choose modular pieces from non monolithic frameworks and "Angular sucks" because it doesn't do what you like.
There's nothing wrong with Backbone, particularly when you like to replace parts with other parts. But Angular is not bad simply because modularity wasn't a design goal.
It's notable that your arguments aren't arguments against Angular persay but against every single non-modular framework ever made.
I don't mind people disliking Angular. I mind it when people pretend their preconceived notions about software design are "right" and software that doesn't align with their notions are "wrong".
I don't like when I can't replace broken part of framework. And this is often the case with angular. Mostly because of foundation it is built on - dirty checking and it's own dependency injection mechanism. Because of these two there are a lot of things backwards. dirty checking is major cause of whole $digest loop, as well as every async function being mirrored via $-equivalent and non working promises. This cruft accumulates over time and wastes a lot of human resources.
The only reason you might not dislike angular is if you never had to deal with issues above OR you never had different experience, sorry.
Like I said, that's a ton of opinion based entirely on YOUR desire to replace parts YOU don't like. Dirty checking isn't perfect (by any stretch) but it's not the worst thing to happen since the cold war either.
The bottom line seems to be that your bad experience is relevant while all good experiences are irrelevant because they weren't your bad experience.
That tells me you simply don't know how to use it, sorry.
A number of times: but the code was heavy on business logic, which was factored into a domain model. The UI code was simple, it was broadly mapping domain concepts (states etc) to UI concepts (colors, visibility of various elements).
