Pre-Conj Interview: Anna Pawlicka
From OO to Clojure Workshop!
Watch my free workshop to help you learn Clojure faster and shift your paradigm to functional.
Talk: Om nom nom nom
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
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).
Anna Pawlicka generously agreed to do an interview about her talk at Clojure/conj. The background to her talk is available, if you like.
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?
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?
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 :)