Hacker News Reader

Comment by vmsp | Hacker News Reader

It's a shame that Django's templates are still so bad.

You can't just import and call some arbitrary python function. You most likely need to write a template filter or tag [0]. Maybe there's a good reason for this but it just feels like I'm working around a weird issue in the framework.

Also, I can't use parentheses inside if statements in a template. It's a strange restriction.

I know that Jinja2 -- which is good -- is supported. But it's a second choice, requires some setup and it's not the usual way of doing things.

Don't get me wrong. I like Django and it's still far, far ahead of most other web frameworks. But, because of these issues and also because the frontend story in Django is not that great I find myself reaching for Rails, these days.

[0] https://docs.djangoproject.com/en/3.1/howto/custom-template-...

View on HN

It is in fact deliberate, though; the "Philosophy" section on https://docs.djangoproject.com/en/3.1/ref/templates/language... explains it: "If you have a background in programming, or if you’re used to languages which mix programming code directly into HTML, you’ll want to bear in mind that the Django template system is not simply Python embedded into HTML. This is by design: the template system is meant to express presentation, not program logic."

That's something I think most developers would agree with, I certainly do.

Still, I don't think what I mentioned is unreasonable or goes against the framework's philosophy. The templating system already has plenty of logical statements, might as well make it work like expected.

See also Jinja2's take on that https://jinja.palletsprojects.com/en/2.11.x/faq/#isn-t-it-a-...

The way I've seen this play out in reality is that a lot of the "presentational logic" required by the templates gets computed in the "Django Views" layer (akin to the "controller" layer in traditional MVC). So in the end Django views both perform business/service logic and presentational logic.

I took it for granted after doing Django for several years but after doing a lot of web development in a more explicit MVC paradigm (Elixir and Phoenix in this case), my old Django code didn't really separate the web layer from the business logic layer. If I write more Django in the future I'll definitely be more aware of this but in many cases the framework (Templates, Forms, Models, Django-apps) don't really encourage this type of in-app architecture.

I think a lot of developers have moved to reactjs calling an api.

Basically doubling the complexity of an app. If you need a fair amount of front end interaction, fair enough, but many apps would be a lot simpler with Django templates and a bit of jQuery.

Agreed. This is why I created a library to render JSX through Django. See it here: https://github.com/silviogutierrez/reactivated/

Both my personal blog and business run on it in production. See my profile for links.

The biggest issue was deploying it since you need python and node. Still a work in progress, and docs are severely lacking.

But I did add a single-click deploy to Heroku:

https://dashboard.heroku.com/new?template=https://github.com...

This is one of the reasons why I'm moving to Rails. Frontend work is quite hard with templates and most of the community has moved towards Reactjs because of that, which I don't like.

I think they designed it this way because they assumed that the backend and front developers would be different persons/teams, which makes sense for many projects but for me I'm just a solo dev trying to get work done as fast as possible.

The way Rails does things with ERB makes total sense. DHH himself said that Rails was designed in a way that a single dev can take the framework and build something with it, no teams, no microservices, just plain Rails.

ERB is more dangerous than Django Templates but I like it when a framework doesn't try to protect me from myself.

By what you're saying Rails is indeed gonna serve you well, that's exactly the use case where it shines: small teams that need to move fast. I also believe it's simple structure is quite good for big projects/teams as well but that's a different discussion.

Jinja is just as bad. They’re both a pain to extend.

I believe firmly in separation of concerns but I have never understood the stubborn stance that there should be little to no logic inside of the template layer.

ERB does it right. I have seen some heinous things there, don't get me wrong, but the freedom to use any part of Ruby is incredible.

Nothing worse than when a client is hoping for a 1 hour fix on a really benign and silly bug - only to find that you'll need most of that time to whip up a custom template filter or tag, jumping through hoops to do all that.

You can use different template engines fairly easily.

Reply on news.ycombinator.com