 up my sleeves, that means I'm serious. This presentation can go either really, really well or really, really badly. And it can go bad for one reason is that I have too many slides, but each slide kind of builds on the previous one. And also, I see that there are a bunch of smart people here that can keep up. So, let's see. So, journey from procedural to reactive from JavaScript. Before we do that, I just want to say that every time I program in JavaScript, I always think, why am I doing this? Right? Like, why am I dealing with this stuff? Well, one joke is that the guy who created the language doesn't understand the quality. Second, it's not about the quality. Like, less than looks absolutely crazy. So, every time you program in JavaScript, you're kind of doing this, right? And at some point, you hit the mine. Compared to other languages, JavaScript has lots of, lots of bad parts. If you look at the books, you know, JavaScript Bible versus JavaScript of good parts, like it's like phone book versus like a booklet, right? So, that means that if we really want to improve the quality of software, because JavaScript is everywhere, we have to develop, you know, improve the quality of development. That means improving the tools, the language, but most of all, us. So, I work at Kensha. Kensha is a very successful startup in Boston and now in New York. We have a huge web app that can tell you, for example, if you have like a sudden, you know, deep freeze in New England like we had, should you buy, you know, a stock of Coca-Cola or Pepsi. And you can tell you right away based on historical events. So, we have a huge app. It used to be Backbone. Now it's Angular. It can show thousands and thousands of data information, graphs and stuff like that. So, the problem with that, as we know, we kind of were adding features was the code complexity, right? And trying to reuse components and trying to make sure everything works and trying to make sure that it actually works when a client uses that. For a startup, it's very, very important. So, we're writing JavaScript or Kafka script wherever you want, but what we need is our JavaScript to be as clear as English language. English language is pretty standard, right? You know, there is now an verb and so on compared to other languages, but we want our JavaScript to be even clearer. We always want to produce expected results. We really want it to be simple to test. Some stuff in JavaScript or in a browser world is very hard to test. We're trying to make the code as simple as possible. And finally, we're going to reuse the code, right? We don't want to write the same stuff over and over making the same mistakes. So, I will not argue why we reach this conclusion. We can argue, you know, offside, but what we decided is to apply the functional programming techniques and reactive programming for user interface. You know, there are books on functional programming. If you watch anything that Netflix pushes, they give a lot of examples of reactive programming for the web UI. So, we wanted to do that. And this consists of two major parts. Functional programming in JavaScript. JavaScript is not as functional as other languages like ClojureScript or Scala or Haskell or all the tools that are useless, but it stresses small and pure functions. And I will give examples of those functions. And when it composes complex logic out of very small and simple things. And, you know, JavaScript has asynchronous programming. Don't use callbacks, use promises. But the most important thing that everyone kind of stresses is immutable data. It will make your reasoning much simpler. And then the second part, right? So, this is just programming everything. Programming the web UI. We use reactive patterns or we're trying to use. And we model everything as asynchronous stream of events. Everything. We don't register individual callbacks. We always build a stream. So, user action is a stream of events, server responses, server events, web circuits, individual JSON, logins. It's all stream of events also. And streams can be processed using standard operations and not show how it's done. So, the problem with that is that you explain this to your developers and they're like, oh, what are you talking about? Right? This is not jQuery at all. Well, and it's not jQuery. And the problem is that for most people, JavaScript is not the first language. If it's the first language, it probably means they came from the designer world and they should go back. But the real people come from real, usually, classical languages. So, I came from C++, from computer vision, from computer graphics via a long journey through Kafka script and finally JavaScript. Other people in our company, we use Python back end. So, they come from a Python world. And everyone kind of touches the front end at a different degree. So, it's easy to kind of take the guy who only, who uses 90% of, who spends 90% of his time on the front end and say, don't make mistakes, use this, right? The challenge is how to take the guy who only spends 10% of his time and write JavaScript in such a manner that when he touches, he can quickly implement a feature, fix a bug without breaking anything else. I think that's the real challenge. It's not the difference between junior versus senior developers. But the whole front end, if we take it all together, is huge. And people have strengths and knowledge in different areas. Some people use only a jQuery and do good CSS and layouts, browser kind of stuff. I myself, more like in the third column, I never touch virtual CSS or lasso stylus or even templates, but I program everything else. So, we take everyone and we say, well, from now on, tomorrow, we'll take a giant leap and we'll do functional reactive programming. Except it doesn't work in reality, right? It's like trying to reach from here to there in one giant step. You have to make bunch of steps. And in my case, the bunch of steps were this. So, I started with like normal C++ programmer and I'll show examples of that on the top and then slowly I kind of progress. You don't have to do everything. You can take shortcuts. I think these are the most important parts highlighted. But in reality, it's all just me talking. If you don't program binary tree and don't put it on a GitHub, has it really happened? Nothing, right? So, here's an example. It was a joke. Not very good one. I have an array of numbers, right? I have three numbers. I have a constant and I want to multiply each number by a constant and print the result. So, we'll look at this example in every different paradigm and we'll see more and more power while, you know, semantically it will be very, very simple. Remain very simple. For some reason, my browser shows syntax highlighting. Projector doesn't. I don't know. I apologize. So, this is how I would program once I joined the web development team. I would just write a for loop. I would put everything, right? Simple. Works. Extremely bad. So, the first kind of thing that I want to notice is every time you put a for loop, it's bad, right? Because this is imperative programming. You're trying to tell how to do something instead of saying, I want to iterate over numbers. And for loops, coming from C and C++ always, you know, broke my programs at some point. Right now, we have a semantic linter for yes lint, but actually this allows you to use for loops like this. Or you have to put it like a big exception there. This also has a problem, right? We, inside the for loop, we're mixing multiplication and printing. So, we're mixing the, you know, concerns. So, the first thing we can do is we can suggest to a person during the code review, hey, why don't you move the functions out and then just have iteration for for loop and the logic separately. So, that's not a big deal, right? It's not a big conceptual leap. You can do it. But the objective here is make the code boring, right? And I'm doing it right now in my speech. I'm making it boring. The boring code is not boring like Java code boring. The boring code is the one that doesn't surprise you. Right? For loops will always surprise you. Always. Especially if you try to modify the array while you're iterating, you will always fail. It will always be something. Using this, so relying on specific context, will surprise you. Using anything but local variables in a function will surprise you at some point, especially after someone refactors your code and the next day it breaks. The most boring functions are pure functions like multiplication here or print. I consider print a pure function, although it's not sometimes. So, output only depends on input. So, every time I multiply two numbers, it will give me the same result back. No surprises. The best code. You cannot prove that a function is pure by inspection. It's equivalent to a halting problem. But you can actually test the function's purity against your unit test and then say the functions are pure against my unit test. Just like boring parents raise boring kids, boring functions make new boring functions. And the mechanism for making new boring functions is built into the language. And it's called function prototype bind. We usually use bind to bind the context, right? Like cancel log statement. But in reality, it can also bind arguments left or right. So, like multiplication, you can buy a single or the second argument above. And then you can make new functions. So, JavaScript has dual nature, right? On one hand, it's functional, like I showed, right? It has little pure functions. You can create new functions out of old ones. But majority of people use it as object oriented. And the new ES6 syntax kind of moves along and creates all these classes, which I personally think is a mistake. But nonetheless, you have an array class. You can do map. You can do for each. You should use those methods. And you can change your program, right? And instead of for loop, you can write iteration. And now this is a declarative syntax. You know, Longo will create a surprise by forgetting to increment, you know, K index, for example. So, this is much better loop. Even better is instead of mixing the concerns, we used to say, you know, numbers, that map, a callback, and then for each print, right? So, now by reading this, you can kind of understand what's going on, right? So, you're making a code clearer. And so, what we notice is that a lot of our code just does the same thing. It handles a lot of data. Usually, the data is a list. And so, we can use array prototype methods like for each and so on. But even before ECMAScript 5 was standard, people used ECMAScript 3 and they had library with polyfields like load dash. And the library had all these methods plus extras. So, it's a huge, well, it's not surprised, but if you look at NPM registry, two out of three of the top most dependent libraries are underscore and load dash, which is a big surprise, right? You don't expect everyone to use functional tool belt like load dash. I think the number one is async. But the people use functional features or functional utilities a lot. So, taking my favorite load dash, I can partially apply things. I can pipe my operations. And now the code is much, much easier to understand. Simpler to understand. Every callback is pure function. No surprises. An interesting side effect is that by using a third-party library, you can iterate over objects, not just arrays. So, that's cool. And then other people, myself included, looked at the array prototype map. An array prototype map operates on the instance. Load dash, for example, has a map where the instance of an array is the first argument and then everything is the second. And then these guys from Connecticut came along and they said, hey, hey, hey, you usually know the arguments before you know the array. So, why don't you put an array at the last position, right? And so, what happens with rounder, you can take all your functions and everything you know, like constants and everything, do partial application, combine everything together, and create a single function, like I call it algorithms, which means sequence of steps, and then apply it to array. So, that's a huge change, right? Instead of creating things when you have a data, you create whole functional smart pipeline first and then just give it data. This makes it very, very easy to test. So, let's compare object-oriented programming to functional. So, back in C++, I would write something like this. Number multiplier, I would write a method add, pass numbers, write method multiply, write method print. So, very smart object and very dumb data, just integer. In functional programming, our code, for example, deals with very dumb objects. Usually, it's just constants or most likely a list. But our pipelines are very, very smart, right? Our pipeline is wrap an array, map it through multiplication, and then for each print. So, instead of passing dumb data with past functions, the guy who wrote Algol programming language said it's better to have 100 functions operate on one data structure, aka array meant to have 10 functions operate on 10 different structures. If you have a second after this conference, spend it looking at my slides, but then the second second, look him up and look where this quote comes from. You have this whole paper of like things like this that are super funny. You should read it. Okay, I'm going to skip transducers. At this point, we have to say goodbye. Every time we learn something, we have to throw something else we knew, right? Because we leave it at space. So, the most difficult thing for me was to abandon return values. And the thing is, I used to write code in C that was like that. I call something and get return value. I can use it right away. Well, when you do pipeline, I'm wrapping numbers when I'm mapping by constant, and then for each, I call print. I don't get anything back. That's the weird part. Yes, I set up my by constant and I loaded load dash synchronously. But after that, there is no return value. So, tell return value is bye-bye, changes your thinking. I used to write a lot of temporary functions, but just pass argument to another function. You don't have to do it, right? You can adapt the signatures on the fly and use this point-free style. At any point in your JavaScript, you can modify the array, even during iteration, because it's a third argument or it could be a global, and that can really screw up your logic, and it's really hard to find. So, there are a bunch of libraries nowadays that kind of make your data constant immutable, so you can never modify it. It makes the reasoning about data very, very simple. So, before that, or before this point, we actually talked about data we have, right? And we would do the same operation for every item. So, you grab the latest version of load dash, you map, you know, do the same thing, but you also introduce take two, and all of a sudden, your pipeline is lazy. It will only produce intermediate values for only the output resolution. It will not create huge intermediate arrays. Lazy evaluation. You know, people say, lazy evaluation should be one of the characteristics or requirements for functional language. Right there. Most popular functional library has it by default. But it's another library that's interesting, lazy.js. This actually creates a sequence, and it has an operator called async, which actually calls the rest of the pipeline after an interval. So, everything before this was synchronous. Now, we're actually looking at asynchronous operations. And again, mentally, it's exactly the same pipeline as we had before. So, now we have to talk about promises. Promises are excellent. If you never use them, use it. It's a single shot operation. Only thing about promises is that here's an example of computing, multiplying, and printing in parallel. Easy, right? Okay, there is some boilerplate, not too bad. But if you try to do it in sequence, it becomes a little bit messy. Of course, you know, I'm a good developer. I could actually use a shortcut. But the promises are not very, very simple to use when you have repetitive things, because promise only executes once, and then it's done. So, if you need to process multiple items, you have to create a promise for each one, and then kind of sequence. So, if only there was something that could do asynchronous operation over and over, and there is such a thing called event emitter. Come standard in node, or you can get a library for browser. In this case, we have a number emitter. Every time you send it a message number, it will print it or multiply and print. And the generator in this case down below is the lazy sequence that we saw on a couple of slides. So, every time we generate a number after each second, we call the emitter and say, here's a number. Do it. Everything, but whatever I marked with red line, red errors, is a boilerplate code. So, we can move, for example, the action, right? What happens when another generate is generated? Or we can dig up the generator portion. And if we just take a look at the user code, well, we have a generator function, generates numbers. We have action function. That's something with each number it receives. And we use plain JavaScript. Source generate on action. And we use this pattern over and over, right? So, every time we register a callback in the browser, we use this pattern. Every time we communicate between frames or sockets, we use the same kind of own callback. Just now, we extend it to everything. And yet, you know, I'm looking into, you know, into my developer's eyes and who has seen Shrek? You know, puts in the boots, right? Everything needs to be simple, right? I used to do multiplication and print. And now, I have to do things like source and some kind of generator. Is it asynchronous? Who knows? Right? And then there is on. What is on? Right? There is no semantic meaning to on. I mean, you can say there is, right? Something that happens on an event. But I'll show what I mean later. And how do we connect multiple steps? That's also important, right? It's not a single action. If we're trying to split a pipeline into small steps, we have to be able to connect multiple event emitters together. So, let's go back to the simple stuff. I take my numbers, I multiply by two, and for each, I call print. This is what I want, right? I want source of an event, and then I want to be able to call map. Give it call back. I don't care if it's synchronous, asynchronous function. Then I want to say for each another call back, and I just want this to work. So, I wrote this library called chain emitters. Visa emitters with a couple of extra methods. And they're showing, so one of them is map, and another one is for each. This is what I need. And the cool thing is that after each dot map, I actually return another instance of emitter. So, if down below, I say source numbers, and when I say dot map by constant, yes, it will call by constant for each item. But then it will return a new event emitter. So, I can chain for each to a new instance. So, this works. Okay. I can even write a buffer method. And a buffer would wait for a couple of items, buffer from above, and then pass it to the next emitter. So, I can say source numbers, map by constant. So, this generates a number and multiplies by constant every second. And then buffer will accumulate three numbers. And that means that after it accumulates three numbers three seconds later, it will call for each, and it will print one array as a single shot. And now let's look back. What do we have? We have map and for each. This operate as individual data items. Buffer operates on a sequence. Right? So, we are again mixing concerns. And so, you know, we could write a whole bunch of, you know, methods. I will skip now streams. And now we're getting interactive programming. So, we're really kind of seeing how we can connect multiple emitters and kind of, but we need access to two different methods. One to process data items, one to actually synchronize the sequences. And that's what reactive is. Everything could be a sequence of asynchronous events. And you just create a pipeline, just like we did before. I'm using a library called reactive.js from Microsoft. They've done a very nice job compared to other libraries by being cross platform, cross language. Everything is an observable. So, at the top, I have timer events or time events. Every second, it's a stream of timestamps. And then I create number events by absorbing my array. So, at each iteration, it will give me a number. And then I have rxabsorbable.zip. So, this method takes two asynchronous streams and zips them up, right? Takes one item, another item, whenever it's ready. And then selects one of them. In this case, I don't care about the timestamp. Excuse me. I only care about the number. So, I return the number in the callback. And then I can map and I can print. All the methods are implemented for me. We used to actually have generator that we've built in asynchronous timestamps. In this case, it's completely different stream. So, you know, mentally, it's much better abstraction. We completely separate the time events from numbers, which means instead of, for example, time streams, we can look at button clicks and think of button clicks as a stream of events and use exactly the same code for each button click to print a number. Every library that does reactive functional programming uses this as an example. So, imagine I have to implement a smart search, right? I'm searching something. It fires over search and then shows me the results. There are lots of ways this can go wrong. A lot of this is when you fire off a query and then fire another query and the second returns before the first one and then you're very confused. In this case, I can look at my key strokes and I can create an event stream. I can throttle it so I don't send more than two requests per second. I don't send a request if it's the same as previous one. So, for example, if I type the character deleted, I don't send this again. Flat map latest means that I can fire off multiple promises. So, the top method that actually does the JSON request, Ajax request, returns a JSON. It's a promise returning method. So, all these libraries work very nicely with promises. Flat map latest makes sure I always get, I discard everything but the latest one and then I can subscribe. So, and then there is also a build in error-handling just like with promises. So, reactive libraries, they implement all this, you know, collection processing methods like map filter for each reduce and so on. But they also add sequence control methods like zip, like buffer and so on. So, just to sum up, use small pure functions, the most boring function wins. If you have single asynchronous event, don't use callbacks, use promises right away. If you have multiple asynchronous events, use reactive streams. And now let's look at Canso. Canso is a good startup. We have 25 people, most of them coding. And if we look at what features, it's not even a report card. This is what features of JavaScript we're using today. We almost never use object oriented features. We never call new foo. We use everything in functional. So, we use low dash and RAMDA and we wrote our own utilities for functional pipelining. We don't use immutable data almost anywhere but we are starting to use this. And we're starting to use this because we now have to reason, oh, is this original data from the server or is this modified data so it's hard? I'm almost done. And we don't use lazy evaluation. Lazy evaluation is very application specific. We usually have to process all the data. We don't, it's not a use case of it. We use a lot of promises. We use Angular so event emitters are everywhere. We don't use reactive streams but we probably will use them soon to simplify our UI logic. Future is very bright. I've shown all the examples using current JavaScript standard. The new one, I mean, some things will be simpler to write. I'm always afraid of a new thing that puts focus on classes, right? I kind of love JavaScript but I can just write functions and never worry about prototypes and instances and stuff like that and contacts by kind of putting a focus on a class ES6 is making a mistake in my case. And now the conclusion of this talk. So you might ask me, where is the long journey? Which step causes the most problems? I ask around at my company and it's lack of return values, right? If you imagine the pipeline in imperative code at each step you would get return value, you can name it variable something meaningful and you can reason, oh, this returns this, this returns that. When you create a pipeline, you don't see the intermediate values at all. So it's harder to reason. And another thing that you might ask, well, how do I actually do this at work? And the problem is even if you have a master of everything here, if you hire someone, and you give them this book on functional programming and you tell them, hey, read this, come back in a week and then we'll start real work, they will refuse. And I think the mental picture is this. I'm smart, I just survive five hours of interviews and now I have to go and learn something again, like I don't want to do this, right? But it's a huge resentment. And the second thing is the imposter syndrome. People who already have your company, who don't know some areas, pretend like they know it, right? And you also get surprised. So what we found very, very popular is we periodically organize book clubs, right? Where we go through a book, you know, functional programming, JavaScript talent, whatever you want, but we all do it for everyone interested, not just new developer. We never say new developer, read this. Instead, we say, hey, we're going to meet regularly and we're going to discuss this book. Everyone. Oh, who wants? So I think this solves every objection very nicely. So I'll be happy to answer any questions. These slides are on the web. The blog post, that was a little basis for this presentation is where I'm really happy that you guys listen to me. Thank you very much.