On Tue, Jul 8, 2014 at 12:56 PM, Ryan Kaldari <rkaldari(a)wikimedia.org>
wrote:
On Tue, Jul 8, 2014 at 12:20 PM, Rob Lanphier
<robla(a)wikimedia.org> wrote:
Is there someone who has the time to perform and
publish an independent
audit on performance specifically? We currently have this:
https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library…
...which suggests that Knockoff is 50% faster than then next fastest
solution (Handlebars), and over 10x faster than most. If this stands up
to
scrutiny, and holds true as Knockoff gains
feature parity, this is a huge
achievement that we should shout about far and wide, since I believe no
one
disputes that a DOM-based approach is much more
secure than a
string-based
approach...
Yes, it's 50% faster, but we're not really comparing apples to apples.
Knockout/T-assembly requires a pre-compilation step, so we should keep that
in mind in the comparisons. The pre-compilation doesn't affect performance,
but it does add a layer of complexity to the process.
At a minimum, it would seem to affect deployment performance. We are much
more forgiving of things that slow down deployment than we are of things
that slow down typical page loads, but not infinitely forgiving. How much
overhead would this add to deployments?
Template compilation is hardly a new technique (Smarty anyone?), so I'm
assuming that technique could be (and has been?) applied to other engines.
The approach that Mantle is taking is pretty interesting, i.e. allowing you
to use any templating system you want as long as it
meets certain
assumptions. I would love to see Knockout/T-assembly and Mantle move
towards being compatible with each other (which wouldn't take much work).
Then people who want maximum performance/security can use Knockout and
people who want maximum simplicity can use Mustache, etc. I know there are
probably few people on this list who would think that offering simplicity
is important, but we should remember that we are an open source project
with thousands of 3rd party users, many of whom are not professional
programmers, but would love to be able to tweak the interface and build
simple extensions. Adopting an MVC framework with templating/widgets is a
huge step in the right direction, but we would be squandering the
opportunity, IMO, if our only templating system is too complicated for
novice programmers to figure out how to use. If we can offer the best of
both worlds, that seems like the ideal solution to me.
I think I'm with Max on this one. There can be only one. Or two.
Definitely not more than two. Ok, maybe for some applications a third.
But only some applications. Wait, where was I? Oh yeah, there can be
only one. :-)
I'm personally somewhat skeptical about Knockoff, but only somewhat. My
main concern is that we don't end up adopting something that people will
consider to be yet another weird Mediawiki-ism, because we have a lot of
those. If we're going to get into the templating engine business, we
should play to win. That means having something that gets a full-throated
endorsement from *at least* this community rather than "it's so great, it's
one of three approved templating approaches in our codebase". We should
also have something that has all of the ingredients to resonate with a
larger development community than just ours.
Gabriel makes a compelling argument that a DOM-based approach is superior
to string concatenation. A general argument against DOM-based approaches
is performance, but Knockoff seems to have mitigated performance issues so
well that it actually seems to perform better than most template engines.
So, I'm left generally asking the question "what's the catch?"
It sounds like the catch may be complexity, but we shouldn't handwave about
that. Ryan, what's an example of something that's complicated in Knockoff
that's much simpler in Handlebars?
Rob