Why Wagtail’s new editor is built with Draft.js

Have you ever worked with rich text editors? You know how frustrating of an experience that can be. Users enter content without much confidence in how the editor will preserve it. Developers have to harden their sites to handle the unstructured soup that is rich text. Designers see their layout completely destroyed by the cheer variation in shape and length. A recipe for frustration.

It’s time to add some noodles and flavour, give some structure to our bland broth and enjoy rich text again.

Recipe: dead-simple preview environments with GitHub, Travis, and Heroku

Developers love to automate things. Shave yaks. Automation can save tremendous time, but automating complex processes can also be a big time sink. This is a story in compromise.

The other thing developers love is free software. I love GitHub, Travis, and Heroku because they all provide a very generous free usage tier – let’s have a look at how we can leverage them to automate preview environments (think: preview the result of a new pull request) for Wagtail, a project I frequently contribute to.

A disclaimer – the end result isn’t full automation, it still is a manual process. We shall call this semi-automated preview environments.

Python memory profiling and speed benchmarks for the Draft.js exporter

Ever heard of Draft.js? We are rebuilding Wagtail’s rich text content management using this rich text editor framework from Facebook. Apart from a new editor, Draftail, we also needed an exporter to convert Draft.js content to HTML: the aptly-named draftjs_exporter.

In this post I’ll focus on this critical piece of the puzzle, which needs to operate as fast as possible regardless of how much content it has to handle. Memory profiling and benchmarks in a Python ecosystem were new to me, so here is what I learned along the way.