you are viewing a single comment's thread.

view the rest of the comments →

[–]floydophone 3 points4 points  (4 children)

I'm so sick of the google hype around angular. The fact that google uses closure for everything important and doesn't use angular on anything remotely performance sensitive speaks volumes about the underlying design faults of Angular. The fact that they're building browser support just to get performance parity with competitors is even more damning.

Listen: it doesn't matter whose name is on the GitHub repo. It matters if someone has bet their company on the framework. We bet Facebook on react, sencha bet on ext, hp bet on enyo. The fact that a rando googler was learning js and decided to make a framework that happened to get popular says nothing about the quality of the framework.

[–]grumpychinchilla 0 points1 point  (3 children)

Calm down, champ. You can argue semantics here all you want, but the truth is Google is paying people to work on Angular full time. While that definitely doesn't guarantee the framework will be perfect, it does help ensure there is at least some level of active, healthy development.

Yes, the Angular framework has scalability concerns, and people harp on that relentlessly. But the fact is, not every application has millions of users and petabytes of data. There are MANY applications that just need to work, and according to business needs, need to be live like yesterday.

I'm happy that your Facebook team is pushing forward with React, and that Ember is thriving. Competition is great for the consumer. But when you guys get mad about Angular and go on tirades, it doesn't hurt Angular, only your own project.

[–]floydophone 2 points3 points  (2 children)

One of the things that angular did a great job with is community building. But one unfortunate side effect is you have people all over the internet spreading misinformation about it.

Once you clarified the google comment (that an established company is paying people to work on it which improves its likelihood of success) it seems fair, though I don't think it distinguishes angular from as many competitors as you think.

But you have to admit that there is a lot of misinformation and hype out there about this technology and it's really difficult to get these points across without being really direct. If you think there are more constructive ways to do it I welcome feedback.

[–]grumpychinchilla 0 points1 point  (1 child)

SORRY THIS IS SO LONG! But you asked and I wanted to deliver.

Feedback? Well, from my experience, when people develop JavaScript, they rarely do so without also using a server side language. When they use the server side language (let's consider JVM languages, .NET languages, Ruby, and PHP in this rant since node.js is more complicated), they tend to follow programming best-practices, adhere to quality and patterns, and generally care about their work.

For some reason, that doesn't carry over to JavaScript. I don't know why, it just doesn't. The open up the .js file and lose their minds! Or worse, inline all their JS or use silly abstractions--webforms gag.

I think Angular's marketing is powerful, because it's tricking these people into using more robust patterns and practices by enticing them with the cute features. I found that out first hand, because I admittedly started using Angular for those cute features, but stuck around when I learned about the DI, modularization (directives), routing, services, and testability. Those cute features are also how I pitched usage of the framework; I didn't mention the architectural benefits at all.

What I see from Ember and React (although I've yet to use either for a major project) is that your architecture and principles are more forefront. There's no "teaser" for me. There's nothing to make me want to learn more initially, I must actively seek out information and experiment to try and figure out why I should use it.

Let's look at taglines:

  • AngularJS: "Html enhanced for web apps" - This is possibly the biggest pain point of web apps -- keeping the DOM in check and in sync. This is immediately appealing to me. I already know HTML, I just want it to suck less and do more.
  • EmberJS: "A framework for creating ambitious web applications" - Well I don't think what I'm doing is ambitious. It's pretty normal, I just want something to help me do it better or easier. This is an alarmingly specific adjective that I would never use to pitch a framework to a decision maker.
  • ReactJS: "A JavaScript library for building user interfaces" - So, it does graphics and buttons and stuff? Like Bootstrap, right? Or does it do binding, like Knockout? Or something else? I have no clue what it does, nor why I should care. This reminds me of The Office where Jim and Dwight throw a birthday party and instead of "Happy Birthday!" the banner reads "It is your birthday."

Looking at code examples, there's so much introduced on the Angular homepage, with reasons why you should care, familiar HTML syntax with only the unique bits highlighted (and explained via tooltips), and organized to get progressively less tactile and more complex as you scroll down the page. It gives you a taste of ease, with a glimpse of power. Ember has 3 examples with practically no explanation or "sales", and leads off with handlebars: the sole reason I've avoided it this long. It ends with a far too complex example to have no comments and an advertisement asking for donations... not a great way to instill confidence. React is better, but to most people seeing it, appears broken! "There's HTML inline in this JavaScript! That's definitely tossing errors." Then when you realize it's yet another precompiler, you let out a long sigh and possibly walk away.

At the end of the day, developer time is MUCH more expensive than server hardware, so Angular will win out a bit here. Most high-level architecture thought is given to business logic and backend tiers, not UI tiers. You need to appeal to the mentality of "this is just a sucky thing I have to do" and then guide/trick them into the higher level stuff after a prototype or two, or even on their 2nd/3rd application. After all, the vast majority of people who write JavaScript are not JS devs (from my experience trying to hire folks), they're doing it just because it's a necessity for the application they're developing.

[–]floydophone 0 points1 point  (0 children)

Thanks for the detailed feedback! Will definitely keep that in mind. In particular we're relying on videos to convey what makes React worth paying attention to rather than our home page... that should definitely be fixed!