I know this is not the place to provide feature requests. I am genuinely interested in a discussion on the pros and cons.
Home Assistant wants to become more and more for everyone instead of programmers. We can already see those upgrades in the UI and overall accessibility. However, there is still one major hurdle for many users: templating.
I believe, along with many of you, that Jinja2 is one of the worst languages in the world to understand and write. It always feels like something is slightly off, whether it is a cryptic syntax error due to an invisible whitespace or a filter that requires a strange, non-documented argument. It just does not feel intuitive, especially for beginners who are trying to move past simple UI automations. There are many options available like V8 Engine (same as NodeRED) or QuickJS. Both available for Python use.
On the other hand, JavaScript is the most widely used programming language in the world. Almost everyone who has ever touched a bit of web tech knows it, and if you do not, the internet is absolutely packed with clear examples. If you google how to capitalize a word or filter an array in JavaScript, you get millions of instant answers. If you try to find out how to do the same with Jinja2 filters in Home Assistant, it often feels like a frustrating treasure hunt.
I would love to open the floor to discuss what Home Assistant could look like if we gradually moved towards JavaScript for templating and scripting instead of Jinja2.
For the most basic stuff, there is not much difference:
Jinja2: {{ states('sensor.living_room_temp') | float(20.0) > 21.5 }}.
JavaScript: states['sensor.living_room_temp'].float(20.0) > 21.5.
Advanced logic, like calculating the average temperature of a group of sensors, becomes much more logical and understandable.
I do understand that this requires some time to change, including a period of which both will be used. But I am genuinely curious to hear what you all think about this. Do you feel this would lower the barrier for new users? Improve possibilities for those who want more? What kind of technical roadblocks or performance concerns do you foresee?
What you’re asking for is a huge change with a huge risk and almost no reward. Jinja is locked down, and directly tied to python both things that we want. Making a change like this is a no-go from that perspective alone. javascript templating in the frontend is only used because the frontend runs in typescript which is javascript lite essentially.
I do use Python a lot as well and understand Jinja2 too (pun intended). I do think Javascript is wider and more easy to write and understand. I remember from the WTH and all the surveys that people in general just dislike Jinja because it is limited and not logical.
it’s limited by design. We don’t want users creating memory that slows down the main event loop. So even if we added javascript, you wouldn’t be able to do most of the things you want to do. It would be something like Nunjucks or similar.
Nunjucks is not much better. I do understand the issue with slowing down the main event loop. I just wished there was a better way, as it is too complicated for people who start coding and too limiting for those with experience. (I do recall the fuss that happened when you switched the template integration…)
I have zero problem with Jinja. As long as the services are provided and accessible to devs.
You can do plenty of amazing things with it… As long as you understand what it really is. It’s a Turing tape rewrite machine. So yih need to avoid loops as much as possible…
Intentionally not one single line of Javascript or python required. In fact unwanted. It opens execution safety requirements I don’t want my project to deal with.
Version 11 will introduce a complete ACL’d filesystem in fact.
I mean you do what you like rn I don’t see an issue. Ok except I do need a user.is_admin object…
I think Jinja is too limiting and unlogical. 99% of the sensors and automation I use, require advanced template. Written by me, not AI. Sometimes using the brain is better than copy paste stuff from internet.
I mean that users couldn’t even get indentation right or fix their template sensors even when using the migration tool and well written conversion guide
if we were to move to anything other than jinja, I’d favor locked down python over javascript. That’s already partially implemented to with the python_script integration.
I could work with locked down Python! Almost anything is an improvement over Jinja2.
I feel like this discussion is going in the wrong direction. I do understand Python, Jinja2 or most programming languages. I just wanted to see if this part can be improved as well, because it feels so limiting. All my sensors work now with Jinja2, so there are no actual limitations for me, the programmes. It is sometimes so cumbersome. I do understand however, the difficulty with people who do not have a programming background