I am a senior engineer at Human Made, where I design complex JavaScript applications and build enterprise-scale WordPress sites. You can find me on twitter at @kadamwhite.
This is a repository of slides from talks and presentations I have given at conferences and meetups over the years.
Technical Disclaimer: Each slide deck should be taken as an artifact of its time—the older the content, the more out-of-date it is likely to be. If you see any technical errors or inaccuracies vs current libraries or evolving standards, please get in touch and I will update the content.
In 2016, WordPress introduced a REST API to expose site content as JSON. Also in 2016, we had the opportunity to present at csv,conf about this paradigm shift: what would it mean for all the content in any WordPress website to be accessible as data? Since then, WordPress has fundamentally reinvented itself using that new API. The project has been reimagined from the inside out, with the humble content block as the foundational unit of site data. But, where was that explosion of data-driven WordPress applications we hoped for?
In this talk we will look at what worked as we integrated this new API into WordPress, and at where we stumbled. We'll explore how roles, access, and authentication limit the utility of data. We'll candidly discuss how burnout affects project stewardship. And we'll also celebrate a tremendous, successful change of course for a venerable open source project, and think ahead to what "WordPress as Data" may mean in five more years' time!
How do you tell the world’s largest open source community that they have to change? Three years ago WordPress co-founder Matt Mullenweg exhorted WordPress developers to “learn JavaScript deeply”. This announcement kicked off a massive project to re-imagine the editor of the most widespread CMS in the world as an accessible, modern single-page JavaScript application; and in the midst of this change, the WordPress community has confronted deep fear, uncertainty and doubt as over half a million PHP developers began to question whether their skills were now irrelevant.
This talk is the story of how we’ve managed the stress and change of rewriting and recreating a fifteen year old piece of software with new languages, tools and frameworks, without leaving our community behind in the process.
This lightning talk investigates how documentation and workflow instructions committed to your code repository as markdown files can improve team communication, reduce switching costs as you cycle between development and meta-tasks, and help keep documentation updated as the codebase evolves.
A Boston reprise of my address from WordCamp Portland, ME in May 2017.
An overview of data visualization on the web for a WordPress audience.
I was honored to be invited to keynote WordCamp Portland, Maine, where I shared my thoughts on how consumer-oriented open source software like WordPress can lower the barrier to entry for new programmers. By encouraging whatever level of technical engagement the writer or author using WordPress feels comfortable with, WordPress enables us to slowly evolve from "customizers" to full-fledged developers; and in doing so, it realizes part of the democratic dream of the early web and stands opposed to unified platforms like Facebook.
Client libraries make it easier to work with APIs; from saving you the trouble of crafting request URLs by hand to providing intuitive data structures to represent the response data, API clients let us focus on our users’ problems and not on the fiddlier nuances of API interactions. But what goes into the creation of a library like this—what can the API of an API client teach us? I will share our design process for the JavaScript client for the WordPress Rest API, and contrast our client’s interface with the Backbone.js client to show how problems like API auto-discovery, custom endpoint handling, URL generation, and response data can be solved in different ways depending on your users’ needs. Building your own client library leads to a greater understanding not just of the WordPress API, but of your programming language itself; give it a try, and make your own!
In this talk we’ll discover the breadth of new WordPress interfaces enabled by leveraging the WordPress REST API, such as visualizations and new editor experiences. How can our API client libraries and the applications that use them be designed for maximum flexibility? The future of WordPress is not one interface, but many.
Over the past two years we have been building a new JSON-based REST API for WordPress. Available today as a plugin, that API could be integrated into a core WordPress release as early as later this year—and with the reach WP has globally, that would mean a "quarter of the Internet" (as WP likes to bill its market share; see W3Techs) would suddenly have unprecedented access to their own content in a structured data format. I want to share the goals we have had while working on the WP-API project and its client libraries, and to open a discussion about how to educate users that they will have access to their data in this way—and that third parties may, as well.
WordPress has been an application platform for some time, but the REST API completely changes what it means to be a WordPress developer. We can now launch WordPress sites with front-ends that don’t use any PHP at all, imagine complex single-page JavaScript applications that run within traditional themes and plugins, or create entirely new editing interfaces and admin experiences. Some of these ideas will inevitably work better than others; but it’s never been a more exciting time to try new things. At the Day of REST London in 2016 I shared several ways that JavaScript and Node.js applications can be built to consume, augment and complement WordPress, and a postmortem of what worked (and what didn’t) in a project that Bocoup executed using WordPress as the editorial interface to a production Node application.
Our industry is built on small parts—libraries, projects, tools, many of them built as side projects. This talk looks at why we do side projects, what we gain from them, and how we can fold some of that exploration into our day jobs, for (as the saying goes) fun and profit.
A brief postmortem of the technical decisions I made while building MBTAwesome this winter.
On a recent project at Bocoup, my team was looking for the best available Node.js content management system… and we picked WordPress! Our clients got all the benefits of WP’s content editing interface, and with the in-development REST API plugin we were able to use that content in our app without precluding any of our other technology choices. This talk will use our project as a case study to share lessons we learned while building a Node client for the API, and why we’re so excited about what the next year holds for the evolution of WordPress as a content platform.
We’re long past the days where a few lines of JavaScript in a single .js file cut the mustard, modern web applications can involve thousands of lines over hundreds of files, and WordPress themes and plugins are heading in that direction fast. You can make your codebase much easier to maintain and expand by breaking your scripts up into modules, encapsulating different logical units in their own files. All these files make developing and debugging simpler but they can take a while to load, so we’ll also look at how to use a build tool to boil all those files back down into a single script for when you’re ready to release the code to your users.
We’re long past the days where a few lines of JavaScript in a single .js file cut the mustard—modern web applications can involve thousands of lines over hundreds of files, and WordPress themes and plugins are heading in that direction fast. You can make your codebase much easier to maintain and expand by breaking your scripts up into modules, encapsulating different logical units in their own files. We will learn several ways to modularize your code, with a focus on AMD and Require.js. All these files can take a while to load, so we’ll also look at how to use a build tool to author your code in dozens of files without compromising performance for your end users. To close, we’ll take a quick peek into the future to discover the native module syntax coming in the next version of JavaScript!
A talk for Somerville Open Studios on what makes for a good art website, and how to make your own with free online platforms.
An overview of Backbone presented through WPSessions.com.
WordPress 3.6 includes version 1.0 of Backbone.js, the JavaScript library that powers the new WordPress media uploader. It can be intimidating to get started with a library like Backbone, but it is a powerful tool for developers of WordPress plugins, themes and web apps alike. In this session we’ll look at several ways to begin integrating Backbone into your WordPress themes and plugins, including a step-by-step demonstration of how Backbone can improve the quality of your existing jQuery code. There’s no reason to stop there, though—to close we’ll walk through other exciting ways to use Backbone alongside WordPress, including how to make a standalone Backbone application that only uses WordPress for its data!
WordPress 3.6 includes Backbone.js version 1.0, the JavaScript library used in the new WordPress media uploader. It can be intimidating to get started with a library like Backbone, but it is a powerful tool for developers of WordPress plugins, themes and web apps. In this session we’ll look at several ways to integrate Backbone into your WordPress themes and plugins, including a step-by-step demonstration of how Backbone improves the quality of your existing jQuery code. There’s no reason to stop there though — to close we’ll walk through other exciting ways to use Backbone alongside WordPress, including how to make a standalone Backbone application that only uses WordPress for its data. Mad science, for fun and profit!
These presentations, with limited exceptions, all use in-browser HTML5 slide deck libraries. I am particularly indebted to the authors of the tools listed below, without whom my presentations would have looked considerably less good and taken considerably longer to create:
The Microphone I am using as a favicon is from The Noun Project.
Images used in slide decks are either credited in the slides in which they are used, via HTML comment or visible attribution text, or else credited in bulk at the end of the presentation.