 So the name of the template engine is actually Kajiki. So for any of you who wasn't at my talk this morning, I spoke about a totally different argument actually this morning. I'm one of the core developers of Turbogeos, which is a web framework that has been around for as long as Django. And it was pretty big like four or five years ago. And then Django is now the ruler of the web world. But there are still a lot of people, especially in Europe and India and other countries that are using Turbogeos heavily. And in the context of upgrading Turbogeos to Python 3, one of the problems we faced was that we were using Genshi, which is a very powerful and flexible template engine. But it has two major side effects. It's really complex to use for some cases and it's really slow. So we started to look around for other projects and there are actually tens of template engines and if you tried any web framework like Django, Flask, Pyramid and so on, each one of them has its own favorite template engine. And what we were looking for was something that was really similar to Genshi. So I provided some core features that we are going to see and we ended up in a situation where there was not much interesting around that could satisfy our needs. So first of all, let's have a global look over the template engines that we know and that exist in Python, which are the most common one are probably Mako and Jinja and Django templates, even though it's never listed as a template engine as is actually more parts of Django itself. But I would say that the properties of those template engines are usually divided in two kinds. One which is if the syntax is markup based or if it is free text. For example, if you ever use Jinja, you can actually write practically everything inside the Jinja template. It doesn't really have to be valid markup in any way. As far as the template is able to understand the structure of your code, it's fine. You can even use that for JSON, for example, or whatever you want. And then there are the text markup templates and then the way they actually run the template itself, which might be compiled or streamed. The compiled template engine are the most common kind of template engine nowadays because they are really fast usually if you did things in the right way they can be really fast. In fact, the fact that the template engine is compiled means that it gets converted to pure Python code. So your template doesn't exist anymore. It gets translated to Python code and that Python code gets executed. While in the other case, Genshi, which was one of the few examples of a stream the template language is actually can perform the runtime so the template can change itself, for example, because the template has its own structure and just a stream of tags of parts of the template and each part can actually change the one that are going to come after him or they can do powerful manipulation at runtime of the template itself, which is something that looked really cool but was actually pointless and made a lot more complex to use the template engine and in practice people never ever used it in real world apart from the guys that actually created Genshi. And I was trying to remember in which project Genshi was created. I can't remember right now. It was a issue tracking tool, so they created for their own needs. We really love the fact that Genshi was perfectly valid HTML, which means that you can open it with any editor that understands HTML, doesn't need to have any specific support for Genshi templates themselves. They are perfectly valid HTML, while in fact like Mako and Gene Giant and so on add one more layer on top of the HTML, so you need specific support for them. And the fact that the Genshi syntax was pure HTML means that it was really similar to the output you got. So the template itself was in fact the result of its execution. Maybe some piece were removed or things like that, but it was still really similar to the to the template itself. And we love Genshi so much that in version 2.2 of TurboGear, it became the standard template engine and all the pluggable application, which are plugins you can bring into your TurboGear application, were based on Genshi as it was the standard default template engine. But one day the guys that were maintaining Genshi decided that it was no, they were no longer interested in maintaining Genshi anymore. So it actually, some people stepped in but the project is nearly dead nowadays and it's not being seen, it's not seen a release for like years and has been ported to Python 3 but works only on some version of Python 3. If I'm correct, it only works up to Python 3.4 on 3.5 and so on, it doesn't work anymore. And then that this was actually our feeling at the time this news came because we just made Genshi our default engine for everything and then the next day they just removed it. They say, hey, this is going to die. So, we didn't want to step in and maintain Genshi because due to the design, due to the fact that it was a streamed engine, it was incredibly complex. It was one of the most complex code that I ever seen. Imagine you are trying to create an interpreter for a dynamic language which also has built into the language itself the ability to modify the language itself but not in the way that Python does it, which is you can modify the bytecode but in a way that you can actually modify the source code itself. So, you cannot transpile that source code to some things easier. You always need to work on the high-level complex language and convert it to a stream of tags and things like that. Well, it was really powerful but very few people understood the inheritance system of Genshi because it was really complex. I'm not going to show you much about Genshi because we are going to see how Kajiki works, which is nearly the same, the syntax remain the same and we were lucky enough that one of the turbogears core contributors was working at Suisse Forge at the time and Suisse Forge was looking to a new template engine that could replace Jinja and be as fast or even faster than Jinja but with better validation for what they were doing and things like that. So, they started experimenting with the idea that then became Kajiki and this is the syntax of Kajiki. From this short example, you can actually see what I was trying to tell you, which is the code itself is pure HTML with some added attributes. For example, you can see the pi content or you can see the pi4 and things like that. The pi content means replace the content of this tag with the value of the expression that is contained in the pi content. While the pi4, of course, means repeat this tag as many times as the iteration of the loop and you can, of course, as usual, put variables with one of the most widespread notation for variables replacement in templates. So, it was easy to see that the good part of these kind of template engines is that you can actually throw the template at anything that works with HTML. For example, I saw people having their designers work on the template file themselves with some kind of what you see is what you get, editors and they could just change it in any way they liked and then the designer, when he was happy with the result, would provide back the template file to the developer and it was still a perfectly valid Genshi or Kajiki template. As far as the editor didn't remove the tags they didn't know or things like that, which they usually don't do. If they see a pi content, they just leave it there because they don't know what to do with it. The directives that are provided by Kajiki are the most common one. You can have, of course, if else, which, for, that, I'm not going to spend too much time on this because I suppose that most of you already work with some kind of template engine and they nearly all behave the same way. But the interesting part is that Kajiki is pre-parsed and converted to pure Python code. This is a really interesting feature that not many template engines provide and which allows us to do very cool debugging and very simple inspection of what is going to happen while we are writing our own template. The code itself is actually generated by, well, I used the wrong verb because it's generated by a generator in the sense that there is a generator that goes through your wall syntax tree, your wall template structure and for each tag that you wrote it actually yells back a Python expression. So you just can see that your template is converted one by one to Python code. So you, if you know when you start working with Kajiki you will know which code will end up from what you wrote and you will know how fast it will be, which side effect it will have and things like that. And then after the compiled parts it could represent everything to an intermediate representation which is simpler than the template itself. In this context it actually resembles how most of the compilers work. Most of the compilers get your source code, get an intermediate representation that is easier for them to manage and then they throw out something else. And this is actually what Kajiki throw out. So the same exact template that we saw before gets converted to this code. So you can see that it's a class that provides a single method usually which is the main, which is actually the body of your template. And for each entry if it is something that doesn't need to be processed in any way it's the plain text that you've wrote. So for example I had the HTML tag they had and the title and so on and they are just sent back as they are. While then it comes the real interesting part. Inside the title I provided the custom content which was the title variable. And what Kajiki does it just replace the text with the instruction that would set the title into the result, into the output. So we see that we have the title then the content of the title variable which is yelled at back. You can see one more function being called around because Kajiki provides automatic escaping of the entities. So you don't have to bother yourself to like replace the text to escape the angle of brackets or things like that. The user cannot provide any content that will break the HTML because Kajiki will escape all the variables that you're going to show. And then you have the title, the closed title after the variable. And then there is one more interesting part. If you ever work with GINJA or other template engines the internationalization, the translation of the text is something that you usually need to take care of by yourself. You have to like put underscore or something in front of the strings that you want to translate or you have to collect them in some way or things like that. While in Kajiki the internationalization is built into the system. As it works on a structured language like HTML it kind of recognizes which part of the template is the structure, so the tag and which part is content. So they body the text of the tag. And you can say, okay, I don't care about the structure, the title, the ad and the body. Those are not something that the user cares about. They are just something that represents the structure of my page. But then the user cares about the text that is contained inside. These are some fluids. And the text that is contained inside is automatically translated by you, for you by Kajiki. So if you have a translation available for that phrase, Kajiki will automatically translate that for you. So you don't have to remember to wrap all your text in get text calls or things like that. And then it provides the for loop because we added a pie for tag to, I don't remember, which was the tag, to a list item. So we have a list item, the loops. So Kajiki compiles it to a for loop that prints the list item and its content. And here you can see that it is again, that I like the variable fluid and then there is a new line. This is actually an old version of Kajiki because in your recent versions, this one won't be translated because just empty text so it will just be skipped. And then you have the ending part of your template. Okay. So this is the result. Well, the template that we had when those two, these results, which is the same page with the text we provided in the variable and the repeated entries we had in the fluid. The fact is that this approach is able to make Kajiki really, really fast. For example, by doing a comparison to Mako, I could render this simple example like in one million times rendering this example one million times to 22 seconds in Mako while doing the same exact example in Kajiki took only half of the time. So it's twice as fast as Mako, which is actually one of the fastest template engines that we have around. So it's actually a really interesting feature. And it's actually pure Python. What you get is pure Python. The result of Kajiki is pure Python. So you can apply anything that works with Python, like libraries, like inspection, like debugging, whatever you want. For example, in this case, it does something really mad, which I suggest you shouldn't do yourself, which is compiling the template engine with Cyton. So in this case, it converts the code that Kajiki generated to pure C code that gets compiled to assembly and runs as binary code. So it's even faster. I don't remember if I did any benchmark of this experiment. It was just to show you that anything you can do with Python, you can do it with a Kajiki template because it's just the same exact thing. Of course, there are a few things that need to be converted because, for example, there is no Kajiki exposed context while compiling to Cyton. But in the end, it works. Yeah, there is a benchmark. You can see that without much changes, if you ever work with Cyton, you can actually improve performance a lot if you pay attention to a few things. But without any single change, just by wrapping my code into Cyton, I got speed up from 12 seconds to 9 seconds, so just by applying Cyton and nothing else. I'm sure that if anyone would invest time in optimizing it, it would at least be half of this time, which would be like four or five times faster than Maco, which was still the fastest, one of the fastest ones. And the fact that it's pure in Python means that it's easy to debug, and it will, you know, that it works with Python, works with Kajiki. And, for example, one of the examples is the Verzoic debugger or the backlash debugger into a buggy. Which, whenever you have a failure in the Kajiki code, can pinpoint you at the exact place where the template failed, and you can see the exact destruction that failed, and you can inspect the variables, because they are just plain Python variables. Nothing magic happening. So the only magic is actually the Kajiki inspects the code and replaces all the information, all the data that Python uses for debugging with other values. For example, instead of pointing to the line of the Python code, it points to the line of the template. So whenever you see the failure, you know that it failed at line 25 of your template. You really don't care if it failed at line 400 of the Python code that was generated as a result of your template. And it provides perfect Python syntax checking. This is something that many template engines that are streamed or things like that or processed at runtime do not provide. Whenever you start a Kajiki template, when you compile it, not when you run it, so not when you are showing your page, but just when you are compiling your source code, your syntax gets checked, both has the HTML and at the Python level. So in this case, for example, I got an issue with my Python code being invalid. And it tells me the exact line, because instead of writing pi 4 in, I wrote pi 4 on. And it complied that there is, at that line, there is on instead of in, okay? So I get Python code that gets validated. And some of the features that I already explained to you, which are the error reporting, whenever the Kajiki template fails, you can inspect it and see what failed. You get automatic escaping, so you don't have to remember to remove any character from the input that might break your HTML or might cause JavaScript injection in your template. It does automatic translation for you. And it automatically minifies the result, the result to a page if you want. Usually it's an option I don't keep enabled, but there are people who care, and it will minify the HTML for you. And the thing that I love most from Kajiki is actually the fact that it validates my HTML too. For example, I still remember that more than 10 years ago, I was working with Ruby, and a really big project we were working on or raised had a page that was broken. And it took us like two hours to find which partial template that it was used from a component as the 20 depth of distance from the page itself had a tag that wasn't properly closed. And we didn't realize and we only got to finding the issue because some user complained that the page was broken. And while in Kajiki, it checks your HTML and it checks that it's perfectly valid. Like in this example, I opened the four with a list item, but then I closed it as a span item, a span tag. And Kajiki says you did something that doesn't make sense. You opened a list item and now you're closing a span. This is clearly wrong. So you can see that it's going to prevent you from any errors. It's going to do a lot of things for you. And it's actually faster than most of the template engine you can find around. And here is an example of the automatic escaping that I was telling you. Like if I render a Kajiki template with Apple as a fruit, but in this case, Apple has the Angular brackets. So it should break our HTML because I get an Apple tag which makes no sense at all. While Kajiki detects it and it will print as a result the escape version of the Angular brackets. So it will print the less than entity and the greater than entities instead of the Angular brackets. So it means that you don't have to care too much about your users, writing in their comments malicious JavaScript or things like that. Because when you will render the comment that they provided, even if you stored the malicious code into your database, Kajiki will escape it for you. And you won't be able to break your page. And the translation, if I write something like this, I like through it, then Kajiki automatically detects that the I like part can be translated. It's simple text that is interesting for humans and not interesting for the HTML parcel. So it's something that we can translate. And it automatically wraps the text for you into a get text code. If you didn't provide any translation, it will just output the default text you brought. If you provide the translation, it will correctly translate it. And it does minification. For example, in this case, you can see that I brought a template which is rendered to this set of list items. And if I strip the text, which is enabled this option in Kajiki, Kajiki will output a version of the HTML which is stripped for all the empty spaces, which is still valid HTML, so it will maintain, like, content of parlay or scripts or things like that. But it will strip anything that it knows that it can strip. And of course, like many other template engines, if you are not working with HTML but you are working with something else, you can use it on plain text. So in this case, it's the Kajiki syntax for plain text. Like we did the example of using a template engine with JSON or things like that. Okay. The time was short and I did this talk last time, like, three years ago, so I didn't remember everything. Hope you enjoyed it. It was a good fallback. And if you have questions, feel free to ask. And try Kajiki and let me know what you think. Okay? Thank you. Oh, yeah. Not directly related to Kajiki, but what is happening with Turbogears? I mean, is it still under active development or because it kind of got folded into whatever the pyramid and then there was another one that began with P and they were going to, you know, which was supposedly the whiskey thing. Is it still under active development or what's going on with it? Yeah, it's still under active development. It became the default template engine in Turbogears in version. No, but Turbogears itself. Yeah, yeah, yeah. We just released, like, three days ago, version 2.3.11, if I'm correct. Okay. And there was a major overwrite during version 2.3 that made it, like, four times faster and it's not depending on pylons anymore, but it's still fully backward compatible. And the upcoming version, which will be version 2.4, has a major overwrite in the plugin system for configuration and things like that. So it's still under active development and it's trying to maintain full backward compatible while moving on and things like that. And how any developers are actively working on it? Currently, I'm currently the release manager for Turbogears and there are, like, other three people that continuously work on it on a daily basis and there are, like, seven, eight people that contribute from time to time. Okay.