Ask HN: Why is there no Django/Rails equivalent in JavaScript world?

To some degree, this is a question of time. You may think of Rails as a monolith that developed all its own technology, but really it’s a framework that’s been around for a while and done a good deal of absorbing good ideas and composing existing libraries.<p>- Rails controllers and plug-in architecture come from MERB (absorbed for Rails 3) <a href="https:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;Merb" rel="nofollow">https:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;Merb</a><p>- 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)<p>- 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.<p>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 &#x2F;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.<p>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+.

I think Django embraces the Python mentality of &quot;batteries included&quot; and Javascript frameworks follow the Node mentality of reusability and fragmentation. So in my mind it makes sense there&#x27;s no Django for Javascript.<p>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...<p>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.<p>Django doesn&#x27;t feel so at home in those &quot;newer style&quot; apps. Most features go unused and the ones you want don&#x27;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.<p>So in other words I think a Javascript Django would have very low usage, because people just don&#x27;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.<p>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.

Here is my most cynical opinion. The fragmented JS &quot;build your own stack&quot; community prioritizes quick prototypes and developer employment over long term developer productivity. It&#x27;s easy for a company to get stuck with a quickly prototyped piece of garbage JS software that works quickly but then the developers can spend years reinventing every single crud wheel and calling it a &quot;feature&quot;.<p>Hence you end up evolving a large community of people who could stay employed by keeping company&#x27;s on the hook vs developers who actually managed to get their project into a fully working state and become obsolete.

My experience having written all of the above is that JS is significantly more fragmented, and also has to deal with a frontend-backend severed line.<p>Rails, Flask, Django (and PHP, purely server side JS that generate HTML with templates like express) are basically all &quot;backend serving frontend and templating&quot;.<p>Front end JS is more of a &quot;frontend + backend with frontend serving backend&quot; 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.<p>It&#x27;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 situation began with a market gap in the late 2000s: the need for &quot;web scale&quot; apps capable of handling tens of millions of requests per day.<p>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.<p>These new &quot;do anything however&quot; 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.<p>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&#x27;t even bother with many of these... niceties.<p>&quot;NoSQL&quot; 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 &quot;NoSQL&quot; tools like Mongo.<p>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.

There are, there are just too many of them so not a single one can get traction, so they’re all mediocre and different. This is already proven by the fact that every comment below mentions another framework.

&quot;Why is there no Django&#x2F;Rails equivalent in JavaScript world?&quot;<p>Because there isn&#x27;t enough time. Every twenty minutes there is a new framework. Things cannot mature. &quot;AngularJS is now scheduled to reach the end of its life on December 31st, 2021.&quot; 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.

Well, well... that may not be true for much longer. just take a look at RedwoodJS - <a href="https:&#x2F;&#x2F;redwoodjs.com" rel="nofollow">https:&#x2F;&#x2F;redwoodjs.com</a>. It&#x27;s near 1.0, has a solid core team (with a really sounding track record) and just works (really)!<p>You can&#x27;t get anything near as sober, sane, predictable, and idiomatic as it IMHO. Just try it.<p>--

I&#x27;ve worked with Django and nodejs as well. When working with node, I usually just grab express and some decent ORM that knows how to postgres, and I feel like I&#x27;m pretty much there. I&#x27;ve just never missed anything from Django.<p>I haven&#x27;t worked with rails yet though.

Others mention timing, another reason might be the language itself. Unlike Ruby&#x2F;Python and other languages, core JS is very small, relying on large numbers of dependencies where other languages would have core builtins - the &quot;leftpad&quot; problem. This makes large frameworks difficult to maintain, because the number of dependencies you would need to manage keep the whole thing going (including security patches) makes such projects quite unwieldy over time. Even a &quot;large&quot; framework like NextJS for example sticks to a pretty minimal feature set (rendering, routing, assets), leaving it to the developer to add an ORM or integrate with external APIs.

I&#x27;d say Ember.js is the biggest example of this. Their whole premise is &quot;batteries included&quot;, you don&#x27;t need to think about a lot of stuff. Things like a router and such are built-in.<p>When you do need to start adding libraries, they have strong installation hooks so most of the time it&#x27;s one CLI command everything is scaffolded&#x2F;wired up.

It is funny that several frontend frameworks got suggested here. How can software engineers make that mistake?

I think of Angular as being closer to a “batteries included” approach. Google at least has an opinion about most things.<p>The only problem with Angular is everything else.

Adonis.js is a sort of Laravel clone for the node eco-system. Its been around for years, but i don&#x27;t see it used very much

For backend needs, Fastify is as solid as it gets for Node.js<p>For isomorphic SSR there&#x27;s Nuxt.js, Next.js, SvelteKit etc — typing these here because they haven&#x27;t been mentioned yet.<p>I&#x27;m building <a href="https:&#x2F;&#x2F;fastify-vite.dev&#x2F;" rel="nofollow">https:&#x2F;&#x2F;fastify-vite.dev&#x2F;</a><p>See <a href="https:&#x2F;&#x2F;fastify-vite.dev&#x2F;meta&#x2F;philosophy.html" rel="nofollow">https:&#x2F;&#x2F;fastify-vite.dev&#x2F;meta&#x2F;philosophy.html</a>

At one point at work we were evaluation Nest.js vs. Loopback.js as a backend framework for rewriting our home-brewed solution.<p>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&#x27;t seem to want to maintain in any longer). It&#x27;s so hard to find a framework that is not only technologically capable but also sustainable.<p>Nest.js on the other hand seems to be alive and well but is very much tied to a single organisation &#x2F; person. Also it has many concepts I did not quite get, probably due to its Angular background. It&#x27;s still quite promising, though, and I was able to implement a PoC that is still used in production :-)<p>Other options with a slightly different focus are Sails, Feathers or Deepstream.<p>In the end we settled with keeping our own code and gradually refactoring stuff with Typescript.

