Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I believe Rails is still relevant in 2019

devbrett.com

Post reply on HN
Print view View original

151–160 of 264 posts

Re: Why I believe Rails is still relevant in 2019

#151

Post by freehunter »

gumcreme wrote: post #115

While reading this thread, it feels like a flashback from 2009 and now, I remember what was my biggest gripe with Rails (next to all the bad parts mentioned here in this thread): It is the culture. I really find the Rails culture odd or tbh, I utterly dislike it. I mean if met a Go guy, he tells me all good with Go, it gets the job done but it has its warts, the same with Rust, node, React and so on. People of other…

Maybe this is because everyone has spent the last 10 years telling them that Rails is dead, they're stuck to a dead technology, and Go no wait Dart no wait Rust no wait Javascript no wait Node no wait React no wait Phoenix is better.

Re: Why I believe Rails is still relevant in 2019

#152

Post by chvid »

freehunter wrote: post #148
rimliu wrote: post #99

Earlier quoted context omitted.

> For example - is it really "better" to say 7.even? rather > than isEven(7)? Yes. And that has nothing to do with rails, it's just the Ruby way. > Or is the article's example of a data model migration > really better than a series of alter table sql statements? Yes. Migrations provide much more than just altering DB schema. > And why not go for a pure SPA rather than an > AJAX-sprinkled compromise I would love more…

>I would love more people to ask themselves "do I really need SPA?" actually. And I'd love if people asked "is anyone actually doing SPA" beyond what TurboLinks + a Vue frontend on a Rails backend would get you.

My point is rather if you are doing that (a hybrid app) wouldn’t doing a full spa actually be simpler? And allow you to use a less complex framework / a framework which doesn’t have to support that legacy.

Re: Why I believe Rails is still relevant in 2019

#153

Post by freehunter »

derekdahmer wrote: post #39

Was anyone saying Rails wasn't relevant?

All the people trying to sell you something else. I heard someone on HN call it "blog driven design". Tech blogs need something to write about, Udemy teachers need something new to sell, startups need some way to differentiate themselves from their competition, so they start talking about how awesome [insert new tech stack here] is. The cycle continues and in 6 months, [new tech stack] is old news and you can't build the modern web with it and it doesn't scale, so here's [even newer tech stack].

Meanwhile Ruby, PHP, Python, and Java are still powering all the sites that are telling you those technologies don't work anymore, and powering the site that takes your money when you buy another Udemy class to learn [even newer tech stack].

Re: Why I believe Rails is still relevant in 2019

#154

Post by sidcool »

I think Rails is fine. It gets you up and running super fast. GitHub, Heroku, Basecamp etc. run on Rails and they are doing great. It's popular because it's relatively 'low-code' than other language/frameworks. Ruby is quite simple to get started with and Rails' convention over configuration philosophy gives a lot out of the box.

Having said this, it's not all rosy. Rails does buckle under scale, hence LinkedIn and Twitter had to gradually migrate to Scala(I think) based platforms. This is more a problem with Ruby than with Rails. A huge Ruby backend application becomes quite difficult to reason without a good type system. It's not impossible, just more difficult than say Scala or Haskell or Rust, that have very strong static types.

I am sure I am missing a lot in this comment.

Re: Why I believe Rails is still relevant in 2019

#155

Post by sidcool »

gashaw wrote: post #118

