00:00:16.240
Thank you! Hi there, my name is Kevin, and this is a talk about building a theme engine for filmmakers and developers. I'm going to discuss some of the goals and decisions that went into the theme engine we're building at VHX and how these decisions will hopefully give developers some interesting options when they develop for our platform.
00:00:35.920
A quick background on myself: I was previously the Director of Engineering at Vimeo, where I worked for about six years. I've now joined some good friends and former colleagues from Vimeo at VHX, where we're specifically focusing on direct-to-fan distribution. This means working with filmmakers and artists to sell their work directly from their own websites and identities. I'm assuming some of you have podcasts or have self-published eBooks, so the concept is similar. Artists can now utilize their existing audiences and social reach to promote their work, translating into more rights, more money, and more insight into their customers.
00:01:22.479
A few examples of our platform include comedian Aziz Ansari and Sundance films like Dave Grohl's 'Sound City', with whom we got to party at Sundance, which is a pretty sweet job perk! Another Sundance film is 'Indie Game: The Movie.' It's a great developer movie by the way, so check it out if you haven't. Just a few quick screenshots of our platform showcase the analytics we offer our filmmakers, and a glance at the theme engine, which we'll demo shortly.
00:01:54.880
Okay, so some product goals early on: we had our goals, but also some standards to meet. Everyone at our company are big fans of Tumblr, and they set the bar really high with their theming engine. Even more interesting is their marketplace around that theming engine. There’s a model where developers can make themes, and there are even businesses focused on creating themes for sale on Tumblr, which contributes value back to the main goal of the site. We feel this model works.
00:02:28.319
On a very basic level, what VHX aims to do is to accomplish the theming capabilities of Tumblr or Shopify, but with video and e-commerce baked in. As developers, we wanted an awesome developer ecosystem around these themes. If we believe there is a great developer environment for VHX, then developers will inherently contribute to these filmmakers and artists and their distribution needs. Some of these goals include striving to build something simple at its core, which I personally find helps a product as it evolves and scales.
00:02:55.199
Our first goal as developers and users of Tumblr was to address some challenges we observed while working in online editors. Although we offer an online editor, we believed it would be advantageous to work offline and in our own development environment. I’m sure most of you agree that we are more comfortable in our own environments. Having the flexibility to work offline with an online theming engine could be a valuable addition. Additionally, I was keen on implementing server-side rendering for production environments, focusing on rendering performance, caching capabilities, accessibility, and SEO considerations, which are crucial for our model where artists self-market their work.
00:03:54.880
Given our client and server-side rendering needs, we turned to Mustache. It's been around for a long time and is implemented in many languages, making it a very mature library, particularly Ruby and JavaScript, which we utilize. For those unfamiliar, the gist of Mustache is that it takes an object of key-value pairs and a template that references those keys and values. When you call Mustache render, it outputs the expected result. Here’s a quick example of Mustache in Ruby, which is also a minimal version of what our theme engine calls. The same situation exists in the JavaScript implementation.
00:04:50.880
Although Mustache is quite simple and has many limitations, embracing those limitations along the development path has enforced good standards and helped simplify problems and decisions as they arose. Let’s do a quick demo to provide some context. Just know that the left side is dynamically powered and rendered from this Mustache data, which I’ll demonstrate shortly. We have keys for color, image, text, and options. For instance, if you have 'color.mainText,' we render those color pickers. If you have 'image.features,' we know to render images and uploaders, and the same goes for text fields, select menus, and checkboxes.
00:06:34.560
This demo could have been more impactful, but as it stands, the right side is an iframe. It's fully rendered on page load by the Ruby side. This set-up allows us to transfer responsibility and store templates on the client-side, where changing a value, like the color of the main text for example, sends a post message to the iframe with that key-value update. The entire front end can then completely re-render using the JavaScript Mustache implementation, allowing for instant feedback while editing within the online editor.
00:07:20.320
Looking at how this works, we have a simple architecture where a site is themed with many themes. One is the published production version, and another is a working draft. This means that while making changes in the demo, it won’t affect what’s currently in production or what viewers are purchasing or watching. Additionally, the system allows for versioning, letting users undo changes and roll back as needed.
00:08:04.000
A theme itself stores the Mustache templates required for the site, including those for the HTML, stylesheets, and JavaScript. The site then utilizes these templates and variables merged with any site-specific customizations. For instance, VHX might have a default background color of black, but a site can override this with red without impacting the shared master theme across multiple sites. Here’s an example of what a final merged object would look like. You’ll see references to color and image, as well as automatically injected Active Record data. In Aziz Ansari’s example, we would have site data related to the package he's selling, which is a comedy special for five dollars.
00:09:07.360
We also merge in per-request data, indicating whether the current user is logged in, geo-blocked, or whether they have purchased the product. If rendering in JavaScript, that object will be used for the Mustache render. For the Ruby side, the theme engine extends Mustache via a class, using meta-programming to define methods for all these keys and values, which is consistent on both the Ruby and JavaScript sides.
00:10:02.880
Although our current engine is simple, it proves to be quite interesting. We have a clear separation between data and presentation, as well as portable rendering engines, one via Ruby Mustache and one via JavaScript. This separation enhances our ability to use the client-side implementation for live previewing, as demonstrated earlier. Moving forward, our plan is to provide a completely local development environment in addition to the online editor.
00:10:44.000
Eventually, we want to offer an offline theme package that includes templates, variables, and any local assets. With a small script, developers could coordinate the rendering of the theme with JavaScript Mustache, further polishing our local development environment and workflow. We aim to extend Mustache with Handlebars. Thank you for your time!
