[wwweston]

> The difference is Rails can handle both the front-end and backend of a typical web application, whereas Angular is just the front-end.

Think about these questions: is Rails really "behind" everything involved in a typical web application request/response cycle? Or is there something else behind it? In what situations is Rails not a client? For the situations where it isn't... how common is that setup, and which situations could Angular not cover?

(There's a few, but I suspect they're vanishingly rare.)

You may not have been doing this long enough to remember, but there was a time when "front-end" meant something different than it does now, reasonably so, and there's still some circles where people use it to invoke the layer of an application that generates HTML in back of an HTTP server because of what it's in front of.

> Equating Rails data store backend to Angular's service backend is a poor analogy.

In both cases, you have a given runtime opening up a socket connection through which some protocol exchange negotiates a request-response sequence to a server which provides some representation of application data. What, specifically, is the "poor analogy"?

Sure, everybody understands that the runtime in question is different and execution takes place in different environments. And like I said in my earlier comment, you can make distinctions between types of data stores (though given how common JSON responses are these days, most database developers seem to be working really hard to minimize those distinctions). You can make (some) distinctions between the demands of a multi-request environment and a browser's (likely) single user environment. It doesn't change the fact that there's a reasonable level of consideration at which Angular and Rails are doing the same thing: mapping view actions to controllers, running control code to update/retrieve model state including hitting data sources over the network, and updating the view. An analog doesn't have to be perfectly isomorphic in order to be useful or true.

Now if you really want enlightenment, ask yourself what problems the application of those patterns is meant to solve, and how effective Rails and Angular are at solving them. Also, what parts of the system are "in front" of the browser?

Or don't, I guess, and insist that labels like front-end and back-end represent disparate iron clad categories of platonic computing ideals with an insuperable gulf betwixt.

[dasil003]

You're touching on my main beef which is that a service that you run for others on your servers requires a massively different mindset from a client-side app that you distribute to run on others' hardware. Do they use a common flow control pattern? Sure, but the performance and security requirements mean you have to think about them completely differently. I'd consider an iOS app is more akin to an Angular app than a Rails app is.

Does that mean I'm trying to put a stake in the ground on the canonical definitions of front-end vs backend? Hell no, it's totally relative, I'm only commenting within the context of Angular vs Rails so don't read too much into it.