Hacker News Reader

Comment by EvilTrout | Hacker News Reader

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 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.

View on HN

What you're saying is interesting - I just want to make sure I'm understanding correctly.

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?

It's not as periodic as that.

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.

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 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).

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!

In Angular if you need to share global state between controllers you can just create a service that will fetch the object once and then cache it. I would like it if service/provider/factory were a more unified concept as they can be confusing when starting out. However, once you understand how to use them they are straight forward to use and provide a nice way to share code between controllers.

Reply on news.ycombinator.com