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

101–110 of 127 posts

Re: Django and Postgres for the Busy Rails Developer

#101

Post by giancarlostoro »

silviogutierrez wrote: post #61
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.

Nothing on the python side for templating will ever come close to React or things like that. I built https://www.reactivated.io specifically to let python do what it does best (business logic / backend) and render using React. But all still server side without the downsides of a SPA.

It can, just needs to be built. I'm thinking of something that can both compile to WASM AND be somewhat like Phoenix Liveview.

Looks like there's some attempts for Phoenix Liveview for Python.

https://github.com/liveviews/liveviews?tab=readme-ov-file#py...

Re: Django and Postgres for the Busy Rails Developer

#102

Post by blitzar »

melodyogonna wrote: post #83
aerhardt wrote: post #22

Earlier quoted context omitted.

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

Can confirm. Django's ORM is the main reasons I use Django. A work of art in software design.

I am unsure why the ORM hasn't been stripped out and made into a standalone product.

Re: Django and Postgres for the Busy Rails Developer

#103

Post by acdha »

blitzar wrote: post #102
melodyogonna wrote: post #83

Earlier quoted context omitted.

Can confirm. Django's ORM is the main reasons I use Django. A work of art in software design.

I am unsure why the ORM hasn't been stripped out and made into a standalone product.

That increases the support cost so I think the first question would be who’s going to use it. Django has a lot of value from integration and you wouldn’t get that as a stand-alone product, and the people who want to mix their own framework tend to pick SQLAlchemy. If there isn’t a clear community it’d be taking time away from things existing users want in the hopes of attracting other users, so you’d really want to make sure that demand was there.

Re: Django and Postgres for the Busy Rails Developer

#104

Post by acdha »

globular-toast wrote: post #88
irjustin wrote: post #56

Earlier quoted context omitted.

Yeah SQL Alchemy is 1000x better. Django's ORM is miserable. User.objects.filter(company__product__product_variation__var_type__in=['var1', 'var2']) vs User.where(company: { product: { product_variation: { var_type: ['var1', 'var2'] }}}) Little things like that make it so much harder to read.

Not to mention SQLAlchemy supports the unit of work pattern meaning you can update many objects at once. It tracks and figures out how to apply the updates all in one go. Django supports one object at a time. With SQLAlchemy it's easy to build mappers to real domain objects that are independent of the database. Most Django people treat the Django models as entities or, worse, do business logic in views etc. It's poss…

I class the SQLAlchemy unit of work pattern as one of the harder things: in the cases where Django’s bulk update mechanisms wouldn’t work, it’s extremely easy for someone who isn’t an SQLAlchemy expert to get confused about when changes are committed or to inadvertently leak sessions.

It’s a powerful idea but having helped people with it I’ve mostly felt it reinforce my belief that less magic is usually better from a support perspective.

Re: Django and Postgres for the Busy Rails Developer

#105

Post by wfleming »

Izkata wrote: post #87
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…

> - The makemigrations command to auto-generate pending migrations is very aggressive and will detect things as "changed" that don't impact the schema. If you changed some help text on a field, or a localization string, or the aforementioned only-in-python default value, makemigrations will see that as requiring a migration that does nothing. Leads to lots of cruft. # Attributes that don't affect a column definition.…

Our Django app was still 1.x when I joined, I’ve gotten us up to 3.2 and hope to be on 4.0 in January. It looks like this was added in 4.1, so this’ll be a nice QOL improvement to look forward to, thanks.

Re: Django and Postgres for the Busy Rails Developer

#107

Post by pkphilip »

pmontra wrote: post #35
techscruggs wrote: post #14

Earlier quoted context omitted.

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/ . 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 does a great job of showing off…

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

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.

Re: Django and Postgres for the Busy Rails Developer

#108

Post by melodyogonna »

blitzar wrote: post #102
melodyogonna wrote: post #83

Earlier quoted context omitted.

Can confirm. Django's ORM is the main reasons I use Django. A work of art in software design.

I am unsure why the ORM hasn't been stripped out and made into a standalone product.

Wouldn't know. However, some standalone projects are attempting to replicate the same experience, check Tortoise ORM - https://github.com/tortoise/tortoise-orm.

Re: Django and Postgres for the Busy Rails Developer

#109

Post by silviogutierrez »

giancarlostoro wrote: post #101
silviogutierrez wrote: post #61

Earlier quoted context omitted.

Nothing on the python side for templating will ever come close to React or things like that. I built https://www.reactivated.io specifically to let python do what it does best (business logic / backend) and render using React. But all still server side without the downsides of a SPA.

It can, just needs to be built. I'm thinking of something that can both compile to WASM AND be somewhat like Phoenix Liveview. Looks like there's some attempts for Phoenix Liveview for Python. https://github.com/liveviews/liveviews?tab=readme-ov-file#py...

I think the foundation, sure.

But the ecosystem of React, including UI libraries, charting, forms, and so forth, is enormous.

Re: Django and Postgres for the Busy Rails Developer

#110

Post by davepeck »

globular-toast wrote: post #95
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

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/

PEP 750 started its life in part as a result of learnings from pyxl [0], which used some clever hacks to add a JSX-like syntax to Python.

In the end, my instinct is that t-strings are the better more generic feature to add to the language itself today.

That said, I'd love to see the Python ecosystem get to the point where it's relatively easy to implement transpilers and get new grammars integrated with key tools (colorizers, formatters, linters, type checkers, etc). After that: let a thousand JSX-likes bloom.

[0] https://github.com/gvanrossum/pyxl3

Post reply on HN