Why I was Wrong to be Afraid of Angular.js, Part 2 | Hacker News Reader

Why I was Wrong to be Afraid of Angular.js, Part 2

daemon.co.za

45 pointslerouxb53 comments

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.

Performance is a big one for many. There are also some patterns that developers using jQuery tend to adopt that has performance ramifications, such as use of global DOM selectors like $('.foo').

> Performance is a big one for many.

Given how poor Angularjs performs that's not really the point of Angular.

> such as use of global DOM selectors like $('.foo').

Which is perfectly valid especially when doing event delegation.

The point of Angular is not to replace jQuery,the point of Angular is to have a clean way to integrate DOM manipulation into pages that have a complex application logic. Something devs should do with or without AngularJS,just that Angular forces (some) S.O.C.*

But one still does DOM manipulation in directives. with jQLite BUNDLED with Angular. AngularJS is no magics ,AngularJS has its own limited jQuery. Makes sense because the unique point of jQuery is DOM manipulation,not building applications with complex logic.

So people saying "I replaced this fairly large jQuery app with AngularJS" are lying, You cant write a "fairly large app" just with jQuery,You need to roll your own framework on top of it, at least.

* : My advice to anyone jumping in the next framework bandwagon is never couple your application logic to any framework. But that's what we see with AngularJS, everything in controllers or services tied to AngularJS apis... so much for separation of concerns...

> But that's what we see with AngularJS, everything in controllers or services tied to AngularJS apis... so much for separation of concerns...

The web is a complex beast. Front ends doubly so. The idea here is to keep your web based interactions as thin as possible and keep all of the logic in the business logic models. Combine with dumb templates and you have stuff that will scale out or up fine, given the availability of appropriate processing power on the client end.

Not sure about what you mean about how poor Angular performs - Angular performs pretty well, unless you're naively doing inefficient things.

I've written some medium sized Angular apps that are pretty performant.

> unless you're naively doing inefficient things

This counts for anything including your original jquery example.

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

I think that there are always arguments made like this with any language/framework and the endgame comes down to where there is a use case there is a will.

I recently participated in do a full webapp conversion from jquery to angular. One driver was a realization that jquery and related tools filled quite a bit of bulk in the platform(cutting them out the minified js ended up being 1/5th the original size).

Another was a conscious decision to rebuild API first and angular provided a unique ability to very cleanly abstract a View/Service/Server type of architecture that has just never worked for us in Jquery.

Plenty of people will continue to use JQuery just as plenty of people continue to develop in Perl despite other communities feelings that it does't fit their use case.

Hold on. I'm not talking in a "Angular vs jQuery" way. I meant "Angular vs something like Backbone that just happens to use jQuery".

I wouldn't build a large app straight on top of jQuery ;)

See how quickly careless words can brand you as a sadistic maniac :) !!

But seriously not to answer a question with a question, though I am going to... but maybe the better question is "why do frameworks like Backbone need to use jQuery?"

Base angular is incredibly compact and I have yet to really run into a wall with it compared to projects we have tried to do in Backbone (that sounds like we have had problems in backbone we haven't I am just saying the experience is comparable). It seems to me like the best reason to keep jQuery in something like Backbone is to make it easier to integrate existing jQuery libraries... which is maybe worth reconsidering anyway.... see argument #1

Not sure about Backbone specifically, but jQuery is good for a lot more than DOM manipulation. It hides a lot of the differences in browser Javascript APIs, and provides a lot of convenient AJAX tools. For instance, server communication is as simple as a $.getJSON away.

so http requests are also similarly directly handled in Angular without the need for jquery.

But his point stands: jQuery is useful beyond DOM manipulation as a library. In one of my current side projects, all of the DOM is managed through React, but I'm still using (and loving!) jQuery for all the $.ajax stuff.

To be fair your statement is more inline with my first point, for as much as someone shows how clean Angular http services are there will always be someone who like the simplicity or paradigm of the more seasoned pillar platforms

we're kind of shackled to jquery, and it's really difficult to NOT use it.

I think that the angular way is just cleaner, and less likely to break because it is pretty sensibly encapsulated.

I suspect these libraries developed for angular, is a break from the past that the web is going to need eventually.

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...

I hear you and I don't disagree with you. I just freak out when I open a console and $ doesn't exist :)

