On Tue, Jul 8, 2014 at 12:56 PM, Ryan Kaldari <rkald...@wikimedia.org> wrote:
> On Tue, Jul 8, 2014 at 12:20 PM, Rob Lanphier <ro...@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#Performance > > > > ...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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
