Live data from Hacker News

AngularJS versus Ember

eviltrout.com

151–160 of 163 posts

Re: AngularJS versus Ember

#151
post #57

Earlier quoted context omitted.

Let me say to start that I'm no JavaScript expert. I don't write JavaScript full-time (we're a small company; I don't do anything "full"-time), though I do like the language and what it can do for web-based client-side programming. I've written non-trivial apps for the same backend, first in Ember, then in Angular. The Ember app is the consumer-driven frontend, while Angular runs the administrative interface. It wasn…

> However, the discussion forums are horrible. They're using Discourse, which was written in Ember, and it's nearly impossible to find answers to anything previously posted. Because it's in Ember it's all JavaScript, so nothing is indexed on Google, and the built-in search is awful. Not true. All Discourse content has been indexed by Google since day one. Even though it's a Javascript app it's search engine friendly.…

How do you ensure that Google is able to index it? Do you sniff the user-agent and serve it a pre-rendered view of the discussion thread?

Re: AngularJS versus Ember

#152
post #119
post #97

Earlier quoted context omitted.

I use Knockout, too, and it has served me well. All the computed methods and model change detection are trivial in Knockout.

Knockout is only about data binding as far as I know, whereas Angular and Ember are full stack SPA frameworks. Also, while I'm a knockout fan, dealing with observables is not ideal when compared with plain old javascript objects that Angular allows you to bind with.

I agree, Angular has the right implementation. It's just not clear that it needs quite so much stuff to solve one problem. And if it isn't solving one problem, why not?

Re: AngularJS versus Ember

#153
post #32

I haven't much experience of either framework, but seriously, they're both way too complicated for what they do. Knockout is about the right level of complexity for the problem space, but Angular has the right engineering. But what does it need an IoC implementation for? I'm happy to accept the problem is hard, but I doubt it's so complex it's impossible to decompose.

If you don't have much experience, how do you know they're too complicated?

You're right, I'm shooting my mouth off here, but this is the whole problem with these huge frameworks: they're so huge that, by the time you've spent the time to evaluate them properly, your objectivity is likely to be compromised. You'll never see an even handed comparison between the two.

This isn't unique to js frameworks. There's plenty of systems like this e.g. Hibernate. At least backbone was small enough that I could seriously evaluate it in a month long project. (For the record, I didn't like it, but at least I actually can have a considered opinion on it without being well past the point of no return.)

Re: AngularJS versus Ember

#154

Earlier quoted context omitted.

> However, the discussion forums are horrible. They're using Discourse, which was written in Ember, and it's nearly impossible to find answers to anything previously posted. Because it's in Ember it's all JavaScript, so nothing is indexed on Google, and the built-in search is awful. Not true. All Discourse content has been indexed by Google since day one. Even though it's a Javascript app it's search engine friendly.…

How do you ensure that Google is able to index it? Do you sniff the user-agent and serve it a pre-rendered view of the discussion thread?

See https://news.ycombinator.com/item?id=5198934

> Our site is indexable by Google and it doesn't do much fancy. On certain URLs, we generate a small HTML view of the content in the tag. You can see this by viewing source or disabling JS in your browser. It's just a simple ERB template in Rails, and uses the same object graph that we serialize via Active Model Serializers.

> Google can see it and index it, we've confirmed by searching post launch.

> As time goes on we'll probably work more on it to make the SEO even better. As you can imagine it was tough to do when we were in stealth mode ;)

Maybe we could get an update from eviltrout on that.

Re: AngularJS versus Ember

#155
post #152
post #119

Earlier quoted context omitted.

Knockout is only about data binding as far as I know, whereas Angular and Ember are full stack SPA frameworks. Also, while I'm a knockout fan, dealing with observables is not ideal when compared with plain old javascript objects that Angular allows you to bind with.

I agree, Angular has the right implementation. It's just not clear that it needs quite so much stuff to solve one problem. And if it isn't solving one problem, why not?

Angular team is going to split the Core into several small modules, hopefully a data-binding module will be available to replace knockout and do nothing more ;)

Re: AngularJS versus Ember

#156
post #134

Earlier quoted context omitted.

I'm mostly talking about sharing data in this post. If you have a user object from the server, why would you need to retrieve it again as you navigate around? It's already been given to you from the server. Secondly, client and server interfaces are not as symmetric as you indicate. Discourse has much more validation logic on the server than the client. We generally "assume success", because the vast majority of requ…

If you have a user object from the server, why would you need to retrieve it again as you navigate around? It's already been given to you from the server. I will never forget my first interactions with a team who took this line of argument seriously. They were an outsourced team who had been given a spec for a website. They said they were on track. Our product team went down to talk to them. The most memorable quote…

This is exactly the kind of reason frameworks were created; breaking the back button totally sucks. By handling this process for you, the framework can make it much easier to have the behavior you'd expect.

Re: AngularJS versus Ember

#157
post #117
post #90

Earlier quoted context omitted.

This is an important point, but I see it differently. Want to become a truly great developer? A real one-percenter? Get in the habit of diving into other people's big, scary codebases when you hit a bug. Learn how things work, learn why they're breaking, and fix it. Who has time for that? That's part of my point. Many people won't invest in their own capabilities in this way. But once you do, you get dramatically fas…

I've been referring to the Django source nearly as much as the docs lately, and it's actually very pleasant to "unmask the magician", as it were.

As someone with commit to Rails, it also makes you have a totally different perspective on 'magic.' You end up seeing how things work, and it no longer feels magical. It's just code.

Rejecting 'magic' and just reading the code definitely helped me to get to another level of coding.

Re: AngularJS versus Ember

#158
post #93

Earlier quoted context omitted.

What problems did you encounter with dirty checking?

The way AngularJS works is that it allows you to use plain ol' JS objects all over the code and allows you to implicitly/explicitly set-up "watches" on these JS objects. Whenever the value of the object changes, your app is given a chance to react to it. When you use these objects in your view, the "reaction" is implicit, i.e. the view gets automagically updated. However, the process of checking whether JS objects ha…

Thank you for this explanation. I didn't quite 100% grok how it worked, and had heard there was some kind of limitation around it, but didn't know the details. This was very clear.

Re: AngularJS versus Ember

#159
post #150
post #101

Earlier quoted context omitted.

Nested views aren't in Angular. Also Angular doesn't really have models. It has data and dirty checking, but nothing a Rails dev would recognize as a model.

can agree with the fact that angular models are really left up to you, but stating that angular can't do "nested views" just shows your ignorance

You can make a much more powerful argument by showing how nested views work in angular, rather than by making strong statements with nothing to back them up.

If nested views are in the basic Angular docs, it's even more strong. Don't just say someone is ignorant, show them how to not be ignorant any longer. It helps them, and makes you seem like less of a jerk.

Re: AngularJS versus Ember

#160
post #134

Earlier quoted context omitted.

If you have a user object from the server, why would you need to retrieve it again as you navigate around? It's already been given to you from the server. I will never forget my first interactions with a team who took this line of argument seriously. They were an outsourced team who had been given a spec for a website. They said they were on track. Our product team went down to talk to them. The most memorable quote…

This is exactly the kind of reason frameworks were created; breaking the back button totally sucks. By handling this process for you, the framework can make it much easier to have the behavior you'd expect.

By having a framework "handle this" you teach novice devs that they don't have to think about it and then they do stuff the framework can't fix and wonder why the framework is broken!
Post reply on HN