My question is then: why are people purposely choosing not to use the advantages of client side MVC code? All of a sudden we have access to all these awesome features of long lived applications and people are choosing patterns that don't embrace it.

> That said, I use computed properties in a couple places with Angular, and watches have performed perfectly fine for my use

I do say in the end that there are viable workarounds. It's an issue of maintainability and consistency. Ember embraces patterns for ambitious applications.

If it works for you I'm glad, I just think we should open ourselves up more to the advantages of rich client side apps and not hold back!

You can't trust the client. Therefore a good part of the logic MUST be built on the server side. When you've had to build that logic once, building it again on the client side is a maintainability problem of exactly the same kind that you decry with Angular.js. Except worse, because frequently the client and server are different languages and so are harder to keep in sync.

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 requests do go through correctly. So if you submit a spam post for example, we'll show it in the client side view right away, but once the server asynchronously replies a failure, we'll display an error message and remove it. This can be jarring in the case of a failure as you'll see something appear then go away, but the vast majority of the time it doesn't happen.

The client side interface should do what it does best - display stuff quickly and avoid server round trips as much as possible.

So, the app functions on its own in the client, and only checks-in periodically with the server to see if anything is not valid?

(As opposed to sending a request to the server for every change.)

So for example: when I submit a comment, it doesn't go to the server right away. It immediately displays successfully in my browser, and could be submitted to the server 2 seconds from now, or something?

Ajax by definition is asynchronous. When you submit a post, the Ajax request is fired right away. But we don't wait for a response before showing the post in the stream (success case). We show it right away.

Then WHEN we receive a reply, we check the error status and if it was success, do nothing. If it failed, we revert the UI to the previous state. This is really easy with a client side MVC framework.

The downside is the failure case can be disorienting, as something will appear and then disappear. But the vast majority of requests, say, 99% never fail so the user so we optimize for that case.

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 was their lead developer saying, "We will just have to train our users to not hit the back button." Almost as bad was, "We have no idea how to support IE." (Over half of our business was IE, and many of our users were casual browsers.)

There is a legitimate debate between rich client-side applications and keeping work on the server-side. Anyone who tells you - either way - that one approach is obviously the right thing to do simply lacks full perspective.

But personally I've been burned enough by people who want to create complex client-side interactions with serious UI mistakes that I have a certain reflexive caution about arguments for pushing everything to the client.

YMMV (and apparently does).

> My question is then: why are people purposely choosing not to use the advantages of client side MVC code?

I didn't understand this question (it seemed too obvious to me and felt like a bait to get into a broader discussion). In both Ember and Angular apps you still have a 'model' that is stored outside of the DOM, the only difference is how the model is works, which seems orthogonal to 'advantages of client-side MVC.'

I wonder, though this is speculation, if this question and post are some kind of elaborate troll. EvilTrout hails from Forumwarz, which is a game that may use these techniques every day:

Forumwarz is a parody role-playing game that takes place on the Internet. In fact, Forumwarz is the Internet...in game form.

Magical dragon-faeries? Flaxen-hair'd elflords? Dank scary dungeons, reminiscent of Grandpa's basement? Kids' stuff. In Forumwarz, you can pwn trolls in ridiculous web forums...buy hacked warez from shady Russian websites...or upgrade your skills with breast implants, malt liquor and antidepressants.

To spell out the question in a different way:

I have an object that represents some kind of object, like a User, for example. On every page, I display the user's name.

With the 'long lived object' strategy, I fetch the User on the first page load, and display it. The JS object then sticks around, and as I navigate, the same User object in memory is used on each 'page' to put in the username. No difference.

With the 'mostly server side' strategy, I fetch the User on the first page load and display it. When I navigate around, I then re-fetch the User on every single 'page'.

