
Why I was Wrong to be Afraid of Angular.js, Part 2 - lerouxb
http://daemon.co.za/2014/03/why-wrong-to-be-afraid-angular/
======
lerouxb
I agree with just about everything in the post, but:

> I think the fact that the Angular community has made real progress towards
> divorcing themselves from jQuery is one of the most encouraging signs for
> their future. The design of Angular is just different enough, and it is just
> compelling enough, that it has convinced a whole range of developers to
> build a new generation of libraries that I suspect are more likely to be
> suited to whatever the next iteration of the web as a platform will look
> like.

This part bothered me a bit. The article doesn't make the case for why jQuery
needs replacing or why all that duplicate effort is a good thing. Don't get me
wrong: I'm not married to jQuery and I'm open to the idea of there being a
better way.

I just don't find the idea that we have to move away from jQuery that self-
evident.

~~~
farnsworth
It's about imperative vs declarative styles in DOM modification, animations,
etc. I've been learning Angular the past few weekends, and I've come across
tons of SO questions that boil down to "how do I use my familiar jQuery
patterns inside Angular?" where the answers are usually "you don't, here's a
better way" usually with some Angular directive which fits that pattern
naturally. Also, lots of blog posts contrasting the two styles.

As I've gotten comfortable with it, I've come around to seeing it their way.
I'll never write jQuery-selector spaghetti code again if I can avoid it.
Here's my favorite SO question on the topic:
[http://stackoverflow.com/questions/14994391/how-do-i-
think-i...](http://stackoverflow.com/questions/14994391/how-do-i-think-in-
angularjs-if-i-have-a-jquery-background)

~~~
ssmoot
> It's about imperative vs declarative styles in DOM modification, animations,
> etc.

I don't understand. I mean, Angular doesn't seem any more "declarative" than
the Behavior.js you could write 7 or 8 years ago.

And jQuery made setup a bit different, but you could easily still keep doing
the same thing with declarative decoration.

When talking about directives (specifically) Angular doesn't appear (to me) to
really offer anything new outside of some questionable conventions for
structure.

~~~
bmm6o
Angular is an MVC framework, which means that your code should be updating the
model and letting Angular push that to the view. A lot of the stuff you would
do with jQuery is directly updating the view. So instead of writing something
like:

$('#whatever').addClass('selected'); // say this is in an event handler

you should write:

$scope.isSelected = true; // this is your ng event handler

and the html is like this

<div ng-class="{selected: isSelected}">

That is, you think a lot more about the model and how it's represented in the
view (declarative) and less about what to do to the view to make it look the
way you want (imperative).

That's not to say that there's no place for jQuery in an angular app, but it
does replace a lot of the typical uses. And fighting it just leads to
frustration.

~~~
ssmoot
I guess it's a grey area, but that all looks pretty imperative to me.

I think a Calendar Directive is probably a better example. But the declarative
part (ng-calendar vs a jQuery binding for data-calendar) is the smallest part
of the effort.

I don't know... it all just feels like a lot of work for little benefit. Back
in the Rails 0.x to 1.x days even point releases routinely broke applications.
In hindsight it was a terrible idea to build on the platform at that time.
Going with more mature solutions would ultimately be more cost effective for
anything but prototype level demonstrations (IME).

Angular feels a lot like that. Plus the whole nested controllers are pretty
reminiscent of Windows Forms programming. Which was an awful paradigm that was
replaced with stuff much closer to HTML for a reason. So Angular feels like
repeating the mistakes of the past.

On top of that you're using a fairly terrible language, and reintroducing the
idea that you need to write tests to prove syntax and correctness at a text
level.

Then you write more code to accomplish less.

And 6 months on you've spent more money than the team who went with HTML and
jQuery, and over the long term you've increased maintenance costs over that
team's output if they've put any care at all into maintainability,
encapsulation, modularization, etc.

That's just my personal experience anyways. It's an awful, terrible, complex,
fragile framework with a lot of busy-work attached in a runtime that's just
not very good with these patterns.

I mean Patterns are Typed. That's the unspoken bit. You can't describe an
ActiveRecord, a DataMapper, MVC, MVP, Strategy, etc without Types. And JS has
about the weakest Type system among mainstream languages I can think of.

I implemented a "JavaScript on Rails" sort of system in JScript in ASP Classic
some 8 or so years ago. The fact that the runtime is persistent now and
parsers much faster doesn't much change the fact that it's still an awful idea
IME leading to... well, a lot of wasted time and money when you could instead
be doing something predictable, that's more maintainable, runs faster, and is
less expensive to develop and maintain.

But maybe that's just me. :)

~~~
bmm6o
Sure, I wish Javascript had a stronger type system too, but I'm not sure how
that's relevant to an Angular/jQuery discussion. You still have business logic
that you either test or don't test, right? At least angular globally supports
DI for sane unit testing.

You're right that directives are very declarative, but I didn't mention them
because they don't really have a counterpart in jQuery unless you rolled your
own.

I like Angular a lot. Even just the data binding and $watch system would
relieve a lot of tedious code and can make for a really responsive UI.

