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.
You might want to try (my project) iommi https://docs.iommi.rocks/ It's very different.
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.)
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)
select * from book where author_id = 5
If you represent your data as objects, you'll create a Book class with an attribute of type Author. If you now want to run the query above, you'd say (in c# likelihood, but not a real Entity query):
Database.Set<Book>().filter(author.id = 5).all()
But that instructs the ORM to fetch the author attribute from all books, and only then filter it by id. So, you will end up running the following query:
select * from book join author on book.author_id = author.id where author.id = 5
There is no reasonable way to represent the difference between this query and the one on top with an object representation. And even though both have exactly the same semantics, databases have been historically bad at optimizing them so the second one can be orders of magnitude slower.
You grab all Albums. Then you make a table of the albums with name and artist name. The artist name is in a separate table linked with a foreign key.
So the code might be:
for album in Album.objects.all():
print(album.name, album.artist.name)
So "N+1" because it's N queries (every album) plus 1 (the original "all albums" query).
The fix in Django is to do `Album.objects.all().select_related('artist')`. Then there will be just one query.
var customersWithOrderDetail = context.Customers.Include("Orders").ToList();
Would generate :
SELECT * FROM Customers JOIN Orders ON Customers.Id = Orders.CustomerId
The awareness is the key imo. That's what iommi's tool gives you out of the box.
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.
Have you benchmarked this?
Anyway, I disagree. Sometimes the conversion of raw data from the db to Python objects can be the bottleneck for a view. Of course, almost always when this happens it's not really a problem per se as the view is plenty fast enough.
With FastUI, you write Python.
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.
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.
Jinja:
{% for item in items %}<br> {{ item }}<br> {% endfor %}
Blade:
@foreach(var item in items)<br> {<br>@item<br> }