Honest question. What technology are people enjoying on the server-side with sites built in React or Angular? I've seen some of these done with Rails, and some done with Node, neither of which I personally enjoy a whole lot. (Note, I'm not making an argument that either are BAD - just that I don't really like working with them). I'm curious to hear what other people are having success with in production.
Pheonix looks promising. It's basically Erlang on Rails.
Today I accept that Rails is yesterday’s software
81–90 of 166 posts
Re: Today I accept that Rails is yesterday’s software
#82I agree with some of the issues that the author points in Rails; but, at the same time, he is unable to name what is "today's software" using his words. Until then, I will stay with Rails. Until then. Moreover, the author seems to be imagining Rails as a huge monolithic piece of software. That does not need to be true.
Doesn't the author end by saying Swift, Rust and Go are "tomorrow's languages"?
So far, I still haven't seen anything better than Rails to solve yesterday's (and today's) problems.
Re: Today I accept that Rails is yesterday’s software
#83Earlier quoted context omitted.
Yep! Nothing wrong with yesterday's technology if you're solving yesterday's problems! I don't mean that in a sarcastic or glib way, most of your problems really are yesterday's problems. Or even yesteryear's problems…. now that I think of it, when I depart from rails in a rails project (which is common), it's usually to use raw sql, unix, various networking protocols, or other programming languages that predate rail…
ORMs get a lot of undeserved flak for being considered "training wheels for SQL" but they can save you from writing an awful lot of boilerplate code.
Re: Today I accept that Rails is yesterday’s software
#84Earlier quoted context omitted.
Yep! Nothing wrong with yesterday's technology if you're solving yesterday's problems! I don't mean that in a sarcastic or glib way, most of your problems really are yesterday's problems. Or even yesteryear's problems…. now that I think of it, when I depart from rails in a rails project (which is common), it's usually to use raw sql, unix, various networking protocols, or other programming languages that predate rail…
ORMs get a lot of undeserved flak for being considered "training wheels for SQL" but they can save you from writing an awful lot of boilerplate code.
But yeah if you use them judiciously they can remove some drudgery.
Re: Today I accept that Rails is yesterday’s software
#85Just use Java people. You can bootstrap a Spring project in 10 minutes and it will have every feature (ORM, security, caching, MVC) available with just a maven dependency or you can roll your own and it will work fine. Strong typing, good performance, sensible stack traces (if you don't overdo annotations) and all the testing and monitoring tools you could ever dream of.
This comment is what I feel like replying with to every article about some "fast iterating" language. IMO the only reason to use rails if you don't actually understand how web development actually works. Why would you pick a slower language and platform like ruby/rails when java/spring is right there available to anyone?
Re: Today I accept that Rails is yesterday’s software
#86Earlier quoted context omitted.
That's a pretty shitty attitude to have. What framework is sufficiently irrelevant that Pragmatic Press or O'Reilly can't be bothered to write a book about it?
Actually O'Reilly published a good book on Rails in the early days 'enterprise rails', which was a very well written book. The pragprog web books seem to be a bell weather, the shiny web crowd flowed into Rails, node and soon probably phoenix. The early start and promise and phoenix will soon sink under the weight once hex packages bloat in number like the festering turds within ruby gems.
You sound out of your mind. Please try and make a rational argument.
Re: Today I accept that Rails is yesterday’s software
#87Earlier quoted context omitted.
I completely agree with you. But when it comes to developing web apps rapidly, Rails is about as close a silver bullet as you can get. If your entire purpose is to ship a product quick, you should be ignoring the "too much magic, too many dependencies" narrative and building something, which Rails is wonderful at.
With Rails 5 just coming out now does it make sense to just start learning there. Is the material like the "Ruby on Rails Tutorial" book that uses 4.2 still worth reading or is it a large change, something like the python 2.7 to 3 where tutorials and reference material are largely dependent on the software version you use.
Re: Today I accept that Rails is yesterday’s software
#88Being "yesterday's software" is a necessary step. It's the final part of the Gartner hype cycle: maturity. https://speakerdeck.com/tehviking/surviving-the-framework-hy...
Re: Today I accept that Rails is yesterday’s software
#89For those that are feeling fatigued from working with and around the magic of Rails, Sinatra is a great choice (in python land Django has an alternative called Flask). http://www.sinatrarb.com/ That said, you will have to re-implement machinery that rails gave you for free. If you're building a simple API, there will be obvious simplicity benefits. If you're trying to build a server-side rendered web application, you…
You will indeed have to re-implement stuff Rails gives you. But more importantly, you will have to maintain it. I maintain a large-ish Sinatra app that should've been done with Rails. Update cycles on the gems are a nightmare. It feels cobbled together. it's a "half baked homegrown version of Rails." Someday I will just move the logic to a new Rails app and be done with it. It was a terrible idea. * your experience m…
Re: Today I accept that Rails is yesterday’s software
#90Honest question. What technology are people enjoying on the server-side with sites built in React or Angular? I've seen some of these done with Rails, and some done with Node, neither of which I personally enjoy a whole lot. (Note, I'm not making an argument that either are BAD - just that I don't really like working with them). I'm curious to hear what other people are having success with in production.