Ruby is great, Rails is good enough. The main issue with Rails (it's the same with other frameworks) is that it discourages from doing proper design. The only design decision you make is where to put a piece of code, which is ridiculous ("Fat models, skinny controllers" is a bad design heuristic.) Following Rails conventions works for small (simple) applications, but over time you arrive at a point where no one under…

I have the exact opposite view that I have mentioned in another comment on this post. "Rails is amazing, Ruby is good'.

Re: Why I believe Rails is still relevant in 2019

#156

Post by mmartinson »

I worked on a couple of production apps in Rails at the start of my career. It was the first way I learned to make web applications.

Rails works as advertised and is great at what it does, but I think ultimately the conventions-obsessed nature of the community, that is often so helpful, has settled on some patterns that make the Rails approach more bother than it's worth with other good options out there. Often touted for being able to scale business logic and developer productivity at the expense of runtime performance, I see some serious issues with the claimed strengths.

- The powerful active record pattern and accompanying library makes it easy to pile on coupling between business logic and database access code.

- Ruby doesn't give you a straightforward way to protect against mutation, which leads to some real debugging nightmares at the worst of times.

- Rails conventions openly disregard low hanging fruit best practices of OOP like the SRP, and make it difficult to design code that follow these practices without straying outside the well trodden conventions (hi again Active Record).

- Rails provides configuration-like interfaces that don't feel like you're calling Ruby code. They are convenient, but offload a big cognitive burden in the name of convenience whenever you need to problem solved something that's not a garden-variety bug.

Ultimately I made the time investment to try some other approaches and have been finding that it's possible to get much of the productivity of Rails at the (arguably worthwhile) cost of a bit of extra typing up front. If you know Ruby well already and have some business goals with some urgency behind them, certainly a great move. If you are earlier career and looking to invest in a productive skills set, you may be better served to consider a few different options.

Re: Why I believe Rails is still relevant in 2019

#157

Post by nathan_long »

I spent a couple of years dreaming of getting paid to work in Ruby and Rails and about 7 years doing so. There are many things I loved about Ruby, and Rails brought a ton of good ideas to web development, as this post describes (though I don't agree with all the highlights).

I've since moved to using Elixir and Phoenix, and then even more recently, done some consulting on a Rails project. So the contrasts are on my mind.

My perspective now is that the advantages Ruby/Rails have over Elixir/Phoenix (community size and number of libraries) are circumstantial, and the advantages Elixir/Phoenix have (fault tolerance, concurrency, speed, less requirement for external tools) are inherent in the VM.

Yes, speed of development and maintainability matter. And yes, you can write good or bad code in any language. But if Rails taught us anything, it's that defaults matter. And the default pattern in Rails is to use ActiveRecord and rely heavily on model callbacks, which can get confusing quickly. ActiveRecord also has no way to turn off lazy loading as far I know, and chasing down N+1 queries to improve performance is something I spent far too many hours doing.

My productivity also wasn't helped by the long test run times of Rails applications, or by wasting time trying to optimize view rendering on a heavily-used page.

All of those are either non-issues for me now or at least greatly reduced - Phoenix view rendering is crazy fast, N+1 queries aren't possible with Ecto and it doesn't have callbacks, Elixir test suites are highly concurrent and generally fast (though driving a headless browser is still rather slow).

Performance and concurrency do impact productivity. And I find that "functions in modules" is a great way to structure code and makes it easy to refactor. So does being able to run the entire test suite faster than I can get distracted.

The best ideas of Rails, in my opinion, are present in Phoenix - things like structural conventions, English-like naming, and database migrations. But many of the pain points are missing.

Phoenix and Elixir aren't the One True Way™, aren't the best for every conceivable software problem, etc. And surely they'll be superseded. But in my opinion, Rails already has been.

Re: Why I believe Rails is still relevant in 2019

#158

Post by [deleted] »

monkeynotes wrote: post #132
lmm wrote: post #105

Earlier quoted context omitted.

A summary of my experience would be: libraries are good, frameworks are bad. (Indeed possibly the best "framework" I ever used was TurboGears which is very deliberately just a collection of dedicated libraries, all of which you can replace piecemeal as and when you need to). Rails raised the bar for how little custom configuration should be necessary to do a simple, straightforward thing. But it turns out being a fra…

Can you give an example of a collection of libraries that you would consider would compete with Rails?

[deleted]

Re: Why I believe Rails is still relevant in 2019

#159

Post by cutler »

wrestlerman wrote: post #140

I thought same in 2018 when I didn't use Phoenix. But after trying out Elixir and Phoenix, damn... Elixir and Phoenix give you so much, nice websockets, concurrency, fucking easy to read code with great docs. I was a bit sceptical about the praise Elixir was getting, but after working with it for a while... I started noticing a lot of stuff that is lacking or abused in Ruby and Rails.

Elixir looks great until you look at modulecounts.com where Erlang/Elixir libs total a mere 7900. Compared with Ruby's 150900 gems that's a lot more code you're going to have to write surely?

Re: Why I believe Rails is still relevant in 2019

#160

Post by smt88 »

monkeynotes wrote: post #134
smt88 wrote: post #106

Earlier quoted context omitted.

> starting from scratch or from a minimal base is massively slower This isn't the better alternative to frameworks. The better alternative is using libraries and optionally a bootstrap code generator, which is not at all "starting from scratch". The major difference is that you tell the libraries how to work together, rather than the framework telling you how to work. Some frameworks become like a terrible DSL that y…

> you tell the libraries how to work together Doesn't this just become a bunch of decisions and team cognitive load you have to deal with?

Less than you'd think.

The team architect should set up the project structure, not a committew. Most languages have idiomatic conventions for writing framework-less code, so it's not going to look totally unique when they're done.

Post reply on HN