12
32 Comments

Rails, Django vs NodeJS, GO. What Backend Framework to Use?

submitted this link to Icon for group Developers
Developers
on December 17, 2020
  1. 16

    Here's my order of operations for these types of questions:

    1. If you already know a way to effectively and efficiently get the job done, do it that way.
    2. If you know a language that has a battle tested way to do the job effectively and efficiently, use that way.
    3. If neither apply, consider no-code.
    4. If none of the above apply, spend a couple hours looking at the job market and pick something people are hiring junior devs for, so that your bootstrapped project could be an inroad into a future career if things don't take off as planned. And if things do take off as planned, you know you'll be able to find a developer to take over if necessary.

    In general, I try to avoid the pitfals of using something new, or trendy. This is difficult to spot if you're new. Feel free to ask others. But generally, I like the suggestions of Django, and Rails I'm seeing in the comments for newer developers that are looking for code based solutions for getting an MVP up quickly.

    Personally, it's almost always either Rails or Sinatra for me, but that mostly just means that I can write Ruby faster and more effectively than I can write anything else.

    1. 1

      100% agree with this one as that's what my co-founders said in the video.

      I also like the explanation that Django and Rails have the most common building blocks already built so you don't spend time reinventing the wheel.

      It's like to choose if you want to build a car from scratch or you will already use some ready-mate wheels and base.

  2. 9

    Short Answer: The one that you are the most comfortable with. Next question, please. 🎤

  3. 8

    Rails all the way for me

    1. 3

      Rails has some flaws in many contexts, but man, for rapid prototyping web apps there isn't much better. It was born by indie bootstrappers for indie bootstrappers.

      1. 1

        I think django very much fits into the same category

        1. 1

          I'm not an expert really, but wasn't Django initially a "Rails, but in Python" sort of project?

          1. 1

            I'm not sure either but that would make a lot of sense!

  4. 7

    Django is just amazing. Everything just works, and if you need a backoffice, you have the django admin which gives this out of the box.

    I personally prefer Django's philosophy to Rails.

    1. 3

      I'm fairly familiar with rails, but can you expand on the philosophical difference? Rails is kinda "do it our way and you can get something off the ground fast", which is a great modality for an indie. There are scalability pains, but quick and dirty is for sure the way to go for your MVP. Worry about making it nice when (IF) it's paying you, haha.

      But I haven't done anything with Django. What's their MO and how is it working for you?

      1. 1

        I'm not the person you are replying to, but I can give my 2 cents. I have used both. They are both "do it our way and you can get something off the ground fast", as you say, but -in my experience- in Django, if you want you can rely less on the "magic" and go more "low level", whereas in Rails the "magic wall" is more impenetrable. The flip side of the coin, is that in Django you don't quite have just "one way" of doing things, so for example if you are working on an app written by someone else, there are more unknowns.

        Maybe what I said is partially a reflection of the fact that I have more experience with Python compared to Ruby, so it's easier for me to "break free" and going "off the rails" when I'm using Django, but I think there is also bit of a difference in the way the frameworks are designed.

        1. 2

          Oh man, the "rails magic" is really hard to break through for a certain kind of developer (i.e. me). "So this worked.... and I have no idea how." is the kind of thing that will keep me up at night. I think I might be a misplaced python developer because I'm much happier working with one obvious way of doing things. But I know rails well enough at this point to understand the deep magic so there's not much incentive for me to learn a language like python with so much overlap with ruby.

        2. 1

          Having worked with both, I actually find the opposite true. To me Ruby is more expressive, and it's really easy to do metaprogramming and go "off the rails". Python keeps things simple and stupid. Probably more verbose, but you don't get all the rails magic.

          1. 1

            Yes but that’s because you’re thinking more about the language whereas I’m thinking primarily about the framework. Actually Django is sometimes described as “non Pythonic” because there are often many ways to achieve the same results (which is against the Python principle "There should be one- and preferably only one -obvious way to do it."). On the other hand, Rails really contributed to popularise the principle “convention over configuration” and you can feel that when you use it.

  5. 3

    Absolutely Rails. But I believe anyone should go with what suits their use case best, and what you're most comfortable with.

  6. 3

    Loved doing the Weekly format but this makes more sense for now! 🐒

  7. 2

    Just use whatever framework you're comfortable. Users/Customers don't really care about it.

    I'm comfortable with Rails so I'll use it. Even there's a lot of blog/comments about how bad it is.

    1. 1

      Yes! There are blog bad blog posts about every framework out there. It's really about what you are comfortable with as you said.

  8. 2

    In my eyes, frameworks are an interesting detail that I try to avoid using as long as possible. Some will recognize that I'm referring to uncle bob's views (clean architecture).

    Many times I've started with a framework to only realize at some point that my traffic pattern was really spikey and that using a different compute type (django, rails etc. typically run on a traditional compute type) whereas my traffic pattern was great for serverless functions (aws lambda, azure functions etc.). Other times I did end up using a framework.
    These days I always start with a simple cli app and decide as late as possible how I want to show my data/ solution to a user.

    Everything is a trade-off. Just get started with what you know best/ fits your style the most. At the startup stage you shouldn't be worried about frameworks, rather worry about making it work.

    Nonetheless, if you do have some time I would really recommend serverless for many usecases as you eliminate nearly all the devops, scaling if your app works etc. You don't want to spend time on these things as for your customer it has 0 value. Yes, often you spend a little bit more time on glueing things together but in my eyes it's well worth the effort :)

  9. 2

    I've already seen a lot of people say that it doesn't matter. And for the most part they are right. Usually, go for whatever you already know, but that's boring. I would say that go for what feels right. For example, I know more JS/TS and Java than Python, but Python just feels right to me. In DHH's words, it fits my brain like a glove.

  10. 2

    Rails, Django, NoCode, voodoo, do simply what works for you!

  11. 2

    I'll have to watch here in a bit, but Django or Flask for me. I've begun to fall in love with Django-CMS, and I'll actually love it once I figure out it's insides properly.

  12. 1

    100% Rails. It 's now almost a low-code solution.
    As DHH (Rails' creator) says , Rails is the one person framework from Hello World to IPO.

  13. 1

    It is all about the best tool for the job and the one you know well/have most experience in.

    This will determine your ultimate time-to-value, the sooner you ship it, the sooner it will start generating value to your customers/users.

    Personally, for side projects I use symfony and have been using it since its early days (1.x)

    Spotify, among others, is built with symfony: https://www.youtube.com/watch?v=CFQaVDR96x4

    1. 1

      Also, Laravel, Drupal and others use symfony components: https://symfony.com/projects

  14. 1

    Been love with Django for last 10 years. Will continue...

  15. 1

    NodeJS is my fav ❤️

  16. 1

    I can only speak for Django and Node but here are my thoughts:
    If you need something quick, go for Django since it comes with a ton of things out of the box.
    If you're looking to hire / off load, go for Node since JS devs are cheaper and more common that Python or Go.

    Personally I've worked professionally with both and I'm going with Node only because I want a typed language (typescript vs python) and to use some TS graphql libraries.

  17. 1

    As a non-coder but fairly technical founder, I look at it more from a business perspective and am fairly technology agnostic.

    I try to look at market opportunity first, and then make decisions about how I think I want whatever "it" is to be packaged and delivered. Then, I go look for resources that I think have the highest probability of successfully executing my vision.

    In the case of our current project, I decided my biggest target market would be Android users since it's got the lion's share of the worldwide market. I wanted to reduce the cost of engineering and development, so I decided to forego building either a web application or an iOS app until we get traction and start to achieve some revenue growth.

    The last major project we did was PHP with some limited javascript and Node.js because that's what that particular crew of developers were comfortable with and liked to use. It was a web application and we were supposed to get both an Android app and an iOS app but that didn't work out.

  18. 1

    I would go with whatever people can help you with - my buddie knows Django so I chose that (I also don't really care for the syntax of other languages as well )

  19. 1

    This comment was deleted 3 years ago.

  20. 1

    This comment was deleted 5 years ago.

    1. 2

      Absolutely! This was a huge part of my thinking when I was building Nodewood. I've run into so many issues where you have a validation or calculation that has to be coded separately in the UI for presentation and on the back-end for your business logic, and then requirements change and only one side is updated, or a subtle bug is introduced into only one side, etc. Being able to use the same code and libraries throughout the whole app is such a time saver, both when you're building the initial app and when you're maintaining it over time.

      Plus, modern JavaScript is a lot of fun to write in. You can do some very clean functional stuff and async/await has essentially completely gotten rid of "callback hell". Oh, and developers for it are everywhere, so if your project takes off, hiring doesn't have to jump over the hurdle of "finding a good candidate that knows all the different languages in your stack".

Trending on Indie Hackers
Your SaaS Isn’t Failing — Your Copy Is. User Avatar 61 comments The Future of Automation: Why Agents + Frontend Matter More Than Workflow Automation User Avatar 21 comments No Install, No Cost, Just Code User Avatar 20 comments Build AI Agents & SaaS Apps Visually : Powered by Simplita ai User Avatar 17 comments AI Turned My $0 Idea into $10K/Month in 45 Days – No Code, Just This One Trick User Avatar 13 comments For years, I was terrible at estimating projects. Here’s what changed. User Avatar 6 comments