Ask HN: Why is there no Django/Rails equivalent in JavaScript world?
87 comments
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+.
- 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+.
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.
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.
"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.
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.
The could and was said before React about all the mix-and-match parts.
> 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.
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.
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
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
Rails for sure. I don’t see how Django would benefit you if you are already familiar with Rails.
> 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.
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.
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.
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.
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.
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 situation began with a market gap in the late 2000s: the need for "web scale" apps capable of handling tens of millions of requests per day.
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.
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.
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.
"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.
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.
AngularJS is not Angular https://www.upgrad.com/blog/angular-vs-angularjs/#:~:text=La...
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.
--
You can't get anything near as sober, sane, predictable, and idiomatic as it IMHO. Just try it.
--
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.
To me, it remains different from Django (or Rails) in a sense Django developed all the framework components themselves, which has major implications.
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.
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.
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.
I haven't worked with rails yet though.
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.
> 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.
It's also not what I said :-)
Admin is a good point though. I actually do miss that when working with node.
Does your solution have protection against cross-site scripting attacks?
[deleted]
you can use same-site cookie attribute to prevent csrf attacks these days.
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.
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.
Others mention timing, another reason might be the language itself. Unlike Ruby/Python and other languages, core JS is very small, relying on large numbers of dependencies where other languages would have core builtins - the "leftpad" 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 "large" 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'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.
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.
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.
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.
> 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:
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: 15mioWell, 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.
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.
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?
Is there something I'm missing?
It is funny that several frontend frameworks got suggested here. How can software engineers make that mistake?
They had a burning answer they just needed to find a question for.
Maybe folks don't understand what Django and Rails do?
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.
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't see it used very much
For backend needs, Fastify is as solid as it gets for Node.js
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/
See https://fastify-vite.dev/meta/philosophy.html
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/
See https://fastify-vite.dev/meta/philosophy.html
At one point at work we were evaluation Nest.js vs. Loopback.js as a backend framework for rewriting our home-brewed solution.
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.
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 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'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.
Blitz is getting tons of traction. Thousands of businesses all around the world are using it in production including Algolia and GraphCMS.
Over 400 new projects are being created every day.
Keep in mind, Blitz is still pre-1.0, so there's a lot of folks wanting to use it that are waiting until 1.0 (expected by end of year).
But overall, it's only 1.5 years old. Getting massive adoption just takes time.
Over 400 new projects are being created every day.
Keep in mind, Blitz is still pre-1.0, so there's a lot of folks wanting to use it that are waiting until 1.0 (expected by end of year).
But overall, it's only 1.5 years old. Getting massive adoption just takes time.
"Thousands of businesses in production" + "still pre-1.0" in the same sentence perplexes me a lot.
Someone's pet todo-list is a business I guess...
There is a long list on https://0ver.org/ but I understand what you mean.
For me any modern JS/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 "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.
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]
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.
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.
Sounds like you want nextjs
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.
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!)
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.
I think some of the original devs moved on to develop Koa.js.
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.
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.
It would be nice of them to release the v5 though. Native support of promises (and async callbacks) is still not released for example.
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
https://github.com/layrjs/layr
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.
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.
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.
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.
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.
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?
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?
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.
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.
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.
Never again.
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?
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.
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.
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?
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.
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.
Can you elaborate on why you dislike it for your personal projects?
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.
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.
Sails.js [0] has been around for years. I don't know how good/bad it is, but there are lot of big name shops using it.
0. https://sailsjs.com/
0. https://sailsjs.com/
I generally do not trust the front page logos, there is a difference between, Amazon using it for their e-commerce needs and using it for a feedback form collection service. Some small team might be using it, which may not be as significant.
Last I tried Sail JS along with Meteor( i admit 3 years ago), it was slow and buggy.
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.
We are using feathersjs now, which solves most of the same problems Django did, but is easier to understand.
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.
than to take over new "microservices" 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?
> Nest (gathering best tools [...]
LOL. https://redd.it/lwje83
LOL. https://redd.it/lwje83
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!
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!
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.
Then the SPA frameworks came into the fray, and I never really saw node.js being used server side like that much anymore.
I think there isn't anything I could name as a close alternative to Django/RubyOnRails/Laravel/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).
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] might be close to mimic them.
[0]: https://xkcd.com/927/
[1]: https://nestjs.com/
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] might be close to mimic them.
[0]: https://xkcd.com/927/
[1]: https://nestjs.com/
Yes. NestJs is the closest.
MeteorJS
Because developers of the JavaScript world wouldn’t find the performance of django or rails acceptable.
Rails/Ruby performance has improved:
https://medium.com/retention-science/ruby-is-still-a-diamond...
Alhough, compiling Javascript to binary makes code even faster https://nectar.js.org , although I wish that project would get more love with bugfixes https://github.com/NectarJS/nectarjs/issues
https://medium.com/retention-science/ruby-is-still-a-diamond...
Alhough, compiling Javascript to binary makes code even faster https://nectar.js.org , although I wish that project would get more love with bugfixes https://github.com/NectarJS/nectarjs/issues
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.
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?
...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.