Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The lack of batteries-included frameworks don't mean it's not impossible. But it might means 2 things:

- Production codebase is really hard to extract into reuseable libraries.

- There're too many standards on the same things.

Rails is a success for one of reasons, is, DHH is the main leader, no "competitive standards".



Rails is special in that, arguably, Ruby wasn't otherwise a massively adopted language, at least not on the scale of others. RoR drove Ruby adoption in a very unique way.

PHP, Python, Java are massively adopted languages where you can name a leading batteries-included framework or two. There were different reasons for converging into a leading framework (ex: the case of Spring may be very different to that of Django), but that convergence happened.

JS/TS? No real convergence 14 years after the introduction and massive adoption of Node.js as a backend runtime. Why not? Beats me.


For me - it's massive churn due to newer versions generally being incompatible with the earlier ones, and being pushed out fast.

Whenever I do start using any kind of JS framework and go through the process of researching best practices, ecosystem of related packages, etc., in a year or two that is largely irrelevant. Thus, the next time I need to start a JS project, it doesn't matter to me whether I'll pick the same or a different framework du jour, I will have approximately the same amount of (re)learning to do.

Compare that with Django, where little changes in years (one data point, I recently upgraded a legacy SaaS from Python2 and Django 1 to Python3 and Django 4 and it was a few days' work). This means every time I work with Django, I learn more about the ecosystem and it's easier for me to just start new projects in it as well.


Is it the culture? For years the people (Microsoft, Apple) who would have naturally pushed standard ways of doing things in javascript front end, actively neglected it. So lots of much smaller entities had to invent their own ways of doing things. That culture persists on the back end.


I think it might partly be due to the culture around how large or small libraries tend to be. Node grew up with NPM, and with it came the culture of building things from tiny parts. Most libraries have usually had a single focus, and even a lot of the batteries-included options today still depend on other major libraries instead of reinventing the wheel. I think that culture sorta naturally leads to XKCD-style “15 competing standards”.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: