No, use Phoenix!
Use Rails
11–20 of 88 posts
Re: Use Rails
#12> (Really, though, it doesn't matter. Your software stack is almost certainly not going to decide the life or death of your business.)
This is the part that's going to sting.
I suspect, given the general admiration for Paul Graham on YC, many people subscribe (if only unconsciously, and at least to some degree) to the idea that using techno X (where X would be Common Lisp in the case of PG, but everyone will insert their own pet tech here) can _by itself_ make your startup successful.
Whereas the sad truth is that choosing the wrong tech can definitely _kill_ your shop, but choosing the "right" one will not ensure its survival...
Re: Use Rails
#13I see the arguments and they resonate with me (e.g. boring tech). However, rails has some pretty unique footguns compared to other frameworks [^1]. I would vastly prefer some other framework that isn't built on a meta-programming language that essentially has a narrow niche (e.g. django).
Further, it's 2024, building on top of a language / framework without proper compile-time tooling (e.g. static types, capacity for an LSP) is a terrible idea.
Re: Use Rails
#14I 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…
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.
[deleted]
Re: Use Rails
#15I 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…
What is your ideal Django stack (from front-end, to backend, APIs, database, hosting, etc), using well-supported, solid tech?
Re: Use Rails
#16I 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…
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)
Re: Use Rails
#17> (Really, though, it doesn't matter. Your software stack is almost certainly not going to decide the life or death of your business.) This is the part that's going to sting. I suspect, given the general admiration for Paul Graham on YC, many people subscribe (if only unconsciously, and at least to some degree) to the idea that using techno X (where X would be Common Lisp in the case of PG, but everyone will insert t…
[dead]
Re: Use Rails
#18Rails 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/ruby/comments/105sdax/whats_the_lat... for a discussion.
2. The lack of static typing meant far less IDE support. Fewer documentation tooltips, less autocompletion, etc.
3. I used to do a lot of Rails consulting. And whenever I had to drop into a codebase with more than 50,000 lines or 5 active developers, it was generally a painful slog. Too many weird Rails plugins that stopped being maintained, too much magic, too many nasty surprises while refactoring.
Basically, smaller Rails projects were an absolute delight. Larger Rails projects, though, tended to feel more like a swamp. Tools like https://activeadmin.info/ could tip the balance where applicable.
I still think that small Rails projects are fantastic, and I don't think anything since has remotely matched Rails' productivity within that niche. There's just too much mature tooling, and much of it works together seamlessly. But not too many projects want classic multi-page apps right now, and small projects often grow up to be big projects.
Re: Use Rails
#19> (Really, though, it doesn't matter. Your software stack is almost certainly not going to decide the life or death of your business.) This is the part that's going to sting. I suspect, given the general admiration for Paul Graham on YC, many people subscribe (if only unconsciously, and at least to some degree) to the idea that using techno X (where X would be Common Lisp in the case of PG, but everyone will insert t…
The key here though is that choosing a bleeding edge tech is more likely to be a problem because it's fairly untested.
I can tell you what ALL the problems with rails are. For the most part they won't even start to bite you until you hit scaling problems. By the time you hit scaling problems with Rails you can probably afford to pay engineers to solve the scaling problems, and/or port off at that point.
I love sveltekit and use it a bunch for my own personal projects, but it's too immature to recommend to others. Instead I mostly point them at Next.js if they want a javascript stack and Rails if they don't. I have created and maintained apps based on both platforms for 6 and 16 years respectively and know exactly what I'm recommending to people.
Re: Use Rails
#20When Rails became popular I started using it on basic web site catalog / e-commerce projects in 2007. It was very difficult to deploy. Thanks to Heroku and other pioneering companies that is different today. However, at the time I left behind PHP and LAMP stack (Linux, Apache, MySQL, PHP) which provided very simple and cheap deployment. Years later I regret that transition from using LAMP to Rails. I wish I had just stayed using PHP, it would have saved a lot of time and difficulty.
Question for people here on HN: Could a similar position to the blog post be taken in 2024, ie "Just use PHP (and LAMP)"?