[wwweston]

Both Angular and Rails talk to "a backend." In Angular's case it's (probably) an HTTP server handing over JSON representation of data. In Rails' case it might well be exactly the same thing, or it might well be a NoSQL database handing over JSON representations of data, or it might be an SQL database.

You can certainly make distinctions between those data stores, but they have enough in common it's perfectly reasonable to say they're doing many of the same things.

Now, Angular is considerably more horrible than Rails and tries to solve some additional front end problems badly, and its use is a likely indicator that the organization or individual that have decided to employ it aren't capable of making wise technical decisions, so I'd say it's also reasonable to make distinctions between the two on a number of levels. But there's considerable overlap in the kinds of problems they attempt to solve.

[dasil003]

The difference is Rails can handle both the front-end and backend of a typical web application, whereas Angular is just the front-end. Equating Rails data store backend to Angular's service backend is a poor analogy. The concepts and principles behind web browser client code, server-side application code, and data stores are 3 completely different engineering paradigms.

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

[rjreed]

Rails can't handle front end, the Ruby applications aren't running client-side right?

[richardknop]

People used to write websites and web apps long before Angular and single page apps came about. I remember a big part of the beginning of my career it was perfectly standard to render HTML server side. All the templating would be done server side and you'd serve dynamic HTML to browser. With usually some small JavaScripts in HTML for client side.

Even today not everybody uses SPAs. Lots of big old school websites generated dynamically on server. Many Django and Rails projects built that way. Also lots of legacy Java stuff and PHP websites (all Wordpress and Drupal sites out there for example, and there are millions).

[dasil003]

LOL, where to start? 1) There is such a thing as a web app which doesn't run Javascript. 2) Rails can generate and serve JS. 3) Rails was the first web framework with AJAX integration back in 2004 via PrototypeJS, this is the library that kicked off the entire movement that gave us the modern JS world we have today.

[empath75]

It's been year since I've messed with rails, but it generates js code, doesn't it?

[bauerd]

A Rails app is literally one or more Ruby processes whose task is to respond to HTTP requests/WebSocket connections. Yes, these processes will probably make use of other services (e.g. a database server).

An Angular app is a JavaScript file that runs in a client's JS environment.

I don't see how there's considerable overlap here?