Ask HN: Is Ruby on Rails still worth it? |
Ask HN: Is Ruby on Rails still worth it? |
And you'll save yourself the tears of migrating later.
Rails is probably fine and fast and good for small projects. It is probably not good for professional large projects.
UserOne: Don't use [insert language] and [insert framework] because [bad design flaw] and doesn't scale.
UserTwo: But [BigCo with millions of users].
Basically, I think Rails is inferior because it encourages bad practices, has no distinct advantages over Python, Python seems to have a larger talent pool, and Python has uses outside of Rails that make it a better choice for a one-language shop (i.e., your tools can be in the same language as your code and can utilize that + Python is everywhere, Ruby has extra devops costs incurred).
I won't say you can't be successful with Ruby. That'd be silly. But do I think there is a reason to choose Rails over Python if you can start fresh? Nope.
Function composition and partial function application is totally supported in Ruby so not sure what your complaint is there. Here is one rather forced example: http://genua.github.io/ruby/2015/03/17/ruby-function-composi...
I don’t know anything about Elm and Purescript but I’ll look into them. They aren’t hugely popular (as far as I know, feel free to correct me) so I’m not sure that’s a major win for portable skills versus Ruby engineers learning Scala or Python. If you don’t get too wild with the symbols, Scala can actually look quite familiar to Ruby programmers. Twitter had people use a subset of Scala when they transitioned many services from Ruby to Scala so that it would be an extra easy transition.
JavaScript has come a long way though and is certainly the lingua franca of the Internet.
pp_proc = self.method("pretty_print_me").to_proc
Exactly :(Even assuming you implemented it their way, their code isn't very concise. In the snippet you pasted, "self.method" could be replaced with "method" for example without changing anything
- Out of the box, Rails has close to unbeatable developer ergonomics, tooling, stability, and ease of use
- Lots of high quality, large companies use it (GitHub, Shopify, Airbnb, Square, Twitch) and have by now figured out how to scale it, often sharing and open sourcing their efforts, e.g. https://github.com/Shopify/identity_cache
- If your product front end is simple, Turbolinks can be an excellent choice (find me a faster, more bug free product than Basecamp)
- If you prefer to use a more modern JavaScript solution on the front end like Ember or React, Rails API is a perfect fit
- The Ruby ecosystem and community are both very high quality
I wonder if or when Rails will settle down and stop changing everything between major releases causing all documentation to be out of date, gems to break, developer habits to break, etc. Not to mention all of the related tooling like Bundler which seems to spit out new and uninteresting warnings and errors every time I update it.
It would be great to be able to write an application using a framework and not have to constantly change the application just to get long-term updates to the framework like bug fixes, security patches, compatibility with new versions of Ruby, etc.
Basically Rails-LTS but not from a 3rd-party (and embraced by the ecosystem).
Rails is quite stable.
If I needed to spin up a new project and get to work right away on something I'd go with rails no question. I've yet to find another language/framework combo that works as well as a Ruby & Rails stack (Laravel and Django are good alternatives too, I'm just more experienced with Ruby). Don't think too far ahead. Premature optimization or thinking about future scaling issues if starting a new project is time that could be spent better. Rails isn't going anywhere anytime soon.
Pros:
- easy enough to find libraries for most things I wanna do
- community likes testing, as do I
- community seems to focus on business & web implementations, so good for those use cases
- lots of questions for which I want answers already answered
- package management
- deployment to PaaS/Herorku-ish platforms pretty easy for smaller teams
- here in San Francisco, there are lots of job opportunities for Rails developers
- I like Ruby, even though I am less excited about OOP these days
Cons:
- Rails is magical & opinionated, and that always annoys me
- Figuring out where some method is coming from in a Rails object is often a pain
- In Elixir I almost never need a debugger, but in Ruby I almost always do
- loading Rails apps can get really slow, and learning to wait for software to boot isn't a skill I like to develop
- I feel more pressure "to do it" right when the time "to do it right" simply doesn't exist for reasons, because trying to come back and refactor gnarly Ruby code is just harder than it is in a compiled language
- Ruby has to be installed on the system to which an app is deployed, and needing to think about how to pre-install Ruby or how long a Ruby install takes is a mild pain (stand alone Go binaries or Elixir releases are pretty sweet)
Core team takes care of many things like webpack, ActiveStorage, etc for you, many thanks to folks. I've been doing Ruby on Rails since 0.19 as far as I remember and it's been great ever since.
Not that hyped anymore but who cares about hype when you get your shit done. Also as you grow, you appreciate talent availability when it comes to Ruby/Rails.
Long time rails developer, but if you can green-light a project I'd highly recommend node all the way. I've found it much easier to comprehend a pure javascript stack (or even better an all-Typescript stack) due to substantially less cognitive overhead, find other people to work with (very important as your project scales), and the fact I can deploy node with a serverless implementation on Azure, GCP, and AWS makes it a home run when it comes to security and devops costs (and the need for devops in general).
While rails has a bunch of great features, those features (rightfully) have been copied elsewhere, e.g. Active Record, which has a fantastic javascript implementation - TypeORM.
Finally, when it comes to interface development, nothing in rails will get you as far as React these days, especially as the web moves mobile, and into AR/VR, which IMO present the next challenges of interface development. And like rails, nearly every question related to React/Node is answered on Stack Overflow or has a well-documented library to solve that use case.
EDIT: On the other hand, I wouldn't choose Rails for a project where the main concern is performance/scalability
Now that .NET with .NET Core is officially a first-class citizen on Linux, there really no good reason not to embrace it.
"I just started using Ruby and omg it's out-of-box everything, rapid development, monkeypatching makes everything super easy, it's like second Jesus coming."
and the second category is this:
"I am working with RoR for years, maintaining/migrating anything is super painful, because everyone is monkeypatching everything, so you cant safely touch anything."
Choose wisely.
Most Rails applications I see have minimal monkeypatching and I can’t remember the last time I had to debug an issue related to one. On the contrary, monkeypatching is most often used to fix issues in libraries that would otherwise require forking or pushing changes upstream to the project to fix. For example, Rails 3.2 is missing a few time duration methods from Rails 4 which Ruby 2.4 relies on so you need to add those via monkeypatch to run Ruby 2.4 with the legacy Rails version if you can’t upgrade everything at once.
In summary: If you need to get shit done fast, it's a good bet.
It isn't as hyped as it used to be 5 or so years ago, and if hype cycles are relevant to you, you likely already know your answer.
As to whether you are asking whether learning it would make you unemployable, by no means. RoR is still going strong, at least in my country.
Smart, experienced people can of course identify where the framework leaves off and build within the confines of Rails to get things done. But I wouldn't say that Rails makes it particularly easy to, for example, use a object-oriented approach the the model layer. ActiveRecord, with its lovely but dangerous APIs, really wants to be your everything class. Domain namespacing, while doable (you can do anything in Ruby), isn't particularly intuitive compared to other parts of the framework.
None of this is to say that Rails is a bad tool and I'm grateful for what it's provided (thank you OSS maintainers). It does, however, trade medium-term maintainability for the up-front productivity it offers, which could be totally fine, but for me doesn't feel like a great trade.
You are right that it's far from perfect and it really is a "be everything" ORM.
I've recently started to learn vue.js and it's making JavaScript a pleasure to use alongside rails. I think my future projects will be vue + rails by default
If I was building a product focused stack, then I would simply do React+ Typescript. Why bother bringing in two different languages for front end and backend ?
Typescript is pretty awesome in itself.
As stated, it depends on your context and your goals, but if speed matters to you, it’s hard to say rails is not a top solution.
Knowing Python and Django (which I do) does not afford you any ability do to those things.
I don’t know of a better way to get an MVP project up quickly. Rails at scale is probably a touch harder to manage, but that’s by no means impossible.
With Rails 5, it's good for a simple API backend as well. And there are a ton of gems that can alleviate a lot of pain.
It's when something non trivial where Rails may not be a good choice.
If you are thinking about learning Rails now, probably not.
Yes Rails is great for MVPs, but then so are a lot of other things, like Meteor.
But if you have a smart team and a little bit of time for ramping up then I’d suggest Elixir+Phoenix or Node tbh.
Rails is good at what it’s designed to be - a one stop shop for fast to develop, kinda dirty, framework magic, webdev.
And there is nothing wrong with that.
But that sort of reinforces the point I was making tbh. Want something that makes all those choice for you? Right or wrong? Rails.
Nothing wrong with that as such, but it will cause issues eventually.
If you'd take a look at https://news.ycombinator.com/newsguidelines.html and https://news.ycombinator.com/newswelcome.html and follow the spirit of the site, we'd appreciate it.
What framework do you use on node.js?
My experience with nodejs has been pretty poor. I'll give some examples;
* The language and runtime is constantly updating - there is no such thing as stability
* Even npm couldn't produce deterministic installs until this year
* npm dependency hell
* there are lots of ways to do any task, so there is much fragmentation with advice / community
* the repls in node suck compared to pry
* I can't find a good opinionated framework - so everyone lays out each application differently, with different standards etc. That means you end up spending a ridiculous amount of time configuring everything.
* most apps i've needed to make don't actually benefit from being a SPA. It's a cargo cult thing.
* javascript as a language sucks!
To answer your points:
* You're right it hasn't been - but it is now with LTS releases of Node.
* I agree, this is why I use yarn.
* Yarn has solved any dependency issues I've witnessed.
* While this is true, every solution boils down to simple objects or simple functions. New solutions tend to be simpler than the status quo (e.g. redux)
* While debugging isn't as easy - all my back-end code boils down to simple functions which just need a simple test (I use mocha which is a lot like RSpec). Also Typescript and TSLint enforce types and code styling so I don't really need the pry-style debugging.
* The only configuration I feel you need is Typescript and TSLint which will enforce a very specific way of styling code, file naming conventions and so much more. From there my individual functions representing GraphQL mutations and queries on the back-end or React components on the front-end are small, modular, and encapsulated in a folder to make for an easy `cp -vr`.
* You're only talking about web. React Native/VR are extremely compelling reasons to expand beyond just the browser. Plus I feel separation of front/back-end makes for faster product development on bigger teams.
* Haha yes, though ES2015 made it a lot better and Typescript has made it complete IMO. Microsoft and Google have both made substantial investments into the language, with the former making it as big of a center-point as C#. That's saying something. You can code Typescript code on a cheaper and faster Windows machine, ruby? much more difficult.
Rails's out-of-the-box React integration [1] should get you _exactly_ as far as React these days.
I don't know if you are familiar with any programming languages at all, but many skills translate cross-language...the paradigms are the same. Particularly with Ruby & Python which are very similar languages. They're good at the same things, by and large.
Taking your Ruby skills over to Python will be a matter of "google: [python thing] in ruby".
For a specific example, Python has a unique thing called "list comprehensions". Using that google string you can get some great ideas about replicating that functionality in Ruby.
Anyway, on a grander scale, picking up new languages is the easy part of programming--even when they're not so similar.
Best of luck!
Rails 5 was the easiest upgrade yet. ActionCable was the big change, but it’s an addition to Rails, not a replacement for some existing tech. As a result, it doesn’t disturb much existing code.
Everything would have worked fine if we didn't keep things up to date, but just about everything in the software world needs to be continuously updated due to security updates/patches, etc.