Live data from Hacker News

Why I believe Rails is still relevant in 2019

devbrett.com

231–240 of 264 posts

Re: Why I believe Rails is still relevant in 2019

#231

Earlier quoted context omitted.

ngninx supporting http/2 != Rails supporting http/2 Depending on the use case you leave out nginx sometimes, eg. when doing microservices. Not that nginx is bad but with other stacks you very often don't need nginx and/or connect directly to the CDN reducing complexity in a stack.

nginx transparently proxies using http2 to client and http1 to server. In a standard setup at any scale with a load balancer it doesn't matter that Rails doesn't support all of HTTP2. The client still gets all the benefits of header compression etc.

> In a standard setup

What is a standard setup in 2019, there is none? There is also no standard in using nginx as front facing entity.

In my prior comment I was friendly and gave an example why some might not have nginx in their stack and BTW the discussion is about Rails lacking http2 and you try to convince me that this is expected and right.

This is pure ignorance paired with incompetence, maybe in your small world things work this way. Let's just stop here and go back to your legacy stack.

Re: Why I believe Rails is still relevant in 2019

#232
post #162

Earlier quoted context omitted.

Shouting and insulting people is no way to have a discussion. Without moderation or some other mechanism this is what online communities devolve into and it destroys them. /r/programming used to have lots of great discussion. Now it's mostly a deserted wasteland.

>Shouting and insulting people is no way to have a discussion. Says you! I don't enjoy the flaming, but things have gone too far to the other side where you can't anything online or you get CoC broken over it.

I think the forum matters. Want to insult people and get praised for it? Twitter and Reddit are the place to be.

Just like in the real world, some language is appropriate at the library and some is better saved for the bar.

Re: Why I believe Rails is still relevant in 2019

#233

Earlier quoted context omitted.

> a asynchronous worker manager something you don't need anymore with a modern stack > an upload manager, and BI tool standard stuff every other ecosystem has > mature gem ecosystem missing essentials like stable http/2 and full of unmaintained gems

Just to share for anyone interested in the Rails gems I'm using. An asynchronous worker manager is helpful for handling cron jobs, mail tasks, and various batch processes that can be loaded into memory (mostly Redis) but processed later. I use the gem Sidekiq which, as is, provides a UI and API that I rely heavily on. I might just not know the best practices, but I definitely find this valuable. The BI tools are not…

I know what an async worker and what sidekiq is. But apparently you don't know that in modern stacks you don't need this anymore and it was an oddity because of RoR.

I am on mobile and don't have time to write down why, please just go to StackOverflow and ask people why something like Sidekiq is not needed in stack x.

Re: Why I believe Rails is still relevant in 2019

#234

Earlier quoted context omitted.

Just to share for anyone interested in the Rails gems I'm using. An asynchronous worker manager is helpful for handling cron jobs, mail tasks, and various batch processes that can be loaded into memory (mostly Redis) but processed later. I use the gem Sidekiq which, as is, provides a UI and API that I rely heavily on. I might just not know the best practices, but I definitely find this valuable. The BI tools are not…

I know what an async worker and what sidekiq is. But apparently you don't know that in modern stacks you don't need this anymore and it was an oddity because of RoR. I am on mobile and don't have time to write down why, please just go to StackOverflow and ask people why something like Sidekiq is not needed in stack x.

What stack would you recommend if not rails? Serious question with no malice

Re: Why I believe Rails is still relevant in 2019

#235

Earlier quoted context omitted.

> Rails scales Your post is a bit misleading. Rails can scale but to get there is different than with other stacks. Some would say, it's much more challenging or complicated, some would call it just a PITA and if you really, really want to scale, like e.g. a porn site, Rails is the worst choice you could ever take. Or you would just completely rewrite it but what is then the motivation to take a framework? Maybe fram…

So let's just forget about Basecamp, Github, AirBnb, Hulu, Kickstarter, MyFitnessPal, Twitch and all the other Rails sites and continue to pretend Rails can't scale and won't work for the modern web.

I love Ruby and like Rails, but unless you can cache most of your content, scaling is going to cost you.

Re: Why I believe Rails is still relevant in 2019

#236
post #175

Earlier quoted context omitted.

You know that Rails is a collection of libraries that can pretty much all be replaced with the alternative of your choice, right?

Up to a point. In my experience there is limited support for e.g. using "mismatched" versions of different parts of it.

Isn't that the same with any collection of libraries? If you don't use a framework and just pick your libraries, you'll still need to ensure that their versions work fine together.

Re: Why I believe Rails is still relevant in 2019

#237
post #127
post #30

Build your app using whatever you're most comfortable with because in the end an existing product is better than no product. Will you enjoy spending an extra hour per day working with this framework over another? That's an hour more of progress. Personally I think Spring Boot with Kotlin is a way better choice today for monoliths that transition well to micro services. But if you're already deep in the RoR world just…