~~~
ssmoot
The relevance (to my mind) is that Angular tries to bring in MVC and other
Patterns.

And I think any time you attempt to mix PoEAA style Patterns with weak Type
systems you're trying to force a square peg into a round hole.

IME it's much more successful to focus on the Functional aspects, Declarative
binding, and Modularization since with tools like jQuery these things are
JavaScript's bag.

And Angular is about as far from a Functional style as you can get. So to me
at least it feels very much like the wrong tool (JavaScript) for the job
(building and using an MVC framework).

------
singingfish
We've been doing well encapsulated, tricky back end stuff for a while. Started
with angular over the last month. Angular basically achieves the same proper
separation of concerns that our perl-based back end tools do.

Angular is not really interesting because it's the new big thing. It's really
interesting because it's right. (bitch of a learning curve though).

~~~
AdrianRossouw
I think it's interesting in that it proves that the web components approach is
going to be a valid and attractive way to solve certain types of problems.

I think that it started us off into a bold new direction, and due to it's
popularity will increase the general audience who would be attracted to it or
related systems.

I don't know if it's going to still be around if/when we reach whatever the
'platonic ideal' of this approach to web applications is.

~~~
singingfish
Yeah I kind of agree. Which is why I'm more interested in it because it's
"right" rather than because it's trendy.

------
AdrianRossouw
This is part 2 of this discussion :
[https://news.ycombinator.com/item?id=7384937](https://news.ycombinator.com/item?id=7384937)

------
ahuth
You don't need to worry about dependency injection breaking when your code is
minified. You can supply a list of the dependencies as strings, and minified
code will work fine:

    
    
        angular.module("whatever").controller("YourController",
        ["dep1", "dep2", function (dep1, dep2) {
            whatever...
        }]);
    

Even though the `dep1` and `dep2` params get minified, angular will still pass
in the correct dependencies.

~~~
AdrianRossouw
that's exactly my point

why have the magical version if all it does is break, and there's a perfectly
valid way to do it that is really not THAT much more complex.

The magic version is the first thing they teach you, and then you have to read
the fine print to see you shouldn't be using it.

Why just not have it in the first place?

~~~
leddt
For what it's worth, I use ng-min which will automatically generate the safe
syntax when minifying. I like it very much because writing the safe syntax
does not feel "dry" enough to me.

~~~
AdrianRossouw
I know about ng-min, and that's part of what I'm writing the next article
about.

But you've now got a situation where it justifies the creation of all this
contrib level code that is just not needed if you don't do it the magic way in
the first place.

You just wouldn't need ng-min or grunt-ngmin or on some level generator-
angular to set it up for you.

When you take into account all of the code, documentation, github issues,
stackoverflow questions etc. this results in, there's no way that this clever
hack can be worth it.

~~~
Cthulhu_
> there's no way that this clever hack can be worth it.

Well I may not be overthinking it too much, but, Angular's DI is the cleanest
way to do DI in Javascript I've seen so far, at least until modules and ES 6
finally become standardized. ng-min solves the duplication one gets from the
'array' notation, as well as that from my previous project which used
RequireJS.

Doing fulltime Javascript development, I found Angular's DI to be a relief.
And yeah, it is a hack, but because Javascript (and all web standards, for
that matter) develop so slowly that a standardized, non-hack solution just
won't happen in the next couple years.

Compare ng-min with polyfills that add support for ES 5 or 6 features to JS
projects targeted at older platforms that don't support it yet. Hell, compare
it to Coffeescript, which transpliles JS-but-a-bit-nicer to JS.

------
hellbanTHIS
I love it but it's sometimes not as smart as it thinks it is. For instance
they removed ng-bind-html-unsafe (because "safety"! Thanks Ralph Nader!) and
now you have to jump through all kinds hoops to add a simple ng-click to a
dynamically generated element.

That's something that can be done in 30 seconds with jQuery but my
determination in making it work the 'Angular Way' has turned it into a 48 hour
Donald Duck cartoon.

------
scotty79
Angular seems not to have much of actual models (not view models), it's all
about the view components and syncing them with their view models. Backbone
doesn't have much support for the views, it's all about models and collections
and syncing them to the server.

Yet people don't seem to be too eager to use both together. Why do you think
that is?

~~~
jaxytee
Because their cores solve the same problems, and it would be overkill to pull
in both projects for views or models. Also, I don't think backbone.js models
solve any problems in an Angular application.

~~~
scotty79
Could you point me to some tutorial how to implement client side business
models in Angular autosynced to the server, backbone style?

From what I've seen on Angular people are really hyped about extending html
and two way binding but when it comes to communication with the server they
just wrap arbitrary ajax call done via $http or $resource in Angular service
or factory or provider and call it a day. After seeing what backbone does,
this seems to me to be as reckless as manipulating the DOM using jQuery.

------
bdg
I find the architecture of ng fits a vast number of projects I work on very
elegantly, however, I feel like I am learning to walk all over again.Things I
could do in a day take me a week to learn, but I feel like my learning is
progressing fast enough that I will be skilled at its use in a week.

------
otikik
Am I the only one who can't stand Angular simply because of its naming?

