Hacker News Reader

Comment by criddell | Hacker News Reader

Now that Rails isn't the cool new thing anymore, is it still a good choice for new projects?

For the new year, I'm thinking about the programming landscape and contemplating what I want to learn next. I've tinkered with Ruby on Rails in the past and think DHH is on to something with the doctrine he has laid out. I've only scratched the surface of Rails, but it still seems pretty neat to me. A deeper dive would be fun.

On the other end of the spectrum, Dart + Angular is appealing in part because I'm a fan of some of the Google developers working on Dart. While Rails feels like it is entering a comfortable middle age (or at least adulthood), Dart feels a little like a car being assembled as it cruises down the interstate. It's new and maybe a bit dangerous.

Both projects are super-appealing to me. Unfortunately time constraints prohibit me from chasing both and I'm interested in opinions especially of Rails people. Are you still excited about it?

View on HN

I didn't learn Ruby/Rails back when it was the "cool new thing" -- I resisted and tried to wrestle PHP to my liking. Eventually I gave up and threw my hat in the ring, and I'm so glad I did. My advice is to learn Rails first, and then take all the wonderful things you've learned and apply them to other languages and ecosystems if you wish (many libraries and frameworks for Javascript and other langs are inspired by Ruby or Rails). I don't think it's as valuable to attempt the reverse...

When doing projects on the side, I like to play with node.js or Elixir but when I have to develop projects for paying customers, I tend to gravitate towards Rails...

Few reasons for that:

1. I'm extremely productive and fast at developing in Rails

2. It's much easier for the client to get an app that's develop for a Framework that's been there for a while, is stable and will continue to be there

3. Ruby is a nice language and the principles behind Rails resonate with me (so it's not like Java and Spring which I was eager to get rid of when I switched to Rails a bit over 10 years ago)

That doesn't mean that I don't use node.js for certain specific use cases on client projects... But my goto framework is Rails

I'm not sure I understand why "comfortable middle age" is a negative.

Unless the argument is that Rails has either a) accumulated damaging cruft or b) missing out on important new features/paradigms, "comfortable middle age" seems like a huge selling point, right? Battle-tested, mature, a huge amount of shared knowledge, etc?

I didn't intend for that to be a negative, just that it's a different point in it's life.

I'm not trying to make any argument about Rails, but am very interested in your opinion. Has it accumulated cruft? Is it missing something that newer frameworks have embraced?

I've been programming Rails since 2010, and still feel like it's far-and-away the most productive I've ever been for turning SQL into HTML and then user actions back into SQL. If your task is SQL into HTML and then user actions back into SQL, with a few "sprinkles" of Javascript on top of it, Rails will not steer you wrong.

I have also recently been doing, for the first time in a long while, work which is not SQL into HTML and then user actions back into SQL. Rails was never seriously considered for that part of the project. This was the correct call, and the new stack (GoLang and React) are fun things to have in my toolbelt, but there have been a few points this year where I've said "I just spent two hours on something which would have been 4 lines in Rails and I'm not sure I'm done yet."

> turning SQL into HTML and then user actions back into SQL

You've really distilled it to it's essence and that has given me a lot of clarity.

The company I work for uses an issue tracker written with Ruby on Rails (Redmine). There's a few things I'd like to change and so I think I'm going to spend the first part of this year getting comfortable with Rails and making a few changes to Redmine that I'd like to see. Then, I might transition to Dart and see if I can put together an interesting browser-based client.

Rails is an awesome framework to develop in. For me, however, it is less about Rails and more about the community. Take for instance the popular Ruby job processing system, Sidekiq. It integrates very easily into Rails and makes that whole async job thing painless. I haven't seen anything as sophisticated in other languages. ActiveModel is also a very nice library to work in, and having it by default is nice.

I personally do Rails backend + Angular frontend and it is a very rewarding stack. I get the power of Angular, but the simplicity of Rails in the backend. DHH is wholly against that, but it works really well.

He is not against angular-like frameworks, he is against attempts to apply them everywhere.

> Now that Rails isn't the cool new thing anymore

But why does that have an impact on what tech you use?

It's a good question and it's really what I'm asking about.

The only web-stuff I've worked on in a commercial settings was a long time ago using Java and Tomcat. At the time, it was the cool new thing. I think that some of the pain points of languages and frameworks from that era are what prompted DHH to develop Rails (I'm specifically thinking about convention-over-configuration and admit I could be totally wrong here).

So today, I probably wouldn't pick Java and Tomcat for a personal project just because I know it won't be as fun and I won't be as productive as I would be with different technology. Has Rails been eclipsed in a similar way?

No.

