 So good morning, everyone. Good morning. My name is Akira Matsuda. Today, I'm going to talk about my personal history, I mean, story about Ruby template engines. I'm from Japan. My name is Akira. I'm an ATSUDA on GitHub. And I usually work on Ruby and Rails projects, also these actual projects, I mean, the Ruby language and Rails framework on GitHub. So what I mean by template engine is a kind of software that compiles text files plus Ruby into HTML files, particularly on Rails, the files that are named as app views, something HTML, something. So my first Ruby template engine was, of course, ERB. It's default, right? It's included in the CRuby package as standard library. So I guess everyone's first Ruby template engine must be this one, right? The syntax is very straightforward. You can put some Ruby codes into the HTML file with these special tags. And to me, it looks like very familiar at first because I used to be an ASP and PHP, JSP programmer. And basically, these languages are the same. So, and the spec, the ERB spec is, the specification is actually defined as ERuby. And ERuby was created by Shugo Maeda, was Matt's boss at his company. And he said, he copied, I asked him and say, so he said, ERuby was not his original. He copied the syntax from the URL. So I just wanted to mention that it's not Ruby's original. So ERB sometimes sucks because, for example, if you want to render something like this, we often make mistakes like this, right? Then what's going to happen? The HTML break, it's going to be broken, but it kind of works on the browser because browsers are so clever and kind of rendered somehow. So sometimes it does work, but sometimes it does not work, which is so annoying. So I was always wondering why doesn't the framework like ActionView or ERB or someone, why don't someone validate the response? The framework has to do this job. Then one day, I met Hamel, this boy. Hamel is, according to its official site, it's a templating high crew, which means the template is beautiful and dry and well and then in clear markup. And it parses the markup, then compiles into an HTML. So as far as compiler is working, it always outputs valid HTML file. So the problem was solved. Hamel file looks like this. It's very high crew. So yeah, I really loved it because we're no more having these broken HTML problem. So then one day, the Rails newbie came to me and he said, Hamel is slow. Why Hamel is so slow? This is what he experienced. His JSON API works very fast, but with the same data on the same controller, when he rendered Hamel, then it's very slow. So his assumption is Hamel was slow. This Rails newbie's name was Minero Aoki. He is a Ruby committer. He graded Net HTTP file details, wrapper, rack, emails, tons of these core libraries. And also he's an author of the legendary Ruby book titled Ruby Hacking Guide. So he used to be a Rubyist and he once quit from being Rubyist. Then he came back to the Ruby world very recently and he started using Rails from two, three years ago. Then he found that Hamel is slow. And his book, Ruby Hacking Guide is available online. You can read in the English version here on the internet. So please check this if you're interested into the Ruby's implementation. So I thought, yeah, Hamel might be a little bit slow because it's going to do, like the parsing Hamel is very slow because the syntax is complex. So I thought, yes, I know he's a superstar but he's a newbie on Rails, so maybe he's wrong. Maybe his Hamel code has some problem. I said parsing and compile Hamel is a little bit slow but that doesn't really matter because ActionView caches the compiled Ruby code. Then the second request will be returned from the compiled Ruby code. So compilation runs just once, basically. So who cares? By the way, if you think your Rails view is slow, probably it's because URL for it is slow. My advice is avoid using dynamic URL for a generation like URL for a link to. I'm sorry to say this but these methods might be very slow. So we're going to fix it on Rails 5 probably. Anyway, let's make sure that my assumption was right. So let's compare Hamel and ERB and let's make sure that Hamel is not very slow. So I just create a new Rails project and very basic scaffold like this put 1000 data, 1000 records and run this in production and make 100 requests. Let's take a look at the log file. You see in the log file it shows the total response time and view rendering time, right? So let's make 100 requests and summarize the view rendering time. I did this for Hamel and ERB and the result was like this. So mineral was right. Hamel is a little bit slower than ERB. So Hamel is slow, like 7% slower than ERB. So what should we do? Let's do nothing. We just should let it be slow. This is what I mean. So the 7% performance difference is not a big deal because that's not a bottleneck perhaps. Even if the template engine is like 7% slow but the total response time will be like maybe less than 1% difference. It's not a big deal. So if you really care about the performance then you should stop using Ruby. What we Ruby should really care about is the balance between performance and these things like basically developers' happiness, right? Actually just last week I gave a talk at Ruby on Rails. I mean, Rails. And as I mentioned in this presentation, if your application is not fast enough, add more servers, that's the solution. Or as a second thing we can do is switch back to ERB. If you really care about the 7% difference. But to me, syntax matters. Again, the balance is important. If your template engine becomes 7% faster, the user experience will surely just a little bit improve, I'm sure, but it makes you unhappy probably. It's a motivation killer for me. Or as a third solution, we can find something else, something faster. So how can we find something else? When we find something, we do this. I mean, we do this. I did this, then Google taught me that there's something called Slim and someone is claiming that Slim is fast, so we should use it. The internet said so. So Slim. Slim is something similar to Hamel. It's built on top of a kind of template engine abstraction framework called Temple. The syntax looks like this. I mean, I just wanted to print out Hello World. It's just Hello World on ERB. It's just Hello World on Hamel. But with Slim, you need a pipe for some reason. If you want to print out bigger Hello World, then you can do the first example, H1 Hello World. The first H1 becomes the tag, and the rest will be the content of the tag. To me, it looks weird. It's a matter of taste, but I prefer Hamel's straightforward syntax. So yeah, Slim might be faster than Hamel. I don't know. It's a good marketing. I love it. I mean, really, it's a good marketing. So you can choose, Slim, if you really care about the performance and if you don't care about the syntax. You can choose it. But I don't want to write the pipe thing. So this is my take, improve Hamel. Of course, the faster software is better than slow software. So even if it's not a very critical problem, still it's better to improve. And I really don't know why, but I had a commit bit to Hamel project once I made this pull request. Hamel didn't work in Ruby 189, so I just added 2s here. I had to do this because our application was still on 189 at this moment. But it was 2013, so probably they didn't want to work on 189 anymore. So they gave me the commit right. Anyway, so I got the commit right with this 2s. So anyway, I started reading Hamel, and I made some commits like this to improve the performance. But still, Hamel is slow because after this improvement, for example, if you compile this ERB saying hello, it just prints out hello, it's going to be compiled into this Ruby code, urb out hello. And if you do the same thing with Hamel, Hamel compiles this code into this huge amount of Ruby code, which is apparently very slow. Yes. It's a haiku. So apparently the Ruby code is problematic, so we have to improve this Ruby code to be like this, like this. And so what I did was this. If you want to make some change on the software, you need to care about the compatibility. And I tried to improve without forking, but I found it's impossible without breaking the compatibility to make it faster, as fast as ERB. So I forked it. And actually I kind of talked about this at the last Ruby call. I named it HamelX. Current status is still undone. So current status is, I did this this morning. It's pretty close to ERB, but still a little bit slower. So I haven't released this yet. I'm still working on the fork. This is my take to make Hamel faster. And this is the sixth option. Not to fork Hamel, but create a new one. So my co-worker at Cookpad, a company called Cookpad, which I'm consulting, this person with a weird name, Eagle Tomato. I don't know what it really means, but he has this weird handle name, this guy. After my talk at RubyConf, he started creating his own Hamel, just for fun, probably. So my approach was fork Hamel then cut slow parts from the fork. But his approach was he built Hamel from scratch. His concept was like this. He started building Hamel on top of Temple, which is used for creating Slim. The creator of Temple, I found this from his blog. He said, it's worth trying, but the author of Hamel said it's very difficult because Hamel is so complex, so difficult. And I actually tried to build Hamel with Temple, but I gave up. It is so difficult. But he did it, because this 24 years young hacker is, apparently, he's a better hacker than me. So this is the repository. It's actually already gemmified, so you can install and use it. And Benchmark shows it's super fast. I guess it's possibly faster than Slim, because he made some trivial optimizations that even Slim is not doing such optimizations. So I guess this is the fastest template engine at the moment. But this is still an experiment project. No one uses this. It's just a toy project, basically. So I guess it's not stable, but it's fast. And there's another problem, the name. It's named Fast Hamel, which is a terrible name. But still, it's worth trying. If you're really sure that your bottleneck is in the template engine and you really want to make it faster, then this product will be the best solution, I think. Or if you just want to experience the world's fastest template engine. So my talk was titled, The Quest for the Ultimate Template Engine. The Ultimate Template Engine, in my opinion, has to have a good syntax and good performance. And we're getting pretty close to the Ultimate Template Engine. So please stay tuned. Stay tuned. Or you can do it, of course. You can make it. You can patch Hamel. You can create your own engine, right? So this is my message. If you're interested, please join us. Thank you.