Firebug has a $ built in just for debugging.

> 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.

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

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.

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. :)

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.

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).

I felt the same way the latest SPA projects I did jquery didn't even need to be included.

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).

> bitch of a learning curve though

The problem is that you have to change your mindset from server rendered pages + jQuery. Second problem is with UI directives. Nice abstraction and encapsulation, but try to restyle something easily.

I've been having some success by handing my look and feel over to a css specialist whith instructions along the lines of "make my prototyping less of a hack". So far she hasn't had to be aware of any code related issues.

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.

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

This is part 2 of this discussion : https://news.ycombinator.com/item?id=7384937

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.

Shouldn't that just be the only and correct way, then? No need for .toString() magic..

Sure, that makes sense to me.

Looks like I misunderstood the author's intent. This should be the only way, though.

Also, I didn't even realize that this way doesn't require .toString magic.

Actually I'm not 100% sure it that it doesn't require toString magic at all, but it would at least require less and probably be more reliable.

Agreed. And at least it's more clear that dependencies are being injected.

Then again, reading about Angular's DI for a few minutes should lock this convention into your mind pretty quickly, I think.

An array of strings where the last entry is a function that takes arguments named after the strings of the array it's defined in... sounds rather hacky and confusing to me, not to mention it duplicates strings. Easy to make a typo, easy to change the order of arguments - and no compiler or any kind of sensible IDE or tool to warn you about it.

toString is only used to parse the function signature to get the list of dependencies. If you use the other syntax it doesn't have to do the "magic" at all. I haven't looked at the output (though the magic function itself is pretty simple) but I would imagine it just creates the explicit version that you can choose to write manually.

I'm a little torn myself; on the one hand, I prefer explicit code without magic. Having said that, you often need quite a few dependencies and it's a pain, and ugly, to write them all out twice on all your signatures.

it doesn't need the toString this way, because it's already a string being passed in.

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?

Gotcha. Your point is that this way (that doesn't break when minified) should be the only way to do it, right?

I'll agree with that.

Initially, I thought your point was the dependency injection as a concept needs to go away in Angular.

god no. the dependency injection is fine.

i just think that the unsafe way shouldn't even exist, much less be the first and most prominently featured in the documentation. It even has fine print, which everybody has to add in everywhere whenever they talk about it.

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.

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.

I have to say I disagree. It is worth it for sure.

The reflection "hack" allows a very clean and fast way to program js apps without needing to bootstrap them with a whole bunch of wiring code you get in things like backbone (also love in any case).

The choices you're left with:

- write clean easy to read code with a few conventions and use an ng-min call in gulp / grunt or w/e, if you're accustomed to live reload and watch this won't hurt at all.

- write in the annotations yourself and deal with it

- use something else and put up with having to write all the extra code

I've left out the other option, don't minify your code because I think thats a bit of a moot point.

> 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.

ng-min won't catch some cases, like resolvers or some cases of inline controllers, which were not fun to debug.

Because writing controllers, services, directives, etc. with various dependencies is something you do all the time, and the DI reflection lets you do so in a quicker, friendlier, and non-duplicated way, whereas setting up the ng-min step is something you only have to do once, then you can forget about it.

You already need to set up a build pipeline to get your minification, concatenation, etc. in the first place. It's hardly a terrible burden to have to stick an ng-min step in there as well. It seems like you're trying to justify an instinctive distaste for this feature by exaggerating how problematic it is, when in reality it isn't problematic at all.

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.

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?

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.

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.

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.

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

Reply on news.ycombinator.com