I dunno, blitz.js is already pretty well baked and I find writing with it to be quite comfortable. I suppose it may not be getting a lot of traction in the greater Javascript world, it&#x27;s hard to tell since maybe I am already in its bubble? Either way, I really like it and have converted to it for all of my current projects.

For me any modern JS&#x2F;TS backend framework needs to offer strong support for some Websocket technology (like Phoenix LiveView or Rails Action Cable). Too often we need to jump through hoops and think a lot about how to integrate realtime elements with server-side rendered pages. This should be much easier.

My personal opinion is that the async event loop of Js, while powerful and &quot;fast&quot;, is unnecessary overhead for most basic CRUD apps. Promises, callbacks, async&#x2F;await are cumbersome and cause issues when not reasoned through properly. I&#x27;ve never experienced that with Django.

I had been wondering this exact thing. Does typescript have good metaprogramming tools?<p>I feel like you could build a good Rails-clone (trails?) in typescript that serviced regular old HTML well and have something extremely useful.<p>Selfishly I want this so I can pair it with htmx.

RedwoodJS and Blitz try&#x2F;tried to fill the missing gap with a bit different approaches each but I feel like at this point in JS world everything is considered &#x27;niche&#x27; when compared to things like React or Next.js.

I always thought ExpressJS was the equivalent on the NodeJS side, but looking at the docs now it appears nigh abandoned (jokes on them, I built like 3 pieces of software on top of it in the past year!)

Layr.js is trying to take on something in this middle space. It basically hides either end from you and is still hard to reason about. Only mongodb is supported now. And yes I much prefer the option of having many community made packages over one supported way.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;layrjs&#x2F;layr" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;layrjs&#x2F;layr</a>

Feathers (built on express) comes close, but I’ve not used it for anything serious.<p>I’ve seen it combined with next.js which <i>sounds</i> 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.

This is fairly close <a href="https:&#x2F;&#x2F;sailsjs.com" rel="nofollow">https:&#x2F;&#x2F;sailsjs.com</a>. I&#x27;ve used it on some side projects and it definitely felt like it made doing node apps faster than doing things by hand.

There are. Next.js is probably the best example. Despite having worked for the company that makes it now, I wasn&#x27;t personally a huge fan of it for my own projects, but I also wouldn&#x27;t recommend my own toolset for many others. Next.js is a fine framework for most websites and it has great support, a great community, and genuinely smart people behind it.<p>Meteor is good for prototyping but I would highly recommend against it for anything serious.<p>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&#x2F;setters, which means there&#x27;s no way to understand the side effects of seemingly innocuous code.<p>Django feels like PHP&#x27;s Magento - bloated, cumbersome, poorly designed, and ultimately a giant footgun.

Sails.js [0] has been around for years. I don&#x27;t know how good&#x2F;bad it is, but there are lot of big name shops using it.<p>0. <a href="https:&#x2F;&#x2F;sailsjs.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;sailsjs.com&#x2F;</a>

Django is the absolute worst. I just finished two projects with it. It&#x27;s OO hell full of side effects.<p>We are using feathersjs now, which solves most of the same problems Django did, but is easier to understand.

It&#x27;s much harder (hence no economical sense) to compete in &quot;monolith&quot; battlefield with established leaders<p>than to take over new &quot;microservices&quot; area, which JS successfully did.

I am primarily a Python developer, but recently discovered express.js. It is similar to Flask (which you mentioned). Maybe give it a try?

&gt; <i>Nest (gathering best tools [...]</i><p>LOL. <a href="https:&#x2F;&#x2F;redd.it&#x2F;lwje83" rel="nofollow">https:&#x2F;&#x2F;redd.it&#x2F;lwje83</a>

I think it&#x27;s simply that (and this is from my memory only):<p>Node.js was THE first back-end JS thing, and its &quot;micro&quot; philosophy kind of set the precedent for everything else that follow in that space. It was the time when people started to feel Django&#x2F;Rails are cumbersome for some of their needs, too, so the MVC approach never caught on for JS devs.<p>So I think it&#x27;s just popularity. Pick whatever tool you deem suitable!

I think there isn&#x27;t anything I could name as a close alternative to Django&#x2F;RubyOnRails&#x2F;Laravel&#x2F;Symfony in the JS world. It would be even difficult to find an alternative in other programming languages like Go, Rust or aforementioned JS. The landscape, in my opinion, looks like a bunch of archipelagos that are composed of bigger or smaller islands. They are many frameworks who got acclaimed as good ones and gathered a notable community, which has written various libraries to extend core modules (e.g. fastify.js, hapi.js, express.js, Gin, fasthttp).<p>You can see land of static-page generators, which has changed &quot;the way how to do backend™&quot; 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 &quot;old&quot; backend (no admin panel, headless Wordpress, Contentful).<p>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&#x27;t need call Jinja to render the template anymore nor host website on the EC2&#x2F;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.<p>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&#x2F;Memory time). Personally, I don&#x27;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).<p>Of course, there are also attempts to create frameworks in faith of &quot;batteries included&quot;, 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.<p>[0]: <a href="https:&#x2F;&#x2F;xkcd.com&#x2F;927&#x2F;" rel="nofollow">https:&#x2F;&#x2F;xkcd.com&#x2F;927&#x2F;</a><p>[1]: <a href="https:&#x2F;&#x2F;nestjs.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;nestjs.com&#x2F;</a>

Yes. NestJs is the closest.

MeteorJS

Because developers of the JavaScript world wouldn’t find the performance of django or rails acceptable.

H