Pre-Conj Interview: Anna Pawlicka
Talk: Om nom nom nom
Background
Anna Pawlicka's talk at the conj is about Om, David Nolen's project, started in December of 2013. It's essentially a wrapper around Facebook's React. It's a way to define HTML components functionally and has been making quite a splash.
David Nolen's talk at Clojure/West relates Om and React to the history of the GUI. It's the best high-level introduction I can imagine and discusses the ideas that motivated its design. If you watch one video to prepare for this talk, this should be it.
For a good talk about React itself, check out Pete Hunt's talk Be Predictable, Not Correct. He's one of the main contributors to React and has been evangelizing it.
Why it matters
React is significant because it is very different from other Javascript MVC frameworks. It takes a very functional approach instead of object oriented. React makes much easier to reason about the UI. Om has also made waves because David Nolen has shown that using ClojureScript's immutable data structures with React can be faster than Backbone.js (a very popular library) even though immutable data is commonly considered slower than mutable data.
About Anna Pawlicka
Anna Pawlicka recently gave a talk at EuroClojure about Reactive data visualisations with Om. The slides are available (they're not visible in the video).
Introduction
Anna Pawlicka generously agreed to do an interview about her talk at Clojure/conj. The background to her talk is available, if you like.
Interview
PurelyFunctional.tv: How did you get into Clojure?
Anna Pawlicka: During my final year at university I was looking for a contract work or a summer internship and my recruiter suggested a big data startup. Description mentioned Clojure so I solved some 4clojure problems and they sparked my interest. Computer Science course I studied was mostly based on Java so it was refreshing if not challenging to try functional programming. I got a Clojure in Action book, applied for the internship and luckily was offered the job. It was a fun summer: lots of Cascalog queries, friendly Clojure Dojos and interesting talks organised by London Clojure Community. It felt like home and you don't walk away from that feeling. I stayed for both the language and community.
PF.tv: You've been presenting and blogging a lot about Om. What are you using Om for and why?
AP: We've been recently working on a building performance platform at Mastodon C (project is open sourced). It's built around high volumes of data and big part of it was UI programming. We were looking for something that performs well but isn't t too complex and Om came out just in time for us to solve this problem. We've built the entire UI using Om and we combined it with d3.js and core.async for nice data visualisations and user interaction. I don't think we'd be able to achieve that using vanilla JavaScript. Sure, there were some bumps along the way but the overall reusability makes it worth a while. Outside of my day job I'm working on a in-browser genetic algorithm testing tool, using Om and Quil, but with all the presenting and other activities I had to pause the development for a while.
PF.tv: I've used React or Om for a few things and it quite simply enables me to develop UI interaction that would be too intricate otherwise. How has your experience with Om been relative to other frameworks?
AP: I haven't used any frameworks as it's just easier to mix and match various Clojure/ClojureScript libraries depending on one's needs. Om was the first library we've tried for interacting with React and it suited our needs well enough that we haven't had the need to try anything else. If you choose a framework, like let's say Hoplon, you have to go with its programming model and you lose the ability to control every part of your stack.
PF.tv: You say you're using Om with d3.js. Om is a very functional style, while d3 uses mutation pervasively. How does the integration work? How well do they work together?
AP: Fortunately both are driven by data so having d3 visualisations render on your application state change makes perfect sense. I use interop a lot, and although it doesn't look as nice as pure ClojureScript, it does the job. We can easily replace iteration methods like map and reduce with their ClojureScript alternatives. The only problem is the type coercion between Clojure's data structures and JavaScript's Object. It's not always immediately clear which one should be used where. The perfect option would be to control SVG via Om (or similar library) and use C2's functions to calculate path data. But I haven't tried that myself yet. Charts I've been working on are quite complex and d3 comes with this gold mine of resources that none of the other visualisation libraries has. I'm not yet done experimenting though.
PF.tv: Can you explain the basic models of Om and d3?
AP: D3 performs data-driven DOM manipulation, e.g. you can build a bar chart out of an array of numbers and when your data changes so will your chart. D3 can manipulate any part of DOM and has lots of helper functions to compute our visualisations. React/Om works on DOM as well - we write functions that translate our data into a DOM, but the difference is that the DOM is virtual. Each time the data changes, React/Om compares the old and new state and computes the minimal set of transformations that will be applied to the real DOM. DOM operations are slow so naturally this virtual representation speeds things up by skipping unnecessary transformations. This means that both Om and d3 want to be in control of the DOM inside our component. To make use of both libraries, you can either have Om take care of everything (but this means we need to write functions to compute paths, scales, etc.), or you could use d3's scales, projection helpers and path generation while having Om generate and manage SVG, or you can have an empty div rendered by Om and allow d3 to generate and manipulate the SVG inside. The latter is the most common approach, probably because we leave the decision whether to re-render to Om (skipping any insignificant data changes), and when Om decides to render the component, d3 takes care of the rest. We combine the best of both.
My talk will include some of that, with examples, since you can't have a dashboard without a nice chart :)
PF.tv: I see. It sounds like they work well together. I wouldn't have guessed that.
In the talk you mention live data. How does your system handle that?
AP: I don't have an actual system that I plan to demo - the talk is based around various ways to create, reuse and combine Om components to display data. Long polling and HTTP streaming are available through HTTP Kit, but I also like how Sente combines that with core.async. But the focus is mainly on the components themselves - how you can mix and match them.
PF.tv: Really cool.
Talks are always limited in time, and there's lots of context that you assume people have (or wish they have). What is something people can learn more about to help them get ready for your talk?
**AP **: I will try to keep the talk as self contained as possible, but I won't be able to cover things like the basics of web development with ClojureScript - this would be material for a separate talk. However, more and more people are using ClojureScript so I hope most of the attendees shouldn't have a problem with that. Those who feel that they need to prepare more will find lots of resources online.
PF.tv: Where can people follow your adventures online?
AP: The usual: Twitter, my blog and GitHub account. I'm also often on #clojure and #clojurescript IRC channels if someone wants to chat.
PF.tv: Ok. One last question: when they make a movie about programming languages, who will play Clojure?
AP: That's a tricky one! I'd say Leonardo DiCaprio since he's one of the best actors yet still without an Oscar (read: very good but underappreciated) :-)
PF.tv: Thanks for a great, informative interview.
AP: Thanks for putting this together. It was my first interview and it was fun :)
