Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Django and Postgres for the Busy Rails Developer

andyatkinson.com

Post reply on HN
Print view View original

91–100 of 127 posts

Re: Django and Postgres for the Busy Rails Developer

#91

Post by globular-toast »

pmontra wrote: post #18
pmontra wrote: post #4

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 (Mod…

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.

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.

Re: Django and Postgres for the Busy Rails Developer

#92

Post by cplat »

lmm wrote: post #84
cplat wrote: post #82

Earlier quoted context omitted.

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 exp…

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

Good for you.

Re: Django and Postgres for the Busy Rails Developer

#93

Post by RangerScience »

Tainnor wrote: post #38
RangerScience wrote: post #30

Earlier quoted context omitted.

The Rails apps I’ve worked with where there was an ORM mess (which yeah… is all of them) it’s extremely clear that the mess is the normal “too fast” software development mess. Sure, it’s worse because it’s the ORM (and/or sharp knives), but it’s also always been the case that I can clean it up with better use of Actuve Record. Also, I’ve worked with some pretty gnarly pure-SQL systems that had essentially the same ki…

Rails and especially DHH particularly encourage not having any sort of separation between your domain objects and your persistence (and even your views), which is why N+1 queries are so goddamn common and why people are going to put confirmation mail logic in model callbacks etc.

> your domain objects and your persistence

Hmm. Thinking over my career...

Maybe I don't know what you mean by "domain objects", "separation", and "persistence", but when I think over the stuff I've worked on in my career, and the problems I've seen in codebases...

Yeah, I think I'm with them on this - your domain objects and your persistence should pretty much be the same thing. There's gonna be a few exceptions (and, ofc, you can do a shit job building the models), but I expect those to be short-lived and small.

Otherwise, you shouldn't have domain _objects_ doing all that, you should have functions operating on data, and the data is pretty much always going to be either (1) some incoming hash or (2) some database record; then you group the functions into handy modules for humans. And then they're not domain _objects_.

Do you have a good example of a "domain object" that you think really _should_ be heavily separated from persistence?

PS - The one time that comes to mind that might fit, the data I wanted to persist was essentially logging data on the operation that was performed on other data.

PPS - N+1 queries are kinda trivial to resolve in most cases in Rails? There's core ORM functionality for it.

PPPS - Yeah, don't put your confirmation mail logic in the model callback, that's a bad plan.

Fake edit: Like, you either have data you want to persist, or you have data you're transforming. If you're transforming it, it's temporary, and either I don't understand what a "domain object" is, or I think you'd make a mistake to make your temporary data into a domain object.

Re: Django and Postgres for the Busy Rails Developer

#94

Post by andybak »

ltbarcly3 wrote: post #68

Django is a framework made of several components: - ORM: bizarre and can't generate lots of common SQL you will want to generate. Weird joins via counting underscores. Horrible errors that don't make sense. Lots of builtin functions have never worked and they won't fix them. (ROUND has never worked!) - Template language: Slow and borderline unusable. are 50 pages of recursive nonsense tracebacks that doesn't tell you…

As someone that's inherited Flask projects that attempted to match Django levels of functionality, I couldn't disagree more.

Re: Django and Postgres for the Busy Rails Developer

#95

Post by globular-toast »

davepeck wrote: post #25
giancarlostoro wrote: post #10

Earlier quoted context omitted.

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.

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/ [2] https://htpy.dev

I use htpy and it's great. There are others like htmy[0] too.

The problem with templates in general is you can write malformed HTML in them. The nice thing about htpy et al is you simply can't do that. I feel like what we really want is JSX in Python, where you can write XML-like syntax and it's converted into Python at import time.

[0] https://volfpeter.github.io/htmy/

Re: Django and Postgres for the Busy Rails Developer

#96

Post by brap »

joshlemer wrote: post #49
brap wrote: post #48

With all of this praise Rails is getting, even still in 2024, it’s mind boggling how there was never a successful Rails alternative in one of today’s popular web programming languages. Nothing ever caught on.

Laravel and Django don't count?

There are several comments ITT that explain how far behing Django is. As for Laravel, I personally don't know anyone starting a project in PHP in 2024 unless there's a strong legacy reason to do it

Re: Django and Postgres for the Busy Rails Developer

#97

Post by Lio »

theappsecguy wrote: post #73
Lio wrote: post #44

Earlier quoted context omitted.

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.

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

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

2. https://github.com/tmm1/ripper-tags

Re: Django and Postgres for the Busy Rails Developer

#98

Post by neillyons »

wfleming wrote: post #12

> Migrations in Django > > The Django approach has noteworthy differences and a slightly different workflow My explanation of Django's approach to migrations would involve a lot more expletives. It is by far my least favorite thing about the framework. - Fields are not-null by default, the opposite of SQL itself - Field declarations use argument names that sound like the SQL equivalents (default, on delete cascade/re…

Yep, Django's on_delete behaviour being implemented in Python instead of SQL has caught me out a few times over the years.

I often do `on_delete=models.DO_NOTHING, db_constraint=False` and add the on delete cascade constraint manually to the migration file. https://stackoverflow.com/a/78668897/288424

Same goes for `default. Prior to `db_default` I'd often edit the migration file and set the default in SQL.

I much prefer Elixir's Ecto now.

Re: Django and Postgres for the Busy Rails Developer

#99

Post by robertlagrant »

globular-toast wrote: post #90
adammarples wrote: post #52

Earlier quoted context omitted.

Actually the dango dev is saying that the whole appeal of dango is that you can swap the defaults out easily, kind of the opposite

The problem with Django is not swapping out defaults. The problem is it doesn't like to sit at the edge of an application where it belongs. Django should be equivalent of any other MVC-style framework (like Qt etc), sitting right out in the "interface" layer of your software. But it just doesn't work well out there, mostly due to how tightly coupled it is with its ORM.

Django isn't that, though. That would be something like Flask. Django is batteries-included for one (broad) purpose: you are going to use a relational database to make a CRUD app and we will make that easier for you by standardising a load of stuff. That constraint buys a lot of power.

Re: Django and Postgres for the Busy Rails Developer

#100

Post by giancarlostoro »

va1a wrote: post #57
davepeck wrote: post #25

Earlier quoted context omitted.

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/ [2] https://htpy.dev

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 s…

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

Post reply on HN