September 25, 2014
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.
Twitter - Github - Blog
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).
This post is one of a series called Pre-conj Prep, which originally was published by email. It's all about getting ready for the upcoming Clojure/conj, organized by Cognitect. Conferences are ongoing conversations and explorations. Speakers discuss trends, best practices, and the future by drawing on the rich context built up in past conferences and other media.
That rich context is what Pre-conj Prep is about. I want to enhance everyone's experience at the conj by surfacing that context. With just a little homework, we can be better prepared to understand and enjoy the talks and the hallway conversations, as well as the beautiful venue and city of Washington, DC.
Clojure/conj is a conference organized and hosted by Cognitect. This information is in no way official. It is not sponsored by nor affiliated with Clojure/conj or Cognitect. It is simply me curating and organizing public information about the conference.
You might also like
October 24, 2014
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
LispCast: 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.
LC: 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.
LC: 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.
LC: 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.
LC: 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 :)
LC: 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.
LC: 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.
LC: 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.
LC: 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) :-)
LC: Thanks for a great, informative interview.
AP: Thanks for putting this together. It was my first interview and it was fun :)
This post is one of a series called Pre-conj Prep, which originally was published by email. It's all about getting ready for the upcoming Clojure/conj, organized by Cognitect. Conferences are ongoing conversations and explorations. Speakers discuss trends, best practices, and the future by drawing on the rich context built up in past conferences and other media.
That rich context is what Pre-conj Prep is about. I want to enhance everyone's experience at the conj by surfacing that context. With just a little homework, we can be better prepared to understand and enjoy the talks and the hallway conversations, as well as the beautiful venue and city of Washington, DC.
Clojure/conj is a conference organized and hosted by Cognitect. This information is in no way official. It is not sponsored by nor affiliated with Clojure/conj or Cognitect. It is simply me curating and organizing public information about the conference.
You might also like
October 07, 2014
Nathan Herzing and Chris Shea's talk at the conj is about using Pedestal, Om, Datomic, and core.async together. They promise to code systems live.
Background
Pedestal was the name for a frontend framework create by Cognitect. They deprecated that framework and used the name for a small piece of it that was libraries for backend web servers, which is now under development. So Pedestal now is a set of libraries for web development. Watch this Webcast for background.
Datomic is Cognitect's append-only database with Datalog queries. A nice introduction is this talk by Rich Hickey.
Om is a library in ClojureScript created by David Nolen. It is a wrapper around React, which is Facebook's library for manipulating the DOM in a functional way. Watch David Nolen's talk for a good introduction.
core.async is a library that brings Communicating Sequential Processes to Clojure and ClojureScript. A great talk on it is one by Rich Hickey.
Why it matters
I've said before that I like experience reports. This one will also combine it with live coding, which is exciting. Live coding is always a risk. This talk will combine four of the major components Clojure brings to the table, which are all very powerful in their own right. What will happen when their powers combine?
Github
Github
This post is one of a series called Pre-conj Prep, which originally was published by email. It's all about getting ready for the upcoming Clojure/conj, organized by Cognitect. Conferences are ongoing conversations and explorations. Speakers discuss trends, best practices, and the future by drawing on the rich context built up in past conferences and other media.
That rich context is what Pre-conj Prep is about. I want to enhance everyone's experience at the conj by surfacing that context. With just a little homework, we can be better prepared to understand and enjoy the talks and the hallway conversations, as well as the beautiful venue and city of Washington, DC.
Clojure/conj is a conference organized and hosted by Cognitect. This information is in no way official. It is not sponsored by nor affiliated with Clojure/conj or Cognitect. It is simply me curating and organizing public information about the conference.
You might also like
March 20, 2015
Brandon Bloom's talk at Clojure/West is about Om in production.
Background
It's hard to believe, but Om was actually started in December 2013. That's just 16 months ago. There hasn't been a lot of time for companies to explore it in production. Brandon Bloom helped build CircleCI's ClojureScript and Om frontend, which is now open source. This will be a wonderful glimpse into the challenges and advantages of Om in a production system.
At last year's Clojure/West, David Nolen introduced Om and the design decisions behind it. And more recently at React.js Conf 2015, David Nolen went a bit deeper.
Homepage - GitHub - Twitter
This post is one of a series called Pre-West Prep, which is also published by email. It's all about getting ready for the upcoming Clojure/West, organized by Cognitect. Conferences are ongoing conversations and explorations. Speakers discuss trends, best practices, and the future by drawing on the rich context built up in past conferences and other media.
That rich context is what Pre-West Prep is about. I want to enhance everyone's experience at the conference by surfacing that context. With just a little homework, we can be better prepared to understand and enjoy the talks and the hallway conversations.
Clojure/West is a conference organized and hosted by Cognitect. This information is in no way official. It is not sponsored by nor affiliated with Clojure/West or Cognitect. It is simply me (and helpers) curating and organizing public information about the conference.
You might also like
April 09, 2015
Introduction
Brandon Bloom generously agreed to do an interview about his talk at Clojure/West. The background to the talk is available, if you like.
Interview
LispCast: How did you get into Clojure?
Brandon Bloom: From 2009 to 2011, I encountered a couple of Rich's talks and writings. Each time I would look at Clojure briefly, but it never really clicked. When ClojureScript was released, my startup was heavily using CoffeeScript, so I decided to take a more serious peek at this new alternative. I immediately fell in love with Clojure and started contributing to ClojureScript. My startup never did get a chance to use ClojureScript, but Clojure on the JVM quickly became one of my favorite tools for prototypes and experiments, and I've lately, I've used it for serious business with some frequency.
LC: You will be talking about the CircleCI frontend, written in ClojureScript and Om. Om is less than 18 months old, and yet it is used in production systems and I assume replaced their previous frontend system. Can you speak to this decision? How was it evaluated?
BB: I honestly can't speak to the decision to use Om. That was made before I got involved. What I can say is that CircleCI was already a big Clojure user and their front end used to be CoffeeScript based. Daniel Woelfel deserves all the credit for choosing Om and delivering a production system with it. I got involved much later.
LC: What were some of the challenges that you faced when developing with such a new library as Om?
BB: Om is/was still evolving. It's got bugs, misfeatures, and other problems. Luckily, I've had the luxury of regular face time with David Nolen, Om's author, out at the Kitchen Table Coders studio in Brooklyn. I think that it's important for new library producers/consumers to interact regularly. Beyond that, the design patterns aren't established yet. It's difficult to simultaneously think deep thoughts about a challenging design space such as UI code, while also building a useful UI for your product. Sometimes, you just need to hack it and you can't be afraid to dig in to the library code while you're hacking it. After that, you need to reflect on whether your solution actually makes sense: Often it doesn't!
LC: What are some improvements to Om you would like to see?
BB: That's a tough question to answer constructively, since David has already picked all of the low hanging fruit that I've pointed out to him. Overall, Om is an absolute delight. That said, it's clearly a first real attempt at the React style of UI development in Clojure. Some parts of Om, like cursors, just never made much sense. Other parts feel like missed opportunities to truly capitalize on ClojureScript's strengths. At this point, my feedback could be rolled in to notes for a second attempt at this style of UI framework in Clojure.
David has made the very pragmatic decision to assume React.js as a long term dependency. However, once you really get in to the weeds hacking on a UI, it becomes clear, at least it did to me, that less layers is always a good thing. Overall, a virtual DOM implementation is pretty easy, although getting it to perform well is tricky. I'd really like to see a ClojureScript library that drops the React.js dependency in favor of a more direct mapping to Clojure idioms.
The dichotomy between primitive elements and Om components (created via om/build) has got to go. It hurts modularity and refactorability. But I also don't particularly like some users' insistence on hiccup forms for a variety of reasons.
The "no local state" descriptors thing should definitely be the only way Om operate.
The "world in an atom" model isn't quite structured enough. We need something more database-like to manage client/server synchronization. Facebook's Relay is impressive and, if you squint right, their GraphQL looks a lot like Datomic's Pull API. I know that Sean Grove has been experimenting with a DataScript-backed UI. I think that somebody needs to ship a prescriptive framework here that integrates a client-side database with the view layer.
I've also got extensive notes for an alternative events system.
Beyond that, toolability is critical. The framework needs a way to design and test an individual component in the browser. You should have to go out of your way to break that, not go out of your way to enable it.
LC: Where can people follow you online?
BB:
- https://twitter.com/BrandonBloom
- http://www.brandonbloom.name/
LC: If Clojure were a food, what food would it be?
BB: Certainly not a burrito.
This post is one of a series called Pre-West Prep, which is also published by email. It's all about getting ready for the upcoming Clojure/West, organized by Cognitect. Conferences are ongoing conversations and explorations. Speakers discuss trends, best practices, and the future by drawing on the rich context built up in past conferences and other media.
That rich context is what Pre-West Prep is about. I want to enhance everyone's experience at the conference by surfacing that context. With just a little homework, we can be better prepared to understand and enjoy the talks and the hallway conversations.
Clojure/West is a conference organized and hosted by Cognitect. This information is in no way official. It is not sponsored by nor affiliated with Clojure/West or Cognitect. It is simply me (and helpers) curating and organizing public information about the conference.
You might also like
