3 ms·

Frameworks like Rails come with a constant upgrade overhead cost. If you're a solo developer, or even a small (<5) team, that overhead is likely to dominate you

Frameworks like Rails come with a constant upgrade overhead cost. If you're a solo developer, or even a small (<5) team, that overhead is likely to dominate your development time. Also, the main benefit of the framework (keeping a sane structure while multiple developers' are making code additions) isn't any better than just ad-hoc sharing standards and practices amongst the team. So, it's better to use a simple nodejs server or even plain old php pages. Once you get past a certain number of developers, the constant overhead is something that still needs to be dealt with, but relative to the human-hours of your entire team, it's much smaller. Also, the team is no longer able to ad-hoc share architectural goals, and so having a framework in place that enforces them scales much better. Starting with a framework is tempting because everyone thinks that they'll get big. But what if you don't? Maybe it's better to have a little passive income than crash and burn. On the other hand, if you do get big, the tradeoff is that you'll need to rewrite with a framework. That's another opportunity to crash and burn, so it's debatable which is better. Personally I think that Twitter has demonstrated how to do the "start dead-simple and rewrite as the team grows" method.

epalm 5y ago
> Frameworks like Rails come with a constant upgrade overhead cost. If you're a solo developer, or even a small (<5) team, that overhead is likely to dominate your development time. Many years ago I used to write projects with Python/Django. The Django project releases 3-year LTS versions with 3-month overlap. LTS versions are supposed to ease the constant upgrade overhead, and hitting a 3 month window every 3 years doesn't seem too bad, especially when they also release documentation specifically guiding you from one LTS version to the next. Does Ruby/Rails not do this?
- phendrenad2 5y ago
  3 years isn't all that long. There's still Fortran and Cobol in the wild from 40 years ago. Most people in silicon valley will have worked on a 20 or even 30 year old codebase at some point. And why do I need to upgrade Django? Did the fundamental principle of MVC change? No, the developers of Django just didn't like some Python 3.8 syntax and decided to rip it out and replace it with some shiny new thing in 3.9. They stopped backporting security fixes to the old Django version, the one with the totally-gross Python 3.8 syntax. So now, to use the latest Django version, you need to upgrade Python minor version also. Easily avoided if you rolled your own framework. (Of course, sometimes you don't have a choice, because maybe Python deprecated some perfectly-good syntax between 3.8 and 3.9 because the devs didn't like it anymore). Another thing is, that's every 3 years for Django. If you start stacking other 3rd party dependencies on top of Django (even something as simple as a MongoDB ORM), you'll have a separate, secondary upgrade schedule for that library.

epalm 5y ago

> Frameworks like Rails come with a constant upgrade overhead cost. If you're a solo developer, or even a small (<5) team, that overhead is likely to dominate your development time. Many years ago I used to write projects with Python/Django. The Django project releases 3-year LTS versions with 3-month overlap. LTS versions are supposed to ease the constant upgrade overhead, and hitting a 3 month window every 3 years doesn't seem too bad, especially when they also release documentation specifically guiding you from one LTS version to the next. Does Ruby/Rails not do this?

phendrenad2 5y ago
3 years isn't all that long. There's still Fortran and Cobol in the wild from 40 years ago. Most people in silicon valley will have worked on a 20 or even 30 year old codebase at some point. And why do I need to upgrade Django? Did the fundamental principle of MVC change? No, the developers of Django just didn't like some Python 3.8 syntax and decided to rip it out and replace it with some shiny new thing in 3.9. They stopped backporting security fixes to the old Django version, the one with the totally-gross Python 3.8 syntax. So now, to use the latest Django version, you need to upgrade Python minor version also. Easily avoided if you rolled your own framework. (Of course, sometimes you don't have a choice, because maybe Python deprecated some perfectly-good syntax between 3.8 and 3.9 because the devs didn't like it anymore). Another thing is, that's every 3 years for Django. If you start stacking other 3rd party dependencies on top of Django (even something as simple as a MongoDB ORM), you'll have a separate, secondary upgrade schedule for that library.