Hacker News Reader

A lot of contributors could also mean that Angular was buggy or lacking features from the start, and that people had to contribute to fix it themselves. It could also mean that the code was easy enough to understand so that more people could contribute.

I don't think you can reasonably say that there's "the only metric that really counts". All these metrics are indicators of activity anyway, not quality.

I can only quote myself to clarify, here:

> They get community right and at the end of the day, that's the only thing that really counts.

I disagree. The only metric that counts is how productive you are with it. We use something else because it just fits our mindset better.

Sure, but peopke often fall into the trap of only considering short term productivity. Choosing something that won't be maintained in a few years will be a big lose in productivity.

If popularity is the only metric that counts, then logically you should also dismiss anything other than PHP, MySQL, and Apache for the server side out of hand.

I could live with that. That said, they are obviously not the best for every application but swapping out MySQL for the next up contender (Postgres) and Apache with Nginx and PHP with Ruby or python would not change the picture dramatically. Switching to Java+Tomcat or a javascript framework on the serverside would change the picture in a dramatic way.

Popularity is not the most useful measure but it is a useful metric to determine the viability of a framework and it also gives an idea about how open a team is to outside contributions which is a huge factor in eventual success. (See: Linux vs Minix).

I'm not a fan of Javascript either on the clientside or on the serverside but I agree with the GGP that they seem to get community right and even if every other decision they make is wrong in the long turn that may make them the equivalent of PHP in their domain.

Every Angular documentation page has a link to edit the doc right in github.

The same is true for React but not for Amber nor jQ.

However React's docs are much simpler than Angular since it only provides the View and the docs are only a few pages really.

Interesting.

But I see the comparisons is between Apples and Oranges here.

jQuery is a DOM library.

Angular and Ember are client-side MVC libraries.

React is an [isomorphic] UI library.

IMHO Angular/Ember and React and jQuery don't even compare in the same planes.

I'm not supporting React here, but its quite new and off late its getting a lot of traction. So the number of contributors and commits for a library that's quite new is astonishing!

And frankly I feel Angular team made a huge mistake by completely changing the syntax which makes it difficult to be adopted by anyone that knows/uses Angular 1.x.

You say "everybody trying to make this into a tech fight", but the truth is that you are the one opposing communities based on important but not essential metrics.

Some like Angular, some like React, some like Ember. Companies are successful with all 3 of these frameworks. And that's what counts. What's important is whether the tools help us get things done. And all 3 frameworks do exactly that, in different ways.

You can try to say "I win", but you only win if your product works better than your competitors, not if you have a "better" framework.

The only thing that matters wrt software libraries is if it helps deliver and maintain software more efficiently and with less frustration than others. There are three dimensions to this, how great is the library today (with regards to efficiency of construction and maintainability of software), how much better (or worse) will it get in the future, and how long will it be around. Unfortunately these things are hard to measure and predict.

The number of committers only gives you some insight to any three of these things, and can actually mislead you. The Javascript ecosystem is ridiculously fast moving (which is a nice way to put it :)) so number of committers doesn't tell me if all those folks will just jump onto the next thing that comes along. Also, the Javascript community has developers of a wide variety of skill levels, so the number of committers doesn't necessarily say much about the quality of the library without understanding who these committers are. I'd argue there is often a small number of key contributors to any open source project, with other folks contributing small patches to fix bugs or minor enhancements, so the total number of committers doesn't tell you a much more important thing: who are the key contributors, what is their background and views on software engineering, and how likely are they to remain committed to the project over the long term?

It seems to me the main thing Angular has going for it is that Google has bought in to it, so that means no matter how flawed it is (or not), it's not going anywhere anytime soon so you can be sure security fixes and bugs will continue be addressed over the long term. Then again, Facebook seems all-in on React (and I'm not sure about Ember) so maybe this isn't much of a differentiator.

React is just newer. Give it some time.

Indeed. If number of contributors is the only metric that counts then, since React has more contributors than jQuery, I guess that means we shouldn't bet on jQuery. Nobody's gonna be using that fly-by-night project in a year!

That's why I wrote "for reference". jQuery, of course, is a different kind of library.

A proper argument would be: jQuery has about three times the contributors that mootools has. If I had to decide between mootools and jQuery, I'd pick the second because of that metric alone, yes. (And this is how the market ended up playing out.)

Angular (born Jan 2010) has 2.5 times the number of contributors of ember (born Apr 2011), 5 times of React (born May 2013). I'm not just trying to find a reason to dismiss React and I do realize that it is still young. From a business standpoint, though, the choice couldn't possibly be any clearer.

I do agree that React has gathered a sizable crowd in a short time and it's definitely on my list of projects that I keep an eye on. But it's simply too young to warrant the same kind of investment that I have personally made into Angular.

> But it's simply too young to warrant the same kind of investment that I have personally made into Angular.

Sure .. it makes sense. Though one of the main selling points of React is that it's dead easy.

Pro-tip: Instead of pointing to forks and contributors, and complicated metrics, you'd do better advocating for Angular on this site if you instead point to benefits of the technology itself.

We are big boys and girls here we can take the technical details. No need to use all these external proxies.

Those that can't evaluate the technology for what it is have to find other proxies. Number of forks. Number of meetups per year. Blog posts. What color shoes does the creators wars. Etc.

I think once proponets start to point to all these other things and not to nherent benefits or advantages of the technologies, they have already lost me.

Interesting view point, but number of contributors is just proxy for the real metric, which is number of users. You can have a relatively closed group of developers make something that a lot of people use.

Isn't this misguided? A better metric would be to look at the project age as well.

Actually I think there are a few metrics that may be interesting. And different teams and organisations may put different weight to each metric. Have you seen Sarah Mei's talk about metrics and choosing a technology? She talks about Ruby but it seems to work the same for any technology choice. https://www.youtube.com/watch?v=dE4toi7y1MM

What if all 1,044 contributors were non-technical 4 year olds? My point is that you clearly don't mean this literally.

The number of contributors is an indicator of the terminal goal. It's not the terminal goal itself. It's very important to remember that.

You made a good point about the community.

I totally agree on the community point. I was thinking just yesterday how it's strange that when I think of Angular, a single person doesn't come to mind. This is probably a good thing, along the lines of the new way in which protests are developing in a decentralized way, like in Hong Kong. Maybe the model of the BDFL is finally getting superseded by the crowdsourced platform, with all the warts of that latter process. The problem with the BDFL is that there's a lot of trust necessary in the person in charge.

Except Igor Minar is pretty much that guy.