I’m running a team of developers where we are using Rails as our first-line tool, but we are also committed to using the best tool to solve the jobs at hand. So far, we have only needed to add Lua for a small piece of what we are doing because we can reason about what our logic is supposed to be doing quickly and easily in Rails.

Less than a third of my team were Ruby or Rails developers before joining us, and we are always pushing forward on learning more so that we have a great bucket of tools available as we try to solve our business problems and we hit those things where trying to reason about the problem is difficult in Rails, or where performance matters more than readability and code clarity.

I'll pick Java, SpringMVC, Maven, JUnit+DBUnit, and FlyWay (DB migration) and any appserver (jetty, tomcat, TomEE, glassfish) thrown at me except from the BigCos (WebLogic, WebSphere).

Those tools are pretty close to what Rails give you (notice the View/UI is open for anything... Rails View is slightly nicer as it has better templating capabilities but ... not a deal breaker for me).

It's not sexy, it gets the job done, and I know it'll run for at least 5-7 years with minimum hassle.

Plus it's easy to be productive on Java project...

Even as someone who uses the newer languages/frameworks, I wish I could upvote this statement multiple times:

"It's not sexy, it gets the job done, and I know it'll run for at least 5-7 years with minimum hassle."

Upvoted. I am tired of getting the "uncool old fart" looks every time I propose similar stack. You CAN do cool stuff with established tech plus have a peace of mind that you will not run into any "surprises".

It makes total sense to mitigate risk on a commercial project by going with established (well supported, well understood) technology. No argument. But for a personal toy project where you want to be surprised, would you choose something like Ruby on Rails?

Yeah I got trashed karma wise on a previous comment explaining how I had to port some Ruby apps to Java. I don't even care that much about either technology but just mentioning that I had to port something to Java earned me -4.... seriously.

There's a lot of debates about this. Here's a view by a partner at YCombinator in the context of new company:

http://blog.jaredfriedman.com/2015/09/15/why-i-wouldnt-use-r...

I have a different general philosophy:

https://www.nemil.com/musings/shinyandnew.html

My own bias is to pick the best tool for the job, and not risk hype dictating your decisions. If you're learning for fun and personal learning, that' s great - just realize that you should optimize differently.

For those of us who were stuck with the JVM, fortunately there's now Grails (obviously modeled after Rails). Groovy makes programming for the JVM fun IMO.

I've used Groovy/Grails for a number of web apps, both in commercial settings and side projects. Since I had previously been doing a lot of Java, being able to leverage the existing Java ecosystem and libraries with Rails-like productivity was a huge plus.

I wouldn't say I'm stuck on the JVM, I actually prefer building web apps with Grails.

Grails may have a small community, but it makes Java web development really sexy. And I write 50% of my Grails code with Java. Groovy is ok, but I prefer the excellent IDE support I get with Java.

"Stuck with" was probably not the right wording. Where I started with Grails in an enterprise environment, Rails would have been a non-starter (or at least a much tougher sell) because operationally we were a Java shop. With Grails, though, it's just another WAR to drop in your servlet container, so operations doesn't really care.

Which IDE do you use? I find IntelliJ to have great Groovy support. Also, you can optionally type check Groovy, which helps even more.

I use IntelliJ too, and I use static typing and @CompileStatic all the time. I'm not complaining, just being nitpicky. I don't see the point coding Java style with Groovy. And that is in my opinion Groovy's biggest strength, that a Groovy and Java class can work great together. A class written in Groovy works just like a Java class in Java and a class written in Java works like a Groovy class in Groovy :-) And I'm a big fan of using Groovy when working with JDBC.

You don't need a Rails clone just so you can work on the JVM -- you could use JRuby on Rails.

slightly off-topic: there's plenty of new Java frameworks out there that can be pretty productive and "fun" - mostly the Sinatra-style ones (Spark, etc) and stuff like Activejdbc for ORM. Plus, there's fun languages on the JVM that allow for less verbose code without going dynamic - eg Kotlin or Scala.

This probably sounds pretty stupid, but once Oracle (or was it Sun?) started bundling other software in the installer that I don't want, I was done with that language. Then Oracle started claiming the Java library API was their IP and protected by copyright. Ugh. I'm probably not going to go back to Java again.

Yes it does sound stupid.

1. Server-side uses Linux, installation through command-line

2. Java standard library API owns by Oracle? fine by 99% of the companies out there. I'm just using those libraries.

> Now that Rails isn't the cool new thing anymore, is it still a good choice for new projects?

It's probably the best choice for a straight-up CRUD webapp (as was always the case). I wouldn't want to do a project with nontrivial business logic in an untyped language these days (having seen how little flexibility you have to sacrifice for safety in a modern typed language), but your views may differ.

