HN Explorer

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

52 points by bluewalt ↗ HN
To be more specific, some exists, for example Sails (MVC architecture), Nest (gathering best tools and providing an architecture to use them together), or Blitz (Full stack React).

...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.

87 comments

[ 7.1 ms ] story [ 161 ms ] thread
ev1
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.

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.

nhgiang
I think it's simply that (and this is from my memory only):

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!

ev1
At the start of node.js, I frequently saw full web applications written in it "traditionally", fetching data and writing it into pug/haml/jade/handlebars/whatever else templates (during the callback-pyramid-hell days). It was pretty much just another stack like a less opinionated django. People used express, returned HTML, etc.

Then the SPA frameworks came into the fray, and I never really saw node.js being used server side like that much anymore.

dbbk
I'd say Ember.js is the biggest example of this. Their whole premise is "batteries included", you don't need to think about a lot of stuff. Things like a router and such are built-in.

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.

y4mi
I thought emberjs was a frontend toolkit and even looking at their webpage I cannot see any obvious way to connect to a database etc.

Is there something I'm missing?

aogaili
EmberJS is front-end, there is MeteorJS (ignore the FUD), NestJS, SailJS etc.

https://www.slant.co/topics/2428/~best-full-stack-node-js-fr...

To answer your question, there is not one but many simply because the ecosystem is huge compared to anything we have seen in the past.

y4mi
> ecosystem is huge compared to anything we have seen in the past.

thats at least not reflected in weekly downloads. NodeJS MVC backend is really unpopular compared to other options if you trust these numbers.

weekly downloads:

  - MeteorJS: ~2.5k
  - NestJS: ~1 mio
  - SailsJS: ~22k
  - express (not mvc): 18mio

  - django: 1.7 mio
  - flask: 15mio
aogaili
Well, I don't think this stat is represintive of what is happening, simply there are many more frameworks:

FeatherJS, LoopbackJS, koaJS, TotalJS, hapiJS, NextJS, AdonisJS, DerbyJS, BlitzJS, RavelJS, DenoJS and probably many others I have not even heard of.

Now, each of those frameworks has a decent size community behind them, some of them received huge funding (NextJS, MeteorJS etc), some of them launched only recently. Keep in mind that NodeJS is only 10 years old, JavaScript itself had a decent revesion just recently in 2015. I do think the ecosystem is larger and more active than anything we have seen before and it is still growing aggressively, as more php and ruby developers make a switch and new developers join the field.

atraac
RedwoodJS and Blitz try/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 'niche' when compared to things like React or Next.js.
doniphon
Well, well... that may not be true for much longer. just take a look at RedwoodJS - https://redwoodjs.com. It's near 1.0, has a solid core team (with a really sounding track record) and just works (really)!

You can't get anything near as sober, sane, predictable, and idiomatic as it IMHO. Just try it.

--

bluewalt
While it sounds neat in its area, it seems to be the same philosophy than nest js: an opinionated way to gather a set of trendy tools (React, GraphQL, Prisma, Jest, WebPack, Babel, etc.) and enforce conventions around them.

To me, it remains different from Django (or Rails) in a sense Django developed all the framework components themselves, which has major implications.

tyingq
It does look useful, but skimming the docs I see a lot of the management is running yarn commands, hand editing model files, toml files, tweaking graphql, etc.

It seems closer to something like Laravel than Django or Rails. And even that comparison is hard because it's trying to orchestrate a lot of 3rd party stuff where Laravel is orchestrating mostly it's own stuff.

aristofun
It's much harder (hence no economical sense) to compete in "monolith" battlefield with established leaders

than to take over new "microservices" area, which JS successfully did.

devKnight
Adonis.js is a sort of Laravel clone for the node eco-system. Its been around for years, but i don't see it used very much
recursivedoubts
I had been wondering this exact thing. Does typescript have good metaprogramming tools?

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.

xzv
Here is my most cynical opinion. The fragmented JS "build your own stack" community prioritizes quick prototypes and developer employment over long term developer productivity. It'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 "feature".

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.

