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.