4 ms·
You can pretty much substitute "Django" for any case where Rails is not appropriate. That is, they go hand in hand and both have similar uses. But there are ve
by silviogutierrez 6y ago
You can pretty much substitute "Django" for any case where Rails is not appropriate. That is, they go hand in hand and both have similar uses.
But there are very few cases. Fewer I'd say than this article lists. Low level programming, and yes perhaps event-based systems. [1]
I find people just like rewriting their own batteries and conventions. Fun, no doubt, and a good learning experience.
I challenge any microframework / library user to surpass the productivity of a mature framework like Rails or Django. I argue nothing comes close.
And I don't mean "for the 5 second MVP". Perhaps your app won't need some of the batteries, but your app will need logging. It will need database migrations. It will need forms and inputs. It will need media uploads. It will need to send email. And so on.
Future proofing too much is an issue in the industry. YAGNI after all. But this is the opposite case. I deem it: YAEGNI. You are eventually going to need it.
[1] Django 3.1, just released yesterday, begins treating async as a first class citizen. I was initially opposed to this, given 99% of the time you don't need async. But I suppose it's nice to have and drop down to.
- darkhorse13 6y agoIt is very difficult to explain to someone who has not used Django/Rails just how productive they are, especially Node.js devs. I started off with Django, so when I moved to Express for a project, I was immediately slapped with the reality that I needed to write my own forms and admin site. These are some of the things that you simply do not have to worry about with the aforementioned batteries included approach of Django/Rails.
- silviogutierrez 6y agoExactly. Every NodeJS tutorial starts with: "look how easy it is to write a server and listen on port 3000". Yea it's easy. But why are you writing a server? That should be the least of your concerns.
- doteka 6y agoWell, I need to write a server if my requirements don’t fit a server side rendered application and/or my usecase does not fit the absolutely anemic performance of Rails, which also applies when using it only for an API (it’s not Ruby’s fault btw). The classic response is “zomg premature optimization bad”, but some of us work on more complex applications than simple database CRUD.