6 ms·

I'm working on a Rails and on a Django project for two different customers and I've been doing that for years now. I'd pick Rails over Django any time for every

I'm working on a Rails and on a Django project for two different customers and I've been doing that for years now. I'd pick Rails over Django any time for every single feature. The absolute worst Django feature is the templating language. It seems to be designed to slow down developers to the like of old time Java web apps, almost mandatory templatetags et all. The query language is moderately bad, quite verbose (Model.objects every time) for no good reason. The lack of common project structure means that every project is different. There is no Capistrano to deploy. I wrote something like that myself and we have been using it for maybe 7 years. I'm sure I could go on for a while if I keep thinking about it, but you got the gist of it. On the Rails side, sometimes I'd like to have a talk with some of the previous developers of the Rails app, which hid some important functionality in a before save callback in a different module for no particular reason, but one can be too clever with Python too. However the language (Python) is quite dull, which can be a good or a bad thing. It's very subjective. It's a Ruby gone bad at design time to me.

kamikazeturtles 2y ago
Python is used for much more than just web dev and Django, whereas Ruby seams to only be synonymous with Ruby on Rails. Do you think Rails is still worth using when investing in learning Python and Django has a much higher roi?
- karolist 2y ago
  Majority of learning surface will come from framework and not the language, if you need Python elsewhere just learn that as well, but this shouldn't move framework choice much.
  - Tronno 2y ago
    Ruby, and Rails in particular, has a lackluster dev experience with any editor that isn't RubyMine. That's been a huge obstacle for me personally.
    - Joe_Cool 2y ago
      Although a bit annoying to install I am still using the rails plugin for NetBeans. I just never switched to Aptana or Rubymine and now I don't wanna.
    - Lio 2y ago
      Each to their own I guess. Personally I like the ruby-lsp and TPope’s Rails plugin in NeoVim. I dislike heavy weight IDEs, I never find the juice is worth the squeeze.
      - theappsecguy 2y ago
        I want to like ruby lsp but it takes about 8 seconds to get method references in a large monorepo. It’s simply not good enough, and forces anyone looking for a good devex into rubymine
        Lio 2y ago
        I'd suggest maybe trying either Solargraph[1] (which also works well for me) or a ctags based solution like ripper tags[2]. On the plus side, ruby-lsp is always being improved and worked on, so just like Ruby in general it's only getting better at what it does. 1. https://github.com/castwide/solargraph https://github.com/castwide/solargraph 2. https://github.com/tmm1/ripper-tags https://github.com/tmm1/ripper-tags
    - weaksauce 2y ago
      ruby-lsp and rails-lsp from shopify is pretty good right now and getting better by the day. the vscode extension handles it well too.
  - infamia 2y ago
    > Majority of learning surface will come from framework and not the language Once you get past the beginner level in Django, you're going to pick up a ton of Python knowledge (standard dunder methods, MRO, standard lib, data type's im/mutability, package ecosystem, etc.) and muscle memory along the way. Django (for the most part) is just plain old Python data structures, classes, and functions that a decent Django dev will apart, reuse, override, repurpose, and add on to as they do more interesting things. Python is boring (in a good way), however it has a lot of surface area (std lib is massive) and intricacies that a Django dev will pick up along the way to becoming an intermediate/advanced dev. It would take someone coming in fresh to Python quite a while to catch up. Naturally, if the same person knew several languages, the ramp up would be quite a bit quicker.
- criddell 2y ago
  It sounds like you've already made your choice and it's a good one. Go with Python and make great stuff. Rails has been around two decades, Ruby three. Both will still be there down the road when you decide to try it out. A lot of what you learn in your Python work will translate in some way to Ruby & Rails.
- RangerScience 2y ago
  Yes. You learn unique, transferable things from every language and framework; usually, techniques and perspectives, but also confidence and theory. I’d also contest your statement that learning Python and Django have a “much higher ROI” - but, I don’t actually want to get into it.
- x0x0 2y ago
  If you spend a bunch of time in Ruby (or Python), I don't think you'll have a huge lift switching to the other if you ever want to? > Rails is still worth using Yes. Hotwire + Hotwire Native are great tech. The whole suite is integrated in a way that Django isn't ime. I prefer the strong default approach for most things.
