 Hi everybody. When I give a presentation somewhere, I'm pretty much contractually obliged to have some Lisp cartoons in there somewhere. So I was trying to think of what kind of Lisp cartoon I could start with, and then it kind of occurred to me. I wanted to bring in the whole politics thing that's happening right now. And then I realized, oh, the closure logo could be kind of like a basketball. And so then I had this idea, and I thought, well, we need some tension in the cartoon. So Obama has to trip on something. And first I was thinking, well, maybe I should make him trip. Maybe Mitt Romney is throwing some money, and he trips on it because he's throwing money on the cart. But then, like, that has nothing to do with Lisp. So I had to come up with something to trip on that has to do with Lisp. And the solution to this, of course, was slime. All right. I'm going to talk about Webfui. This is a functional client-side JavaScript framework for ClojureScript. Now, there's a million client-side frameworks. I'm sure if you Google the term yet another JavaScript framework, you'll find 10 different frameworks with that name. Now, so, you know, the most important thing when you're looking at a framework is, you know, what were the goals of the designer? And, well, before I get into that, let me just talk about some basic terms. Most people here probably know it, but since there will be a video, I figure I should define a few things. The first one is, what is the DOM? So when you write HTML and the web browser displays your web page, it creates this internal data structure that represents the web page. And the thing about that data structure is it's mutable. So when you write JavaScript, you can actually muck around with that DOM to change the web page in real time. And so Clojure people don't really like things that are mutable. Now, the second thing is, what is EDN? So EDN is basically the serializable part of Clojure. So it has the maps, the vectors. So it's a subset of Clojure of just the data structures that are serializable. So if you're not familiar with EDN, if you just pretend every time instead of saying EDN, I say syntax expression or I say JSON, you'll pretty much know what I'm talking about. The final thing is what is Ajax? So I'm using Ajax in the broadest sense, meaning any time after a web page loads, if the client talks to the server, I'm going to call that Ajax, even though, of course, we don't use JavaScript and we use Clojure script and we probably wouldn't use XML. We would use EDN to send to the server. Now, so what are the goals of my framework? The first thing is, we want to do things the Clojure way. So I tried to come up with something that I feel embodies the Clojure way. Now, of course, everybody has a different opinion on what the Clojure way is and there is no one person who gets to decide what the Clojure way is. Well, maybe there's one person, but anyway. The next thing is I really like functional programming and so I wanted to do something that let me write most of my code as functional. Now, the last goal is something very specific. What I would like is that we just have an atom that contains EDN data, so just serializable Clojure data structures, and that I want to be the DOM. So I want to just be able to stuff information into this atom and I want the framework to just synchronize that with the DOM for me. Now, the standard way that we represent web pages in the Clojure community is to use Hiccup and that's what I really want the EDN to look like. So now there's other people, of course, who have done this sort of thing. So one example is the Singult framework that Kevin Lina has come up with and there's other folks that have played around with these ideas and also in other languages like Haskell, you know, this kind of idea isn't that uncommon. But what I've done is I've tried to take this idea to the extreme to see what it would look like and I feel like you end up with something that's actually a pretty pleasant framework to do web development in. Okay, so there's four parts to Webfui. These are pretty much independent libraries and I'm going to go through them all one after another. The first one and the most low level is Webfui DOM. Now, Webfui DOM has only one job and that is to take a Clojure atom and synchronize it with the DOM of the browser. Now, let's look at a demo application that does this. So here's the simplest application possible. It has two text fields and it adds them together and then shows the result. Now, let's look at the code for that example. So here's the server-side HTML. This is the only time I'm going to show anything server-side. Basically, you can see this is braindead HTML. All it does is load a style sheet, load a JavaScript file, which is, of course, ClojureScript, and then everything else from there happens in the JavaScript. So all examples have exactly the same structure, HTML. Uh-oh. All right. I was warned to use the ethernet and now it's coming to bite me here. Let me see if we can switch over. Oh, dead air. Okay, that looks like it's performing well. I should be up and running again in just a moment here. Okay, so let's look at the actual client-side code that runs this example. Now, the thing about this code is it's very ugly because all this low-level library does is it only solves the last of my three goals, which is synchronizing with the DOM, but it doesn't solve the first two. It's not functional and it's not the Clojure way. So what you can see here, what we do is, you know, we load the libraries. Then we, here's my DOM. It's just an atom that starts off as nil. And then there's a function where I, that I call in the library saying, I want this to be my DOM. Then we have a couple of global variables here that we just set to zero, which are the A and B values we're going to add together. And then we have this function called render all. And this actually just generates hiccup and it embodies our web page. So this is where the HTML is generated. And you can see all we do down at the bottom is we just add A and B to show our result. Now, we need a function that actually takes this rendering and sticks it into the DOM. That's right here. So this is the imperative function here. And then we want to actually call that so that when you first load the page, we see this instead of a blank web page. And then here's the rest of the code. Here's a validator because, of course, browsers don't have text fields that numerically are limited numerically. So you have to implement that yourself so we have to make sure they type in a valid integer. And then here we have watch functions. And this is what actually performs the work. So you can see if I go back right over here, I declare a watch inside my HTML. So this is an extension beyond hiccup that you can attach watches to elements in your data structure. And then, so why am I using watches? Why am I not using events? So personally, I found working with this that events are really not very good for doing functional programming like this because events only have a lifespan that's instantaneous. So an event happens, then it's over. What really, when you deal with functional programming, what you want is you want to deal with entities that have a lifespan. So what I would really like is, instead of getting an event saying, oh, somebody changed text, what I really want to see is just, you know, what did the element look like before they changed the text and what did the element look like after they changed the text. And if I have access to those two things, then I don't need some complicated event object. And I no longer have to read the JavaScript documentation on the event object to remember when I deal with a text area of field, what attribute do I have to check on the event object to figure out what the new value is or whatever. Like, that's just a lot of complexity. And of course, we're familiar with this enclosure in the closure world because we don't have, you can attach watches to atoms in closure and there's no such thing as add event to an object, to an atom. So somebody could have written that, right, where every time you modify an atom, you also send in an extra data structure that says, here's what I did and why I did it. And then you could read that event object, but that's just extra complexity. We just want to see the before and after and we can handle everything ourselves. So, and the way you can describe this is basically show me, don't tell me. I don't want you to tell me the event that happened. I just want you to show me the before and after of the event. So that's why we have watches. So you can see, just to run through this, you can see that when you add a watch to your DOM, you get as a result the old element and the new element. And then this new element, we can actually just read the value right out of it. By the way, Hiccup, of course, has lots of shortcuts where you can, if you don't want attributes on an object, you can just leave off the attributes or you can do things like where you add a class identifier or ID directly to the tag name. So the WebFui library will automatically normalize that so that you're guaranteed that the first item is in the list after the tag name is always an attribute list. So then we just need to check, is this a valid integer? And if so, then we're going to set our global variable equal to that new integer. And then, of course, we have to call update DOM so that we see the result. And then the second one is exactly the same thing. Now, as I said, this is on purpose ugly code. It's just supposed to show the simplest thing possible here. So here's the resulting program. So I can go in here and... What's going on here? Oh, you know what? I think I loaded an old version of this. There we go. So, okay, great. So I can type in... I can just type in numbers here and you can see it automatically updates the result. Now, when this page first loaded, it basically initialized the page with the HTML from the render all function. But then after the initial load, it won't regenerate all the HTML. Instead, what it does is it performs a delta calculation between the previous HTML and the new HTML and it only updates the minimum amount possible to bring it into the new state. That's why when I type things, we actually see that the cursor here, the first item remains focused because if I was to just delete all of this and rebuild the entire page, it wouldn't have focus anymore. And there's many other reasons why you never want to do a wholesale replacement of the page. For instance, CSS transitions have dependencies that will cause your animations to look wrong if you erase items and replace them with identical items. And this will automatically now validate wrong inputs. So if I try to type in alphabetic characters, as I'm doing now, nothing happens because as you saw, only when it validated did I update my global variables and those global variables decide what appears. And then also I validate that the number isn't too long. So if I keep in typing numbers, it will limit it. If you go much past that, it'll start showing it in scientific notation and it looks ugly. So, yeah, so that's basically it and for the basic example. But as we saw, the code was really ugly for this. So how can we make it better? So how do we make webfui pleasant to use? Well, what we want to do is we want to add another item into this chain. We want to make this functional and we want to have a world state object inside our program. And when the DOM atom changes and our watchers get called, we just want to update that state object. And then the render off function, instead of taking the previous version of the HTML, it actually takes the state object as a parameter. And so if we do it this way, we can now write all of our code as functional. So the watchers and the render off function are now functional. They don't have to talk to the outside world. And this kind of design is basically what people used to call data flow programming where we have these boxes with data structures and when one of them changes, we propagate that. So here's the add DOM watch function I showed you a minute ago. And let's see how we can improve this now. So first of all, we get rid of the old element and we replace it with a state. So now you can see it receives the state as a parameter. And now what I have to do is return the new state. So what I do is I take the state variable and I associate to the key a the new value of a in this case. And then if a was a valid integer, we just return the state. Now this is ugly for several reasons still because for one reason I'm a believer in declarative programming and that a soak in function isn't very declarative in nature. What I want is I want a function where the body of the function looks like the data that it operates on and the soak in kind of breaks that rule. What I really want is something like this where we load in our state and then we build a new state and you can see a map literal in there where we're constructing it and you can see what the end result of the function looks like. Now this has a new problem though because now you can see there's references to b, the other variable. But we're writing a function to just handle a right now. So we don't have proper separation of concerns. So what we really want to do is we want to say oh, I just want to modify a in the state. I don't want to modify the whole thing. So how can we do that cleanly and still have it be declarative? So that's what the second library is for. It's called state patches. And basically what this library does is it takes, it lets you write just a diff description of how you want the state to change and then it will apply it to the state for you. Now the reason this works is that when the state in your program is always going to be very similar to the problem domain that you're dealing with, and so when the user performs an action, it will usually only modify one or maybe a couple of variables in your state because of how you have organized it. So it's highly localized. So we want to make pinpoint changes to the state. Now this is different from the DOM, right? So if you have a website for selling widgets and the user picks a new widget, the entire web page may change because you're showing all the data on this new widget. However, the state on the web page is probably only going to change like one variable that's called selected widget ID or something like that. So we don't want this for modifying the DOM. We just want it for modifying the state. And usually a diff has three parts, right? Things that have been added, things that have been edited, things that have been deleted. Well, I don't want to worry about all this stuff because usually with a diff, we have to worry about all these things. But when you create state in Clojure, you're usually going to have a map. And so with a map, editing and adding are exactly the same, right? If you just reuse a key you already had, then it edits it, otherwise it adds it. And we can simulate deleting by simply setting a key to nil. And that's almost as good as having deleted. So it's not a true diff with the system because you can delete keys. But what this allows us to do is we don't have to do all this bookkeeping with three different types of diff. So here's what the function looks like. Essentially in its basic form, this state, this patch function, is just a recursive map merging function. So if it encounters anything that's not a map, it simply does a wholesale replacement. And the one exception is that if you have a vector in the second to last example here and the diff that you're applying into that vector is a map, then it will treat the first item as an index into that vector. And it turns out that just from practical use, this is something you often want to do. You often have a vector of similar items and you just want to modify one single item in that vector. So that's the one case where you can do a diff on something that's not a map. And so I find this particular function very useful when you have a world state object in your program and that's what I use for this library. So with this new function, we can now rewrite our code like this where we just send back the value of a and we don't have to reference b. So now we have proper separation of concerns. It still looks declarative because we're just declaring the new structure of the state. Now the last thing I do is if you saw before, I actually have a function that I place in here. So I rewrote it as a macro so that it looks more like the add DOM watch function is like a command, kind of like a function definition and we don't have to explicitly send in a function. So this is what, after all the transformations, what we end up with and this is a much cleaner way of writing a watch. So what you see here is this is the second version of the program and this is all the code. So you can see up here we import our stuff. Here's our render all which hasn't changed except that we now use state variable that's passed in so it's functional. This didn't change. And then just to make it even more elegant, I got rid of the code duplication by just pulling the ID of the element out of the watch result I get back and so I can just handle A and B simultaneously. So this is, in my view, a pretty elegant way of writing something like this. Now, sometimes things don't change the DOM but we still want to capture them. So as you saw this watcher does is it watches a part of the DOM. So what if the DOM doesn't change? How do we handle that? Well, there's a mechanism for putting in plugins. So there's a plugin protocol and there's basically two different things that a plugin does in WebFui. The first thing is it makes hidden DOM changes visible. So there's a lot more you can do with DOM than you can do with HTML. So, oh, that didn't format. Well, no, that's good. So in this example you can see, you know, we have the two plungers and you can see the DOM plunger has all these extra features. So what am I talking about here? So let's say you wanted to display a web page and you want a, you have a scroll bar in your web page and you want that scroll bar scrolled all the way down to the bottom. Well, there's no way you can write HTML that says, oh, place this scroll bar all the way down on the bottom when you display this page. The only way to do that is through JavaScript. You have to call the scroll top property on that item. Another thing that you can't do is that obviously a browser knows when you've pressed a button because when you hold down on a button, the image of the button changed into a pressed down button. But we don't really have access to that. There's no way to display a web page with a button already pushed down. But there is a pseudo class in CSS called active. Now, why that isn't just a regular property on an item? I don't really see any good reason for that. So with this type of model I'm showing, since we're trying to avoid working with the DOM, we have to lift items that are only available in the DOM into the regular HTML so that you can modify them directly. And so that's one thing that you can do with plugins. The other thing is that you might want different type of watches. So I just showed you the basic type of watch. But if you're dealing with something like mouse, somebody is wiggling the mouse around the screen and generating all kinds of points with a mouse move, that isn't even a hidden DOM property. So we have to somehow be able to capture that. So the first plugin I'm going to show is the scrolling plugin. So the demo of that is right here. It's pretty basic. We just have a scroll bar here. And if I move the scroll bar, you can see it changes the number down here. I can go down here and edit the number. Oh, another little technical glitch. I should be able to edit the number in here. And it would move the scroll bar so these two are synchronized. So this is what the code looks like for this. So this is just the part that responds to moving the scroll bar or changing the number. So the first one, all it does is it just gets the scroll top of the element, which is now lifted into the regular HTML that gets returned as the new element variable. And we just set the position in our state to that new scroll top. If they change the number in the text field, you know, I have a function here called triparse that simply makes sure it's a valid number just like we saw earlier and just sets it to zero if somebody types in alphabetic characters. And so it does the same thing. It just sets that same position variable. And that position key in the state drives the values for both of those items. Now let's talk about something more complicated. How would we handle a mouse? Now, the way people have been handling mice has actually changed a lot in the last couple of years because people use mobile devices. And so one thing that you used to see a lot is that web pages would give you hints when you had your mouse hovering over an item or would highlight items when a mouse hovers over it to show that they're active. But of course, there is no such thing as hovering on a touch device. So usually, most mouse actions now are more like gestures where we capture when somebody pushes down on the screen what movement they do with their finger and when they release it. So just capturing that covers 90% of what people want to do. And that's what this plugin does. So if you need to do hovering, which most people don't these days, then you can write your own plugin that adds that feature. But this simplifies it by treating gestures as a separate entity. So, well, let me show you the sample code for this. So here's just a circle of numbers. I can click on a number. And you can see it automatically highlights that number out of the set of numbers and gives you a little ghost. And I can drag this ghost somewhere else and it will add that number together. And we can keep doing that. And we go like this. It will keep making larger and larger boxes. So this would be like the start of a simple game like what's that called? Not Gattica, there's a Galcon. It's sort of a game where you drag planets together in order to do strategic stuff. So this is my idea of how a modern web app usually handles input from the mouse. And of course, I want this to also work on an iPad. So here you can see the same circle on an iPad and I can click on an item here. And I get a ghost and I can drag that to another location. So this plugin automatically handles both of those modalities. Now, let's look at the actual code. All I'm going to look at is this, most of the code is just involved with rendering these boxes in the hiccup format. This is the only code that actually performs an action. And the important thing here is that this mouse watch, which is a new type of watch and it adds an extra parameter called points, which gives you the entire vector of all points as the mouse movement happened between pressing the button before it was released. So that's the one change. And then the other thing is that it gives you the first element and last element of the motion. So if somebody drags from one point to another, you get the first and last element. And so this is the only function that exists in WebFui for mouse interaction and it handles dragging and it handles mouse up, mouse down, mouse move just in this one function. And of course we don't want to function like mouse down, because what do you usually do in mouse down? There's a global variable called isMouseDown and you set it equal to true so that later on in your mouse move you can then have something happen only when the mouse was down. So that's already imperative programming. So having, treating the mouse action as a gesture, we can be completely functional. And the most interesting thing that I'm just going to explain is this sizes part. This is the part that increases the size in our state to be the new size where it adds the location we're moving from to the location we're moving to. And the interesting thing is that, as you saw, if I decide not to let go the mouse on one of those bubbles, but instead just go into the white area, it will cancel my action. And in the same way, if I move into a box and I move my finger away, I want it to subtract that value that was temporarily shown as a preview. So this code handles all those cases. So it handles the previewing, it handles the addition and the subtraction because the state that is passed in here is actually the state at the time the mouse was pushed down. So what this means is one of the nice things about functional programming is that if we have a world state, we can keep old copies of that state. And for mouse movement, the most important state that we want to keep is the one at the time the mouse was pushed down because if the user wants to cancel the action halfway in their gesture, we want to be able to get them back to that default state. And so this one function handles all those things at once. Now let's look at a slightly more complicated example. This is just a simple calculator. So this has all the functionality of a typical 80s desk calculator. And it has memory. It properly performs overflow. So if I multiply this by a large number, let's do that again. Then it'll say overflow. And there's tricky things you have to do. Like if somebody presses the decimal point and then types in trailing zeros, you have to display those. So it handles all those cases. So this program in Webfui is 92 lines of code. And just to show you quickly, here's the actual code. I won't go into this in detail, but you can see it just declares some data structures here. And then here we handle all the cases of overflow and the decimal point and all that. Here's where we watch the watch functions for the number keys and the operator keys. And then the important thing is that right down there, when you use the framework library, that's what gives you the ability to work with state. So that's a layer, a library that is on top of the lower level DOM library. You just call this function launch app. And that one function out of all those 92 lines of code, that's the only one that's truly imperative code. Everything else is just regular functional code. So now let's talk about the elephant in the room, which is performance, right? Because every time a user action is performed, we generate this giant hiccup structure that represents the entire web page. Then my library performs a delta calculation on that data structure. And then we update only that part. So all of that has to take time. So to see what kind of effect that has, here's an example where I just created 40 of these calculators. So this page has over 2,000 DOM elements in it. And each individual calculator, you can press the buttons and it does work. Now, if I do timing on this on my laptop, it takes about 250 milliseconds to handle a key press. So that's not really great. I mean, we want to have it feel responsive. We want at least 20 frames a second response, which would be like 50 milliseconds. So I think to make this approach really work, I would want this particular example to run in 50 milliseconds. Now, there would be one easy way to do this immediately. And that would be to simply write the library itself, most of the work instead of the library, in JavaScript. And I've done that in the past, created similar libraries that do this sort of thing. And I found that JavaScript will give you this level of performance. Now, I'd like to avoid doing that. I'd like to keep the library in closure code. But even if it was rewritten partially in JavaScript, it would, of course, be invisible to the user that can just continue to write closure script. Now, let's talk about Ajax. So that's the next thing we have to deal with. So Ajax is tricky because we have this beautiful functional program. And anytime we talk to the server, it means that we have side effects. So how do we deal with that? Now, one way of doing it is that we have a request queue in our state atom. So what we can do is, in all our functional code, if the functional code realizes, oh, we need something from the server, we have inside the state variable some kind of queue where we say, oh, fetch this extra thing from the server for me, and then we have some other imperative code that pops stuff off of that queue. You don't want to do that. Just like I was talking before with events, you really don't want to deal with things that only have an instantaneous lifespan. And putting these requests into a queue in a state atom, that's not really the job of the state. The job of the state atom is to show things that persist over time, not to just, for an instantaneous second, pop in a little message and then have somebody else consume it. That's not what state is for. What I find, just in terms of my own practices, what works for me is to always think of Ajax as a flaw in the state object. And so the way you want to think about this is inside our closure script program, we have this world state object that's supposed to hold all the state for our program. Now, the moment we do an Ajax call, we can see that this is a lie because the only reason we would do an Ajax call is because there has to be some other state out in the world that we either want to write to or read from. So the moment we do that, we know that this world state that we have is a corrupt system. And so the best way that I like to think of it is that the places in our program where we have to communicate with Ajax, it's almost like a form of corruption in our world state for our program. And as we know with corruption, corruption tends to spread like a virus. So if you have corruption somewhere in your data and you keep using that data, it's going to break other things in your program. So I like to think of server communication as a virus. So the idea here is that we want most of our functional code to say to itself, oh, this world state, that's all there is in the world. But then there's another part of your program that knows no, no, this isn't true. There's other state. Now what will happen is that if you think that your world state is the entire world, then eventually you're going to run into problems and you're going to run into the situation where you get corruption into your program because there's updates happening from a separate location. So now if you think of it that way, if you think of it as a virus, there's three different ways that you can handle Ajax inside of your program. So let me give you an example. Let's say you have a web page for browsing widgets. Somebody clicks on a picture of a widget and now we want to load in all the information about that widget. Well, that information about the widget is on the server and we're pulling it with an Ajax call. So now all of a sudden the functional, our state has like an item called selected widget ID. But inside of the state there's the information about that widget doesn't exist. So now our state has become corrupt. Well, we might get lucky because it might be that so we just display a blank page because we don't have anything better to show. But then immediately a couple seconds later the user clicks on another item and we do have the information about that. The other thing is we can try to contain it. So we can say, okay, if you click on an item and we can't display that information, let's stop you from doing anything else until we get a message back from the server with the result. And the final thing is we can cure it. So the only way to cure this virus is to get a response back from the server. So what we do, so I created a calculator with persistent memory. And the only way the program differs from the previous program is that I set the memory, instead of setting it to zero, I set it to unknown. So this is like a little bit of corruption in our program. And so if we try to read that memory, that means the amount displayed on the calculator will also be unknown, which isn't a valid number. And so this corruption has propagated. But however, I put a watch on the state variable and that watch checks to see if the amount in the calculator is unknown. And if so, it sends off a AJAX request to get the memory that's stored on the server for this calculator. And simultaneously, if somebody changes the state and the amount was already unknown, in this particular example, I simply prevent people from doing anything with the calculator while the amount is an invalid value. So we're containing the damage caused until we get a proper message as a response. Now you could make this more fancy and let the person continue working. If they want to do things like hit the AC button, then we don't care that there's a corrupt memory because that'll get overwritten anyway. So you could get really fancy and let people work a little longer even if the AJAX result isn't back yet. So this is just a model that I found useful of working with this type of library and doing AJAX. And this is completely orthogonal to Webfui. So there's nothing in Webfui that deals with AJAX, but you can just have a separate function that you use to watch your state and have that function be imperative and it's responsible for talking to the server. And the rest of your code can be completely unaware that anything like AJAX exists or that it has to talk to the outside world. So I won't bother demoing that. So the very last thing I want to show is something that's a little flashier. So this is an example of a little inverse kinematics engine I wrote on top of Webfui. So here we have a little guy and I can click on his arm here and the arm will move like that. And this is completely functional, 100% functional code. I can move him every which way here and I can move his little ball around here. So yeah, so if you download the example on the Webfui examples on GitHub, so it's under Dr. Code Webfui, you can play around with this inverse kinematics library. And yeah, and you can see the performance is pretty good and this will work on an iPad, though it's a little bit slower on an iPad. And that's pretty much my demonstration. All right, I think that's it. All right, thanks everybody.