Live data from Hacker News

Today I accept that Rails is yesterday’s software

medium.com

81–90 of 166 posts

Re: Today I accept that Rails is yesterday’s software

#81

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.

Or Rails on Erlang (even though I see what you did there).

Re: Today I accept that Rails is yesterday’s software

#82
post #4

I 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"?

That's the issue: he calls them tomorrow's languages, implying that they need to change ("can you marry modern thinking, build a community [...]) before getting there, or being "today'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

#83
post #69

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

And... a lot of awful boilerplate code too. Not to put too fine a point on it, but much of what I see people write in the effort to avoid using an ORM is insanely poor, but they saved 2ms off of a report query that's run 3x per day. Nevermind that I can delete your entire database by modifying URL structure - ORMs are inefficient!

Re: Today I accept that Rails is yesterday’s software

#84
post #69

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

Activereord certainly saves me a lot of time. I think the reason orms get a lot of flak is that people see them usedin wildly inefficient ways that could have been solved with a simple join or other basic sql operation. Or alternatively people to to comical levels of twister to stay within the framework and create a parallel implementation of Sal.

But yeah if you use them judiciously they can remove some drudgery.

Re: Today I accept that Rails is yesterday’s software

#85
post #25

Just 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?

And Grails is very similar to Rails, and you get the full power of the JVM/Spring technology stack. And Groovy is a fantastic language that gives you the flexibility everyone like to dream about.

Re: Today I accept that Rails is yesterday’s software

#86

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

Rejecting a platform just because a publisher has written a book about it is like turning down a job because your astrologer said it was a bad fit.

You sound out of your mind. Please try and make a rational argument.

Re: Today I accept that Rails is yesterday’s software

#87

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

There will be some major changes, but not as drastic as the Python version upgrade. I'd think the 4.2 book will be totally fine, and when 5 is out, just look at the changelog and start adding what you need from it.

Re: Today I accept that Rails is yesterday’s software

#88
post #5

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

The criticisms made of Rails in the article have nothing to do with its waning hipness. Rails falls into the trap of mistaking "easy" for "simple".

Re: Today I accept that Rails is yesterday’s software

#89
post #65

For 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…

My experience was exactly the same. Sinatra is for super tiny things. Rails is for most things.

Re: Today I accept that Rails is yesterday’s software

#90

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.

Elixir's Phoenix:

https://dockyard.com/blog/2015/11/18/phoenix-is-not-rails

Post reply on HN