00:00:23.720
Good morning everyone.
00:00:28.960
My name is Akira Matsuda. Today, I'm going to talk about my personal history, or rather my story related to Ruby template engines.
00:00:33.399
I'm from Japan, and I usually work on Ruby and Rails projects. You can find me on GitHub as amatsuda. What I mean by a template engine is a kind of software that compiles text files plus Ruby into HTML files, especially in Rails.
00:00:58.920
The files are usually named like app/views/something.html.erb. My first Ruby template engine was, of course, ERB. It's the default engine included in the Ruby standard library, so I guess everyone's first Ruby template engine must be this one.
00:01:20.759
The syntax is very straightforward, allowing you to insert Ruby code into HTML files using specific tags. This felt very familiar to me since I used to be an ASP, PHP, and JSP programmer.
00:01:30.480
And the ERB specification is defined as ERuby, created by Shou Matsumoto, who was Matt's boss at his company. Surprisingly, he said he copied the syntax from eRuby, so I just wanted to mention that ERB is not originally Ruby's design.
00:01:52.760
You know, sometimes ERB can be problematic. If you want to render something, mistakes can happen. This can lead to broken HTML, but browsers are clever and can adjust; sometimes it works, but sometimes it doesn’t, which can be very frustrating.
00:02:09.920
I always wondered why frameworks like ActionView or ERB don’t validate responses. Then I discovered HAML—hear me out, HAML is supposedly a templating language that emphasizes beautiful and concise markup. It parses this markup and compiles it into valid HTML, which is a significant advantage.
00:02:27.880
The HAML syntax looks really neat and clear, allowing me to eliminate the broken HTML problems. Then one day, a Rails newbie came to me and asked why HAML was so slow and how he was experiencing it. His JSON API was fast, but when he rendered HAML with the same data, it was slow.
00:02:41.440
This newbie, whose name is Minero Oki, is a Ruby committer known for creating Net::HTTP and a variety of other libraries, including an influential Ruby book titled 'Ruby Hacking Guide.' He used to be a Rubyist—and after quitting for a while—came back to the Ruby world recently, discovering that HAML was slow.
00:03:01.680
He speculated that HAML's speed issues were significant. I thought, yes, HAML might be a little slow due to its complex syntax. Although he's a super smart guy, he’s still learning Rails, so I thought maybe there was something off with his HAML code.
00:03:21.200
I explained that while parsing and compiling HAML can be a bit slow, it doesn’t really affect performance in the grand scheme because ActionView caches the compiled Ruby code, and subsequent requests will benefit from this cached-result.
00:03:38.240
So, essentially, the compilation only happens once, and who cares? However, I advised him if the view is slow, it could be due to dynamic URL generation methods like `url_for`, which can also be quite slow.
00:03:46.280
We should fix this in Rails 5. Anyway, I wanted to verify my assumption, so to compare HAML and ERB, I created a new Rails project, ran a basic scaffold that had 1,000 records, and made 100 requests to analyze the performance.
00:03:54.480
From the log file data, I calculated the total response time and rendering time for views. I did this for both HAML and ERB, and the results showed that Minero was right: HAML indeed is a tad slower than ERB.
00:04:14.760
The difference is around 7%, which is noticeable but not enough for us to panic. So, what should we do? Let’s do nothing! A 7% performance difference isn’t a big deal. We need to focus on more critical bottlenecks, after all.
00:04:37.520
Even if a template engine is 7% slower, the total response time might be impacted by less than 1%, which is inconsequential. If performance is paramount for your application, consider switching engines instead of wasting time on a marginal discrepancy.
00:04:57.440
In fact, what we should aim for is a balance between performance and developer happiness. During a recent talk, I recommended adding more servers if your application isn’t fast enough. Alternatively, if you're deeply concerned about that 7% difference, you could always switch back to ERB.
00:05:18.800
But for me, syntax is significant. If the template engine compromises speed for syntax, it can deter developer motivation. So you could explore alternative solutions, and while searching, I came across an engine called Slim.
00:05:38.240
Slim claims to be lightweight and fast, built on a template engine abstraction framework called Temple. I was intrigued by how Slim's syntax necessitated a pipe character for rendering content, which felt odd compared to HAML and ERB.
00:06:01.520
Though it might be faster than HAML, I personally prefer HAML's straightforward syntax. Slim could very well be a good fit if performance is your priority.
00:06:23.440
But again, if performance is what you're after, you might be inclined to choose Slim over HAML. However, I personally dislike the pipe syntax,
00:06:35.680
So here's my take: it's always better to improve. A fast software is always preferable to slow software, even when not critical. I had the opportunity to commit to the HAML project once when I made a pull request to ensure compatibility with Ruby 1.9.
00:06:57.760
Although they were also focused on dropping support for older Ruby versions, they still granted me commit access, and I started reading and contributing to HAML to enhance its performance.
00:07:19.760
However, despite improvements, HAML remains slower than ERB because compiling HAML often results in generating a larger amount of Ruby code compared to what ERB generates.
00:07:42.760
After my improvements, the compilation resulted in huge amounts of Ruby code, which slowed down performance compared to simpler ERB compilations.
00:08:04.760
The problem with HAML isn't just speed or syntax; it's about the balance between those aspects and compatibility. Attempting to improve it without introducing breaking changes proved to be challenging, so I made the decision to fork it.
00:08:24.760
This process, which I discussed last time at RubyConf, led me to create HAML X. Its current status is that it's close to reaching ERB's speed but it still needs work.
00:08:45.760
I haven't released this yet as I want to ensure it's stable before making it publicly available. A second approach is to build a completely new framework by starting from scratch.
00:09:07.760
One colleague of mine started building his own version of HAML from scratch just for fun, while my approach involved forking HAML.
00:09:29.760
He utilized the Temple framework, which is used for building Slim, but building a new HAML on Temple turned out to be notably complex, and I ultimately decided it wasn't feasible for me.
00:09:51.760
However, although HAML is complex, this individual has made notable strides in his project. This repository is already functional, meaning it's possible to install and use it.
00:10:13.760
Benchmarks indicate it may even be faster than Slim, suggesting that it performed some optimizations that Slim hasn't accomplished yet. This might be the fastest template engine available at present.
00:10:35.760
However, please bear in mind that this is still an experimental project; no one currently relies on it since it remains in its infancy.
00:10:57.760
This brings us to a naming issue; it's unfortunate that it's called Fast HAML, but if you feel your bottleneck lies in the template engine, it might be worth checking out.
00:11:20.760
Moreover, it could be fun to experience what might be regarded as the world's fastest template engine. My talk today was titled 'A Quest for the Ultimate Template Engine.' I believe the ideal template engine must have both good syntax and performance.
00:11:42.760
I can confidently claim we are getting quite close to developing the ultimate solution. Please stay tuned for more development, or feel free to contribute to HAML or even to create your own engine.
00:12:07.760
If you’re interested enough to join the community, it would be great! Thank you for your attention.
