[sirsinsalot]

After years of crispy forms and HTML-in-Python hackery, I am firmly on the side that the presentation layer shouldn't be so tightly coupled to the code that renders it.

A template language (that isn't Python) is sufficient. Even better if you can render the templates from different languages.

I'll never be defining web app presentation in Python.

[boxed]

I think you might be colored by having used a bad system. It's like all those people who say ORMs are bad and evil, and somehow almost all of them have been forced to use Hibernate :P

You might want to try (my project) iommi https://docs.iommi.rocks/ It's very different.

[mvdtnz]

ORMs are bad and I say that as a veteran of Hibernate, Entity Framework (almost every version, including code-first and db-first), E Bean, NHibernate and, worst of all by far, ActiveRecord.

[animal_spirits]

Django's ORM is beautiful, I can glide through queries using it. It makes SQL a breeze

[LtWorf]

But is it fast?

[asyx]

Fast enough. You get enough tools to optimize the queries. Keep in mind that Django is still a web framework. You can go nuts with Django and it starts to feel like maybe raw SQL would have been easier but I've rarely encountered this.

[LtWorf]

In a previous job we were using some ORM for mongodb and writing queries by hand gave massive speed gains.

[boxed]

Fast to develop with? Yes.

Fast to run? Well.. no.. it's Python.

I personally care much more about development speed and time to market/customer than execution speed. It's good enough for 99% of cases.

[LtWorf]

You're doing queries to a db, the fact that it's python is not your bottleneck

[marcosdumay]

And yeah, you are just reinforcing the GP's point, because all of those are atrocious.

I am at the ORMs are bad club, but if you try any of the systems that encode the logic paradigm into their interface, they are a completely different kind of beast. (MS has brought some of it into C# with linq so you can use with the Entity Framework. It's not a fully logic system, and has so many attrition points with the Entity Framework that it's mostly not useful at all.)

[mvdtnz]

I'm very familiar with Linq and Linq to SQL. It's as close as any ORM got to being "good enough" and was abandoned by Microsoft very early in its lifecycle. Linq in Entity Framework is a minefield of N+1's and excessive eager loading.

[boxed]

The N+1 problem is solved in iommi (again, I am one of the authors) by simply:

1. keeping a log of queries per request with stack traces

2. at the end, checking if there are N+1 problems

3. print a big warning with example SQL and stack trace to the console

During dev if I miss a prefetch_related/select_related the console will start to print gigantic stack traces telling me where the problem is. I don't have these problems in production because I get alerted to them in dev.

These are not only solvable problems but EASILY solvable problems!

(Also, in iommi tables, most of the times it can automatically figure out and do the prefetch/select related for you, further diminishing the problem)

[Timwi]

Can you explain what an N+1 problem is?

[skyde]

In EF line expression you can easily specify which navigation should be Eager loaded.

var customersWithOrderDetail = context.Customers.Include("Orders").ToList();

Would generate :

SELECT * FROM Customers JOIN Orders ON Customers.Id = Orders.CustomerId

[boxed]

Imo the issue isn't that it's hard or easy to fix. The issue is that you might not be aware that you need to fix it.

The awareness is the key imo. That's what iommi's tool gives you out of the box.

[neonsunset]

Thankfully, not an issue as of today. EF Core has client-side evaluation disabled by default. It was an enormous footgun in EF so to bring that behavior back you have to explicitly opt into it.

[hk1337]

ORMs are bad at some things and good at others. Some people are stubborn and feel like if they’re using an ORM then everything has to go through the ORM, for example.

[bpanon]

AR is fantastic. I never struggled to get what I wanted with AR.

[946789987649]

JOOQ is the only acceptable ORM.

[boxed]

And me, who have never used Hibernate, but has spent over a decade in Django thinks ORMs are great. This is exactly my point.

[Capricorn2481]

Why not Python? I've never seen huge differences between Jinja, Razor, or Blade. Is there something about it you find extra annoying?

[pjerem]

In Jinja, Razor, or Blade, you write, HTML that you enrich.

With FastUI, you write Python.

[peddling-brink]

When Python is the hammer you have..

Not every web app needs to survive HN levels of traffic. Empowering the <insert profession here> that already knows Python to make an app to automate their team’s toil is a great thing.

[astrea]

Exactly. If your team is fully fluent in Python and has a need for a web UI, easier to adopt something like FastUI than try to quickly upskill in JavaScript for a one-off project.

[sirsinsalot]

Perhaps, but it is a false economy. Anyone writing a UI for the web, should be fluent in HTML/CSS and so on. In that case, other templating approaches make more sense.

I say this with absolute conviction; you're just deferring costs, technical debts with compounding interest. When you come to pay it off, it'll bankrupt you.

[staticautomatic]

I'm not the least bit ashamed to say that I can't grok CSS today any better than I could when I first tried to learn it about 20 years ago. Whether or not alternative abstractions are "bad" or "wrong" or whatever is entirely irrelevant to me. The worst case scenario is that I end up finding them as painful as CSS.

[LtWorf]

They can use markup and a mkdocs

[Capricorn2481]

What? How is Razor more of HTML than Jinja? Both are mostly HTML with syntax specific to their languages. They don't even look that different.

Jinja:

{% for item in items %}<br> {{ item }}<br> {% endfor %}

Blade:

@foreach(var item in items)<br> {<br>@item<br> }