Transcript
Joy Clark: Hello everyone, and welcome to a new conversation about software engineering. This is Joy Clark and today on the CaSE Podcast I am talking with David Nolen about ClojureScript.
Joy Clark: David is a member of the core ClojureScript team at Cognitect, and he has been so kind to take the time to talk to me today. Welcome to the show!
David Nolen: Hi! Thanks for having me.
Joy Clark: I mentioned that the topic for today is ClojureScript. Could you maybe briefly introduce ClojureScript?
David Nolen: Yes. ClojureScript is a version of Clojure; I guess you could say a dialect of Clojure, though we try to keep the differences small as much as possible... But it's a version of Clojure that compiles to Javascript. It's now about six years old. Rich Hickey and other members of Relevance - which was what Cognitect was called before - announced it in July 2011. So it's been going on for quite some time, and there's a pretty nice, healthy ecosystem around it. Most of the people that use it - it shouldn't be surprising - are Clojure users, so people doing sort of full stack Clojure, where they have some significant back-end component, and they would rather write Clojure on the front-end, then ClojureScript is a good answer for that problem.
Joy Clark: I'm a Clojure developer who has done that, so... We did do a podcast on Clojure itself, so we'll link that in the show notes. But maybe for those listeners who might have missed that episode, could you just briefly describe what the language looks like?
David Nolen: ClojureScript, or Clojure?
Joy Clark: Well, it looks the same, right?
David Nolen: Yes, the idea is that it should be the same. There are, of course, some minor differences... These are largely because Clojure talks to Java, but ClojureScript talks to Javascript; Java and Javascript are two pretty different languages. The interop technically looks more or less the same, but the types of things that you're going to be doing are going to be different. In ClojureScript you're often interacting with the browser and third-party Javascript libraries - a good amount of what people are doing is really that.
David Nolen: If you're not familiar with Clojure or ClojureScript, Clojure is a functional Lisp, it emphasizes programming with values through a standard suite of relatively performant, persistent data structures. Clojure did quite a bit of innovation there when it was released in 2007, and those implementations were more or less ported to ClojureScript I think in 2012. So the same immutable data structures that you like and enjoy in Clojure are available in ClojureScript.
David Nolen: Almost all the standard libraries are mirrored... That's another thing that's kind of fun about ClojureScript - you get to have all this Lisp goodness when doing front-end programming. There is a small, but I think growing community of people who aren't coming from a JVM background, where actually ClojureScript is their first introduction to a Lisp, to functional programming, and then it's not uncommon to hear people really like it, and then be like "Oh, maybe I should check out Clojure, because ClojureScript is pretty cool." That's not how it used to be, but that's definitely a growing area of the user base.
Joy Clark: For those users who might be using Javascript right now on the front-end (or some kind of Javascript variant), what features would you see in ClojureScript that would encourage them to move to ClojureScript instead of Javascript?
David Nolen: Javascript continues to evolve very quickly. For the past 4-5 years it's been actually quite nice... As a language, nothing much was going on for about a good decade, from about 2001 to 2011, but then due to the efforts of the TC39 - the overseeing standards body around the language - you're seeing the language evolve. And actually, it's hard to point out any particular thing about Javascript that you can't do in Javascript, right? There are immutable data structure libraries, there are functional programming libraries for Javascript; Javascript now has a lot of Sugar and syntactical affordances... So if you were going to say "What's the one feature...?", it's kind of hard to point at one thing that ClojureScript can do that you can't do in Javascript.
David Nolen: I think the real difference is what's idiomatic, right? Even though a Javascript developer can use immutable JS, if you've ever used it, it doesn't necessarily feel idiomatic. If you're going to use a library like that, you have to be willing to make sure that everybody that you're going to collaborate with is on board. And it definitely has an impact for interop between libraries.
David Nolen: If you think about ClojureScript, ClojureScript ships out of the box with persistent data structures; it's just the default. Every library that you might use that's written in ClojureScript - the currency is immutable values, so everybody is sort of bought in, and functional programming is highly idiomatic. When you meet somebody else and they say they do Clojure or ClojureScript, there are certain expectations about what that means, and assumptions that you might have.
David Nolen: If you're sitting down an API or a library, that's actually really freeing. You know that the people that might use your thing are going to understand the choices that you made. And that I think is the real difference. It's not a specific feature, it's "What's the philosophy? What's the frame of mind that you can expect when you're interacting with Clojure or ClojureScript libraries?"
David Nolen: If you're just talking about -- today if you're like "Oh, I really love all the ideas", you could cobble a bunch of libraries together and more or less achieve the same thing in Javascript; it's just not out of the box, it's something you have to put together yourself, whereas ClojureScript, it's out of the box.
Joy Clark: Is there an adoption trend for ClojureScript, compared with other kinds of Javascript?
David Nolen: Adoption trend...? It's more or less Clojure programmers, and that's to be expected. It was created for Clojure programmers, and most of the people that use it are Clojure programmers. Even the people that come to ClojureScript out of curiosity, it's more common that those people end up being like "Oh, I like Clojure." ClojureScript is an introduction to Clojure... So that's the main adoption trend.
David Nolen: That said, ClojureScript can compile itself to Javascript. That's existed for about two years, and there is a small but growing ecosystem and interest around "JVM-less ClojureScript development." There's a lot of work to do to make that practical, but there's interest; people in the community are pushing that along. It's not really a priority for us, but we're not in any way discouraging it, and certainly we maintain the bootstrapping capability explicitly so people can do innovative stuff like that.
Joy Clark: Where do you see the language heading?
David Nolen: We really don't try to do anything in the language that's different from Clojure. Most of the language changes happen in Clojure first, and then once they look like it's definitely going to be a certain way, we end up porting that to ClojureScript. Spec is a good example - Spec appeared first in Clojure and was available first in Clojure, and then slowly, over a period of several months, we reached parity, and so on and so forth.
David Nolen: Language changes are really driven by Clojure. That said, there are things that are specific to the challenges of ClojureScript which Clojure is not concerned about. For ClojureScript, that's mostly integrating with the Javascript ecosystem... So something that's not obvious to Clojure programmers, and Javascript programmers, or Python, or Ruby, or whatever. If you're coming to ClojureScript, one thing that a lot of people won't be familiar with is that we integrate deeply with Google Closure compiler, which is the optimizing Javascript compiler. So we produce code that's designed to be understood by Google Closure, because Google Closure provides tons of facilities, but one of the biggest ones is just dead code elimination. So it can analyze your program and determine which parts of the program aren't used, and that can really significantly shrink the size of the final artifact, which is important when you're targeting web browsers. Download time is important for user experience.
David Nolen: The point here is that Google Closure makes integrating with third-party Javascript libraries a bit more challenging, because Google Closure compiler is something you have to write -- you have to write code that's aware of the fact that it's going to go through Google Closure. That's the biggest area of work for us right now - just making it possible to consume more and more of the Java ecosystem, and ensure that that stuff can successfully pass through Google Closure. That's a new focus, that's not something we cared about in the past. So that's probably the next year, to be honest; that's probably where we're going to be spending most of our time, because that's high impact. A lot of what people struggle with (the pain point) is that it is challenging to integrate third-party stuff into your build.
Joy Clark: Yes, I have stumbled on that problem before. That's the externs file, right?
David Nolen: Yes.
David Nolen: Joy Clark:[00:12:12.18] Defining the functions in your Javascript library that your ClojureScript file needs to know about so that the compiler doesn't optimize them away.
David Nolen: Yes. Just to stick on that for just a moment - the Google Closure compiler is a whole program optimizing compiler, so its expectation is that it sees every line of code that will ever be run in your program. The problem is that you want to use a third-party library that's not Google Closure compatible that it's never going to actually analyze or look at. The issue is when you're calling out into what we call foreign libraries - these libraries that the Google Closure compiler will never see - in order to prevent Google Closure from either eliminating something that doesn't need to be eliminated or renaming a property... A huge optimization that the Google Closure compiler does is it takes your human-readable names and it shortens them down into one or two characters. But that doesn't work for properties that it didn't see, some property in a third-party library. In that case, you provide something called an externs file which says "There's an external library that exists, and these are the names that we're calling into, and it's not okay to rename those properties."
Joy Clark: I heard a rumor that that's not going to be necessary in the future... Is that correct?
David Nolen: It's not something you can ever completely get rid of. We would like it to be more unusual that you would need to provide it. If we can successfully pass a library through Google Closure, then you don't need externs files. Actually, what we've discovered is that often Javascript libraries need very small changes to be Google Closure compatible. For example, we can actually right now pass all of React, which I think is more than a hundred source files and all of its dependencies, through Google Closure compiler. I think that's about 40,000 lines of Javascript. And for 40,000 lines of Javascript, we only need four explicit externs, and those four could actually be eliminated just by the most minor tweak to React.
David Nolen: Ideally, in the future - the future that I was envisioning two years ago when we started on this - what would happen is that as we are more invested in the Javascript ecosystem, I want to use React and I try it and I'm passing it through Google Clojure, and I see that "Oh, I only need these four externs", but in fact I wouldn't even need those if they just made a minor change to React. So I can make a PR to React saying "There's this little bit of dynamism that you don't actually need and nobody depends on that or relies on that; let's just get rid of it", and now that Javascript library is fully Google Closure compatible.
David Nolen: We've seen this actually in quite a few libraries, that you need very small changes. This is particularly true for ES6 libraries with static import/export. So our hope is that as we develop the ability to consume Node modules and random Javascript libraries, that that will encourage ClojureScript programmers to make the small PRs to make these libraries Google Closure compatible. Because again, the changes are often trivial. So the answer is yes. Assuming that you've done this, yes, you wouldn't have to provide externs because you've made the change to make that library Google Closure compatible, and then you don't need externs.
Joy Clark: So the solution is for Javascript libraries to become better.
David Nolen: It's going to require effort on our part to interact with that community and show them that it requires very small changes. My suspicion is for the most popular libraries this is going to be a pretty straightforward thing. And then it's going to be harder -- for just any old, random library it'll probably be a bit more challenging and we'll have to solve that on a case-by-case basis. But my impression so far is that if we could cover especially the React ecosystem, because so much of ClojureScript is around React and React-based libraries... If we could cover React and React components and the most popular libraries in that world, as well as React Native, I think the happiness level of the average ClojureScript developer would be greatly improved.
Joy Clark: I believe you. So is ClojureScript like a transpiler or a compiler?
David Nolen: People like to debate what these things mean... I have no strong feelings. I guess some people argue that technically a transpiler is just a compiler; it's from one representation to another representation. I think transpiler was popularized just because you were going from, say, one human-readable source to another human-readable source. I feel like I observed that name sort of become popular with CoffeeScript, because CoffeeScript went from -- you know, you would write readable CoffeeScript and it would generate readable Javascript; that was a value proposition. So it was like a slang to talk about this curious way of designing compiler - readable source to readable source.
David Nolen: I would say probably if that's the colloquial definition, then ClojureScript doesn't really try to generate readable Javascript. You can understand it if you looked at it enough, but we've gone out of our way with things like source-mapping to make that not be necessary. We, as a general rule, really don't want people to have to think about it.
Joy Clark: My next question is a bit of a personal one - how did you get started doing compilers? Was ClojureScript your first one?
David Nolen: I would say ClojureScript was my first one. I was always a fan of Lisp, so of course I've done some interpreters. And to be honest, if you've done an interpreter or two just for fun, then you kind of at least have some context for how a compiler might work. In an interpreter you learn how to make an environment... With Lisp it's easy, because you don't have to deal that much with syntax. And really, a compiler is -- instead of writing code to run the thing, you're just like "Well, we're just going to take what was an interpreter, and instead of running stuff, you generate some other thing."
David Nolen: ClojureScript's compiler is a bit big now just because we've been working on it for six years, but when I started working on it, I think the compiler and the analyzer was maybe 1,200 lines of code; it was quite small. It was 600 lines of code for the analyzer, which is the thing that takes the S expressions and converts them into an abstract syntax tree (AST), and then the compiler would take the AST and generate Javascript source.
David Nolen: So the early versions were pretty easy to understand, but I would actually argue that even though in this current state it does a lot more, particularly around the area of optimization, it's still a pretty straightforward, simple thing. I think a lot of people's first impression is that it's intimidating, and they play around with it and they're like "Oh, this is really actually a lot of fun, and it's actually not that hard."
David Nolen: If you're interested, there's a really great talk - I think it's two years old now - by Maria Geller... She actually did a lot of the initial work on this Javascript ecosystem integration stuff, and she did a great talk and the Conj two years ago. It was sort of an easy introduction into the ClojureScript compiler. I recommend checking it out.
David Nolen: Back to the first part of your question, I got interested in ClojureScript actually while I was at the New York Times. I was doing some CoffeeScript, I was doing Javascript and Ruby, and Clojure was a hobby language for me... And when ClojureScript came out, I was just really excited about it because I liked Clojure so much, and I was like "Wow, a version of Clojure that compiles to Javascript!" I'd been doing Javascript already for six years, so it was kind of like a combination of two things I was very enthusiastic about - doing Javascript UI stuff, and Clojure... And sort of like my hobby functional programming language thing.
David Nolen: I worked on it on my free time - ClojureScript was very much a free time open source thing for me for about three years, and then I joined Cognitect in 2014 and at that point, officially, a good chunk of my time is dedicated to ClojureScript, in a more official capacity.
Joy Clark: We'll link that talk in the show notes, so listeners can look it up late. Concerning the compiler itself, it's written in Clojure?
David Nolen: Yes. ClojureScript is written in Clojure, which is actually quite different from Clojure itself. Clojure is written in Java; the compiler, the analyzer and the data structures are all written in Java. ClojureScript, since day one, the whole thing was written in Clojure. Rich Hickey actually said in the early days "This is the first attempt at a Clojure in Clojure", meaning a Clojure that could be self-hosted. It actually took us four years to actually get to self-hosting, but that was the idea... ClojureScript - the compiler is written in Clojure, the data structures are written in ClojureScript, but it's Clojure...
David Nolen: I think ClojureScript, if you look at all the sources for everything, I think it's 40,000 lines of Clojure and ClojureScript - basically one language - and I think we have 200 lines of Javascript. So there's only a tiny, tiny amount of Javascript. And all the Javascript, to be honest, is just about Node integration. We have a few things for integrating with Node where there's no benefit, or actually doing it in ClojureScript is more complicated. But otherwise, everything in ClojureScript is either written in Clojure or ClojureScript itself.
Joy Clark: When you're running the compiler, do you run it in ClojureScript? You said that it could be self-hosted - does that mean I don't have to have Java installed? I mean, you need Java for Clojure, so...
David Nolen: Yes, there's an option. Basically, the way we wrote ClojureScript is that you can have ClojureScript compile itself. And when you have it compile itself, you then have a Javascript file, which is the compiler and the analyzer and all the things you need, compiled down to Javascript. We don't give that to you out of the box, but it's more or less now easy to compile the whole thing to Javascript. That's how Planck -- there's a command line scripting tool called Planck, and Planck is a version of ClojureScript which has no Java at all; it's just Javascript core, bundled with the self-hosted compiler.
David Nolen: We have another thing called Lumo. Lumo is another self-hosted thing, and the way that works is that they compile the compiler and the analyzer, and they take that Javascript file and they load it into V8, and then V8 has this really cool snapshot capability where you can basically dump the heap. So the VM can basically snapshot its state, and then you have something that boots very quickly. So Lumo is yet another bootstrapped ClojureScript thing; you don't need the JVM to run that. Those things don't require the JVM. Those are Javascript, and that's it. You just need Javascript for those things to work.
Joy Clark: And do macros still work in ClojureScript?
David Nolen: Macros are different in ClojureScript than in Clojure.
Joy Clark: Could you briefly explain what a macro is for the listeners?
David Nolen: Yes. A macro is -- so one of the early discoveries around Lisp, since Lisp has this fairly self-similar representation... You have these S-expressions, and most Lisp systems act on that representation, but that representation is a data structure, right? So when you write a function and you (defun parameter-list body-of-the-function), well you can not only just run that thing, but it also is just a piece of data, it's just a list with symbols in it, and maybe some other data structures. And Lisp programmers realized "Oh, it's just a data structure and we have functions to manipulate data structures. We could just take an S-expression and transform it into something else and then evaluate that.
David Nolen: So the big idea behind macros is that because Lisp is homoiconic, as they like to say (Code is data, data is code), a macro is this idea of taking a source and expanding it into something else. It's so trivial in Lisp; most Lisp has this capability, and Clojure is no different. And ClojureScript has this capability as well. The difference though is that when we target web browsers, we don't wanna ship -- when you're writing a GUI app in the browser, we don't want to ship the analyzer or the compiler or all this other stuff that we use to generate the program, because that would bloat your final artifact. You would have all this extra stuff that you're not actually using in your UI, that we would have to hand to you. So ClojureScript's macro system is a bit different in that the macros are compile time only.
David Nolen: Some people refer to this as sort of like staging. So the macros that you write are written in Clojure, so that we don't need to include the analyzer, the compiler or the source-level reader inside of your running program. All this stuff happens only at compile time. While it would seem like it's a big limitation - and it is a little bit tricky to get used to it if you're coming from Clojure - this means that what you're sending (your final program) is really really really small. In fact, I think the entire ClojureScript standard library - if you're not bringing in a bunch of other dependencies - is under 30k. The entire core library is under 30k gzipped, which historically speaking, that's smaller than jQuery, that's definitely smaller than React, and all this is due to the magic of the Google Closure compiler, that even though we have this massive standard library that is quite small -- but if you were going to add all the stuff that you need to get macros at runtime, I think the smallest size you're going to see is more like 60k or 70k at minimum; it could be even bigger than that. It's been a while since I've checked. So that's why we don't do that.
David Nolen: We're very much concerned about -- it's a typically Javascript best practice, you want your actual application to be quite small, because you want it to load quickly.
Joy Clark: So 30k is the overhead that you would get by writing ClojureScript, as compared to Javascript directly?
David Nolen: That's right. Even though this come us -- you know, native Javascript, which makes me laugh, because... I mean, even in the early days, dealing with browser quirks, not having access to a standard library -- you always want to use something, so I'm not a very big believer in the native Javascript thing. You're always using some library to get something done. I think in a post-React world it's just not a huge value proposition. Most people are totally fine with taking on React as a dep and building higher level stuff on top of it.
Joy Clark: When you're using ClojureScript for doing front-end development, do you have to do the whole front-end in ClojureScript, or can you just choose parts where it's the most effective?
David Nolen: Something like CoffeeScript, or even things like ReasonML, and there are other compile to Javascript languages where doing a small thing in Javascript is actually a lot simpler, because they are not doing this whole program optimization thing. A lot of it is just because a lot of these other compile to Javascript languages don't ship a massive standard library, where we ship a massive library. The standard library is like 10,000 lines of ClojureScript. So for us, something like Google Closure compiler is kind of a requirement. We need some way to manage the fact that we have a very large standard library, and it's something that users want. You're used to a rich standard library from Clojure, you want the same thing in ClojureScript. But if you're using Google Closure compiler, that really restricts the flexibility in just using ClojureScript for one tiny thing.
David Nolen: I would say that ClojureScript to this day (and since day one) is really about single-page apps where you're in control, and your goal is to use ClojureScript as the main language of the project. You can mix it with Javascript, but I would argue that that's a bit challenging, and to be honest, not really a use case that we support or even intend to support.
Joy Clark: The Google Closure compiler - does it do dead code elimination on the core library as well? The core library is probably pretty big, and if I don't use most of the functions - which I probably don't - will those also be shipped to the UI?
David Nolen: No. One of the tests that we do is just to make sure that we haven't messed up dead code elimination is if you write a ClojureScript program and the only statement in that ClojureScript program is js console.log("hello world"), then out of advanced compilation you're going to get something that's just a few bytes; you're not going to get the standard library.
Joy Clark: That's good.
David Nolen: Yes, it's also why I would say in ClojureScript as a general rule users are significantly more fearless about their ClojureScript dependencies, because they know -- if I take on a very large ClojureScript dep, I'm very confident that I'm only going to get the pieces from that dependency that I actually need, because Google Closure compiler works great.
Joy Clark: Great. Concerning front-end development, you mentioned that React is used in a lot of the libraries in ClojureScript. I've heard a lot of people describe React using a term like "the functional way to do UI design." Could you explain to me what that means?
David Nolen: ClojureScript is the functional way to do UI design?
Joy Clark: React. React is the functional way...
David Nolen: Oh, React is the functional way, sorry. The cool thing about React is React sort of introduced people to functional programming as a philosophy. People think that functional programming is like map and reduce, persistent data structures, or whatever, but that's not really true. To me, functional programming is a mindset about how one goes about organizing their programs. React, even though it had this object-oriented veneer, it really was getting people to think about a very functional approach to UI development.
David Nolen: A lot of people got hung up in the early days on this thing called component local state, but the truth is that if you think about component local state as like the transient part of your program and it's not the essence of what you're doing in the UI, then React is a very functional, friendly system.
David Nolen: I remember my friend Brendan Bloom introduced me to React, and I was very skeptical because I said -- of course, I also thought on the surface it looked very object-oriented, but I think I spent like four or five days and I realized that you could write a very clean binding to React with ClojureScript, and you could basically do functional UI programming in a way that at the time seemed to me very novel. The Clojure and ClojureScript community more or less came to the same conclusion. There's Reagent, there's re-frame, which is built on top of Reagent, there's Rum, you've got the library that I've worked on, called Om, as well as the successor, Om Next, there were other things like Quiescent... Everybody more or less jumped on board because React again, fundamentally encourages (in a big picture sort of way) a functional approach to UI development.
David Nolen: There are, of course, a lot of other problems that need to be solved, but to me it was a big step forward. Basically, the way that React works -- it's functional. You have a component, you pass some props, and then you have something that will get rendered by some other thing, and you don't really care. But it's a function of, you know, from your data to something that will get rendered by something else, and you're not really that concerned about how that's going to happen, and that's the big idea.
Joy Clark: I personally love to develop web applications using pure HTML, with sometimes a little bit of Javascript... I think it's interesting, because it feels to me like everyone is moving away from HTML and focusing on frameworks like Angular and React, single-page apps. I can really see the use case for developing rich client applications, but I think there are also cases where HTML is great. My question is would you use ClojureScript or Javascript for everything on the web, or do you see a use case for plain HTML?
David Nolen: It really depends. Something that you could do - and actually, there are some companies that do this, but you don't hear that much about it... For example, I could imagine a case where you decide "We want to use ClojureScript, but we don't want to use React, because we want to use HTML... And we may even want to use a smattering of Javascript, and all we have to do is train our Javascript people to do Google Closure compatible Javascript, which again, these days it's getting easier and easier, because Google Closure can consume ES6, and it can understand Node modules and all this stuff... You could totally imagine a case where you're building a giant website, it doesn't need a lot of Javascript, you write a little bit of ClojureScript here and there, you write a little bit of Javascript here and there, and you only rely on Google Closure library, which has a vast array of facilities for doing -- whatever, if React is the new way, then the old way, you could say the more traditional approach to doing client web stuff... You could totally do that. In fact, that's how it was before React - people were either scripting jQuery from ClojureScript, or Angular, or they were like "I don't need jQuery, because Google Closure has all the stuff I need to do for lightly scripting a web page."
David Nolen: So there's nothing about ClojureScript that requires React, and that's very intentional. React is great, and there's a lot of excitement around it because of things like React Native and so on and so forth, but if you want to do HTML and you want to do lightweight scripting with ClojureScript, we've certainly made no choices that would prevent you from doing that.
Joy Clark: If you personally were to develop a website, would you use ClojureScript or would you just do it in HTML? I think it's interesting, because React seems to have become like an industry standard, and then people are like "Build me a website and use React", and I'm like "Really?" I mean, it's three pages, and they're linked, and I can write them in HTML; they're cacheable, and it works without Javascript.
David Nolen: Yes, it's a great point. Keep going, I didn't mean to interrupt.
Joy Clark: I just wanted to hear your thoughts on that. I feel like there's a push for using React and like a single-page approach to every kind of application or website on the internet, regardless of if it's good for the use case... And I guess I wanted to ask you how you would make the decision about what technology you would want to use for the UI.
David Nolen: For me it's quite simple - if I'm building an SPA (single-page app), then there's no problem with React. Or if I'm doing mobile, then I want to use React Native; it doesn't really matter. I have a blog, and my blog isn't so active these days, but my blog is a Jekyll blog with Ruby, and I do very light scripting with ClojureScript. I'll bring in Code Mirror, and whatever... I don't use React. There's all these use cases where there's no huge benefit from using React. I just need to program a couple of elements on the screen, and that's it.
David Nolen: For me it's just like it was before - does it make sense for the task at hand? Would I say that you always need React? No. Should you always design like you're building an SPA? It doesn't make any sense to me. I wouldn't encourage that or do it that way.
Joy Clark: Do you have any ideas about how user interface design might change the next few years? I'm just wondering what the next big thing is going to be.
David Nolen: I think the things to follow are no different than things that I think are interesting... It's not like I know the answer, or whatever -- the stuff that I like is good or bad. It's just the things that I think are interesting that have a high impact for UI, it's definitely GraphQL. The GraphQL approach will likely have a huge impact -- not GraphQL specifically as a specific technology, but just that idea, GraphQL and Falcor... This idea of allowing clients to have finer grain control over what data they pull from the back-end. It really can radically simplify how you go about doing UI stuff, especially for more sophisticated SPA-style applications. So I see that as having a huge impact.
David Nolen: I also think that it's not like that people have completely solved the new sorts of problems that React introduces; there's still a lot of friction that didn't exist when you weren't doing things in the React way. Traditional MVC has some nice properties that I would argue still haven't really been fully recovered in the React approach, and that's something for people to reconcile. I don't know if people are going to do it, but I would say there's some work to be done there. I would see that as being the next important step, to sort of reconcile the lessons of the functional UI with more traditional approaches. But I suspect it's going to take some time yet, for people to really identify that as a problem.
Joy Clark: With so many libraries being based on React in the ClojureScript world, do you think there will be an issue for the libraries with this -- there's recently been the outrage over Facebook's licensing treatment...
David Nolen: I think that's a team-by-team, company-by-company, case-by-case basis. I definitely sympathize with the frustration about that. My impression is that in the end most users really aren't that concerned about it, they just want to ship stuff. In the end, I see that as having a very minor impact... Largely because I view the Clojure community as being a fairly pragmatic community; it's sort of a community of people that want to ship stuff and get stuff done. In some sense Clojure and ClojureScript programmers are not purists. Clojure programmers are okay with the JVM, they're okay with talking to Java libraries. A lot of programmers wouldn't touch a Java library with a mile long pole; just the idea of Java being their stack is revolting, and Clojure programmers just don't have this.
David Nolen: You understand the value of what Java and the JVM bring. You don't necessarily wanna program it, but you appreciate access to that ecosystem, and I would argue that in the ClojureScript world it's the same. The React patent thing kind of sucks, but until somebody else comes up with something that has the same properties and has the same amount of reach, specifically something like React Native, I suspect you're not going to convince many people.
David Nolen: At the same time, my point there is that React could totally get replaced if somebody comes up with something that delivers the same value on the same level of reach, but I don't think the patents clause is compelling enough for people to -- that alone is not going to cause people to rewrite everything.
Joy Clark: That's probably true. You mentioned React Native a couple times - could you explain a little bit what that is and how that can be used to help create mobile apps with ClojureScript?
David Nolen: Yes. Something that a lot of companies struggle with - and I saw this when I was at the New York Times - is that you build an app, and then you have to build that app again with Java on Android; assuming you've done it once on the web, you have to build that app again on iOS, with Objective-C or Swift. And that's great when you have tons of money and can afford to hire tons of developers, and you can pay an Android developer, an iOS developer and all the QA-ing that that requires, and the testing that requires... So that's a real pain point. There are a lot of companies that would like to have a better, simpler story for reaching the major client targets without having to invest so heavily in so many different technologies.
David Nolen: There have been other approaches... There have been things like Cordova. With Cordova you could write your iOS and Android app in Javascript. But those involved WebViews, and the big tension there was they didn't look or feel native, and they often had performance issues that arised from embedding a full-blown web browser into the app.
David Nolen: Facebook had a very clever idea, which is that React is a very high-level system... And what it renders to is decoupled from the semantics of React. The DOM is just one possible render target, so some engineers at Facebook said "We could have a different render target. That render target could be iOS native use, or it could be Android native use." So React Native basically allows developers to write Javascript and React Native can deal with the fact that you're going to target Android or iOS, and with some minor work on the part of the Javascript user, you could write components that work on three completely different platforms. That's huge.
David Nolen: You write your component once, and you can use that component on many different platforms. And the performance profile of React Native -- of course it's not going to be as good as if you just wrote it native, but the point is that you've really decreased the gap, where a much larger demographic of applications that you wouldn't have considered doing it this way, now it's fine... It's fine for a much larger set of applications, which is cool, and we see that - the amount of interest in the ClojureScript community around React Native is significant.
Joy Clark: What other frameworks and libraries are available? I don't know if we've mentioned any, but what frameworks and libraries are available for front-end development, or just development in general in ClojureScript?
David Nolen: To be honest, if I wasn't doing React, I would just use the Google Closure library. The Google Closure library - they have everything. They have battle-tested -- basically, the Google Closure library is what runs all of Google's major Javascript properties... Gmail, Google Docs - all that stuff runs on Google Closure library. They're not using React, they're not using other frameworks... They're not using Angular, even though Angular is from Google. The customer-facing Javascript properties are built with Google Closure library.
David Nolen: If I wasn't using React, I would just be using Google Closure library. It's just a massive set of functionality for dealing with browsers. Basically, almost anything you could think of doing, they've done -- they've really thought through hard problems like internationalization, and it's constantly in development, it's not something that's sitting still. Google Closure library isn't just version-controlled, they just use it for master.
David Nolen: We happen to snapshot it for ClojureScript developers, but yes... Every time I look there, there's always something that I haven't seen before that's useful, that's worth trying out and using. That would be my suggestion... It's very rare that I would ever think about using a Javascript framework if I wasn't using React. I would just switch to Google Closure.
Joy Clark: What React-based frameworks or libraries are there in ClojureScript?
David Nolen: The most popular one is probably Reagent now, because it's pretty easy to use. I recommend it if you just want something that's basic React; it's very easy to get started with. If you're doing a blog, again, I would probably do what I've done, which is I wouldn't use anything. If you need something more sophisticated where you're expecting that you're going to have a more interesting relationship between the client and the server, then you have something like Om Next. You may find Om Next to be a bit too abstract, and the truth is Om Next is really a set of ideas, and in fact, I've actually personally worked on projects where we chose Reagent, and then we just had an Om Next architecture, and that worked great.
Joy Clark: Om Next is your library, right?
David Nolen: Yes. Om Next is basically just cribbing a bunch of ideas from GraphQL and Falcor and then just making them a bit more Clojury.
Joy Clark: Are there any major tooling efforts to improve the adoption of the language?
David Nolen: There are so many community-related things. You've got Figwheel, which I think is like the de facto REPL now for most people, because it's really great; it's brought a lot of ideas from Elm for error reporting. You can get Figwheel and you can immediately start coding. Figwheel with Reagent is a lot of fun, so if you're starting out, I recommend trying that. I think people are blow away because a lot of things that require configuration in the Javascript world, like hot code reloading -- all that stuff just works out of the box, there's nothing to do there.
David Nolen: Other things that are cool are Parinfer. Parinfer is an effort by Shaun LeBron and a bunch other contributors to make Lisp source editing easier for people who are just coming to the language. It's a system which will automatically calculate your parens for you based on indentation, which I think for a lot of people, especially from Ruby or Python (or even Javascript) it's more familiar. And that works in Atom, it works in Visual Code... So that seems to be quite popular.
David Nolen: Of course, you have things that are not open source, things like Cursive for IntelliJ... That's actually really far along now. If you want an IDE experience for Clojure and ClojureScript -- that's what I use for work, and I think it's great. So that helps a lot.
David Nolen: Cljs dev tools for enhancing the experience in Chrome is also pretty cool. And then there's also some other interesting things... Another thing that we are interested in about is expanding Clojure and ClojureScript adoption, and we're always thinking about better ways to introduce people to the language. So there's nothing specific here to talk about, but I see things happening in the community where people are looking for better environments for people to be introduced to Clojure and ClojureScript, because I think one of the challenges is that Clojure and ClojureScript assume some familiarity with the Java ecosystem, so a lot of times when people get started, people do get hung up on the fact that they're not familiar with the Java ecosystem. There is a learning curve there, from "I just wanna play around", but then you have to know all this stuff before you can do that. So it's something that is definitely getting worked on, but it's going to take time yet.
Joy Clark: Are there any resources you can recommend for getting started with ClojureScript?
David Nolen: I would say the website is probably a good place to start. We have a tutorial there. Another place - the Slack community is really friendly, it's really active. It's clojurians.net. I recommend going there; there's a beginner channel. People ask advanced questions, they ask basic questions in the ClojureScript channel, and it's totally fine. There's also an IRC channel, there's a mailing list... If you're interested in learning, I would go to the website and then check out one of these community places to hang out.
David Nolen: Unfortunately, there's not really a book -- I take that back, there are books; they're online books. There's no printed book right now from a major publisher that sort of covers everything, and a lot of this is due to the fact that ClojureScript actually is still evolving pretty quickly... Again, not from a language standpoint, but from a tooling and JS ecosystem integration standpoint.
David Nolen: I definitely know and sympathize with book authors... They're afraid that if they write about something, they're going to miss out on very impactful changes, and I would probably argue that it's probably going to be another year before we're at a point where I would say it's harder for me to see bigger changes coming down the pipe.
Joy Clark: Thank you so much for your time. I thought it was very interesting. For all our listeners, thank you for listening. Until next time!
David Nolen: Great, thank you.