Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login
Why Should You [Still] Choose Ruby on Rails to Develop Your Product in 2023 (mobidev.biz) similar stories update story
39 points by mobi-dev | karma 21 | avg karma 0.08 2022-12-15 09:15:25 | hide | past | favorite | 34 comments



view as:

With 2023 approaching, Ruby on Rails is becoming an even more mature technology, since its initial release occurred 18 years ago. Having emerged as a white knight for the area of web app development, Ruby on Rails is still in use, but concerns about its relevance and popularity are rising more and more often. So in this article we will answer the following questions:

- Is Ruby on Rails dead or still alive? - Why leverage Ruby on Rails in 2023? - When to use Ruby on Rails and when to shun it in favor of more competitive technologies?


Please, shorten your sentences. Check out "On Writing Well" by Zinsser.

Nobody asked but we've all noted, you have trouble with reading comprehension. I read the parent comment easily and found the commas helpful.

While a bit rude, they aren't wrong. The referenced text is grammatically correct, but poorly structured - making it more difficult to read.

> One of the RoR vulnerabilities is connected to Mass assignment capabilities, which enables attackers to alter values in database columns and create new records in tables. But seasoned ROR developers can easily minimize risks in that case.

This hasn't been the case for some time. By default, you can't pass in raw parameters from a request in a controller into a model. You have to either allow-list specific fields or create a hash from the parameters.

You have to intentionally bypass this security feature to get a vulnerability.

Recommend using brakeman to catch these kinds of mistakes. :)


Feels like blogspam.

It's an advertisement for their consulting services.

There's so much wacky nonsense in there that I almost don't believe it's real.

It's like ChatGPT has turn the tables and is trying to provoke us into saying something not nice...


Honestly all of this applies to Django as much as Rails. Their comment "Django does not support full stack development" is incorrect. I know what they mean, they mean "does not come with JS out of the box".

Django is frontend agnostic so you can use whatever flavor of the month you like. (For better or worse hahaha)

Update: To be clear, I think Rails is a fine choice. I just don't think there is much of a reason to use it over Django these days unless you already know Ruby and don't know Python.


Rails 7 isn't strong tied to any frontend. You can add --skip-javascript to the generate command and it will omit that. You can also add --skip-asset-pipeline to remove the default asset bundler as well.

:)


People say this, but a whole bunch of rails gems still require sprockets to import their assets

> Honestly all of this applies to Django as much as Rails.

And probably Laravel as well. And maybe Spring Boot.


i have been working professionally with ruby on rails for about 3 months now, coming mainly from a javascript ecosystem.

im still struggling. there's a lot of magic happening. i'm not bad with the ruby language itself. but i"m so used to first principles. im open to suggestions on improvement here


I suggest getting comfortable with pry and pry_rails, and use them to get to the code behind the magic. For example try `ls <object>`, `cd <object>`, `show-source <object>`. These tend to be obscure features, but add a whole lot of visibility to Ruby code.

My suggestion is to read and re-read the Ruby guides and documentation. Trying to just "figure out" what Rails is doing and why is a frustrating experience. Taking the time to understand the higher level concepts and methodology is critical.

Learn the ruby metaprogramming model inside and out, start reading the rails source starting with activesupport

As an alternative to the voices below - I did this path, I'm now 4+ years in at a RoR's shop and I came in with basically no background in Ruby or Rails.

I personally just don't like Rails. I find it annoying at best, and utterly infuriating at worst.

It's a modern ASP.net - if you want to do dead simple things, Rails does the job quickly and easily, with lots of nice generators, and simple drop in tools.

If you want to do anything outside the happy path, you need to know the entire framework like the back of your hand, because you'll need to unwind the magic and they shoved far too much magic into what should be a simple thing.

And just like ASP.net - the magic changes every version because "best practices" for the web are also changing incredibly quickly. What magic incantation you need depends on which version of the framework you're running, and the docs are bad on this front.

I get Rails - but it is very much not my cup of tea. I don't want to learn their specific DSL and unwind all their magic when I already understand the topic at hand, and just want it to do the thing I'm asking it to.


Looks like more blogspam intended to snipe search results for "is rails dead". Rails is still great and will still be great for many years.

Sorry, but I am fully sold on Elixir and Phoenix. I am sure Rails is still great, but the performance and utility of tools like LiveView are what bring it home for me.

I think RoR is a viable and smart choice in a lot of circumstances, but this article did nothing to inform that opinion.

> Ruby serves for functional programming and web development, while Python has found application in different branches of AI and academic programming.

> Ruby is 100% OOP language, while in Python these principles are implemented only partially.

> Principles of declaring variables and working with them differ.

Well, jeez, if I have to work with the variables differently, then...

Who wrote this? The bookkeeper?


> Well, jeez, if I have to work with the variables differently, then...

Thank you for a good laugh!

I had a stressful day and your comment made it much better.


This feels like one step above typical SEO spam.

ChatGPT!

My first reaction was that this is targeting executives as it looks like the kind of writing I have seen in emails from executives.

I switched to Elixir and Phoenix this year, and Elixir is a joy to write in. It makes me so happy to write less business logic by leveraging their pattern matching. I struggle going back to other languages and have to re-adapt a lot.

I love Ruby, but Elixir/Phoenix is the natural next step after Rails.


Ruby is an incredibly flexible language.

Elixir & Phoenix are great, but I'm quite confident whatever you're doing in Elixir/Phoenix - you could, with minimal effort, also do in Rails.

The reason to use Elixir/Phoenix is not because of pattern matching - it's because of the BEAM VM.

If you don't need it or want it - you're probably better off with Rails.


ooh been wondering this for ages actually. (I've played with Rails a bunch, but never E/P)

Why do you say you'd prob be better off with rails?


THE point of using Phoenix is to run on the BEAM.

If you don't want or need that, there's really no reason to use Elixir/Phoenix.

Ruby on Rails is much more widely used - so you're going to be able to find more community support & libraries & integrations than you will with Phoenix.

Why tie your hands behind your back if you don't need the BEAM?


What issues do you have with BEAM?

> I switched to Elixir and Phoenix this year, and Elixir is a joy to write in. It makes me so happy to write less business logic by leveraging their pattern matching.

Pattern matching does streamline a lot of logic, which is a big reason Ruby added it in version 2.7, three years ago. But, while, there are reasons I can see that one might prefer Elixir/Phoenix today, “you can write less logic because pattern matching is available in Elixir” isn’t particularly one of them.


It's not the same as Elixir at all. Elixir takes it further and allows method overloading, so you can pattern match methods with the correct arguments. I would suggest giving Elixir a try if you haven't yet!

You really should use the tech you like if you are serious about your product, if you see yourself as a craftsman, if you feel like you want to make something good, because as a founder/maintainer you are going to spend a huge lot of time working on it, tweaking it, sweating about it, and also enjoying it, so it better be something you trust and like.

If you are just there for the money however (VCs, HN, github stars, ...), trying to make an MVP and run, just go with the shiny and trendy.


Legal | privacy