I am not familiar enough with the details of Angular (and, frankly, Ember, which I'm still new to) to tell you if this maps 1-1 with the way that they work, but it's the two different approaches in a general sense.

FYI according to Stack Overflow, Steve is in his late 20s and has been a professional developer for several years. I'm in my mid-40s and have been a developer since the last millennium. Both of us have been on this site longer than you, and have much higher reputation here. Neither of us are kids. Assume that we can understand your actual substantive points, make them, and move on.

(I will look into exactly what Services are, thank you.)

http://www.youtube.com/watch?v=W13qDdJDHp8&feature=c4-overvi...

For instance, scope will be optional in the future, not only that but the roadmap for Angular Next is very impressive (see around the 44:40 mark).

---

Angular is accelerating; it has more stars/watchers/staff than Ember. Embers' core devs barely have time for pull requests. To the best of my knowledge Ember has no full-time staffers. Angular is fully staffed by Google. Both take contribution from the community.

I suspect Angular's popularity has more to do with a logo than features.

- The unnecessary new module system is a massive waste of time and obviously doesn't play well with others

- It's the first MVC framework I've used that can't properly loop over an array or primitives (the partials for the primitives be displayed,but changes to them won't flow back to the parent as Angular can't make a $parent (IIRC) key.

Also: 'NG' just fucking doesn't stand for Angular.

http://en.wikipedia.org/wiki/AngularJS#Development_history

Promoting it as 'by Google' is misleading.

> Q: Why is this project called "AngularJS"? Why is the namespace called "ng"?

> A: Because HTML has Angular brackets and "ng" sounds like "Angular".

http://docs.angularjs.org/misc/faq

sigh

The fact there's an FAQ question on an abbreviation should tell you something.

Thanks for the sigh though, and the substantive response to the points raised in the body of my post, it really adds a lot.

Having the server contain the "single true source" is important for many reasons, most of them being the main benefits of the web in the first place - automatic backups of everything, automatic sync of everything, etc. And if you're backing up everything to the server anyway (e.g. every action requires a REST call to the server), then the server is in any case acting as the source of truth, which means it can also do some business logic processing.

That's not to say the client is "dumb" by any means, but you'll be talking to the server anyway.

For example, I have an Ember application running on both mobile and desktop that gives the user complete read/write access to their data even when the network goes down. When they get a connection again, everything synchronizes automatically.

This is an important requirement for us, and once we implemented it we realized that is has very useful side benefits as well: the entire application feels dramatically faster, because you're very rarely waiting for the server. Changes take effect instantly.

It also makes our backend infrastructure simpler. First, because we can take it down for a bit and nobody will even notice. Second, because once you have a true distributed synchronization algorithm running, adding another redundant server is no more complicated than adding another client. They're actually quite symmetric in many respects, running the same codebase.

The only atomic source is probably your database, and from the millisecond that you query it, it could be stale.

It is not the same thing as the class of bug I am explaining where you have multiple copies of the same object in memory leading to confusing state errors.

There are some objects that you just don't need to refresh constantly. In ember there's nothing stopping you from calling refresh when you enter a route, it gives you the object and leaves it up to you. If you think it's important to refresh it as the route changes, by all means do so!

The point is that due to the difference in architecture between an SPA and a more traditional all-server-side app, there's no reason to hit the server every single time. Isn't this the advantage of writing so much JavaScript? If you're going to make a bunch of requests on every page, why not just ditch the JavaScript and write it all server side?

You're questioning the decision making behavior of developers. Developer stereotypically like to think in black and white and therefore as developers we assume that all developers follow one uniform pattern.

To answer your question - I don't know, but this is just like asking why people like chocolate ice cream over vanilla. Here's my theory - Angular.js is "by Google" and therefore has a larger community.

Have you written about them? I haven't come across anyone who has enough experience with more than one of them to comment broadly.

Backbone was tiring for me and my partner with all the files and code to set up each view. I also never liked putting templates in script tags -- it just felt dirty. We see Ember and Angular as similar (how do you pick which language you like?), and we only picked one for atheistic reasons (data-binding in HTML) in our current project. Since I haven't written the same app in each framework, it would be unfair to comment further.

   <div {{bindAttr class="highlighted:paid"}}>{{name}}</div>

What are you working on? I did a quick trawl of your history but didn't see any mention.

If you're like me, then you'd want to see some examples of craftsmanship to weigh the value of different opinions. Unfortunately, I can't provide links to these example works due to a very strict NDA (we did the work on behalf of a couple brand names, and ironically they wanted privacy). The projects definitely fell into the category of 'shit crud app' :)

(To the people downvoting my previous comment: wtf?! Politely questioning someone's stated experience when it borders on absurdity is perfectly valid. And the GP provided a perfectly reasonable explanation: s/10k+ apps/10k+ loc apps/.)

https://github.com/mgonto/restangular

I'd like to call it, "the appeal to the bold new future fallacy, with sensationalist titles"

<template>

Is X trying to change the paradigm ? No. Use Y.

Is Y trying to change the paradigm ? Yes. Use Y

</template>

Some dumb geeks just can't handle "worse is better" !

I am pretty sure you prefer Angular but are just too pussy to say it.

Maybe you think people will think less of you for preferring the framework that is less complex.

I assumed 'not even close' would mean this guy would be siding with AngularJS.

Its sad but many people have the mistaken belief that programming languages and frameworks that are harder to use are more sophisticated and therefore better.

What I think is that deep down people are afraid that others will think they weren't smart enough to figure out the more complex and difficult to use thing.

What I am sure of is that a system that is less complex and easier to use is better engineering.

I agree. I think this is what made the success of very popular libraries (such as Jquery), but also protocols like email and the web.

I've been trying very hard to use Ember on a couple small projects, and I found it very hard not to get frustrated by how difficult it is to execute some trivial tasks.

Part of the problem, I believe, is the way I learn. I usually read a quick tutorial, hack a little bit, read a bit more, hack more, read the full documentation, hack a real project (and getting into the wire of the API at this point). It's a bit oversimplified, but I believe you get the picture.

However, with Ember, it seems to me like it's hard to get started and running without having a full understanding of the full system and how everything fits together.

So yeah, in the end, maybe if you know every part of Ember and how it intrinsically work, then that's an awesome framework to work with. But for the others, like me, who learn in a more spiral-ish way, I think Ember makes it very hard to get shit done and appreciate the value of the framework.

And please, don't get me wrong, I admire programmers who can read the full documentation first.. A good analogy might be the manual (man) on Linux. I know people say RTFM all the time. But for me, it's really more about googling non-stop to get a feeling on the quickest solution for my problem.

I guess it's just a different way to learn and approaches solutions to problem. I know a couple excellent programmers who would just go reading the man and figure everything by themselves.

That being said, not sure why you're being so aggressive in your statements.. I feel you had very valid arguments but these are totally buried under this arrogance.

Funny, I felt the same way about AngularJS. I had been working for a few months with Ember. I was building a new internal tool and wanted to learn Angular but I found a lot of the concepts poorly explained in the documentation.

And I forgot that language like that simply was not accepted on this website unfortunately. However, I believe that the aggressiveness was warranted because there are quite a large number of organizations losing a lot of money on the basis of a poorly informed engineering decision.

Next time I will hopefully remember to be more political and use acceptable language when I feel so strongly about something.

Thank you for your honest comment.

I would ask that you consider, for a moment, that it is possible for someone to hold simultaneous opposing views. I also would ask for you to go back and re-read Brooks' essay about accidental and essential complexity. I believe that the choice of framework and the difficulties associated with a specific framework fall into the accidental complexity category. If after reading the essay you believe the same, then you would conclude that both choices in this thread have similar inherent merits. Such an opinion wouldn't be wishy-washy or a cop-out, but, perhaps, closer to a deeper understanding of our craft.

Every MVC framework I've used in production (Catalyst, ASP MVC, Cake, Spring, Rails, Rails with Spine, this batch of JavaScript frameworks) has had warts and frustrating moments just as all of the web languages have frustrations (Perl with maintainability, PHP with amateur hour inconsistencies, Python with tab/spaces that different IDEs will autocorrect, Rails with too much 'magic' that leads to serious bugs, Java with too much verbosity, Spring with too much XML, C# with too expensive support, Django with too many required add-on libraries, Rust with too few libraries, Go with too new, etc, etc).

Ember was not any harder than Angular to get going (ever try to untangle the service/factory/module/controller mess?). And I have no shame in admitting that I took at least three full workdays to learn each. At the end of the day the two frameworks were just different, in the same way that writing an app using JavaScript MVC is just different than how I used to write ASP MVC apps. The reason I use the newer stuff is because the newer stuff is more fun, I can be more responsive, and (in some cases) I can host an entire webapp on s3 (managing servers can be a headache). Despite some clear advantages, none of these different frameworks is inherently better. They all have tradeoffs. If Microsoft were to come to me and (with a large check) demand that I use ASP MVC, I would do so.

My first response reading your comment is that you have less experience than I do with software engineering. That may be untrue and unfair, but rash responses are correlated with inexperience from my career. I would ask you to consider your strong, aggressive reaction as unhealthy for merit-based engineering decisions. Learning and respecting that most decisions in software are about tradeoffs and not black-and-write-strictly-better-or-worse I believe will help you in your career. Furthermore, I hope you eventually come to point where you realize many of these different languages and frameworks all look the same after a while :) It's not until we can tell a computer what we what and it figures out how that our productivity will massively improve.