This is mostly orthogonal, but I'm yet another dev who loves using Ruby, but absolutely hates Rails. Ruby is a joy to use, whereas Rails is soul sucking, anti fun and overrated.
I haven't been paid to write a line of Ruby in over 4 years but I still use it for the occasional hobby project. Not only do I not use Rails for fun, I'd have to be close to starvation before I used it again for profit.
Now I feel the urge to dust off my copy of 'Eloquent Ruby' and write some fun code.
Similar here. I've used Ruby since 2005, but mostly for backend code, with a sprinkling of Sinatra for my web projects. Sinatra is spartan compared to Rails, sure, but it also means you get to bring just the components you need, and Sinatra is tiny enough to just read the code if you don't understand exactly what's going on. In fact, before Sinatra, I had a couple of projects where I used Camping - _why's micro-framework for the same reason: It brought just the bare minimum, and you could hold all of what it did in your head with ease.
I don't quite have the same hate for Rails, I think. If a client asks for it, I'd consider it. But I also usually tell them I'd rather refer them elsewhere.
Rails was designed at a time before angular brought the SPA into fashion. SPAs manage state and template rendering on the front-end, so much of the Rails machinery becomes unnecessary. You can still use Rails to implement your JSON API backend, but the simplicity of something like Sinatra is often preferable since you're increasing the complexity on the front.
The node+react+webpack combo gave web devs the power to process application states and render the UI on the front-end and the back-end using the same code; a feat that is not possible at all with Rails pushing it a little further out of fashion.
Of course, the SPA suffers plenty of criticism, and Rails is still a popular choice with and without an SPA on the front-end, but I think it's fair to say that Rails is no longer the "fun" way to do things (though the most fun doesn't mean the best business or engineering solution).
I agree with all of the major points of your comment, but I have a quibble:
> Rails was designed at a time before angular brought the SPA into fashion
I dunno that Angular is the relevant point here. Rails (late 2005? I think?) post-dates the public existence of Gmail (public April 2004), a wildly popular SPA. It also post-dates the existence of Google Maps (early 2005). The famous blog post by Jesse James Garrett that coined the acronym "AJAX" is also from early 2005.
The thing that Rails does well was already largely-obsolete before Rails was open-sourced. (Though that is one state-of-the-art buggy whip! Very impressive!)
I absolutely agree that the SPA was already a thing before angular, in fact, angular was specifically designed to wrangle the general design concerns related to building SPAs and doing so sold the distinct concept of the SPA to many developers.
The difference between front and backend web applications is nothing more but where the views are rendered - which on client side also means managing state and IO.
This means Rails and Angular are doing the same job - the main difference is where data keeping and rendering is done.
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.
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.
> 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.
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.
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).
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.
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?
I've done RoR stuff and something about "doing-things-the-rails-way" bugs me to no end. After being paid to work on a RoR app I started to hate Ruby. Some time after I wrote something small and silly for my thesis (to visualize some data and give my classmates something to play with) in Sinatra and it rekindled my love for the language.
Something I can't really put my finger on just rubs me in the wrong way in Rails, but using Sinatra felt like shattering chains that were holding me back. Maybe it was partly that I was learning NodeJS at the time, I dunno, but I can't recommend Sinatra enough. This being said I have zero experience with Sinatra in an production environment, so take this anecdote with a shovel(s) of salt.
For some reason, I could never get the hang of Rails. But when I found Sinatra, it all made perfect sense to me.
Now I exclusively use Padrino [0] as the framework to build all my web apps. It is a framework on top of Sinatra that gives you a lot of the Rails goodness, but allows you to be really agnostic in terms of ORMs, Testing/Mock frameworks, rendering platform etc.
If you want something comparable (feature wise) to Rails, then check out Hanami. It's much better designed for large apps. If you are looking for a micro framework, I'd suggest Roda. I'd characterize those two as the modern replacements for Rails/Sinatra.
I haven't been paid to write a line of Ruby in over 4 years but I still use it for the occasional hobby project. Not only do I not use Rails for fun, I'd have to be close to starvation before I used it again for profit.
Now I feel the urge to dust off my copy of 'Eloquent Ruby' and write some fun code.