Agree on CRUD, but on typing I'm the opposite. Anything sufficiently complex logic, especially etl or projects with multiple models of the same entity, is easier for me in a language with duck typing. It's just amazing how all our brains adapt slightly differently to the different sorts of problems we face and the bag of tricks we use, in addition to the different languages and tools.

I feel bad for anyone who has to swim in your wake. People who embrace dynamic typing generally create write-only code that no one can maintain, since they labor under the delusion that little things like clarity of purpose are a waste of time.

Duck typing vastly reduces the amount of code one has to write that does nothing, making the purpose of the code much more clear. The tradeoff is in compilation, not clarity of purpose. The code tends to be more flexible to changes in the underlying data, as it is easier to modify!

A sad example of those defending static typing are the Java programmers. I point out that Java supports duck typing via reflection, even if the syntax is painful. They say they don't use reflection, they use Spring. [Head in hands]

In any case, there are many happy programmers in my wake, they don't need your sympathy! :-)

Yeah, I got my first exposure to the dynamic side of Java half a year ago. Its honestly not that difficult to deal and the shit it can do is pretty silly.

    Field field = instance.getClass().getDeclaredField("secretField");
    field.setAccessible(true);
    System.out.println("The old private value is " + field.get(instance) + " but lets change it!");
    field.set(instance, "new value");

> Duck typing vastly reduces the amount of code one has to write that does nothing, making the purpose of the code much more clear. The tradeoff is in compilation, not clarity of purpose. The code tends to be more flexible to changes in the underlying data, as it is easier to modify!

It's much harder to make changes because even something like renaming a field requires major testing. You end up writing much more code that does nothing, because the test coverage you need for everything is much longer than the type annotations that would give you the same level of confidence, and whenever you change anything you have to update all your tests by hand. Hope you get the data model right first time! Look at one of those videos of people refactoring Haskell for what a type system can get you.

> A sad example of those defending static typing are the Java programmers. I point out that Java supports duck typing via reflection, even if the syntax is painful. They say they don't use reflection, they use Spring. [Head in hands]

If Java is what you think of when you think of static typing, I don't blame you for hating it. If Java-style typing and duck typing were the only options I'd use duck typing. But there are much better options out there. When I write Scala, most of the time my code looks exactly the same as what I'd write in Python.

Ad-hoc polymorphism (traits/type classes) and parametric polymorphism (generics) largely solves this, whilst giving you a high degree of confidence that your code correct at compile time.

I've found code written in a duck-typed style brittle and hard to refactor safely - it's very easy to try to restructure something, then find out down the line that something blows up because of some incorrect assumptions in another part of the codebase. You can try to grep for all the method usages, but that is a laborious, error prone process in codebases that are sufficiently large enough.

I would say yes, as long as you're building a greenfield project that is a database-driven web application, where your priorities include high productivity and quick time-to-market. It's basically been the default choice for web startups for several years now, lots of startup devs know it, and there are battle-tested libraries available for just about anything you want to do with it. And it is still aggressively adding new features, e.g. first-class support for websockets just came out in rails 5.

Instead of cool & new, think about Rails is stable and mature :)

And yes I think you should consider to use Rails. In my opinion it is one of the best back-end frameworks out there.

> Rails is stable

Rails certainly is mature, its APIs are not stable at all. With every version,even minor, there are annoying changes that often break 3rd party plugins. It shouldn't happen. That's why JEE has specs, as heavy as they get 3rd parties can always refer to them in order to write custom code. Rails is anything but stable. Hard to complete a single tutorial online without running into API issues.

I got my first error right after `rails new myapp` and `rails server`. After some Googling I found out that apparently I had to install Node.js also, but the error message wasn't very clear. This was the official 'getting started' rails tutorial on the rubyonrails.org site [0].

[0] http://guides.rubyonrails.org/getting_started.html

Well, you need a javascript runtime, eg you could install nodejs, that's what the error says. I agree that it might be confusing as a rails beginner, but Rails uses it to convert CoffeeScript files and for minifying and merging all JS stuff into one file.

It depends on what you want to build. I find nothing novel in either tool, so I don't think it's good to learn in a mind-expanding sense. For building medium-sized external-facing apps, rails is one of the better choices out there. For building long-running client-side applications, angular isn't a bad choice (though I prefer Ember for that constraint, personally.)

If you live in the land of Oracle or other proprietary databases, I wouldn't suggest rails. It has some rough edges in my experience. Otherwise, I think you should find a project and run with it, or join a place already in the rails ecosystem. I wouldn't learn it for its own sake.

Tools don't necessarily become less useful with time.

Reply on news.ycombinator.com