...But why none of them are getting a real traction while node.js is popular for many years now? Does people in the JS world usually prefer picking and connecting tools themselves? While I admit this philosophy can have benefits in some cases, it has true and obvious downsides too IMO.
I mean, in Python, you are able to chose your philosophy by picking up Django (all batteries included) or Flask (pick and connect tools of your choice). Both framework are kind of equally popular.
But I have the feeling if you decide to pick JS/TS language (a good reason could be: you build a SPA and want to use only same language for back and front), the only viable option is the "pick and connect tools of your choice" philosophy.
I'm wondering why this is NOT a problem for most of developers I talk to. I think some of them has never deal with full featured framework like Django and don't get all the benefits. But it can't be the only explanation.
- Rails controllers and plug-in architecture come from MERB (absorbed for Rails 3) https://en.m.wikipedia.org/wiki/Merb
- ERB templates, the default for Rails view layer, have been in the Ruby standard library since at least 2007 (which is as far back as the docs go)
- Rails adopted Rack web server interface and the first versions of the asset pipeline in 2.3, neither of those were written by Rails community.
Rails 1 was released in 2004, almost 10 years after the release of Ruby in 1995. Node was released in 2009 - so maybe one of the frameworks mentioned here —- Next.js /Blitzjs, Nest, Meteor, Redwood —- could be a Rails 1.0 or 2.0. Give them another 5 years or so to mature and then you’ll have your Rails.
Personally, I’ve been trying out Blitz and it seems pretty good, feels like a Rails 2ish kind of thing, where you can do a lot of stuff by following convention but can’t “plug in” as deeply as with Rails 3+.
Also Django was created at a time when AJAX was at its infancy. Most apps needed to generate HTML and the server side had to include templates, routing, authentication, etc...
More modern applications rely a lot more on client side code for routing, and HTML generation and the backend is mostly an API for a non-relational database. Plus a lot of other services for random things like Auth, caching, etc... To the point a lot just opt to go serverless and connect directly to a Firebase for storage for instance.
Django doesn't feel so at home in those "newer style" apps. Most features go unused and the ones you want don't have great support and you have to rely on other tools such as django-rest-framework. If you want to use a NoSQL database, then the nice ORM goes out of the window and you usually lose the Admin interface.
So in other words I think a Javascript Django would have very low usage, because people just don't build apps like that anymore. People prefer light backends reliance on external services and more specialized data storage options. So they want something that is lighter, easier to deploy and scale.
The only reason I still would use Django today is the amazing Admin interface you get in exchange for using its ORM with a relational database.
Hence you end up evolving a large community of people who could stay employed by keeping company's on the hook vs developers who actually managed to get their project into a fully working state and become obsolete.
Rails, Flask, Django (and PHP, purely server side JS that generate HTML with templates like express) are basically all "backend serving frontend and templating".
Front end JS is more of a "frontend + backend with frontend serving backend" in the form of server side rendering being more akin to running a browser, loading the frontend, and then serialising that to a page. This is the complete opposite of the above.
It's kind of a different mindset, but at the same time you frequently see flask serving an API, and JS consuming that API from the browser.
This gap spurred the creation of tools with a lot of bad practices (e.g., Mongo, etc., which sacrificed ACID). Relational databases, like Postgres, were just not ready for the kind of scale we would see with popular web apps.
These new "do anything however" tools (like Mongo) lower the barrier of entry into app creation, because you could just turn them on and start loading data into them; even basically just JavaScript objects could be dumped into the database. As a result, a whole new cohort of developers joined in the creation of full web apps.
Now, developers, accustomed to styling drop down menus and creating picture slideshows, were directly engaged in things like data modeling, business logic, and security. As you might imagine, all of those things were tossed out the window. As such, many of the JavaScript frameworks didn't even bother with many of these... niceties.
"NoSQL" as a concept has since lost relevance, because all of the RDBMS have solved the scaling issues. And for folks who got used to using unstructured data, RDBMS like Postgres added support for unstructured data, and in a manner that even outperforms purpose-built "NoSQL" tools like Mongo.
In other words, the gap that created all this bad stuff has long been filled by the existing tools, but the new tools and bad practices that come with them will persist for a generation; just as PHP is still used for new projects today.
Because there isn't enough time. Every twenty minutes there is a new framework. Things cannot mature. "AngularJS is now scheduled to reach the end of its life on December 31st, 2021." Time to learn yet another crappy soon to be EOF SPA junk language. People want html. People want a back button that works, people are sick of popups with CSS transitions - just show the information. Let my browser show html.
You can't get anything near as sober, sane, predictable, and idiomatic as it IMHO. Just try it.
--
I haven't worked with rails yet though.
When you do need to start adding libraries, they have strong installation hooks so most of the time it's one CLI command everything is scaffolded/wired up.
The only problem with Angular is everything else.
For isomorphic SSR there's Nuxt.js, Next.js, SvelteKit etc — typing these here because they haven't been mentioned yet.
I'm building https://fastify-vite.dev/
While I liked Loopback they recently rewrote everything in the version 4 which led to a huge decrease in community. Now it essentially seems to be dead and looking for a new home (IBM doesn't seem to want to maintain in any longer). It's so hard to find a framework that is not only technologically capable but also sustainable.
Nest.js on the other hand seems to be alive and well but is very much tied to a single organisation / person. Also it has many concepts I did not quite get, probably due to its Angular background. It's still quite promising, though, and I was able to implement a PoC that is still used in production :-)
Other options with a slightly different focus are Sails, Feathers or Deepstream.
In the end we settled with keeping our own code and gradually refactoring stuff with Typescript.
I feel like you could build a good Rails-clone (trails?) in typescript that serviced regular old HTML well and have something extremely useful.
Selfishly I want this so I can pair it with htmx.
I’ve seen it combined with next.js which sounds great but I feel in practice you’d end up fighting these frameworks and deciding who gets to be dominant over the other for any specific problem.
Meteor is good for prototyping but I would highly recommend against it for anything serious.
Also, in my opinion, Django is a terrible framework, full of magic and impossible APIs - e.g. the ORM adds fields at runtime that are otherwise impossible to inspect or reason about, as well as firing off synchronous database queries in getters/setters, which means there's no way to understand the side effects of seemingly innocuous code.
Django feels like PHP's Magento - bloated, cumbersome, poorly designed, and ultimately a giant footgun.
We are using feathersjs now, which solves most of the same problems Django did, but is easier to understand.
than to take over new "microservices" area, which JS successfully did.
Node.js was THE first back-end JS thing, and its "micro" philosophy kind of set the precedent for everything else that follow in that space. It was the time when people started to feel Django/Rails are cumbersome for some of their needs, too, so the MVC approach never caught on for JS devs.
So I think it's just popularity. Pick whatever tool you deem suitable!
You can see land of static-page generators, which has changed "the way how to do backend™" recently (Gatsby, Hugo). Generation of static HTMLs made full-featured framework not coherent, because you want to separate website composition and the visual layer. Static-page generators can fetch data from Wordpress or any database, which cuts off some work from "old" backend (no admin panel, headless Wordpress, Contentful).
If you would take a route down the SPA river, you will note frameworks like React (CreateReactApp) or Next.js, which they clearly make backend obsolete in many scenarios. You don't need call Jinja to render the template anymore nor host website on the EC2/VPS server, because there are SaaS solutions like CloudFlare Workers, Vercel or even good old S3 that will completely get rid of V (view) from the MVC.
Finally, there are tons of serverless offerings over the hill - Firebase, GCP CloudRun, AWS Lambda. They will profit you only, if you would have the simplest and the most optimized backend logic (you pay for CPU/Memory time). Personally, I don't see any benefits to have full-featured framework like SpringBoot or Django there, because it will increase operating costs a lot (if it would even work).
Of course, there are also attempts to create frameworks in faith of "batteries included", but they sooner or later end up with same fate [0]. However, composition and fragmentation is the new trend that most folks pursue - nobody wants a big hog anymore. It is especially noticeable in JVM world, like Quarkus or how modular SpringBoot is. I guess Nest.js [1] would be the closest contender to aforementioned frameworks.
[1]: https://nestjs.com/