dudus
I think Django embraces the Python mentality of "batteries included" and Javascript frameworks follow the Node mentality of reusability and fragmentation. So in my mind it makes sense there's no Django for Javascript.

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.

aogaili
"So in my mind it makes sense there's no Django for Javascript."

There is no dominant framework because there are manny good ones focusing and different things. That is because nodejs is larger than anything we've seen thus far.

karmakaze
The could and was said before React about all the mix-and-match parts.
creshal
> So in other words I think a Javascript Django would have very low usage, because people just don't build apps like that anymore.

Some people do still build apps like that – but they have no need to use Javascript for it, as it adds no value to their architecture. So they keep using Rails and Django, and don't waste time on making a JS framework instead.

subsection1h
> The only reason I still would use Django today is the amazing Admin interface

What framework might you use if you had to build a multi-vendor marketplace with hundreds of forms and only 1% of the form fields require JavaScript for interaction? Would Django be a bad choice? I don't have experience with Django, but I have experience with Rails and Node.js, and I would pick Rails over Node.js for such a project without any hesitation.

dudus
Django does include a pretty robust Form framework with advanced features such as custom widgets, validation, and integration with the ORM. But there are other similar libraries outside of Django.

So I'd say Django gives you some tools to implement large forms but don't necessarily is a big advantage compared to something you might find in node or ruby

marz0
Rails for sure. I don’t see how Django would benefit you if you are already familiar with Rails.
jitl
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.

- 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+.

syndacks
My personal opinion is that the async event loop of Js, while powerful and "fast", is unnecessary overhead for most basic CRUD apps. Promises, callbacks, async/await are cumbersome and cause issues when not reasoned through properly. I've never experienced that with Django.
elliekelly
Troubleshooting promises and async/await in basic CRUD apps forced me to learn & understand so much more about programming and browsers than I ever intended to know.
[deleted]
(comment deleted)
junon
There are. Next.js is probably the best example. Despite having worked for the company that makes it now, I wasn't personally a huge fan of it for my own projects, but I also wouldn'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.

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.

sgt
I have to disagree regarding Django.

Yes it hides a bit of complexity if you want to follow the easy route, but you don't have to write Django apps as if it's the year 2010.

I personally use the ORM where suitable, but I do profiling and sometimes I see the need to optimize busier views and API's. Django lets you strike a good balance between productivity and performance (to the extent that is feasible with Python - and even then you can go into layers of caching etc).

Any other opinions?

tgv
I inherited a system using an unholy combination of Django and Angular, and the data structures are only a tiny bit complex: it's not a simple tree, but some records can have multiple parents. I had to add one checkbox on one modal dialog which mainly affects an accounting procedure. It had to be added in the model, in the serializer, in the three places where a new serializer is instantiated, in two or perhaps three places in the Angular controller, and finally one line in the angular html. In some places you add the field, in others you add the field name to a list. Because "batteries" means in this case: Django heavily abuses Python's dynamic nature. It's opaque, and above all unnecessary. Django is a relic from the time when a POST form was the height of user interaction. That started fading out early 2000s. It's slow, and consumes a lot of memory. I hate it.
sgt
Just seems like a crappy project, to be honest. Django has also been constantly improving. It's not slow, and it's pretty decent to whip up an API with if you want to. The alternatives in other tech stacks may also be terrible - if implemented incorrectly.
junon
It's not complexity, it's magic. In a sufficiently complex Django app at work, it was hard to make trivial changes to the codebase without feeling like something was going to unexpectedly break. Development times were abhorrently slow. Even hello-world response times, locally, were in the order of 50-200ms.

Never again.

sgt
Sounds like you were using runserver in Django and comparing its performance to WSGI's like gunicorn and uwsgi. That is an unfair comparison. Up to 200 ms for a hello-world response time even with runserver shouldn't happen. Perhaps you should try again?
junon
No thanks, Django was a complicated mess, and Python is, in my opinion, not at all suited for long-running services in production. There are a plethora of other languages for that.

Seems like you're close to, or perhaps the creator of, the project - nothing against you or the team. I just don't have a lot of positive things to say about Django after having worked with it.

sgt
Not affiliated with Django at all. I just use it for a few production apps, although they are not exactly high traffic.

