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.
(I will look into exactly what Services are, thank you.)
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.