 Hello. Good afternoon. I'm Sri Kumar. I'm from Pramati Technologies. I'm going to be talking about modeling animations in Elm. Elm's a programming language that was created by Evan Chafliki in 2012 as part of his master's thesis and has been evolving since. And it's in great shape today. It's described on elmlang.org as a delightful language for programming reliable web apps. So it's reached that stage much more than what the previous incarnation of Elm used to be. I'm very happy to see that progress. Because it's proved to be a really great prototyping and tool that we are looking forward to put into production soon. So I'll be mostly focusing on animations, but I'll give you an overview of Elm, the language itself. For those of you who are not familiar with it, I'll be a short overview. I'll be showing lots of code along with demos. In case you're not able to follow all the code in all the nitty gritty details, don't worry about that at all. If you can get the general input of what I'm trying to convey there, that's great. So yeah, let's get going. So I'll start with the motivating thing behind working on animations in Elm, both working on animations as well as working on animations in Elm in particular. And especially thinking about animations in the context of the kind of architecture that we do. Just a second, sorry. I forgot to turn off my phone. Kind of architecture that Elm gives you access to. So then I introduce Elm. And we dive into the Elm architecture. I'll also be taking through a couple of factorings of the Elm architecture that I need to go forward with animation work. Then I point out I'll go through a couple of code walkthroughs where I show how an application can be built incrementally, where you start with the functionality of an application. And then you can gradually add deeper interactivity features for the application. And finally, this is the point at which I can enter into animations in Elm. So we'll do this ground up there. And I'll be focusing a lot on physics-based animations because that's something that I would like to see more of on the web today in conventional usage as well. We're all familiar with how the kind of impact that Momentum Scroll has had on us when you're using our mobile devices. That's physics in action for you, right? And I'll be touching on performance briefly here and there. I won't be focusing too much on performance because it's the kind of performance that I'm interested in here that is mostly in the category of not doing the work that you don't need to do. So that sort of about summarizes most performance issues. But anyway. So I'll start with the design toolkit. This set of five items in our bag of visual communication toolkit, the visual communication toolkit back, the expert is required to wield them has not changed in several decades. And it's been evolving rapidly along with the computational medium as well. What has changed is the capability of the browser to deliver on this. The first four are fairly well taken care of today. Maybe there's some room for improvement in layout post-flex box as well. But we've got web fonts now and we can position stuff where however we want. We've got SVG, WebGL for graphics, Canvas, and the Web Audio API is coming to fruition for sound. So that's all looking good. For animation, we are kind of still stuck in the old days of having to specify what to move from where to what value and over which time period. And we're stuck in that kind of a flash like mode of specifying animations. And I want to see what it takes to go further than that. So I want to give a very brief thing about how people have thought about animations in the past. It's not that any work that we do today is going to be new in this because it's several decades old work actually. So Disney guys actually wrote about the 12 principles of animation back in 81. And this is very famous. And I want to highlight a few points on this. Eight, sorry, about 10 of those 12 points are about movement. And that's quite a striking thing, in my opinion. And to add to that, eight of those 10 have to do with physics of some sort, with mimicking physics or imitating physics or exaggerating the physics that we are familiar with in order to create an impact. So there is a reason for that because our brains have evolved interacting with the real world and the amount of CPU load that regular physics that imposes on our brains, that's actually very low. So if you want to build any degree of sophisticated interaction and if you're trying to introduce some new stuff, if you build on that foundation, then it'll help your users draw your users in very well too. And we see that in games all the time. Games come with physics engines just baked in. So they know that upfront. So I want to go back to more than two and a half years when the famous guys launched a demo that kind of went viral. For some reason, we don't see that demo on their site today. I really love this bit. So I'm going to show that to you. It's what the famous team did is they wrote an engine. They wrote a layout engine and a 3D configuration engine, if you want to call that. That's based on what game developers are used to in the world. And they bypassed the DOM layout engine by just directly going to the GPU by using 3D transformations. And it led to some very good insights about what's possible. So thanks to Wayback Machine, we can access this demo today. And this is one of the, I don't know why you're not able to see the entire screen, but anyway, sure. So they just made a demo of these elements that are moving about random. And it's all done in DOM. It's not WebGL. There's no special web trickery involved here. It'll work on any browser that has this. But browsers have come to rely more on the GPU to do good rendering. And this just exploits that. So what I'd like to show is, this is interactive. So you can click on some of this and go flip one of the card. But there's nothing on the backside, but still. You can do that. And I can move back. And I can do a global transformation on that. I can turn into a sphere and rotate that sphere. I can move. I can pick one element out there and flip it and go back. So it feels very engaging. And it illustrates some of the principles that the Disney guys showed, which is quite interesting. The one thing that I want to highlight here in particular is this property of retargetability in animations. So if I move it back, if you notice, if I try to pull this forward, and I can immediately interrupt it before it gets to do its job. And the animation manages to return to its original state smoothly. So you initiate a particular movement. And then if the user decides against that movement through some input, what you do is you figure out another path to the desired state smoothly. So that property is not, however, satisfied here. So it feels I have to wait for it to come all the way to the front before I can go. So what I think is that not having retargetability is not accounting for the fact that your users may progressively get familiar with your application and may want to be more active and more speedily active with your application as time passes. So I want to now go through, just mention a couple of markers for prior work on animation. I'm thinking about animations that's happened in the functional programming community many years ago. So Professor Kavya Arya, he's currently at ITB. He wrote a paper on a functional approach to animation where he considers an animation as a sequence of frames and builds a framework on top of it where you can compose several animations together. And inspired by that, Connell Elliott, in almost a decade after that, created Fran, which I think is a kind of marker for the whole reactive application, reactive development movement that took on after that. So in the work on Fran, he introduced behavior and event which went into the reactive extensions part of Microsoft. And further work was also done on that. There are further frameworks that have attributed his work, Yampa, reactive, and others have attributed his work. And even Elm, to some extent, I mean, everyone has an awesome talk about why he summarizes the history of functional reactive programming. So this is one of our key markers in this. And this is like in two decades ago. So nothing is new in this world. So I'd like to summarize a few key things that we need out of whatever framework that we are building, a framework or library that we are building for this purpose. We want it to be composable. We want to build small animations. And we want to tuck them away somewhere so that we don't have to look into detail and then build larger animations on top of them. And have it behave predictably. Sorry. And physics friendliness, for the reason that I just mentioned, because physics is something that we are so used to that it makes total sense to build experiences on top of that. And performance. Game engines are known for pushing every last ounce out of a box to get to great gameplay. I want to do the same on the web, too. So YL, as I noted there, it's built as a delightful language for reliable web apps. That's certainly true. And I want to highlight one, the main thing that I want to highlight here is you can use it as a kind of a thinking tool primarily because of the way the compiler works. This is true of Haskell also, except that Elm has really awesome compiler error messages. It's really, it might be funny to just highlight that, but it's something that you get to do every day. It's something that you get to see every day. So it has a huge impact on developer productivity. So it's an easy language. And the primary thing that you need to learn about it is just functions and types. And as long as you get comfortable with that, it's very easy to pick it up. There are folks who are trying to teach it to kids. So it's not a complicated language at all, even though some folks may indicate it's Haskell and ML history. And the compiler, the way you use the compiler is very different with these languages that have strong type systems. What it ends up being is that you end up trying a particular idea, and then the compiler spits back at you. And it says, now you tried to do this, but then you told me to do this, and these two don't go together. And then now I have to rethink how my original assumptions about this. And this is a great dialogue to have with the compiler. It feels more like a peer. And the performance, as I said, where it matters. So just don't render frames that the users don't get to see. So that kind of stuff is kind of baked into Elm. And it comes with a great simple framework that you can use to build web apps of whatever complexity you need. So here's the intro to the basic notation in just a single slide. I won't need anything beyond this for this talk today. And for those of you who are familiar with Haskell and ML frameworks, anyone has seen Elm, Haskell, any ML flavored language hands? A few. So the primary difference that you would notice is probably that you don't use parenthesis to do function calls. This strikes people as odd usually. But it's a very useful property of the syntax itself. I think we can have that discussion afterwards. And so functions are defined like that and invoked with just spaces and supplying the arguments. And you can define types like this. What I've defined here is a car enumerator. And one possible car is without permit. Another one is with permit. But then it's got some extra information tucked into that permit. So you can add that kind of info, too. This is very common in languages today, like Rust, Swift, and all of those have this kind of enumeration called sum types. And extensible records are really neat in Elm because they are a very easy way to onboard for JavaScripters. They feel pretty much like normal JavaScript objects. They look like normal JavaScript objects, but they are immutable. So you cannot kind of shoot yourself in the foot like you can with JavaScript, where some other library ends up mutating something that you didn't expect or you did a typo in your key or something like that. The compiler will just catch that for you. So type inference as well as immutability really helps you here. And LED binding for pattern matching is now there in ES6 as well. And then comes with that all ML families have had that. And case pattern matching is another thing that both it's common to Rust, Swift, and all this. There's a lot of borrowing that happens between these languages. So I just want to point out one thing about the case and one about that new purchase declaration. So the colon thing is a declaration. It's a declaration of a function. So it's a declaration of a function from an album to an album. And the arrow indicates that if I give an album to the new purchase function, I would get an album as the result. So likewise for DiffNorm as well, if I give a float, what I would get is a function back, a function to which I can supply another float and then get a float out. So it's cutting is built into the language. So in order to use Elm, it's good to have an idea of the architecture that goes into writing an application in Elm. It's if you know React, we've been talking about React a lot. For those of you familiar with React, you should feel totally at home here. Except that it's going to be probably easier and you can use the full power of the language on whatever you're going to build. So there are Elm introduces this kind of single place where you hold all your application state, which is called a model. And that's the central thing around which the whole architecture revolves. So the browser subsystems end up sending messages to your thing that's continuously maintaining the model application state. And the view is producing what the user is, what you expect the user to see on every instant where you need to change that. And the view itself can produce more messages for your application. Like for example, a user may go and click a button or type some text into a field or do whatever, or mouse over something, drag something. All of those get translated back as messages to your system. And the command is something that your application may want to do, like make an Ajax request and get a JSON back and so that you can process it. And this is a message that you send again to the browser subsystems, say, to do an XHR request. And the subscriptions are something that you indicate to the system so that it takes care of a stream of messages coming in, like for example, web sockets or timer events that you want to set up for various purposes, either for rendering or for animation computations, et cetera. So essentially, your ELM application is deciding what to do with messages, how to apply the models, and how to compute those three things that you need in order to specify that. So this is a new architecture that was introduced in version 0.17. 0.16 did not have this architecture in place. This is much simpler to work with for most people coming into ELM. So I urge you to take a look at that. I'm quite sure some of this will also start seeping into other systems that we use. So your application is essentially consists of four functions, as I said. So those are the boxes that you need to fill there. So you initialize and then you specify how to compute your view based on your model and how to update your model based on the messages that are coming in and what kind of subscriptions you need depending on the model. So this is the basics of what you need. And once you can specify all of these, you're good to go. And sometimes you don't even need all of these. So I'll walk through a sample app with you. This is an example that's already there on the ELM Lang tutorial site. And I made a couple of changes to it, but it's still more or less the same. So this should give you a flavor of what it feels like. So this is the main app. So you have this program, and those are the four functions that you need to give it. And the rest of the application just ends up specifying those four functions. The rest of the file is about that. So in our case, the model that, sorry, let me just change this. Let me just do that. Anyway, I'll come back to that. So the model consists of I'm just counting. I'm just pumping messages into the whole system there. And I'm just counting the number of messages that it can go as fast as it possibly can. So I modified the demo a little bit to do that. So in initial configuration, I can also specify a command that I need to run when my application is starting, with where no interactions have actually happened. And the messages that my application responds to are roller dice. And when I click a button, it'll roll a dice. And then when it rolls a dice, it gets a message back, saying, well, here is the face of the dice that you got. And this is where I update my model here. So roll die is about generating random numbers there and getting it back to your system. And what I'm doing here, if you notice, is I'm updating the count. When I get a new face message back, and I immediately fire off another instruction to roll die again. So the L is now going to do this really fast. So we'll just take a look at that. So it's very simple. It's just a single number. But then when I hit roll, it's just going to go to town. So you're seeing something of the order of 30,000 messages being pumped through the L system per second. And you don't need to be really aware of how these messages are being scheduled. And only the updates that you see will be rendered, like only maximum rate of 60 frames per second. So all of that's sort of automatically taken care of you. And you don't even need to worry about this in this case where I'm creating an infinite loop. I hope that gave you a taste of what a typical L application looks like. You specify your initial configuration. You dictate how your view looks. And you specify how to update based on the messages. And you declare a set of messages that your application responds to. It's very simple, but that's fine. What happens as you build your application to deeper and deeper levels of interactivity is that more of your application's visual state starts getting into your model. And because the model is now a hierarchy of components and the states that the components hold, this starts getting quite clumsy to manage after a while. And it's useful to think of the model as consisting of two pieces. One is the model that you really care about, something that you would want to save, perhaps in the back end or something like that, user information, account information, whatever. And the other is view state, something that info that you purely need for the purpose of rendering stuff. So for this, we can split the update function into an add one more control function, which takes these messages and just computes the visual state, the view state, for our application. And this is what typically a controller does in a typical MVC pattern. So it's not very new either. And especially in the context of animations, you take a cue from what goes on in animation studios, where a director dictates what the whole progression of the sequence is going to be. And then animator step in and fill in all the pieces so that the whole vision of the whole story remains. So it's good to also split the view state further into this kind of a direction that we want to do, want the application to take at any point. Like for example, if I click a particular button, then I want this whole thing to eventually land up in that particular position. That's what the direction should state. And the animator kind of figures out how to get there eventually. This is a very common design pattern. And it was introduced in core animation on iOS, where you have every layer of core, every layer that you put. There's a layer hierarchy that you have, the core animation deals with. And every layer that you have actually has an underneath the presentation layer as well. So if you set a property of the layer, it kicks in an animation process, which will slowly move that particular value towards that particular value over say a quarter second or half second. And while when you're reading off the top layer, you would see the final value. If you dig down into the presentation layer, you'll know exactly where it stands at a given point in time. So this kind of a split between the direction and the current view state is already what's driving adoption on iOS. And it's very easy to program with that kind of a mindset. So this is what our split between the direction and the animation looks like. So the director basically computes this direction structure, which is a rough indicator of where we want to be. And the view state is the animator deals with these time steps and derives how to reach that particular point over time. Everything else stays the same, doesn't change much. So I'd like to show a small kind of tutorial application I built around this particular concept. And I'll walk you through the code to show how we can incrementally develop an application here. And this is a, it's a very simple application again. It just starts fruits and veggies. So on the left you have a list of things and right you have a list of things and you are expected to sort these two into fruits and veggies. So the initial interaction is just, is very, very simple, straightforward, nothing fancy at all. So I can just click on a particular element to throw it into the other list. So pairs, I can just throw it there and broccoli and just throw it here. Very simple. So now if I look at the code for that, I should give an idea of what it's doing there. I'll focus on the modeler alone for this part because that's where the main logic is. So here are the instructions that are coming into my system where it says move this particular fruit from this location to that location, move this particular veggie from this location to that location, et cetera. And it's handling all of those cases. What's going to happen as I show the further versions of this application is that none of this stuff is going to change, but more sophisticated interaction is going to happen. It's not sophisticated, more interaction is going to happen. So the second version is it still behaves the same, but there is some bit of code change that prepares this for new interactions coming in. So as I said, the model doesn't change. It's the same interaction, same set of states that we need to handle in exactly the same manner. But then we begin to introduce a direction, and the director approach. So the director is basically saying, here is where I need to be, but then we don't put in an animator. And the animator just says, yeah, just get there and be done with it. Don't move, don't take your sweet time to do that. So this is our next step to doing that. So if we take the third incarnation of this, we have, now the movement is smooth. So all that's happened in the transition from the second to the third one is that an animation has been added. And this animation is, as I said, retargetable. If you notice here, I can click as far as I want and they would all just move there. And it doesn't, I can interact with it as frequently as I want. It's just plain smooth and there are no surprises involved in this. That's what physics-based animation actually feels like. It's, there are no surprises there. So if you look at the code for that, that's, you find that the modeler is the same. It handles the same cases except a little bit of refactoring, perhaps. And then the direction is the same. Nothing has changed there. But then this is the part that's changed. So I'll be talking more about the specific approach that I've taken to animation here shortly. The, what this one does is it treats each of those boxes as a kind of particle and then composes them all into one mega particle, so to speak. And then says, okay, just do what particles do. So the, so that's for that. So how do we then think about these animations so that they can be pulled out in this kind of a manner and composed to create more and more higher level, application level animations? So the simple animations, we are all familiar with that. It's just, it just says move this particular parameter from this value to that value over this particular duration of time. And we can model that as a normal function from a time to value with a few configuration parameters. Animation curves are very common. We are very familiar with easy knees out. They are all baked into CSS. And the bottom is an example of an acceleration like curve. These are a few kinds of curves that you typically encounter when you're programming animations. The left is an accelerate. The right is a decelerate. This is the actual deceler is probably the most common easy knees out animation that's used. That kind of curve which overshoots the zero one parameterization, it tries to show some amount of anticipation and follow through that Disney folks highlighted very early on. But it needs some amount of special attention when you're programming this in order to use that effectively. Physics is different. None of the simple animations need state for that operation. Physics is inherently stateful. So your whole system state depends on the previous state and then a bunch of forces that are acting on it and anybody could point in time. If you look at that as a time step, what happens to the physics parameters over the time step, that becomes very clear because X, so if you look at the position of a particle, the state of a particle is basically the position and the momentum. And then when it changes in time, I can make use of the previous state and the forces acting on it in order to decide what to do next. So the position and momentum, we can just sort of treat that together in what we call phase space. That makes it easy. Normally when you look at animations in physics, we just bother with the position there but the movement is also useful, for example, to create motion blur at a point when we can do that. This is just a motion of a normal spring, a mass and spring. When you look at it, it's oscillating like this but then in phase space it actually moves in a circle. So we model that kind of recursive nature of physics equations by just using a normal recursive function which we are gonna step through time. In every time step, we are gonna update the state. The state is basically what the position of the particle is in phase space. So there's a couple of steps before we are able to make use of this in an abstract enough form when we can compose it together to form more complex animations. And this is a trick that all of you are probably familiar with but there are times when its use is really surprising and this is one of those occasions. So there are two kind of prefix functions here. The prefix functions take one takes a string and the other takes an integer and prefixes it and you can hide that particular fact when you make a new prefix or one and prefix or two functions this way. So this is a very useful trick when it comes to trying to abstract out the state idea because when you're trying to compose animations you do not want to know anything about what's inside the state but you just care about what goes in and what comes out. So that's what we do. We treat an animation as something as a kind of a process that accepts a particular controlling value on its input and produces a corresponding output value. And the animation process keeps stepping once every request animation frame that's 60 times a second. So we wrap that up in a step function and the step function here is essentially pulls that wrapper out and then applies it. That's, it doesn't do much. This is all we need in order to do, take the next step. Now we hide the state, the fact that this whole thing is using state using a function of this kind. So here is something interesting is happening. So with hitting state takes the state and a step or function that's aware of that state and then throws it, packs it into this animation object which if you see the final part of it, it just says animation in out. There is no indication that the state is present within the animation and that's what we are looking at for the perspective of composability. Once we have that, we can now think about particles very clearly. So we just saw what a particle does, right? I mean, when you click on a particular button there and the fruit moved to the other location like what a particle normally did. So some forces are acting on it and it's responding by updating its value in phase space. So it perfectly fits our idea of animation in this case. And you can describe more kinds of forces here. I just put in a couple just for illustrative, illustration purposes. If you look at the library Elma Anima there are more kinds of forces that come with it. I can show you a couple. So these are some of the forces that come built in. So there's spring, there's gravity, there's a wall that prevents motion beyond a particular point. There's an impulse kick that you can give to objects, all of that's supported out of the box. So we can also pull out this idea because we not only want to animate things in space, in physical space, sometimes you wanna animate things like color, we wanna animate things like, I don't know, some particular property, has some squash and stretch and all of those properties we want to be able to animate. So we wanna abstract out that idea of, instead of just saying wanna animate a float, I can generalize it into a space and we can treat a one-dimensional particle as an instance of that particular space. So that's the primary thing that the Elma Anima library is based on. That's the whole crux of the whole animation specification. But this was not arrived at from the first shot. So this is the beauty of the ML-like languages. So they let you work from a very ground up manner where you're really struggling with the concepts in that particular domain and you really don't have any kind of clarity about it when you're starting out with it. But then gradually you can work bottom up and arrive at the kind of an abstraction as long as you keep your eyes on the ball here as to what you want out of these anime or what you want out of what you're building. So I wanna show one final incarnation of that same application. So it's still the same, but it does something else now. Now I can drag and drop it into whatever place I want. And this is implemented using the same framework. What you're seeing here is not using the browser's built-in drag and drop feature. Every interaction there is coded up in El and it reacts live and uses spring physics in order to do that. So you see everything is reacting to it instantly and you can drag and drop. Even the indicators, the director in this case is the one that's saying that, okay, here is what I want to indicate and the animator is showing the indicator there while it's also following the object around. And it knows that the object that I'm dragging has to appear up front. Every tiny little detail of this drag operation is being taken care of in El and there's no performance penalty that I've seen to doing that yet. The code for this is, of course, because so many of this is being done in El it's fairly complex, but it still follows the same approach. The model is no different. The director is no different, except for the fact that it indicates what the position where it needs to be dropped. But and the animator does a lot based on the drag operations in this case. So it's possible to evolve the interactions of your application without touching the core functionality that you're looking at. And that's a real boon when you're developing over long timelines, when you're developing with a large team of engineers, you can have different folks work on these different parts and be guaranteed by the compiler that when they are put together, it will work. You won't even have to bother writing unit tests for that part, practically speaking. So there's just one more that I want to show in terms of performance here. There's a small collage that I built out of pictures that I grabbed from my colleagues, old pictures they are. And it's a collage of 250 pictures. And they're all alpha blended together into this one smush here. And you can build a small interaction around this so that you can see them go, you can sort of scroll through all of the pictures here. It's largely a black background so that in the light, you're not able to see the reflection of the thing here. It actually has the normal reflection that you would see in most cases. And it's very smooth. And this is entirely written in Elm. It's probably about a page. It's about a page and a half of code, that's about it. And I'm not doing anything special. No optimizations done. The virtual DOM is what's doing its job here. And I mean, though I'm saying Elm is great in this front, I have to really congratulate the browser for actually doing a great job of chunking all of this down to the GPU. So this takes the same approach that the famous guys did. So all of these elements are bypassing the DOM's layout. So as I noted in my original post, I'm a big fan of just trying to do everything in Elm for what it's worth. And I think it's a great way to try to learn about this part as well. So we come to the end and I wanna close with just a few remarks. So these functions and types, especially when you're grappling with a domain that you still not quite got the hang of, they are great sketchpad tools for you to work with. And you can work very bottom up and the compiler is a great peer who will give you the necessary feedback to check your train of thought, whether you're going in the right direction, whether you're managing composability, whether you're composing the right kinds of things together, all of that feedback will be given by the compiler. So in this case, if you notice, we have this modeler that's maintaining the model and then the director that's taking care of how to specify the expected visual state of an application and then the animation is just taking care of that part of it. These are all building on a layered kind of architecture where each layer just needs to talk to the layer below. The animator, for example, has no say over what kind of commands go out to the system. It cannot send an XHR request, for example. It doesn't need to. So these kind of clear layer separations if you establish in your application architecture, I think it helps with code longevity a lot. And it also helps with performance. In case, if you look deep into your system, if you look at the entire pipeline that we are relying on today, we have, we write code in JavaScript, it gets compiled down by V8 into lower level code and the machine code. And then even the processor converts this machine code into microcode before anything actually happens. So this kind of a layered architecture is prevalent. In the GPU as well, we are throwing source code at the GPU pretty much on a live when we are rendering a shader for this. And it's all happening live. So that layered architecture has proven the test of time and we should do more of that in order to help with code longevity, which is something that we are struggling with today, I think. So incorporate physics into your animation designs. So even though the famous guys did that two and a half plus years ago, we are still not yet at a point where we are seeing more of this kind of work happen on the web and I would like to see more of that happening. And especially when it comes to learning simulations, games, it's very welcome to rely on that, especially when kids are involved. Go play with Ellen because it's really fun. I can't emphasize that enough because there are these times when you're up at two or three o'clock in the morning and you're coding and just saying, what the hell am I doing at two or three o'clock in the morning? And Ellen was one of those languages that makes you do that. So try to block that code, that'll be my last slide. Just a quick announcement. We have time for a few questions and people are okay to like eat into the lunchtime. I'm sure there are lots of questions for Sri Kumar. It's a fabulous talk. And also before you guys leave after the questions, we're gonna announce the winners from the contest that collective ran. So please stay back to collect your prizes. Let's take questions. Hi, here. Hi. Thanks for the talk. It was great. So what you do with Ellen, can you do with other languages which share the same principles like functional programming, pure functions or immutable data? Clogescript, for example. Sorry, which language? Clogescript. Sorry. Any language that is functional? Yeah, I mean, in principle, yes. The thing that's nice about Ellen is that it comes with kind of batteries included for the web world. So when it compares down to JavaScript, it's actually fairly performant code and it comes with the tools that you need in order to build web apps. So most other tools don't come with these kinds of battery included mode. And it comes with dev tools. For example, the Elm reactor, which I just loaded up there, that comes with it. So I can just fire it up and I can go click on an Elm file and run it. I don't even have to bother about the compile cycle. That kind of support. And you should see the compiler error messages. I think it beats every other language pretty much hands down. Perhaps not every other language. I don't know all the languages, but at least it does that. So the ecosystem is actually very friendly on that front. Okay, thank you. Hi. Here. Here. The speaker just says here. So what's your opinion about having a shared immutable state? Sorry? It looks like we are sharing state like which is immutable here like so. Sorry, I'm unable to hear you. A shared immutable state. Shared immutable state? Yeah. Immutable states, I mean immutable states just a value. There's no problem about sharing it. So that's the whole point we are actually dealing with this, right? So multicore, distributed computing, all of this. As long as you don't change anything, everybody can look at it. So there's no issues. What's your specific question in that regard? In contrast to say a redux or some other philosophy where sharing state is not really appreciated. And here in elements like contrast where like you gave an example of the physics iteration, recursively we are like passing the state again and again and manipulating things over it. So it's not, it's counterintuitive for a guy who's like coming from the JS world. So you think it sounds intuitive? It's counterintuitive. It's counterintuitive. Yeah, immutable data structures are something that usually whoops folks struggle with. And it's not actually necessary to struggle with so much because there are other places where we are doing this day in and day out but don't even recognize them to be immutable data structures. For example, we use Git, right? Everybody I think here uses Git. And Git's an immutable data structure. You don't lose your source code at all. So once you make a change, it just records that one change. That's what the data structures do here in memory. That's it. So if I wanna share a particular snapshot of my code, I just send you that hash and I'm done with it. So it's the same thing that happens with data structures in languages like this. So there's nothing really in terms of philosophical difference or anything. Those are just big words here. It's very practical to use these in the current context today. You don't want other libraries to stamp on your stuff. You don't want another library to step on your prototype and change some functions that you've implemented in there. You don't want any of that to happen because it's a huge testing burden to deal with that. I mean, yesterday we had a discussion where we were talking about that in particular, right? So I'm forced to use some particular library, but then I have to test every aspect of that before I'm really sure that I can incorporate it into my system and still I'm not very confident of doing that. The kind of immutability and type systems really help with that. Thank you. Okay. Hi, so I love the talk. So my question is, with N, N anima that you wrote, so what's actually, is it doing? Is it actually converting? So you were basically writing those physics, it's converting, somebody is actually converting that physics into, you know, so that it can run on the browser. I understand that you're talking about, you know, bypassing the DOM and, you know, directly using. So is it doing the same kind of stuff that famous did or is it doing something else new? It's not nothing new, it's not anything new, except that in the context of language like Elm, figuring out how to factor this neatly so that you can evolve your application over time is a challenge. And especially when these elements can all interact with each other in certain ways that you don't originally plan for. But that's the kind of stuff that usually gets very messy when you're dealing with in JavaScript. So eventually it has to go and set values in the DOM. That's always there. It's just that in all the demos that I showed you today, we are not using the DOM layout at all. All the layout is just static layout. And all the properties have the 3D transform set so that we hit the GPU as early as possible in the whole pipeline. So that is basically handled by the M compiler? That's, no, it's just something that you do to the DOM, it's nothing that the Elm compiler actually needs to do there. I just said this particular property in the DOM and the browser takes care of that for me. Yeah, so in Elm 0.17, right? Even said the functional reactive programming is dead basically. So your library does not work actually with the latest version of Elm. So how are you planning to make it work actually? Yeah, this is part of the reason I haven't quite, I had a star remark on a couple of slides back and yet I mean the process of updating it to Elm. There are some dependent libraries that need to be ported mostly by removing stuff that's not needed for Elm anymore. So once that's done, it's a fairly easy job. In fact, the subscriptions and the CMD actually makes it easier to do that. It's not so much that FRP is dead per se, it's just that there's one massive signal sitting in front of your entire application that you don't need to be aware of. That's mostly the case with the new architecture. So your question was specific to Elm anymore or anything else? Yeah, so one question I had was if I want to combine Elm with a traditional JavaScript application, how is the ecosystem to start gradually adding parts where Elm would be a better substitute? Is it easy? Yeah, it is actually easy. So with Elm, you can just identify a particular DOM element into which you want to put a part of your application and you can have an Elm application written for it and say embedded over there. You can start with that as simple as that. So you can start by migrating small pieces of your application into that. The main, once you're willing to do it, that is. So, does that answer? Yeah, that answer. Thank you. I recently got a chance to work with TypeScript. You have heard about it. It's like an object-oriented way of programming JavaScript. So is that like Elm is going to be the future of JavaScript? Because? Yeah, I mean, nobody knows the future of JavaScript. That's kind of the beauty of it, in fact. It's not like that. It's almost never like that. We don't know what the case is. But certainly, I get this nagging feeling that we have to go back to the drawing board at some level. I was just chatting with somebody else who indicated this. The same underlying technology is now being used in all browsers. LLD and Bitcode is now runnable in Firefox, Safari, as well as Chrome. And yet, we don't get that exposed outright. So there's still scope for that level of functionality to be safely packaged within browser and exposed to us. So we don't know where that's going to take us. If somebody actually does that, you can use any language to compile LLD and Bitcode and be done with it. So it's anybody's guess, I think, at this point.