I have a high traffic product in use, but the backend is written in Java w/ Undertow.

What I enjoy about Python is that it's great at getting stuff and ideas out quickly. In fact, I just added a new feature tonight to a Django project and that took me ~45 min for something that would likely take 3 hrs to implement in Java.

anaganisk
Yeah, Instagram like sites need to built with rust, using a react app, oh wait no it was built on top of python and Django, yet somehow they became successful. That says a lot about how much it can pull to, may be you expected something thats not intended for Django to do?
Jimpulse
Can you elaborate on why you dislike it for your personal projects?
junon
I don't like React or anything having to do with it, and Next.js is too bloated for my liking on top of that. I use Surplus and not much else, which tends to handle state, updates, re-renders, user interaction, and a bunch of other things much nicer and as such results in cleaner code. It also tops the performance benchmarks consistently.

Plus I don't want SSR most of the time in my apps. If I had a landing page, I might consider Next.js. But at the same time, I might just do static HTML in such a case.

Neener54
This is fairly close https://sailsjs.com. I've used it on some side projects and it definitely felt like it made doing node apps faster than doing things by hand.
unraveller
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.

https://github.com/layrjs/layr

tobyhinloopen
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.
craig1f
Django is the absolute worst. I just finished two projects with it. It's OO hell full of side effects.

We are using feathersjs now, which solves most of the same problems Django did, but is easier to understand.

Jean-Philipe
I'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'm pretty much there. I've just never missed anything from Django.

I haven't worked with rails yet though.

leephillips
Does your solution have protection against cross-site scripting attacks?
[deleted]
(comment deleted)
dzonga
you can use same-site cookie attribute to prevent csrf attacks these days.
leephillips
Not an ideal defense, as explained at https://portswigger.net/web-security/csrf/samesite-cookies

But there are many things the programmer can do to defend against csrf attacks. But you have to know about the problem and know how to defend against it. When I made my first Django site 20 years ago I hadn’t even heard of csrf, yet was protected against it by the framework. It has many such benefits included, so you can make a secure site while knowing little about web security. And an efficient one: it caches DB data for you, for example.

On the downside, as others have mentioned, it’s built using Python class inheritance magic, so can be a headache to modify its behavior.

bluewalt
You can not say you get feature parity just after plugging an ORM to express. Of course if you're building a todolist, I understand the point, but as soon as you have more need, the journey of searching for packages, comparing them, test them, read their doc, starts. Some things I have in mind: security, authentication, file uploads, role management, testing, cache, admin, etc.
Jean-Philipe
> You can not say you get feature parity just after plugging an ORM to express.

It's also not what I said :-)

Admin is a good point though. I actually do miss that when working with node.

nickysielicki
Feathers (built on express) comes close, but I’ve not used it for anything serious.

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.

jikbd
Because developers of the JavaScript world wouldn’t find the performance of django or rails acceptable.
Jensson
Then wouldn't there be a good use case for a performant version in Javascript? Javascript runtime is much faster than either Python or Javascript, so just doing the same thing would be a huge improvement.
montblanc
I doubt that many JS developers know or care much about performance. If performance is that important you have Java/Go/C++ ...why use Node?
iambateman
I think of Angular as being closer to a “batteries included” approach. Google at least has an opinion about most things.

The only problem with Angular is everything else.

Uehreka
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!)
leodriesch
It is more complete than abandoned. They said they would not introduce bigger changes to the library, since it is so wildly used.

I think some of the original devs moved on to develop Koa.js.

speedgoose
It would be nice of them to release the v5 though. Native support of promises (and async callbacks) is still not released for example.
crate_barre
This is the closest answer to the OP’s original question. Express is the trusty hammer we reach for in the Node world. Had they kept evolving it into a more Rails-like/Django-like tool, then Node would have that robust framework. They opted to keep it like Flask/Bottle, and so Node sort of got stunted on that front based on that decision.

Express only offered routing, middleware to plug-in things like Auth and templating. So yeah, we are very anemic in the Node world when it comes to anything that even resembles a Laravel.

ransom1538
"Why is there no Django/Rails equivalent in JavaScript world?"

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.