I use Grails which is very similar to Rails and a lot easier and productive than Spring Boot. Good defaults makes application building a much smoother experience. Grails is still Spring Boot, and you can still code like it was a pure Spring Boot application. Grails has its own ORM called GORM, which can use several different backends like Hibernate/MongoDB Groovy is a great language, with the best from dynamic langua…

I've had some not-so-great experiences developing web services with Spring Boot, Hibernate, Groovy itself, Grails.

We now stick to plain old Java with no annotations, Ratpack, jOOQ, etc.

In my experience, and opinion: Lack of static typing is a good way to make shooting yourself in the foot easy. Annotation-driven magic sucks. Just Writing Queries causes fewer headaches than using an ORM. Basically, libraries over frameworks. YMMV.

Re: Why I believe Rails is still relevant in 2019

#238

Earlier quoted context omitted.

nginx transparently proxies using http2 to client and http1 to server. In a standard setup at any scale with a load balancer it doesn't matter that Rails doesn't support all of HTTP2. The client still gets all the benefits of header compression etc.

> In a standard setup What is a standard setup in 2019, there is none? There is also no standard in using nginx as front facing entity. In my prior comment I was friendly and gave an example why some might not have nginx in their stack and BTW the discussion is about Rails lacking http2 and you try to convince me that this is expected and right. This is pure ignorance paired with incompetence, maybe in your small wor…

Something using AWS or GCP LBs, nginx or Apache covers 99.99% of the modern web app hosting scenarios. All support HTTP2 to the client with HTTP1.1 to the server.

This is why nobody is rushing out to rewrite Rack to support HTTP2. Ruby web apps already benefit from almost all of the advantages of HTTP2.

Re: Why I believe Rails is still relevant in 2019

#239

Earlier quoted context omitted.

> The problem I had with the bullet gem however is that some times you actually want N+1 queries. Especially with Russian-Doll caching. I know it sounds like I keep beating the same drum, but to me this problem seems like "we have slow views, therefore we need to sprinkle conditional caching logic everywhere, therefore we need to allow lazy loading, therefore we need to watch for N+1 queries." As I wrote elsewhere (…

That's interesting to learn... I always assumed caching is a necessary evil if you want to speed things up. I certainly feel like rendering views is rails is slower than I'd like it to be (talking about the rendering part alone), especially with partials. How do you deal with views that pull dynamic data that produce a heavy query however?

If the query was expensive and could be run periodically, I'd either create a materialized view that gets refreshed as often as necessary (maybe by https://dockyard.com/blog/2017/11/29/need-an-elixir-dependen...) or use a GenServer process for caching that data (as you might do with Redis otherwise).

I don't think the view rendering itself would ever be a performance issue, but rendering a view is just a function call in Phoenix, so I could take a similar approach there - store it in a GenServer.

Re: Why I believe Rails is still relevant in 2019

#240

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

I love how every time there is a post about Rails, someone preaches the holy grail of Elixir/Phoenix. I think you are missing the forest of the trees, regardless of whether or not the success of rails is circumstantial, the fact remains that Rails is in the lead position because you can build a business on top of it. It is a solid, battle tested, mature framework that one can use and scale it (up to a certain point)…

> I love how every time there is a post about Rails, someone preaches the holy grail of Elixir/Phoenix.

I can understand how you might feel that way. I tried to make clear that I don't think it's the perfect answer to everything forever, but to specify ways in which I've personally seen it as an improvement. And given that the OP is about the continued merits of Rails, don't you expect some commenters to express disagreement?

> the main thing that execs care about is the bottom line and how fast we can push products to production

True. But that matters not just on day 1 but for years to come. Sandi Metz in the Ruby community teaches that point well.

I've seen Rails patterns like ActiveRecord callbacks lead to buggy, confusing code, greatly hindering progress on feature work and requiring significant debugging effort.

Certainly lots of businesses have succeeded with Rails, and I've worked for some of them. Lots of businesses have succeeded with Python, Java, .NET, PHP, and Node, too. That in itself doesn't argue for which one to pick when starting a new project.

After experiencing difficulties with my Ruby tech stack, I started looking around, and Elixir is where I landed. At this point I'm invested and biased, just as the OP is. But bouncing back and forth between the languages recently has confirmed for me that I prefer Elixir for the reasons I gave above.

> To any young devs out there, I strongly encourage you to not pick a framework by its hype but evaluate it based on your system needs / maturity.

I'd suggest young devs pick tools based at least partly on job postings, and on that measure, Rails will win by a landslide. But keep your ear to the ground. When I started as a developer, I was using PHP, but I kept hearing how Rails was better. Learning it and moving to work in it was a great career move for me.

Something will come after Rails. Something will come after Phoenix. There will always be a new something. Don't get too caught up in the hype, but don't get too attached to your current tools, either.

Post reply on HN