Hacker News Reader

Comment by EvilTrout | Hacker News Reader

> In many (not all) Angular applications, the server is responsible for the model (think a Parse or other REST-style backend), and the Angular app is simply responsible for rendering it.

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!

View on HN

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

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.

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.

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.

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.

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!

Thank you for the excellent and succinct answer!

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

This is a pretty ridiculous conspiracy theory. (Is it a conspiracy if there's only one actor?)

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.

In Angular, there is a powerful concept called services. Services are used when you need to share data between controllers, like your example. Angular services are guaranteed to be singletons, but instead of passing references around, you use dependence injection instead. Ember is fun and kids like it, but grown ups appreciate the superior design in Angular.

Your 'kids vs grown ups' comment just makes me want to learn Angular that much less.

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

Your kids vs grown ups comment is ENTIRELY uncalled for. If you can't justify something based on the merits, then you have no business going for ad hominem attacks. If you can make your point without ad hominem attacks, then you should.

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.

The question was obvious to me. The advantage of client-side code is responsiveness. Everything is loaded, there is no need to go back to the server. Better yet, you can create UIs that couldn't be created otherwise. For instance consider gmail's keyboard interface. Just hitting keys you can navigate through email, delete some, label others, choose to reply to more. Without hitting a mouse. It is a wonderful UI, but only is possible with client-side code. Which is likely to be saner if you have a good client-side MVC model.

You could use NodeJS as your server-side platform and re-use a lot of the same logic bits...

I've worked with both frameworks. You're too quick to judge Angular. Secondly, I suggest you watch Angular 1.2 & beyond:

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.

Angular wasn't invented at Google (it was invented by Angular company, which got acqui-hired by Google) and some Google staffers have mentioned Angular breaks a few documented Google rules for creating Javascript MVC frameworks.

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.

According to angular's FAQ:

> 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

Yes, I (would have thought quite obviously, but perhaps not) know that.

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.

Angular went open source before it turned into 'official google'.

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

Yep. My issue is that it's 'by Google' according to the logo. As you mentioned, it was designed by GetAngular.

Promoting it as 'by Google' is misleading.

I don't think your view on this is correct.

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.

What we're really talking about here is an advanced form of caching. "Long lived objects" doesn't mean you do no validation, or that you don't hit the server to save something permanently.

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?

Any time you are showing a user a representation of data, be it in a web page or client side rendered template, it is potentially out of sync.

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!

That's not a valid assumption for truly ambitious web applications.

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.

why are people purposely choosing not to use the advantages of client side MVC code?

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.

Reply on news.ycombinator.com