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

Use Rails

jmduke.com

Post reply on HN
Print view View original

21–30 of 88 posts

Re: Use Rails

#21

Post by hobotime »

mariocesar wrote: post #3

I strongly agree with the article's points. While I haven't used Rails, I'm a Django developer and have never built something with Rails; I like the benefits of sticking with full-stack frameworks. Rails is a solid choice, but Django, especially when combined with htmx, also enables quick and robust application development. It's refreshing to read about someone who prefers a straightforward approach (using boring tec…

The article said you should stick with what you know and are productive with. For you, the article recommends Django as your first choice.

Re: Use Rails

#22

Post by jupp0r »

Rails is great, until it's not. Many of whe successful companies built on Rails were started in a different world without lots of external APIs (OpenAI anyone?) to integrate with, user expectations around central identity, authz and other things you'll want to talk to in order to serve a request.

In 2024, I wouldn't start a company or project based on a language and framework that doesn't have a great concurrency story (don't tell me how great Fibers are please). There are plenty of alternatives (nextJS, Remix, etc).

On top of that, the prevalence of OO antipatterns in the Ruby community (global mutable state, prevalence of inheritance over composition, complete disregard of SOLID) will eat up any initial productivity gains pretty fast.

Re: Use Rails

#23

Post by axelthegerman »

ekidd wrote: post #18

Rails is absolutely fantastic for projects below 10,000 lines with 1 or 2 contributors, especially if you want a classic forms-based UI. And you can get a huge amount done under those constraints in Rails. But as of couple of years ago, Rails came with a number of drawbacks: 1. There was no really viable system of static typing that a significant number of people were enthusiastic about. See https://www.reddit.com/r/…

Static typing vs not has clear pros and cons. I do appreciate that JS/TS offers you a choice but I personally prefer Ruby the way it is.

Your other comments are basically: - ruby/rails has a great 3P package system - oh and yes you can choose "bad" ones - ruby/rails let's you quickly write great code - oh and yes you can just as quickly write "bad" code

Re: Use Rails

#24

Post by axelthegerman »

W3cUYxYwmXb5c wrote: post #16
graypegg wrote: post #10

Earlier quoted context omitted.

I would totally expand "Rails" to "Django or Rails or Laravel or any other well-maintained mature full-stack web framework in the language you are the most comfortable with". There's a lot of awesome options for boring technology! Even javascript has next.js which is pretty boring at this point, even if it is missing some things.

AdonisJS is also really great, very much inspired by Laravel (which was inspired by Rails)

First time hearing of that, not sure it passes the "battle tested" sniff test here.

No offense, might be a great framework but the gist of the blog post is A) what you know or B) Rails (if you don't know what to choose)

Re: Use Rails

#25

Post by jherdman »

W3cUYxYwmXb5c wrote: post #7

These days I prefer using a NodeJS framework like AdonisJS over Ruby on Rails, but Rails had an important role in getting us here.

What are you using for your ORM? Last I checked Prisma is the new hotness, but it's testing story is frankly unacceptable (i.e. manual DB purges, https://www.prisma.io/docs/orm/prisma-client/testing/integra...).

Re: Use Rails

#28

Post by axelthegerman »

drumpkid wrote: post #4

For most web applications rails is fair enough, a boring technology (as well other boring stacks). Although it got my attention that rails could work really well on production with SQLite (even more boring technology), for small sites.

Definitely would love to see more SQLite adoption, but hosting isn't as straightforward as it should be depending on your hosting choice (e.g. Heroku)

Also had slight issues with concurrent writes on SQLite though potentially things like a SQLite per user would be neat especially when it comes to backup/recovery

Re: Use Rails

#29

Post by quest88 »

ekidd wrote: post #18

Rails is absolutely fantastic for projects below 10,000 lines with 1 or 2 contributors, especially if you want a classic forms-based UI. And you can get a huge amount done under those constraints in Rails. But as of couple of years ago, Rails came with a number of drawbacks: 1. There was no really viable system of static typing that a significant number of people were enthusiastic about. See https://www.reddit.com/r/…

I suspect you'd find the same thing if you were a python or php consultant diving into python or php projects.

Re: Use Rails

#30

Post by rco8786 »

jupp0r wrote: post #22

Rails is great, until it's not. Many of whe successful companies built on Rails were started in a different world without lots of external APIs (OpenAI anyone?) to integrate with, user expectations around central identity, authz and other things you'll want to talk to in order to serve a request. In 2024, I wouldn't start a company or project based on a language and framework that doesn't have a great concurrency sto…

My company (large, well known tech co) actively instructs engineers to not use concurrency features, in a language that is known for having "great concurrency", unless they have a really, really good reason to.

The vast, vast majority of workloads, especially at small startups, do not need a concurrency story outside of running N processes. Concurrency often gets in the way more than it helps unless you're actively trying to optimize something.

My opinion, of course.

Post reply on HN