107

107 JSJ ClojureScript & Om with David Nolen


Panel

Discussion

01:42 – David Nolen Introduction

03:10 – ClojureScript

04:40 – Why ClojureScript?

05:25 – Immutability

09:40 – React and Om

11:47 – How ClojureScript and Om make React Faster

14:08 – Data Structures

19:00 – Learning

22:21 – Object Observation

24:03 – Solving Problems with Om

  • Angular's M story = function MYourself() {}
  • DataScript

27:12 – Mori and DataScript vs ClojureScript

28:31 – MVC

30:13 – How Clojure vs Lisps/Functional Languages

33:08 – Getting Started w/ ClojureScript

38:01 – Coming Soon:

48:05 – JavaScript & ClojureScript

44:45 – cljx

Picks

Next Week

AngularJS with Igor Minar

This episode is sponsored by

comments powered by Disqus

TRANSCRIPT

MERRICK:  When I was 17, I was at jQuery Conf in Boston. And I’m a total newb programmer. I asked Yehuda Katz if Ruby was an object-oriented language. And he just laughed at me. [Laughter] CHUCK:  I don’t blame him. MERRICK:  I was bullied, dude, bullied on the spot. [This episode is sponsored by Frontend Masters. They have a terrific lineup of live courses you can attend either online or in person. Their upcoming course is Hardcore Functional Programming in JavaScript with Brian Lonsdorf. You can also get recordings of their previous courses like JavaScript the Good Parts, AngularJS, CSS3 In-Depth, and Responsive Web Design. Get it all at FrontEndMasters.com.] [This episode is sponsored by WatchMeCode. Have you been looking for regular high-quality video screencasts on building JavaScript done by someone who really understands JavaScript? Derick Bailey’s videos cover many of the topics we talk about on JavaScript Jabber and are up on the latest tools and tricks you need to write JavaScript. He also covers language fundamentals, so there’s plenty for everybody. Looking over the catalogue, I got really excited and I can’t wait to watch them all. Go check them out at JavaScriptJabber.com/WatchMeCode.] [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.] CHUCK:  Hey everybody and welcome to episode 107 of the JavaScript Jabber Show. This week on our panel, we have AJ O’Neal. AJ:  Yo, yo, yo, coming at you live from Provo. CHUCK:  Jamison Dance. JAMISON:  Hey friends. CHUCK:  Merrick Christensen. MERRICK:  Hey guys. CHUCK:  I’m Charles Max Wood from DevChat.TV. And this week we have a special guest, David Nolen. DAVID:  Hi. How’s it going?’ CHUCK:  Do you want to introduce yourself really quickly? DAVID:  Yeah. So, I’m David Nolen. I’m one of the lead developers on the ClojureScript project. I also created the Om library, which is a lightweight library over Facebook’s React that takes advantage of immutability. I was recently employed at The New York Times. I was there for four years. And now I’ve joined up with a company called Cognitect. They’re sort of the stewards of Clojure as well as a new database that’s immutable called Datomic. JAMISON:  You just answered all the questions I was going to ask. DAVID:  Oh. [Chuckles] CHUCK:  Alright, let’s do the picks. JAMISON: Oh, cool. No, did you move to Cognitect to work specifically on ClojureScript? DAVID:  Not specifically. But that’s definitely one of the perks of working for Cognitect and that for me ClojureScript was just like a labor of love and something that was just fun that I did on the side. And it was exciting to see the community around it take off. And then Cognitect approached me and they said there were some projects they wanted me to work on and I’d also be able to do, spend some work time maintaining ClojureScript. That was definitely an attractive aspect of joining forces with them. JAMISON:  Sure. Were you using ClojureScript at The New York Times before or was it more of a hobby thing? DAVID:  There wasn’t any ClojureScript at The New York Times. My team, my past team, was called Interactive News and our stack was primarily Rails and quite a bit of JavaScript on the frontend. But yeah, it was mostly Rails and JavaScript. MERRICK:  So, I would love to, for a lot of people, what is ClojureScript? DAVID:  It’s an implementation of Clojure, which was first created for the JVM. The JVM implementation is now, I think coming up on seven years if not already seven years old. ClojureScript is now three years old. It’s finally in the point where it’s pretty mature. There are still some things I think we need to see fixed before we bless it as being 1.0. But it’s come a long way. CHUCK:  Doesn’t Clojure run on the JVM? DAVID:  Clojure runs on the JVM, yes. Clojure actually compiles to JVM bytecode, which is pretty cool. And it’s pretty fast for a dynamic language. ClojureScript, it’s a source to source compiler. So, Clojure Script takes only a slightly different version of Clojure and compiles it directly to JavaScript, very much in the same vein as CoffeeScript or the other transpilers that are out there. JAMISON:  It provides a whole standard library along with that though, right? It’s not just a syntax translation? DAVID:  Yes. So, some people get confused. So, there is no runtime. There’s no runtime support or any weird thing that we do. We really do just emit JavaScript data structures and JavaScript functions. And that works because Clojure is basically more or less oriented around functions. We generate JavaScript objects because a lot of the data structures need to be fast. And JavaScript objects are now pretty heavily optimized. But yes, we do ship a large standard library. MERRICK:  Why would somebody use Clojure over raw JavaScript or, I’m sorry ClojureScript to be precise, but over JavaScript or CoffeeScript or TypeScript, et cetera? DAVID:  So, ClojureScript is probably more different than TypeScript or even Dart and CoffeeScript are from each other. Those languages for the most part are class-oriented. They don’t actually, the semantics aren’t that different. They’re pretty much object-oriented, imperative. So, programmers really like them because they’re well-designed and they’re very familiar. Clojure is a little bit more radical in that it’s oriented around immutability and that’s not something you see very much in those other languages. We can dive into why immutability’s cool, but that’s really the big difference. MERRICK:  Let’s go there then. Why is immutability cool? DAVID:  So, immutability is neat. So, something that JavaScript programmers I think do all the time, a lot of code, you do object extend, right? That’s really common. You have some object and you want to add some properties. Generally what you have to do, if you get something from somebody else you have to be, “Oh, I have to clone this thing because I got this from somebody else.” So, worrying about aliasing or mutating somebody else’s code or having to defensively clone something, that’s something that ClojureScript programmers don’t do. And once you get that, there are a lot of, the types of programs you might write get dramatically simpler because it’s just not something you’re concerned about. So, if I would say anything, ClojureScript tries to deliver on the convenience, at least at the linguistic level, that JavaScript offers. But it tries to replace all the places where JavaScript is sort of fast and loose about mutation. It tries to add a little bit more discipline to that. CHUCK:  When it compiles, it just ignores the parts that implement mutability and things that we have on regular JavaScript objects? DAVID:  That’s not true. So, the other thing is that ClojureScript’s really pragmatic. I mean, of course there are lots of types of programs one might write where you just need it to be high performance. And in fact, our immutable data structures, the reason they’re so fast is because under the hood we do use mutation. That’s why they’re so fast. We do lots of crazy tricks around cloning arrays and sharing structure between different immutable values as much as possible, and only mutating the part that’s changing. And we expose that, those facilities, to users because there are programs where you might care, where you need it. And also, it’s actually super important for inter-op, right? If I want to talk to the canvas tag, I have to set properties on the canvas tags. So, I need access to mutation. But the idea is that when you’re writing a big program, the places where you use mutation, it’s quite small whereas in the typical JavaScript program, mutation’s happening everywhere. JAMISON:  So, I feel like that’s a really concise definition of immutability. But I don’t think we’ve talked enough about how much that, I mean that’s a pretty huge paradigm shift from the way that most people program most of the time in the browser. Can you talk about maybe the effects of that? So, we’ve talked about what it is. How does that change the way you write programs? DAVID:  Well, so I definitely think that when you write programs that are less stateful, I think people know this, people like stateless services, right? People understand that’s important. So, if your program is, if you think of your JavaScript program as, “Oh, if I start designing my JavaScript program as a series of stateless services then it’s easier to reason about. It’s easier to test.” And there’s a lot, the way that components interact or different parts of your program interact, there are less variables at play. So, that’s the reason people got excited about Clojure. And then when ClojureScript came out people got excited about the fact that I can have an easier to reason about program and target these amazing JavaScript clients like the browser and Node.js and so on. MERRICK: Sure. It seems like the programming paradigm of mutability and imperative code is so ingrained that these platforms are embracing them wholesale. Things like Object.observe are around state change monitoring and things like that. Do you feel like that’s a mistake? Are the things that you would like to see the browser platform implement, I mean I would imagine that you would think that two-way data binding and some of these things are just the wrong way to think about these problems because they all end up in these really stateful situations. DAVID:  So, everybody has their opinions about these things. I’ve been a professional JavaScript developer for eight years now and I’ve built some fairly large projects that were done in an object-oriented style. And I actually thought they were pretty good. And when I look back, I’d read that code and understand it. But at the same time there’s this sneaking suspicion that maybe there’s something more, something better or faster or more efficient or more expressive than lots of mutable objects and observers everywhere. I think everybody understands, with some discipline you could make that work. But I think, maybe we’ll touch on that a bit, I think React showed that there are other ways to approach the kinds of software problems people are attacking. JAMISON:  Do you want to talk a little bit more about React and Om? Because I’d say that’s one of the things you’ve been most well-known for, recently at least. MERRICK:  Yeah. I think it’s kind of funny because in a sense, you’re sort of the great revivalist for React. People didn’t really get it until you started really talking about its use case. DAVID:  Yeah. So, it’s funny. Actually, when I first saw React my response was pretty much the same as everybody else’s. I was like, “Don’t stick HTML in my JavaScript.” JAMISON:  [None of those angle brackets]. DAVID:  Yeah. I totally wrote it off. I was like, “This is not something I’m ever going to use.” But I have a good friend Brandon Bloom who worked at Microsoft. And he did some stuff on Xbox. And he was familiar with programming games on the Xbox. When React came out he was like, “Yeah, it looks weird. But you really should look at how it works because it’s like the way that game developers do game engines.” And I ignored it. But then Pete Hunt went to JSConf in 2013 and he gave a great talk about the design. How does it actually work? It wasn’t just a sales pitch about how this solves all your problems. It really explained the architecture behind it. And I sort of got an epiphany. It was like because React is based on diffing and it’s not based on observation, I really saw an opportunity for immutable data structures to basically make React’s diffing process much faster. Because of immutable data, the differing algorithm just has to do less work. And that was just a hunch. And then he had had [inaudible]. And Om was an experiment to see, just for fun, I’m going to see if this is any faster. And then it was shocking how much faster it was. And not only just how much faster, I didn’t really have to do that much work. And it was just way more efficient than the types of, I would say when you first set out to write a JavaScript program, people say, “Optimization is the root of all evil.” And that’s true because you’re going to get sidetracked when you’re optimizing. But often when you write a JavaScript program and you’re just doing the naïve way and then it performs really, really badly. And what was fun about React and Om was it was really naïve. I didn’t spend that much time optimizing it. It was cool to see that it was just without much work on my part, significantly faster. JAMISON:  So, I know you’ve covered it in detail in other places. There is a podcast you did with the thoughtbot people where you talked a lot about the internals and how specifically ClojureScript and Om make React faster. But do you want to give a quick explanation of it? DAVID:  Yes. So, the way that React works, actually the React guys have done a great job in making it fast. But basically, React takes, if you look at React it basically takes JavaScript objects as parameters. And in order to do the diffing, what they have to do is they have to traverse whatever value you give them because there’s no efficient way to know that something has been mutated unless of course you can do something similar to this with observation. And we’ll get back to why observation doesn’t give you all the properties that you want. But without explicit observation that works on all JavaScript objects you might be interested in, you have to just walk the entire JavaScript object to figure out what changed between these two frames. And with immutable data structures you don’t have to do this. And this is just simply because if two immutable values don’t change, they’re going to basically point at the same thing in memory. That’s really the key idea here. Whereas in JavaScript you can’t detect it, in ClojureScript you can. Because if something is different, you know it’s different. If something is the same, you don’t need to look at it. This is just based on pointers. In JavaScript if you point to some location in memory and somebody changes something about that thing in memory, the pointer doesn’t tell you that it’s different. Does that make sense? MERRICK:  Sure. DAVID:  But in ClojureScript, if the pointers change in memory, it can’t possibly be the same thing so you know to check. But if the pointers are the same, you do not need to look at the contents of the thing that’s being pointed at. JAMISON:  So, maybe another higher level way to say it is that in ClojureScript, equality is based on the values that are in an object, not where it points to in memory. If two objects are equal in ClojureScript it means they contain the same values so you don’t have to descend down into them to check if their sub-properties are equal or not, right? DAVID:  That’s exactly correct. It’s impossible to change something nested inside of a value and not break the pointer. That’s exactly right. If you try to update something deeply nested in the thing, you’re going to change all the pointers. All the pointers must change. MERRICK:  So, it seems like this would become a memory problem really quickly, right? AJ:  Yeah, that’s what I was thinking. MERRICK:  But I know that FRP people have interesting strategies for abstracting these things with deltas and stuff. How does ClojureScript store these kinds of data structures? DAVID:  The idea is very, very simple. You want to represent an array. But instead of having the array be represented as one huge array, which of course is impossible to update efficiently in a mutable way, you can instead organize your array-like thing in terms of trees of arrays. You would have an array at the root. Say it has four slots. And so, if you want to get to the first thing, you descend down the first slot to the next array that has four slots in it. And then you got to descend again. And of course this sounds like, “Oh that works,” and it turns out if you just pick a really good branching factor, it’s pretty wild what you can do. So, the branching factor in ClojureScript is 32. And say you have to descend 32 of these arrays, you go to depth seven, right? If your branching factor is 32, that’s 34 billion items which I think is, you’re talking 60 or 70 gigs of RAM. That’s pretty wild. So, you only have to hop down seven arrays to get to the thing you want. And that size is far bigger than anything you’re going to want to put in the browser. And so, what’s really cool is that imagine you want to update something that has 32 billion items in it. How many things do you have to update to update one value? You just have to replace seven arrays. That’s pretty crazy. In order to update any value in something that large, you’re only going to have to pay for seven array updates. And as it turns out, JavaScript is now, for arrays that are small like this, cloning is really, really, really fast. If you do an Array.prototype.slice on an array like this, it’s a very cheap operation. MERRICK:  So, you said that ClojureScript compiles to these plain old JavaScript data structures. DAVID:  Yeah. MERRICK:  Do you guys compile to an abstraction for making this simpler to pull stuff out of maybe an abstraction that people could use outside of ClojureScript? Or is it pretty coupled to the ClojureScript compilation output? DAVID:  So, I maintain a separate library only for Node, because the payload’s a bit too big for web clients. But what we did is we exported 60% of the ClojureScript standard library to Node.js. So, if you want to use and you want play around with these data structures we have a pretty nice API. It’s called Mori. I think we’re at version 0.2.6. People use it in production. People are pretty happy with it because you get a lot of the value from ClojureScript without having to use ClojureScript directly. I actually got a really nice email from one of the Meteor JS devs and I think they’re about to release a dependency resolution, package management thing, that uses Mori under the hood, which is pretty awesome. MERRICK:  That’s way cool. JAMISON:  That’s really cool. So, basically the reason that you can officially work with immutable data structures is because it doesn’t copy the entire object. It just copies the smallest chunk it needs to when you change something, right? DAVID:  You only need to copy the path that changed, that’s exactly right. JAMISON:  Okay. I’m not an expert by any means with functional programming. I messed around with trying to do it all by myself with just regular JavaScript and I ended up doing just object cloning everywhere. So, it was [inaudible]. [Chuckles] JAMISON:  It had these extra chunks of code in every single functioned called. It wasn’t super-fast because I was cloning these fairly large objects and stuff. MERRICK:  Well, I’ve been a perpetrator of the chaining Underscore methods and calling it FRP. [Laughter] JAMISON:  Yeah. MERRICK:  Do you guys see this sweet .bind I did with this sweet partial application? [Laughter] JAMISON:  Yeah. That was just a big pain point for me because it felt like I was working against the language. It felt like I was trying to do something that wasn’t made easy by the language at all. DAVID:  Yeah. So again, people like Mori. We tried our best to make it palatable to JavaScript developers. We try to make it as easy as possible. But it is true that ClojureScript can produce better code. ClojureScript will often produce code you would never want to write by hand and stuff that we’ve benchmarked on V8 and JavaScriptCore and SpiderMonkey. And we can do these patterns that you would never want to do. For example, all of our fastest data structures use this 32 array branching factor trick. We have a really, really fast hash map. But in order for the hash map to be fast, you have to, on some JavaScript engines, actually emit a JavaScript literal with 32 nulls in it, in order to guarantee that you get a dense array. That’s something that nobody would every write by hand. But we can generate that for you. MERRICK:  Sure. One of my big questions is I’ve definitely been in the world of state and I think that world is proliferated even worse when you start to use things like the whole Backbone, Ember, Angular mantra. You get into these really stateful situations where you fire a bunch of observers and you’re not sure where in the chain your data’s changed. And it certainly leaves you wanting for a simpler model because things become quite untractable. And what I’m wondering is do you believe this is, I mean obviously you care enough about it that you’re working on it, but do you believe this is a better way of building web apps? And if it is, how can people learn? Because it’s obviously a paradigm shift for most people from the web world to go from this C syntax looking language to this Lisp [parenthes-y] overwhelming look. DAVID:  I really recommend, I’m a big fan of when there’s something interesting or new that’s very different, that’s why I made Mori, was to make immutable data structures less scary. Check it out. Play around with it. See what you think. I actually have some friends at a startup right now and they couldn’t convince their team to build their next thing in ClojureScript. But they decided, “Hey, we’re going to do it in CoffeeScript and Mori and React.” And they’re really loving it. And they’re having a great time. That team is figuring out how to build apps in this way, again without completely getting into how ClojureScript works. I definitely think a lot of these ideas can be adopted without leaving the comfort of your home. MERRICK:  Sure, sure. DAVID:  But as far as to whether it’s the solution, I’m always like, you know I made Om. And you put something out there and people are starting to do really cool things. Things that I’m like, “Yeah, that would have been a really big pain in the butt to do in JavaScript,” and it took somebody, they wrote a tiny bit of code then they have something pretty awesome. Want something that’s really cool? Have you guys seen Goya at all? This thing Goya, it’s a pixel editor. JAMISON:  I have not. MERRICK:  Yeah, that thing’s a ton of fun. And it has undo cooked in because of the immutability stuff. DAVID:  Yeah, yeah. So, it’s awesome. So, it’s a 64 x 64 pixel editor. And he represents each frame, the entire pixel region, as an immutable vector. And it’s awesome. He had to write 50 lines of code to get basically undo. It does no code to do the undo. He gets undo for free. But it also made, you can generate an animated gif from the app states that he’s saved. JAMISON:  Oh, man. [Inaudible] DAVID:  Yeah, it’s really cool. And again, what’s awesome is there’s a lot of code there in his project around the interaction. But the code for the undo and the redo and generating the animated gif, it’s like, “Yes, it should always be that simple,” whereas normally it’s a lot of work to write code that can do that type of thing. MERRICK:  Right. Or it’s horrifically inefficient because you’re either doing these huge clones or you have to do event sourcing yourself. You have to store these deltas yourself. It’s a nightmare. DAVID:  Yeah. It’s not fun. It ends up getting very, very manual. So yeah, stuff like Goya. I honestly did not imagine that somebody would have done this so soon after releasing Om. This is the kind of thing where I’m not sure if Om can solve every problem that exists out there when you’re doing apps like this. But certainly, it’s eye-opening how it simplifies what you would think are hard problems. MERRICK:  Right, just by offering a different paradigm. DAVID:  Exactly. MERRICK:  That’s very interesting. JAMISON:  So, you mentioned a while ago that you could get the benefits of immutable data structures and their equality by doing some more in depth object observation. Do you want to talk more about that? DAVID:  What I was going to say there is that, that works for if you want to do fast rendering. So, a lot of libraries have come out since React that use the virtual DOM but they actually end up doing diffing. They don’t have the hooks that you need if you want to use immutable data structures. And it works great and it ends up being pretty fast. But the thing that the observation method doesn’t give you is this Goya-style, oh it’s trivial to travel backwards in time or forwards in time, or snapshot every state. That stuff, you’re not really going to get from the observation. You’ll still have to record deltas and replay those deltas back. JAMISON:  And that snapshot stuff is more a feature of Om than ClojureScript or React specifically, right? DAVID:  The snapshot feature is really, comes straight from the immutable data structures. And we happen to provide them out of the box. I try to tell a lot of people the data structures that ClojureScript uses are basically ports of the ones that Rich Hickey, the inventor of Clojure, originally wrote in Java. We just ported them. They’re amazingly well-designed and they’re ridiculously fast. They’re fast in the JVM. They’re fast on modern JavaScript engines. A lot of the cool tricks we’re doing, you guys could do too. As long as somebody said, “Oh I want to write a pure JavaScript version of these data structures that ClojureScript has,” really the advantage of ClojureScript is that we’ve been working on these things for three years now. And we’ve been working on them three years, optimizing them for JavaScript engines based on algorithms that were optimized for eight years by Rich Hickey, right? MERRICK:  Sure. JAMISON:  Sure. So, I’m a simple man. I’m bad at programming. [Laughter] JAMISON:  I’m not very smart. When I look at Om… AJ:  Wise. JAMISON:  I see how it’s a great solution for some stateful UI problems. But my brain is just so used to constructing large web applications, like what Merrick said, through these object-oriented frameworks where you construct these webs of nested stateful objects. And it seems like some of these frameworks handle some of the larger issues around building web applications like URLs or multiple different pains in your app at the same or things like that. I don’t understand how Om solves those problems. Does it just say, “Those aren’t the problems I care about solving. You’re kind of on your own for that stuff”? Or does Om try and help you construct whole web applications? Does that question make sense? DAVID:  It does make sense. So, I actually think React is pretty awesome if you’re coming from a traditional MVC thing. React’s amazing feature is that subview updating just works and it’s not complicated. That’s not really necessarily true unless you bring a heavyweight framework into the picture. So, React is able to deliver a huge value just from the way that the diffing works. If I update some data up here in this view, all the subviews are going to update too. And that’s pretty slick. So, we get that. As far as some of the other things, other frameworks do give you a richer, they give you the M part of MVC, right? JAMISON:  Sure. DAVID:  So, if you look at Ember, if you look at Angular or Backbone, there’s a really strong M story. And that actually, Om itself probably won’t directly address that. But there are some things afoot. I think that even the M side, you could take an immutable approach and be able to do really, really cool things with that. But that’s, I don’t have anything to talk about today. But it’s definitely something that we know is missing and is important that Om doesn’t actually provide any real solution for. JAMISON:  Yeah. I guess a simpler way to say my question is it feels like React is a really good view layer and Om feels like it’s a really good enhancement on top of a really good view layer. But that’s not the whole problem that you’re trying to solve when you’re building web applications. DAVID:  You’re completely right. It doesn’t have, it’s missing… I actually think that React is a pretty good C. It’s a pretty good controller as well. But no, as far as how do I represent my data? That needs work. There are some exciting things happening. Something I recommend looking at, right now it’s a bit hard to understand if you’re not deep into the Clojure space. There’s a project called DataScript which is by this Russian fellow. And he basically wanted to have something like Datomic, which is basically the database product that Cognitect makes. But what’s cool about Datomic is that it has this really awesome data log query where you can basically have a database in memory in the client where it’s kind of like a document database, it’s kind of like a column database, it’s kind of like a SQL database, but it’s a lot more flexible. And I’ve done some prototyping with Om and DataScript. And this seems like a really, really cool direction. And that one, I think would flesh out the whole story. How do I store my data? How do I query my data? And how do I render that into a UI? MERRICK:  Sure. I guess one question I have is specifically around Mori and DataScript. You mentioned that these things, that Mori in particular has too big of a payload that you wouldn’t feel comfortable sending it over the wire. So, how is that different than compiling from ClojureScript and sending that over the wire? DAVID:  Yeah. So, the problem with JavaScript people that want to use ClojureScript is that they don’t get to be a part of the compilation process. We rely heavily on the Google Closure Compiler to do whole program optimization. And this is something that, Uglify is pretty popular in the Node world and even in the frontend world. But if you generate code that Google Compiler understands, it completely eats Uglify for breakfast. If I write a ClojureScript program and I go console.log(‘Hello world’), it’s going to actually generate after advanced compilation the line ‘Hello world’, right? So, ClojureScript gets to go through that process. If you’re a JavaScript consumer, you don’t get to go through that process unless you’re writing Closure-compatible code which honestly sucks. That’s the whole point of ClojureScript is nobody wants to write JavaScript that’s compatible with the Google Closure Compiler by hand. MERRICK:  Right, right, because you have to do all that extern files and all those things yourself. It’s a real nightmare. DAVID:  Extern files and it’s very verbose. You have to declare your namespaces. It’s just not a fun way to program. That’s something that ClojureScript handles for you completely. MERRICK:  The other question I had is you mentioned that Om needs an M so to speak. And that’s kind of what your DataScript is. But it seems to me that with a paradigm shift this big, maybe MVC is the wrong pattern. Maybe there’s something else. And I would be curious, does the functional world have an answer towards data to view kind of stuff? JAMISON:  That’s a good point, because MVC came from Smalltalk which is super object-oriented, right? MERRICK:  Yeah. It’s also very popular for managing state and marshalling state. And since ClojureScript has different ways of state maintenance or abstraction, really, it seems like a different pattern would be in order. DAVID:  I actually would disagree with that. So, I started off with Om thinking, “Maybe we’re just going to completely shake everything up.” But the more I played with Om and the more I played around with React and started thinking about it, I even went back and read all the original MVC stuff that came out of Smalltalk. And I actually think that the MVC conceptually makes sense.  You have data. You need to present the data to the user. And you need to interact between whatever the user sees and whatever domain thing they want to manipulate, which is the model. That relationship I think is just correct. That seems to me a great model. My claim is that it’s just the way that MVCs are implemented, that the fact they’re built on mutability and observation immutability, that I think we can get rid of and still get all the things that we like about MVC, which is a very good separation of concerns. MERRICK:  Sure. So, you want to maintain MVC as a way to think about the roles of different pieces of a program, but not necessarily the implementation of MVC we have today? DAVID:  That’s right. MERRICK:  Makes sense. CHUCK:  I want to talk a little bit about how Clojure is different from other Lisps or functional languages. I’ve been doing a bit with Scheme. I’ll admit I’m fairly new to Scheme. But I’ve been playing with it. And I think it’s a lot of fun. But when you say array, I think lists or tuples, depending on what’s in them. And so, I’m a little bit curious. You talked about how you have the concept of an object and things like that. I’m wondering how that is all managed in ClojureScript where it seems like the core functionality, in the functional programming that I’ve done to date anyway, is based around lists which can be loosely correlated with arrays as opposed to something as complicated as an object. DAVID:  Right, right. So, Clojure definitely broke tradition with definitely Scheme and to some degree with even Common Lisp and even with a language like Racket, which is a modern Lisp which is really cool, in that JavaScript programmers, Python programmers, Ruby programmers, they want the right data structure for the job. You don’t want a list. A linked list might not have the performance characteristics that you want. You want a random access data structure. So, Rich when he designed Clojure was like, everybody wants these data structures. We should offer very fast, very good immutable versions of the things that everybody likes. And this is something you hear from Clojure programmers a lot, is that people that come to Clojure like, “Oh I want to use a list,” and people are like, “Well, don’t you really want a vector? That’s what you’ve been using everywhere else. And you know the performance characteristics of vectors. You actually don’t want lists.” In many ways, we embrace what other languages have embraced. The only thing we’re getting rid of is mutability. MERRICK:  Got it. DAVID:  Does that answer your question? CHUCK:  Yeah. It sounds like a little bit more fully-featured Lisp, so to speak. DAVID:  Yeah, definitely. JAMISON:  It feels like it tries to meet you halfway, if you have experience in more traditional object-oriented languages, at least with the data structures. DAVID:  Yeah, for sure. I did skip the little bit you said about being able to do object-oriented stuff. And this is actually one of my favorite things about Clojure that’s quite different from traditional Lisps in that a lot of the classic lists that you would use weren’t built on an object-oriented foundation. So, what that means is that when you get a list in Scheme you can’t provide a custom data type that looks and acts like a list. You’re stuck with a concrete type. So, the way that ClojureScript and Clojure is designed, if you want to create your own type and you want to magically work with all code that deals with lists, you can basically create a custom type that satisfies the list interface. And this is awesome because you might want to have a list that has some other methods or other behavior and yet you want it to continue to work with some code that expects a list. And this is one of my favorite features about Clojure. By designing Clojure and ClojureScript this way, Clojure really feels like a programmable Lisp in an even deeper way than just, “Oh I got macros and I can do as much meta-programming as I want.” JAMISON:  So, can I take us in a little bit of a different direction? DAVID:  Yeah. JAMISON:  We’ve talked a lot about ClojureScript. But I know for me it was, I haven’t done a ton, but I’ve played with it a little bit. And it felt like a pain to get started with. Is there a happy path for someone who is a JavaScript programmer who wants to mess around with ClojureScript? I felt like I had to install a lot of tooling and go through a lot of stuff just to get my code running, basically. DAVID:  It’s without a doubt, ClojureScript is optimized for the Clojure community because that’s easily the largest portion of our user base. We’re starting to see more people get interested in it because of things like Om. But as far as being able to provide something that requires zero setup, for example if you like Node, it’s going to require bootstrapping. That’s definitely a goal, a version of ClojureScript that compiles directly to JavaScript the same way that CoffeeScript or TypeScript does. It’s something that we want to do but it’s not super high priority because there’s not anybody in the community that’s really pushing that process along. JAMISON:  Sure, that makes sense DAVID:  But we’re excited about it. If we had it, it would be great. We would love that, to be able to just fire it up and not install anything but Node.js. That would be awesome. MERRICK:  Sure. CHUCK:  I think I gathered before you said something to that effect where, so the compilation, maybe I missed this and maybe I don’t completely understand it, but you’re taking advantage of some of the things that Rich and some of these other folks have already figured out for Clojure, so the Clojure language, you’re doing some of the work in Java and using some of the algorithms that they’ve built? DAVID:  So, let me clarify. So, ClojureScript is a Clojure program that takes Clojure source and generates JavaScript. So, in order to use ClojureScript, you have to have a JVM. And then of course for it to be easy, you have to install, Leiningen is the popular build tool. So, Leiningen makes it really easy, relatively easy to get started with ClojureScript. But if you want a five-minute setup I have a tutorial. It’s called ClojureScript 101. I have a blog post on this I think, or it’s that one and I think it’s called The Essence of ClojureScript. That’s about as easy of a setup as exists. LightTable’s also pretty easy to do. It’s pretty quick. But it’s definitely something we need to work on. It could be a lot better for everybody. And certainly I think when we get to bootstrapping, it’s going to be pretty awesome. It’s something that’s almost done. It’s like this project that’s so close to being done, but somebody needs to push it over the finish line. Hopefully it’s something we can wrap up for the end of the year. MERRICK:  Cool. CHUCK:  Yeah, very nice. JAMISON:  That’s really exciting. It sounds like such a little thing, but small barriers can cause a lot of, I guess people, to be turned away because we’re lazy. [Laughter] DAVID:  Oh, no. Yeah, if it takes 30 minutes to set something up and you’re fighting configuration, that’s not a good experience. MERRICK:  Well, yeah, by the time you actually need to start addressing the syntax differences if you’ve already spent your energy trying to get those jars in order. DAVID:  Yeah, totally. MERRICK:  One question I have is since you guys have this abstraction, this compiler way, then run through Clojure compiler, and you have these immutable data structures, it seems like you could implement abstractions for doing maps and these kinds of things on web workers, a lot of these functional things. I’m wondering if you guys take advantage of any of that or if you just found the performance is not worth it? DAVID:  I will say concurrency is always a bummer to me. And with ClojureScript it’s especially a bummer because concurrency is pretty fun in Clojure. You’ve got a lot of awesome things there, like you’ve got software transactional memory and you’ve got core.async which gives you go-stop concurrency. And we actually do have core.async in ClojureScript and it’s pretty amazing. But things like web workers, we just can’t make them work because you can’t send data over a web worker. You can’t actually move data structures. MERRICK:  Don’t they have, what’s the… JAMISON:  postMessage stuff? MERRICK:  Well, you got to serialize with that. But I thought they had some way of transmuting memory blocks. DAVID:  You have this thing called a transferable but it makes that data disappear from the site that sends it. And that will break everything. MERRICK:  Got it. DAVID:  I wish they would just let us do it, because in the ClojureScript world, we can do that. We could send an immutable data structure into the web worker and it would be awesome. And we would not be worried about these problems that everybody else is worried about. But because JavaScript embraced mutation and the implementers of workers are afraid of that, they make it really unsuitable for the types of things we would want to be able to do. MERRICK:  Sure. Well, that’s unfortunate. [Laughter] DAVID:  Yeah. MERRICK:  Seems like maybe River Trail. DAVID:  River Trail would be cool. It’s one of these things where I’m just if we can get enough JavaScript people to be like, “Look, if we use immutable data structures, we know this is safe. You should take off the training wheels on this.” [Chuckles] MERRICK:  Sure. When I talk to you and other people on this show, I realize that I probably need the training wheels, though. [Laughter] JAMISON:  So David, you mentioned a few times, kind of hinted, that there are things coming up in Om and in ClojureScript specifically. Is there anything? Do you want to layout the roadmap for things that are coming soon? You don’t have to announce stuff that’s not on its way. But just, what do we have to look forward to? DAVID:  I think probably the thing that I’m most excited about is working on the model problem. That’s something that I think needs quite a bit of work. There are some things about the way that Om works that needs fixing, I think. It’s such a young library. To me, the response for something that when I announced it was two weeks old, pretty wild, unexpected. I was actually blown away that people were so excited about it and that it created so much excitement about React. It was really surprising to me. I wasn’t expecting that, actually. So, to me it feels like I just made this thing yesterday. So, it doesn’t feel finished to me. So, there are lots of small things I need to work on. Nothing big. As far as Om specifically, definitely the model thing. I’ve been thinking a lot about the model part recently. MERRICK:  Sure. JAMISON:  That’s super cool. MERRICK:  I have one question that might be a really dumb question. But it seems like there are certain things in the platform that you can’t abstract state away, like DOM APIs. Is that why you push for React so much because it’s an abstraction for the DOM which is so stateful? DAVID:  Right. So, I would actually say that until React came out, I thought ClojureScript was cool and it was a cool idea. I myself wasn’t convinced that it was good enough to stop using JavaScript to do UI work. It was really React that said, “Oh finally. These immutable data structures are really awesome,” because now we don’t have to talk to the DOM and React can talk to the DOM. And then our data structures really get to shine. Now, it’s really valuable. Prior to that, it really felt like I would look at ClojureScript code and be like, “ah, it looks like you’re writing some JavaScript in ClojureScript. Yeah, I don’t really see the big win here.” Some aspects of the program are simpler. Certainly core.async was pretty awesome. I like the fact that core.async tried to solve the complexity around asynchronicity and managing lots of requests and complex control flow around asynchronicity. But it really wasn’t until React I was like, “Okay ClojureScript could be awesome for doing UI work when coupled with all these other things,” like actually have a story that’s compelling, that’s like this seems a step up from what people were doing before. MERRICK:  Right, because otherwise people could just circumvent all the immutability story by just working through the DOM, right? DAVID:  That’s exactly right. You would look at typical ClojureScript programs and they just use jQuery and they mutate the DOM there in many different ways. They’re mutating handlers, they’re adding event listeners or [inaudible] them. MERRICK:  Classic JavaScript plebeians right there. [Laughter] JAMISON:  I am one of them. DAVID:  It’s actually not JavaScript plebeians. No, I like JavaScript and I’m still actually funny enough writing quite a bit of JavaScript right now. Still, the point is that why migrate from JavaScript if you end up just writing JavaScript in a different language? And you have to because the host and the environment really don’t allow you to abstract it away. So, React was eye-opening. I was like, “Oh it is possible to add a layer.” And to me, what was impressive was that, oh JavaScript engines have come so far that adding this type of abstraction is not actually a bottleneck. MERRICK:  Sure. JAMISON:  That’s a good point. This probably would have been a different story five or ten years ago before the explosion of competition between browsers. DAVID:  I think they would have tried and it just wouldn’t have been fast enough. MERRICK: Right. I think that’s true of most things that we’re leveraging today, though. DAVID:  That’s true. That’s true too. [Chuckles] DAVID:  Actually, it’s funny. Our data structures three years ago, it was amazing. Three years ago V8 was the only one that was really rocking. But now, all of them are really, JavaScriptCore, SpiderMonkey, V8, they’re all really good. MERRICK:  Cool. CHUCK:  So, I have to ask. Do you foresee adoption of things like ClojureScript or even TypeScript or Dart or CoffeeScript, that are a little bit closer to traditional JavaScript, do you see the adoption level of those going up? DAVID:  I think what you’re going to see more, and more important than whether people really get excited about these different compile-to-JavaScript languages is that I actually think that we’re moving toward a time when people are finally getting serious about ES 6. And people are realizing that ES 6 will eventually land. You’re starting to see more ES 6 transpilers. You’re seeing that people are getting really excited about generators. Generators basically let JavaScript people do what we’re doing with core.async in ClojureScript. Generators plus promises are pretty awesome. And you can have those today if you’re willing to use a transpiler. Then the transpilers generate source maps. So, I actually think that in the future, it’s really going to, even JavaScript programmers are going to transpile. They might transpile JavaScript to JavaScript, but you’re still going to see transpilation. So, to me the future is really just like JavaScript will be a compile target for everyone, not just people who are programming in different languages. MERRICK: Yeah, for Angular too. We’re transpiling from ES 6 to ES 5 proper. DAVID:  Yeah. Yeah, I think everybody’s converging on the same thing. It’s not as different as people seem, I think. CHUCK:  Yeah. Any other questions before we get to the picks? JAMISON:  I had one question. It’s kind of related to what we’ve talked about already. You mentioned that most of the people who are using ClojureScript are part of the Clojure community. So, they’re already using Clojure on the server. They want to do stuff in the browser, going back to JavaScript feels maybe unappealing to them after being in this world. Do you think there’s a reason why it hasn’t caught on as much with just regular old JavaScript programmers, moving straight over to it? Is it just because of the paradigm difference between JavaScript and Clojure? DAVID:  I think there’s always going to be a little bit of, “Why should I use a different language?” That’s a huge barrier. I will say that I’ve been happy with the response to Om. I thought it was cool. If you write a technical blog post and you have some real benchmarks and people can try them out and you have a really cool new idea about how you can do stuff, then people do listen even if it’s a different language. And I was actually pretty careful in my first Om blog post to focus on the approach and not the fact that it was a ClojureScript thing. So, I actually think that we might see a few more JavaScript people try it out. It’s really, for me, it’s a non-goal. I’m not trying to convince everybody that ClojureScript is the best thing in the world. I’m much more excited about talking about things like why React is awesome, why React plus immutable data structures is awesome. And definitely some of the benefits of at least some of the things that we have in our compiler and what we get out of that, I think are really cool. But if people like JavaScript, there are lots of awesome things happening in JavaScript. If you had told me five years ago that ES 6 was really going to happen, that JavaScript would have macros, that JavaScript programmers would be asking Lisp programmers about immutability… [Laughter] DAVID:  I don’t think I would have imagined that this would have happened. So, I think the amount of interest from the JavaScript world, even if they’re not actually using what we built, is great. MERRICK:  Cool. One last question from me. Does using ClojureScript and Clojure give you interoperability with server code that isn’t coupled to the server? Node people have that story. What if I have my models in Node and the frontend? DAVID:  Yeah, it does. There’s a tool called cljx which allows people to basically cross-compile. So, you can have one source file and it will automatically be shared on the server and the client. MERRICK: That’s cool. CHUCK:  Awesome. Let’s go ahead and do some picks. Merrick, do you want to start us with the picks? MERRICK:  Whoa, caught me off guard. I don’t have any picks today other than I think it’s so rad that people think about things in such different lights. My mind’s totally blown by this episode. It’s just awesome. So, no picks from me today. CHUCK:  Yeah, I have to agree. Going and doing some functional programming, strictly functional in this way, yeah it’s kind of a mind bend. MERRICK: I love that people have the courage to be like, “You know maybe everyone’s doing it wrong in this little thing.” I think that’s awesome. And just continue to implement stuff, that’s great. CHUCK:  Yeah. Alright, Jamison what are your picks? JAMISON:  I just have one. It’s a book on browser networking. It’s called ‘High Performance Browser Networking’ surprisingly. It’s by Ilya Grigorik. He’s a Google engineer that has spoken and written and thought a lot about performance in the browser. And it’s a fascinating read. I never thought that I would be able to read 100 pages about TCP/IP and not fall asleep. But I did it. And it’s because the book is good. It’s good stuff. CHUCK:  We actually talked to Ilya on Ruby Rogues about HTTP 2.0. JAMISON:  Yeah, he has a section on it. I haven’t gotten to it yet. So, don’t spoil it for me, Chuck. CHUCK:  I’ll get a link put into the show notes for that. JAMISON:  [Chuckles] Okay. That’s my only pick. CHUCK:  Awesome. AJ, did I have you do picks? AJ:  No. [Laughter] CHUCK:  You were so quiet, I forgot you were there. AJ:  I know. JAMISON:  That was a mournful no. AJ:  Just having a bad day, I guess. CHUCK:  Do you have some picks? AJ:  I do have some picks. So, once upon a time I picked ‘The Host’ the movie, which got a fantabulous 8% on Rotten Tomatoes by critics, but 50% by viewers, which means that it must be pretty good and critics just bought things to explode more. The fight scenes were not that great. But the book, I read the book. And the book is definitely better. And I just like the story of ‘The Host’ because I think it’s just a cool idea of what it means to be human and what it is that’s part of our genetics and our bodies versus what it is that’s part of our essence and our soul. And also I have some music picks. One is there’s this original album. I don’t think it actually goes to a game, but it’s called ‘Blue Dragon’. And it’s definitely video game style music. And there’s also this, I think they’re a Canadian based band that I met when I was in San Francisco and I bought some of their CDs and I stuffed them in a backpack or a suitcase or something. I didn’t find them until the other day. But they’re also on Spotify. So, I’ll put in a link to them, Behind Sapphire. They’re like Muse meets Mraz meets Mumford and Sons. They’re not really like any of those things, but they’re kind of a little bit like all of them. CHUCK:  I’ve got a couple of picks. I’ve been playing around with Redbooth. It’s at Redbooth.com. It’s a task management system. I’ve been liking it so far, just a way of managing all of my different to-do’s. So, I have projects for podcasts and then I have a project, it’s just a personal project, and it’s just tasks just for me. And then I set up a family organization for my wife and I. and so, she can put the things in that she needs me to remember to do, because if she tells me I’ll forget. And if she texts me, I’ll forget. But if it’s in this list, it’s on my phone and I’ll remember. Really digging that. Another pick that I have, and neither of these are really related to this show, but I’ve been reading ‘Smart Money Smart Kids’ by Dave Ramsey and Rachel Cruze, who is Dave Ramsey’s daughter. And they talk about teaching your kids about money and finances and outline a whole bunch of things that you can do to help them learn how to manage money. And you can start them pretty young. There’s pretty straightforward stuff that you can do. So, I’m definitely going to pick that as well. And then I’ll throw it over to David. David, what picks do you have? DAVID:  I think I only have one pick today. I read this book last year. I don’t know if people know, but Alan Kay writes on the internet. There’s this really amazing mailing list called ‘the foundations of new computing’ which is actually publicly subscribable. And he recommended this really awesome book called ‘The Dream Machine’. And it’s the history of this man Licklider and how basically he helped interactive computing come to be. And it was probably the most inspiring thing I’d read about the history of computers but specifically interactive computing. And it made me excited again about the type of work that everybody does around user interfaces. ‘The Dream Machine’. JAMISON:  You sneakily picked the foundations of new computing, too. DAVID:  [Laughs] JAMISON:  I was on that list for a while and then I got intimidated by all the smart people and then I unsubscribed. DAVID:  Oh yeah. JAMISON:  It’s too much for me. DAVID:  Yeah. There was also a weird period there. But it was worth it just to be able to filter out Alan Kay’s statements. JAMISON:  That’s true. CHUCK:  Awesome. That sounds really cool. I have to go check that out. Alright, let’s go ahead and wrap up the show. Thanks for coming again, David. DAVID:  Thank you for having me. It was a lot of fun. JAMISON:  It was. This was great. CHUCK:  It’s always fun to geek out over your favorite technologies, isn’t it? DAVID:  Yes. AJ:  Way to be a geek. [Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.]  [Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit CacheFly.com to learn more.] [Do you wish you could be part of the discussion on JavaScript Jabber? Do you have a burning question for one of our guests? Now you can join the action at our membership forum. You can sign up at JavaScriptJabber.com/jabber and there you can join discussions with the regular panelists and our guests.]

x