I'm pretty new to front end development, and a few months ago I started learning Javascript by experimenting with a few front end frameworks. When I got to Angular, I dropped it the moment I saw string-based expressions. How is that even remotely acceptable? I can't even imagine the bugs I would be embedding everywhere.
Give react.js a try. I am not a web developer either. Saw Angular first. Got lost in the soup of new terminology -- digest cycles, dependency injections, services, factories, scopes. I suspect Angular probably made sense to already experienced JS developers who had to struggle with jQuery before...
But then I tried react and the whole idea of unidirectional event flow made sense, JSX was a little confusing but it was simple to grasp the need and use of it.
That is the route that I'm currently going down. So far, it has been a joy to work with. My only complaints to date about React have been the incompleteness in the documentation about events, and the jsx attribute renaming (ex. className="foo" => class="foo"). I also worry (but haven't been disappointed yet) about pre-1.0 instability.
I really like the acknowledgment that UIs are fundamentally state machines, and React's explicit connection between state and rendering. I do wish they would introduce more featured state transition/events modeling...Something similar to Jake Gordon's javascript-state-machine[1] library would be amazing.
That annoys everybody. It's that way because the JSX attributes map directly onto the DOM attributes which in turn are named that way to avoid ES3 reserved keywords. It's supposed to be less magic/surprising but far more people interact with JSX (e.g. designers) than work with raw DOM manipulation.
> I suspect Angular probably made sense to already experienced JS developers who had to struggle with jQuery before...
Not really. Angular is its own little world of terminology and ideas. I've heard it said that Angular users don't learn JavaScript, they learn Angular.
Absolutely the case - I enjoy Javascript coding but can't stand having to follow Angular's opinions on everything that should be done to the DOM. Having a consistent model of interaction is great, and Angular enforces that while giving you quite a few nice tricks, but it does it in a way that feels so far away from JS itself that I'd bet it actually hurts your Javascript composition to know Angular.
The concepts on Angular have nothing to do with JavaScript. The new changes they propose to JavaScript borrow most from Dart, which in the eyes of a JavaScript programmer is an attempt to turn JavaScript into Java.
Meh, over the last two years I've worked on a team that put two medium complexity SPAs into production built with Angular; in my experience, the string-based expressions are a non-issue, I can't really think of any time when it caused difficulties in our development. Yeah, it's less than elegant, but if you keep the expressions simple (e.g. use functions for anything more complex than single term expressions) then there really isn't much to stumble over.
So, on one hand, yes. As a clojurian, I feel as if I should add an additional level of condemnation (the whole syntax of my favorite language is good old-fashion data structures, as is almost every construct within the language).
That being said, it's frontend stuff. The turnaround times are so small that those kinds of bugs are pretty hard to ignore, and very easy to find.
Note: I have used Angular, but don't use it anymore, for other reasons.
Their model for dom composition is substantially more complex than I would prefer. Angular, at it's core, is something like a re-imagining of the dom + js-event-loop that is hackable and modifiable. Good goal, but the complexity doesn't buy you much over e.g. reagent or meteor, which are _much_ simpler.
You ask that as if not suggesting an alternative to Angular invalidates suggesting avoiding Angular like the plague.
There are MANY viable alternatives. No one solution fits all, but some solutions, like Angular, fundamentally suck at everything, because they're terribly designed, and their developers refuse to acknowledge or correct that fact.
In order to answer your off-topic question, which is outside the scope of this article, you'll have to explain in detail all about what your actual requirements and experience and expectations are, and for that you should expect to pay a reasonable hourly rate for an experienced developer to listen to you and give you advice.
If that's what you really want, then good luck finding someone to help you with your problems choosing a decent web framework, but at least you now know that Angular simply doesn't qualify. But if you're just trying to imply that it's not right to criticize Angular without evangelizing an alternative, you're wrong.
> No one solution fits all, but some solutions, like Angular, fundamentally suck at everything, because they're terribly designed, and their developers refuse to acknowledge or correct that fact.
That's utter BS. There are lots of very good ideas in Angular. Yes, some of it is not done nice but at the end of the day it's quite a nice framework. Have you even worked with angular?
Two-way data binding really is very convenient, even if it doesn't scale well to large amounts of data. It still saves you a lot of jquery-style boiler-plate code to read values from once place and manually update it in several other places in the DOM.
Also, Angular forces structure on you in ways JQuery doesn't. It makes unit testing viable. I rewrote a javascript slider in Angular, and the code became a lot simpler, shorter and more readable, exactly because of all the stuff Angular abstracts away.
So in comparison with JQuery, the previous best javascript library, Angular has some very clear improvements. How it compares to Ember and Knockout, I have no idea.