- dismalaf 2y ago
  > Ruby seams to only be synonymous with Ruby on Rails. Seems to be... But it can be used for anything Python is. There's ML libraries, bindings to stuff like Torch, all the math-y stuff like Python, all sorts of stuff. Also it's a great language to just roll your own scripts, programs, etc... Then there's also mruby, which can be embedded like Lua...
deleted 2y ago
[deleted]
giancarlostoro 2y ago
Funny you mention templating, its one key thing I'd change about Django, that... and maybe scaffolding, I'd crank it up drastically more. My ideal enhancement to Django would be something like how Microsoft made Razor into Blazor... A template engine that can run purely on the back-end or purely on the front-end, replacing any need to ever use JavaScript, you stick to your native programming tongue if you will.
- davepeck 2y ago
  I think of Django's templating system as a great tool for a previous era. I'm hopeful that PEP 750 [1] gets accepted and a modern ecosystem of template engines emerges in Python-land. For the moment, I tend to use in-python builders like htpy [2] when I want back-end Python code to generate some HTML. [1] https://pep-previews--4124.org.readthedocs.build/pep-0750/ https://pep-previews--4124.org.readthedocs.build/pep-0750/ [2] https://htpy.dev https://htpy.dev
  - va1a 2y ago
    Didn't know about pep 750, that's really cool that there's a push for native templating. I just hope we see a gradual stepping away of "everything clientside" and the JS framework hell that exists today. I've tried and I've tried but I just can't take javascript seriously. It's so ugly and overbuilt. It should never have been brought to the server, Node was a horrible mistake. In my ideal future, the web returns to servers doing their jobs, and JS being used for minor interactivity features when necessary.
    - giancarlostoro 2y ago
      > I just hope we see a gradual stepping away of "everything clientside" and the JS framework hell that exists today. The nice thing about Blazor is you can either have your templates as WASM, or have them be back-end driven, and Blazor does a bit of the gluing for you so your site updates as things happen and need to be updated, like Phoenix LiveView.
  - globular-toast 2y ago
