Anonymous Open Letter to the Ember.js Core Team • Hacker News Board

Re: Anonymous Open Letter to the Ember.js Core Team

#41

Post by 1qaz2wsx3edc » Sat, Apr 13, 2013, 9:00 PM UTC

fudged71 wrote: post #33

1qaz2wsx3edc wrote: post #19

Earlier quoted context omitted.

Yes, browsers have this feature where you can hover a link and it reveals the href.

It's easy to use snark to dismiss someone's problem. Why show the domain at all if you can hover over the links? For a minimalistic interface like HN you'd think there would be a reason for it. And if people are identifying content based on that URL, it's probably best to make it descriptive when subdomains have very different content. Plus, many touchscreen devices don't have an easy way to see where a link is point…

Because that's not what this discussion/thread is about.

Re: Anonymous Open Letter to the Ember.js Core Team

#42

Post by hackerboos » Sat, Apr 13, 2013, 9:31 PM UTC

swampthing wrote: post #34

Not to sidetrack the conversation, but why is Backbone "a joke"? It seems a bit different in approach from Ember, but I've used it for a pretty big application and it worked great.

More importantly; why is Angular dismissed so easily?

Re: Anonymous Open Letter to the Ember.js Core Team

#43

Post by defen » Sat, Apr 13, 2013, 9:57 PM UTC

benatkin wrote: post #27

ctvo wrote: post #9

Why is there drama for such a small community? Angular doesn't seem to suffer from these constant HN threads.

It shows that Ember.js is a community-driven project. Angular.js OTOH is run by Google, and like everything done by Google is part of their strategy to collect data and increase advertising revenue.

This is not even wrong...it's just an absurd statement. Using angular makes it no easier or more difficult for Google "to collect data and increase advertising revenue" compared to any other JS framework.

Re: Anonymous Open Letter to the Ember.js Core Team

#44

Post by skore » Sat, Apr 13, 2013, 11:02 PM UTC

juanbyrge wrote: post #38

Terretta wrote: post #28

Earlier quoted context omitted.

On the contrary, he's unhappy that contributions (PRs) are ignored.

Pull requests can take more time to process than feature requests, because 1) The code is usually inconsistent with the rest of the project, 2) there are often merge conflicts that the submitter has to resolve 3) people rarely write tests or documentation about the feature.

You make good points, but each of these is solvable:

1) Require the code to be consistent. Tell the submitter how to do this.

2) Merges have to be straight forward, or you don't accept the submission. I think Linus Torvalds has the same strategy for the kernel - you figure out the merge, I'll accept it.

3) That depends a lot on how you set up your tests and documentation. If you make it simple to write both, it's simple to require them. If they're not simple, you should make them.