deleted 2y ago
[deleted]
ic_fly2 2y ago
The whole appeal of Django is that you can just swap in a different templating engine / syntax if you prefer. And you can add a DB and let there be managed by some other system. Same goes for extending manage.py I’ve worked on Django projects big and small and generally the speed are which we could deliver even on strange edge cases impressed.
- mostlysimilar 2y ago
  You can do that with Rails too. The difference is that Rails defaults are very good.
  - aerhardt 2y ago
    The Rails dev says that Rails defaults are very good and so says the Django dev about the Django defaults. The Django ORM is loved by tens, maybe hundreds of thousands of Python devs globally, and while I could raise concerns about it (for example, the async experimental capabilities fucking suck, and the core dev team is extremely slow to innovate on them on the basis that that's not "the Django way"), I've never heard anyone but a Rails dev complain that it's "too verbose". People love it so much that they'll do atrocities like import it into Jupyter notebooks or simple scripts that should otherwise have no business in bringing in those type of dependencies. I should know because when I've felt creative and a bit naughty about doing those types of things I've found out - to my unmeasurable disappointment - that there were many other trailblazers before me to write gists, Medium articles, and almost everything every type of format short of an entire O'Reilly book on how to do it.
    - deaddodo 2y ago
      > I've never heard anyone but a Rails dev complain that it's "too verbose". Maybe not too verbose, but there's a large population of python devs that find SQLAlchemy (+ Alembic) the much better option.
      - kshahkshah 2y ago
techscruggs 2y ago
A bit off topic, but whenever Rails and templating get brought up, I have to plug my absolute favorite project out there: Phlex https://beta.phlex.fun/ https://beta.phlex.fun/. It's like ViewComponents, but swap out the ERB for pure Ruby. It has been a joy to develop with. With the addition of Phlex::Kit, it has made building out a component library pretty easy too. RubyUI https://github.com/ruby-ui/ruby_ui https://github.com/ruby-ui/ruby_ui does a great job of showing off how to do this.
- petepete 2y ago
  Funnily enough I write most of my view components without a template these days, unless there's a load of markup. I keep meaning to take a look at Phlex.
- pmontra 2y ago
  Those kind of things used to be a lose lose proposition back at the time of haml (?) and all the yaml like templating languages. That was more than 10 years ago. The reason was that any designer that could actually do html was able to write an erb page, maybe except loops and logic, but they could understand them if a developer added them into the page later. On the other side with one of those languages, and more with phlex, only a developer could write the views so we were back to the 90s with photoshop layouts. Furthermore your can't copy and paste examples. Think about Bootstrap components. You have to really write everything from scratch.
  - techscruggs 2y ago
    https://www.phlexing.fun/ https://www.phlexing.fun/ We have this for that. :)
  - pkphilip 2y ago
    Agreed. The whole idea of writing html from scratch using special tags in the code makes no sense to me. It basically destroys the separation between code and design/templates.
whalesalad 2y ago
Rails is 10x better than Django in every way and it isn't even close.
pmontra 2y ago
I add one item to my own list: Django admin, being backed by default into the framework is a good thing. Rails has ActiveAdmin but it's a separate gem and it requires more work to integrate. Furthermore, being extra work is something that some customers don't want to pay for. With Django, it's always there.
- globular-toast 2y ago
  Django admin is great but it's just CRUD. If you plan to do anything more than CRUD you need to switch off admin at some point. But as a "better than a spreadsheet" database, it's great.
dethos 2y ago
I've worked for many years with both frameworks. I have the opposite view, since I prefer the Django ecosystem and Python. Rails has nice things, but overall, I prefer Django's approach and the language it uses.
mlboss 2y ago
For an alternative django templating, I would recommend htpy. https://htpy.dev/ https://htpy.dev/
mrsilencedogood 2y ago
I've used rails for years, and have used old versions of django at one company, and used python extensively for non-web purposes. I think my take is that there's no middle-ground between Rails and some of the newer Java-based frameworks. Either I'm doing a side project or startup, and I need to go as FAST as possible, type systems and similar be damned, or I'm OK with not going as fast as possible and we're going to go slower but deliver something very solid. Python/django still had me spending a bunch of time on stuff that rails will either generate, scaffold, or hide from you completely. While still not being nearly as safe or performant as anything in the Java world. Note I'm mostly thinking about more modern frameworks like Javalin, not necessarily Spring's entire ecosystem/way-of-life.
- theflyinghorse 2y ago
  I was not aware of Javeline being used in the same way that RoR/django/Laravel would be used. Javeline provides primitives to build a backend/API layer only no?
paulddraper 2y ago
Rails is so good it succeeded despite Ruby. Django's main benefits are 1. Admin interface 2. Python
- kshahkshah 2y ago
  Unfortunately for Rubyists (myself included) those are huge benefits though nowadays. It's much easier to find Python developers. Having an out-of-the-box admin interface means business people can operationalize and workaround short comings of the software today, not tomorrow. I think functional admin interfaces can often be the difference between a successful company and one which is constantly operating off of spreadsheets in the background and never fully commits to their software.
innocentoldguy 2y ago
One of the biggest things I dislike about Django is its lack of a standard project structure. I haven't used it in years, so things may be different now, but back in the day, even the core team recommended against using the default project layout, which always made me wonder why they generated new apps that way. Switching between Django projects while doing contract work was always a "what the hell?" experience. Rails' opinionated nature makes it easy to dive into new projects you know virtually nothing about. Nowadays, I focus exclusively on Elixir/Phoenix apps. Elixir eliminates the OOP requirement (I've never liked OOP because I don't feel it remotely lives up to the hype) while maintaining all the other great things I love about Rails, like consistent project layouts. It also makes writing multi-threaded, distributed apps easy.
- 0cf8612b2e1e 2y ago
  This is a bit of a head scratcher for me. I feel Django very much has a way in which projects are supposed to be structured. Maybe you do not like it, but if you ask me where the settings/templates/tests are stored, I could tell you immediately. In a bigger app, where you might want to break things apart, you have options, but it always struck me as you would maintain the existing structure (maybe debate a views/ with multiple modules in there vs views_x.py, views_y.py in the app root) Unless, you are more angling at the project vs app distinction? Which does seem a bit of cruft. I only ever create a “core” app and put everything in there. Avoids any potential headache. My only really basis of comparison would be Flask, which has basically zero standard. You can organize your app however you want. Given the barebones nature and need for third party dependencies, no two Flask apps will look alike.
  - thunky 2y ago
    > I only ever create a “core” app and put everything in there. Avoids any potential headache. I agree with this, but the Django tutorial would lead someone to believe that you need a bunch of apps. So I've seen newbies create way too many apps without understanding why they've done it.
silviogutierrez 2y ago
Shameless plug for https://www.reactivated.io https://www.reactivated.io It swaps the templating engine for React. But still server side and using all the Django features you know and love. No SPA needed.
- raihansaputra 2y ago
  thanks for sharing! The server side story is definitely a consideration why I'm not hyped on Inertia.js for now, this seems to solve it. My current nitpick is my personal preference for Svelte/SvelteKit. I hope you don't mind me taking a look at the repo and try to have Svelte as an option.
  - silviogutierrez 2y ago
    Sure thing. The magic is in vite.mts, render.mts and renderer.py In theory, you could swap in Svelte in there.
knowsuchagency 2y ago
I saw someone mention reactived but there's also https://github.com/wrabit/django-cotton https://github.com/wrabit/django-cotton
brokegrammer 2y ago
> The absolute worst Django feature is the templating language. It seems to be designed to slow down developers to the like of old time Java web apps, almost mandatory templatetags et all. They wanted to provide safe and clean templating, so they decided to force developers to write tags instead of putting logic inside templates. I agree it's quite overkill because I still want to run code like I would with ERB or PHP sometimes instead of being forced to write a tag. But this can lead to difficult to debug templates and security problems. > The query language is moderately bad, quite verbose (Model.objects every time) for no good reason. The idea was to make the separation between Model and QuerySet objects obvious. When you access the objects property on the model object, you're actually accessing the QuerySet. It seems weird because in Rails, everything is encapsulated in the model's class. But Python devs tend to prefer explicit code. In Django we also have the Manager class as an additional layer used to build QuerySets. I'd say it's just a different architecture instead of a shortcoming. > The lack of common project structure means that every project is different. This is a real problem but I reckon that big Rails projects aren't as easy to navigate either because most don't stick to the Rails way as soon as custom business logic is needed. I would say that Django isn't worse than Rails. They just decided to be more strict in some places, which isn't necessarily a bad thing. In the end, you just need to work with whatever you prefer.
- brokegrammer 2y ago
  > When you access the objects property on the model object, you're actually accessing the QuerySet Made a mistake there. I wanted to say: The objects property contains a Manager instance that allows you to work with QuerySets. I can see how having three layers to work with your database can cause confusion.
- Izkata 2y ago
  > > The query language is moderately bad, quite verbose (Model.objects every time) for no good reason. > The idea was to make the separation between Model and QuerySet objects obvious. When you access the objects property on the model object, you're actually accessing the QuerySet. > It seems weird because in Rails, everything is encapsulated in the model's class. But Python devs tend to prefer explicit code. In Django we also have the Manager class as an additional layer used to build QuerySets. I'd say it's just a different architecture instead of a shortcoming. Also, you're supposed to enhance the models with additional functionality independent of views. Not just in the form of just adding new class or instance methods, but you can also redefine or add alternate QuerySet Managers. For example "Model.objects" could be replaced with a pre-filtered one that includes "deleted=False" and you can add "Model.deleted" for "deleted=True" and "Model.all" for the original get-everything QuerySet. https://docs.djangoproject.com/en/5.1/topics/db/managers/#custom-managers https://docs.djangoproject.com/en/5.1/topics/db/managers/#cu...
ropable 2y ago
I've used them both in production enough to feel qualified to counter these, but we'd all just be arguing for our opinions. Both are excellent frameworks, with no clear standout IMO. I will say one thing in response: we've found it approximately 10x easier to find devs having years of experience with Python than with Ruby. That's a non-trivial argument in Django's favour in our organisation.
- theappsecguy 2y ago
  Perhaps, but ruby is trivial to learn.
  - block_dagger 2y ago
    The basics are trivial to learn but the object model and lambda style programming as well as metaprogramming (method_missing, etc) can be overwhelming for some folks to pick up quickly. I absolutely love Ruby though.
cplat 2y ago
I agree with you. I've wrote very big web applications in Rails, Django, and Java/Spring. I understand the argument for things being "explicit" in Python, but then I just prefer Java if I'm going to be very verbose about what I want (I'm only talking about backend APIs here). It's just my opinion that whether explicit is good or not depends on the level of abstraction we're interested in, and I don't believe that explicit is always good. (I like the concept of meta-algorithms, for example) But if there's a one-person project that needs to be scaled quickly, I prefer Rails. (The article mentions how Django makes model fields explicit in the models file, but doesn't talk about schema.rb in Rails which doesn't require you to view each migration to know how the database looks.) Yes, big projects in any language can get messy, but that's a software engineering problem, not a framework problem. I recently wrote a FastAPI project that was db-driven, with all the necessary test cases, etc. The amount of lines it took to express the controller, the schemas and models separately, the dependencies for auth and stuff, and especially elaborate test cases was pretty substantial. Yeah, the code was all explicit, but it was not enjoyable.
- lmm 2y ago
  > Yes, big projects in any language can get messy, but that's a software engineering problem, not a framework problem. Strongly disagree. IME the biggest factor determining how big your project can get before it turns into a mess is your choice of language/framework.
  - cplat 2y ago
    Good for you.

kamikazeturtles 2y ago

Python is used for much more than just web dev and Django, whereas Ruby seams to only be synonymous with Ruby on Rails. Do you think Rails is still worth using when investing in learning Python and Django has a much higher roi?

karolist 2y ago
Majority of learning surface will come from framework and not the language, if you need Python elsewhere just learn that as well, but this shouldn't move framework choice much.
- Tronno 2y ago
  Ruby, and Rails in particular, has a lackluster dev experience with any editor that isn't RubyMine. That's been a huge obstacle for me personally.
  - Joe_Cool 2y ago
    Although a bit annoying to install I am still using the rails plugin for NetBeans. I just never switched to Aptana or Rubymine and now I don't wanna.
  - Lio 2y ago
    Each to their own I guess. Personally I like the ruby-lsp and TPope’s Rails plugin in NeoVim. I dislike heavy weight IDEs, I never find the juice is worth the squeeze.
    - theappsecguy 2y ago
      I want to like ruby lsp but it takes about 8 seconds to get method references in a large monorepo. It’s simply not good enough, and forces anyone looking for a good devex into rubymine
      - Lio 2y ago
        I'd suggest maybe trying either Solargraph[1] (which also works well for me) or a ctags based solution like ripper tags[2]. On the plus side, ruby-lsp is always being improved and worked on, so just like Ruby in general it's only getting better at what it does. 1. https://github.com/castwide/solargraph https://github.com/castwide/solargraph 2. https://github.com/tmm1/ripper-tags https://github.com/tmm1/ripper-tags
  - weaksauce 2y ago
    ruby-lsp and rails-lsp from shopify is pretty good right now and getting better by the day. the vscode extension handles it well too.
- infamia 2y ago
  > Majority of learning surface will come from framework and not the language Once you get past the beginner level in Django, you're going to pick up a ton of Python knowledge (standard dunder methods, MRO, standard lib, data type's im/mutability, package ecosystem, etc.) and muscle memory along the way. Django (for the most part) is just plain old Python data structures, classes, and functions that a decent Django dev will apart, reuse, override, repurpose, and add on to as they do more interesting things. Python is boring (in a good way), however it has a lot of surface area (std lib is massive) and intricacies that a Django dev will pick up along the way to becoming an intermediate/advanced dev. It would take someone coming in fresh to Python quite a while to catch up. Naturally, if the same person knew several languages, the ramp up would be quite a bit quicker.
criddell 2y ago
It sounds like you've already made your choice and it's a good one. Go with Python and make great stuff. Rails has been around two decades, Ruby three. Both will still be there down the road when you decide to try it out. A lot of what you learn in your Python work will translate in some way to Ruby & Rails.
RangerScience 2y ago
Yes. You learn unique, transferable things from every language and framework; usually, techniques and perspectives, but also confidence and theory. I’d also contest your statement that learning Python and Django have a “much higher ROI” - but, I don’t actually want to get into it.
x0x0 2y ago
If you spend a bunch of time in Ruby (or Python), I don't think you'll have a huge lift switching to the other if you ever want to? > Rails is still worth using Yes. Hotwire + Hotwire Native are great tech. The whole suite is integrated in a way that Django isn't ime. I prefer the strong default approach for most things.
dismalaf 2y ago
> Ruby seams to only be synonymous with Ruby on Rails. Seems to be... But it can be used for anything Python is. There's ML libraries, bindings to stuff like Torch, all the math-y stuff like Python, all sorts of stuff. Also it's a great language to just roll your own scripts, programs, etc... Then there's also mruby, which can be embedded like Lua...

deleted 2y ago

[deleted]

giancarlostoro 2y ago

Funny you mention templating, its one key thing I'd change about Django, that... and maybe scaffolding, I'd crank it up drastically more. My ideal enhancement to Django would be something like how Microsoft made Razor into Blazor... A template engine that can run purely on the back-end or purely on the front-end, replacing any need to ever use JavaScript, you stick to your native programming tongue if you will.

davepeck 2y ago
I think of Django's templating system as a great tool for a previous era. I'm hopeful that PEP 750 [1] gets accepted and a modern ecosystem of template engines emerges in Python-land. For the moment, I tend to use in-python builders like htpy [2] when I want back-end Python code to generate some HTML. [1] https://pep-previews--4124.org.readthedocs.build/pep-0750/ https://pep-previews--4124.org.readthedocs.build/pep-0750/ [2] https://htpy.dev https://htpy.dev
- va1a 2y ago
  Didn't know about pep 750, that's really cool that there's a push for native templating. I just hope we see a gradual stepping away of "everything clientside" and the JS framework hell that exists today. I've tried and I've tried but I just can't take javascript seriously. It's so ugly and overbuilt. It should never have been brought to the server, Node was a horrible mistake. In my ideal future, the web returns to servers doing their jobs, and JS being used for minor interactivity features when necessary.
  - giancarlostoro 2y ago
    > I just hope we see a gradual stepping away of "everything clientside" and the JS framework hell that exists today. The nice thing about Blazor is you can either have your templates as WASM, or have them be back-end driven, and Blazor does a bit of the gluing for you so your site updates as things happen and need to be updated, like Phoenix LiveView.
- globular-toast 2y ago

deleted 2y ago

[deleted]

ic_fly2 2y ago

The whole appeal of Django is that you can just swap in a different templating engine / syntax if you prefer. And you can add a DB and let there be managed by some other system. Same goes for extending manage.py I’ve worked on Django projects big and small and generally the speed are which we could deliver even on strange edge cases impressed.

mostlysimilar 2y ago
You can do that with Rails too. The difference is that Rails defaults are very good.
- aerhardt 2y ago
  The Rails dev says that Rails defaults are very good and so says the Django dev about the Django defaults. The Django ORM is loved by tens, maybe hundreds of thousands of Python devs globally, and while I could raise concerns about it (for example, the async experimental capabilities fucking suck, and the core dev team is extremely slow to innovate on them on the basis that that's not "the Django way"), I've never heard anyone but a Rails dev complain that it's "too verbose". People love it so much that they'll do atrocities like import it into Jupyter notebooks or simple scripts that should otherwise have no business in bringing in those type of dependencies. I should know because when I've felt creative and a bit naughty about doing those types of things I've found out - to my unmeasurable disappointment - that there were many other trailblazers before me to write gists, Medium articles, and almost everything every type of format short of an entire O'Reilly book on how to do it.
  - deaddodo 2y ago
    > I've never heard anyone but a Rails dev complain that it's "too verbose". Maybe not too verbose, but there's a large population of python devs that find SQLAlchemy (+ Alembic) the much better option.
    - kshahkshah 2y ago

techscruggs 2y ago

A bit off topic, but whenever Rails and templating get brought up, I have to plug my absolute favorite project out there: Phlex https://beta.phlex.fun/ https://beta.phlex.fun/. It's like ViewComponents, but swap out the ERB for pure Ruby. It has been a joy to develop with. With the addition of Phlex::Kit, it has made building out a component library pretty easy too. RubyUI https://github.com/ruby-ui/ruby_ui https://github.com/ruby-ui/ruby_ui does a great job of showing off how to do this.

petepete 2y ago
Funnily enough I write most of my view components without a template these days, unless there's a load of markup. I keep meaning to take a look at Phlex.
pmontra 2y ago
Those kind of things used to be a lose lose proposition back at the time of haml (?) and all the yaml like templating languages. That was more than 10 years ago. The reason was that any designer that could actually do html was able to write an erb page, maybe except loops and logic, but they could understand them if a developer added them into the page later. On the other side with one of those languages, and more with phlex, only a developer could write the views so we were back to the 90s with photoshop layouts. Furthermore your can't copy and paste examples. Think about Bootstrap components. You have to really write everything from scratch.
- techscruggs 2y ago
  https://www.phlexing.fun/ https://www.phlexing.fun/ We have this for that. :)
- pkphilip 2y ago
  Agreed. The whole idea of writing html from scratch using special tags in the code makes no sense to me. It basically destroys the separation between code and design/templates.

whalesalad 2y ago

Rails is 10x better than Django in every way and it isn't even close.

pmontra 2y ago

I add one item to my own list: Django admin, being backed by default into the framework is a good thing. Rails has ActiveAdmin but it's a separate gem and it requires more work to integrate. Furthermore, being extra work is something that some customers don't want to pay for. With Django, it's always there.

globular-toast 2y ago
Django admin is great but it's just CRUD. If you plan to do anything more than CRUD you need to switch off admin at some point. But as a "better than a spreadsheet" database, it's great.

dethos 2y ago

I've worked for many years with both frameworks. I have the opposite view, since I prefer the Django ecosystem and Python. Rails has nice things, but overall, I prefer Django's approach and the language it uses.

mlboss 2y ago

For an alternative django templating, I would recommend htpy. https://htpy.dev/ https://htpy.dev/

mrsilencedogood 2y ago

I've used rails for years, and have used old versions of django at one company, and used python extensively for non-web purposes. I think my take is that there's no middle-ground between Rails and some of the newer Java-based frameworks. Either I'm doing a side project or startup, and I need to go as FAST as possible, type systems and similar be damned, or I'm OK with not going as fast as possible and we're going to go slower but deliver something very solid. Python/django still had me spending a bunch of time on stuff that rails will either generate, scaffold, or hide from you completely. While still not being nearly as safe or performant as anything in the Java world. Note I'm mostly thinking about more modern frameworks like Javalin, not necessarily Spring's entire ecosystem/way-of-life.

theflyinghorse 2y ago
I was not aware of Javeline being used in the same way that RoR/django/Laravel would be used. Javeline provides primitives to build a backend/API layer only no?

paulddraper 2y ago

Rails is so good it succeeded despite Ruby. Django's main benefits are 1. Admin interface 2. Python

kshahkshah 2y ago
Unfortunately for Rubyists (myself included) those are huge benefits though nowadays. It's much easier to find Python developers. Having an out-of-the-box admin interface means business people can operationalize and workaround short comings of the software today, not tomorrow. I think functional admin interfaces can often be the difference between a successful company and one which is constantly operating off of spreadsheets in the background and never fully commits to their software.

innocentoldguy 2y ago

One of the biggest things I dislike about Django is its lack of a standard project structure. I haven't used it in years, so things may be different now, but back in the day, even the core team recommended against using the default project layout, which always made me wonder why they generated new apps that way. Switching between Django projects while doing contract work was always a "what the hell?" experience. Rails' opinionated nature makes it easy to dive into new projects you know virtually nothing about. Nowadays, I focus exclusively on Elixir/Phoenix apps. Elixir eliminates the OOP requirement (I've never liked OOP because I don't feel it remotely lives up to the hype) while maintaining all the other great things I love about Rails, like consistent project layouts. It also makes writing multi-threaded, distributed apps easy.

0cf8612b2e1e 2y ago
This is a bit of a head scratcher for me. I feel Django very much has a way in which projects are supposed to be structured. Maybe you do not like it, but if you ask me where the settings/templates/tests are stored, I could tell you immediately. In a bigger app, where you might want to break things apart, you have options, but it always struck me as you would maintain the existing structure (maybe debate a views/ with multiple modules in there vs views_x.py, views_y.py in the app root) Unless, you are more angling at the project vs app distinction? Which does seem a bit of cruft. I only ever create a “core” app and put everything in there. Avoids any potential headache. My only really basis of comparison would be Flask, which has basically zero standard. You can organize your app however you want. Given the barebones nature and need for third party dependencies, no two Flask apps will look alike.
- thunky 2y ago
  > I only ever create a “core” app and put everything in there. Avoids any potential headache. I agree with this, but the Django tutorial would lead someone to believe that you need a bunch of apps. So I've seen newbies create way too many apps without understanding why they've done it.

silviogutierrez 2y ago

Shameless plug for https://www.reactivated.io https://www.reactivated.io It swaps the templating engine for React. But still server side and using all the Django features you know and love. No SPA needed.

raihansaputra 2y ago
thanks for sharing! The server side story is definitely a consideration why I'm not hyped on Inertia.js for now, this seems to solve it. My current nitpick is my personal preference for Svelte/SvelteKit. I hope you don't mind me taking a look at the repo and try to have Svelte as an option.
- silviogutierrez 2y ago
  Sure thing. The magic is in vite.mts, render.mts and renderer.py In theory, you could swap in Svelte in there.

knowsuchagency 2y ago

I saw someone mention reactived but there's also https://github.com/wrabit/django-cotton https://github.com/wrabit/django-cotton

brokegrammer 2y ago

> The absolute worst Django feature is the templating language. It seems to be designed to slow down developers to the like of old time Java web apps, almost mandatory templatetags et all. They wanted to provide safe and clean templating, so they decided to force developers to write tags instead of putting logic inside templates. I agree it's quite overkill because I still want to run code like I would with ERB or PHP sometimes instead of being forced to write a tag. But this can lead to difficult to debug templates and security problems. > The query language is moderately bad, quite verbose (Model.objects every time) for no good reason. The idea was to make the separation between Model and QuerySet objects obvious. When you access the objects property on the model object, you're actually accessing the QuerySet. It seems weird because in Rails, everything is encapsulated in the model's class. But Python devs tend to prefer explicit code. In Django we also have the Manager class as an additional layer used to build QuerySets. I'd say it's just a different architecture instead of a shortcoming. > The lack of common project structure means that every project is different. This is a real problem but I reckon that big Rails projects aren't as easy to navigate either because most don't stick to the Rails way as soon as custom business logic is needed. I would say that Django isn't worse than Rails. They just decided to be more strict in some places, which isn't necessarily a bad thing. In the end, you just need to work with whatever you prefer.

brokegrammer 2y ago
> When you access the objects property on the model object, you're actually accessing the QuerySet Made a mistake there. I wanted to say: The objects property contains a Manager instance that allows you to work with QuerySets. I can see how having three layers to work with your database can cause confusion.
Izkata 2y ago
> > The query language is moderately bad, quite verbose (Model.objects every time) for no good reason. > The idea was to make the separation between Model and QuerySet objects obvious. When you access the objects property on the model object, you're actually accessing the QuerySet. > It seems weird because in Rails, everything is encapsulated in the model's class. But Python devs tend to prefer explicit code. In Django we also have the Manager class as an additional layer used to build QuerySets. I'd say it's just a different architecture instead of a shortcoming. Also, you're supposed to enhance the models with additional functionality independent of views. Not just in the form of just adding new class or instance methods, but you can also redefine or add alternate QuerySet Managers. For example "Model.objects" could be replaced with a pre-filtered one that includes "deleted=False" and you can add "Model.deleted" for "deleted=True" and "Model.all" for the original get-everything QuerySet. https://docs.djangoproject.com/en/5.1/topics/db/managers/#custom-managers https://docs.djangoproject.com/en/5.1/topics/db/managers/#cu...

ropable 2y ago

I've used them both in production enough to feel qualified to counter these, but we'd all just be arguing for our opinions. Both are excellent frameworks, with no clear standout IMO. I will say one thing in response: we've found it approximately 10x easier to find devs having years of experience with Python than with Ruby. That's a non-trivial argument in Django's favour in our organisation.

theappsecguy 2y ago
Perhaps, but ruby is trivial to learn.
- block_dagger 2y ago
  The basics are trivial to learn but the object model and lambda style programming as well as metaprogramming (method_missing, etc) can be overwhelming for some folks to pick up quickly. I absolutely love Ruby though.

cplat 2y ago

I agree with you. I've wrote very big web applications in Rails, Django, and Java/Spring. I understand the argument for things being "explicit" in Python, but then I just prefer Java if I'm going to be very verbose about what I want (I'm only talking about backend APIs here). It's just my opinion that whether explicit is good or not depends on the level of abstraction we're interested in, and I don't believe that explicit is always good. (I like the concept of meta-algorithms, for example) But if there's a one-person project that needs to be scaled quickly, I prefer Rails. (The article mentions how Django makes model fields explicit in the models file, but doesn't talk about schema.rb in Rails which doesn't require you to view each migration to know how the database looks.) Yes, big projects in any language can get messy, but that's a software engineering problem, not a framework problem. I recently wrote a FastAPI project that was db-driven, with all the necessary test cases, etc. The amount of lines it took to express the controller, the schemas and models separately, the dependencies for auth and stuff, and especially elaborate test cases was pretty substantial. Yeah, the code was all explicit, but it was not enjoyable.

lmm 2y ago
> Yes, big projects in any language can get messy, but that's a software engineering problem, not a framework problem. Strongly disagree. IME the biggest factor determining how big your project can get before it turns into a mess is your choice of language/framework.
- cplat 2y ago
  Good for you.