 Good morning. Thanks for coming to this talk. So my name is Dev Naatsana and I wanted to talk to you about Famous today. It's a new JavaScript framework that's come out and we are using it at CosideIO and we want to just talk about it to you all. So a little bit about myself. After graduating, I basically worked in the valley for about five years, first at Cisco and then at Salesforce. So at Cisco I was doing very low level device drivers but then at Salesforce I was on the analytics team and while I was on the analytics team, we were building a phone gap based mobile application. So I had some experience with developing hybrid apps, right? But then in the beginning of the year, we finally decided to take the plunge and I started Coside.io. So Coside.io is basically, it makes your enterprise sales team more efficient and we sit on top of email and we look for certain text markers to decide where in each pipeline, where in the pipeline each deal is and move things along. So this is like a big pain point in the customer relationship management industry. So the thesis of the talk today, that I want to say, the JavaScript is ready for primetime mobile app development, right? And this is more like, so when I went to graduate school, one of my professors, the course was stochastic processes. One of the hardest courses, he said, my job is not to teach you the answer, it's to teach you to ask the right questions so that you can go and find the answers for yourself. And I think I want to take the stock in a similar light. The idea is to take you through our thinking process when we were evaluating this framework so that you all can use the same questions or alert us about other questions that we may not have thought of. And the answers will actually be different for everybody. There's various, various use cases, various trade-offs to be made, and really, that's what engineering is all about, right? So the question is, why do you care? Why do you care where the JavaScript actually becomes a thing for mobile app development, right? And first of all, because this is a JavaScript audience, right? And some of you want to use your skills to build mobile apps. But there's another reason, and that's because in the beginning, all your model used to reside on your server. But ever since the phones came out, your clients are actually connected to your server using a very lossy, low bandwidth network, network pipe. And one of the things, this, one of the architectural decisions that this forces is that you have to now take a model and push it more and more of it onto the client, especially if you want a very responsive app. Now the device fragmentation kicks in, and since you have different platforms, you actually have the model in, like, you have different code bases for the model. And if the code bases, like, fall out of sync, there are various problems that can happen. So let's take an example of a simple bug. So in Cosa's case, we have, say, an analytics engine, right? And the analytics engine is used to filter out, you send some data over about basically your sales and financial data, and you want to allow the filtering to happen. Say I want to say, in the SMB segment versus enterprise segment, how does my pipeline look like? You want all that to happen on the client without having to take a server round trip every time. So say you have your iOS code base and your Android code base, and the filter function has a small little bug in it, because there were different teams that were developing this. And it's a very simple bug. It's like either if less than or if less than equal to. And the problem is that if you look at this table, you actually end up seeing a different value. And this is really bad for you, because in one meeting room, you now have a guy on an iOS device and a guy on an Android device who can't concur on the same number, and they lose trust. And there's nothing that's worse than losing customer trust. So if you do buy into the idea that you want a unified code base for the model, what choices of frameworks and language do you have? The first is C and C++. And you can actually, like on iOS, it's very native. But on Android, you have this concept of a NDK. And then in JavaScript, you actually have this framework called M-scripten, which Mozilla is coming out with, which takes a C++ code and converts it to JavaScript code. And this is actually being used by some video game developers because a lot of the legacy game engines tend to be on C++. So it is like, there are people who are using this. But the other piece of it is JavaScript, your other. Your other option is actually JavaScript, right? And that is using some, a wrapper, sort of like phone gap for Android versus Android and iOS device, and rendering it natively on your web browser. So one of the structure of the stock is basically to talk about the features we thought were important in building a high quality app, right? And we'll go through them one by one. So first, let's talk about performance. So the first thing you hear when you talk about hybrid apps is that, oh, JavaScript is slow compared to native, right? But we're engineers here. So let's try to dig in a little deeper into which piece of the stack is actually a bottleneck. So if you look at the stack, on the first, like on the bottom most layer, you have the device OS, above which you have a wrapper, sort of like phone gap. Then you have the JavaScript interpreter. Then the browser rendering engine. And depending on your mental model, you can think one above the other or below. But for this, the thesis is that they're different layers. And above all of that sits your app. So let's talk about the wrapper. So the wrapper, the point is that you want the latest browser rendering engine for a very performant application. And unfortunately, things like phone gap, default to the default browser. The problem with this is that the default browser before Android 4.4 was not Chrome. It was actually the Android browser, which would be fine in an iOS world because iOS users tend to upgrade to the latest iOS that comes out fairly quickly. But on Android, if you look at the Android adoption usage and we pull this right from the Android developers page, most of the world is still not on KitKat. And this means that you actually have to address the issue. So if you want to use more powerful features like WebWorkers or, say, WebGL, you actually need the latest rendering engine. And there are people who are trying to address this. PhoneGap also has an option for downloading the latest. But the problem with this is it increases your app size. And that is the trade-off that you have to decide whether you make it or not. It may not work well for the bottom, like the low-end smartphones, but for the high-end smartphones, it's a different issue. So then let's move on one layer of the stack to talk about the JavaScript interpreter. And the point is, if you look at the history of interpreters, it used to be true that back in the 80s, it was performant to write assembly language code and you could actually get very good performance out of it. But today, not many people write assembly language code. A C compiler has become good enough. And so the question, the thing you want to keep your eye on is when is this compiler becoming better? So if you look at a JavaScript, the interpreter used to be slow. And then Google invested in it. And they came out with VA. They spent a lot of resources building it. And now it sits inside Node.js, which many of you all actually use on the back end. So if you look at JavaScript performance, when it comes to native Compile C, it's about 80% when it comes to matrix multiplication, at least. And I'll get into a little more detail about why matrix multiplication is important, but it has to do with computer graphics. Then let's talk about the browser rendering engine. The question is, is the browser rendering engine really inefficient? And in some sense, this is true, because browser rendering engines were built to render documents, not the kind of rich apps that we are building today. And so let's talk about an inefficiency in the browser rendering engine, and that is layout thrashing. So there's two codes, one on the left, one on the right. And both of them have the same functionality. Yet the code on the left causes two paint cycles on your browser, and the code on the right causes one paint cycle on your browser. That means the code on the left takes two, like its FPS will actually be lower than the code on the right. And so it will give you a jerkier UI. The problem is, when you're building an application, it's very hard for you to keep track of this exactly how the DOM is rendering, how many paint cycles are being caused. And so now you see new libraries with things like Shadow DOM which are trying to address these issues. But if you actually come from the multi-threaded world, you will notice that actually there's concepts like serializability and compilers like GCC and JVM are actually allowed to reorder your statements so that they maintain the same, as long as they maintain the same functionality so that they can use things like, if a variable is already in cache, then let me use that while it is still in cache. And the reason I want to call this out is because, again, the analogy that the JavaScript is finally, that entire stack is fundamentally a compiler and when people talk about performance bottlenecks, it's not the language that's the performance bottleneck, it's the compiler and the interpreter. And that is getting better. So what you have to do is actually keep an eye out for what new technology is coming out, what impact performance, and when it becomes good enough for your application. So to create, if you take the notion that right now the apps that we are creating are basically three-dimensional worlds with lots of animations which have been rendered onto the two-dimensional screen of your phone, let's go to another industry that has actually done this for the last two decades, and that's the video game industry because maybe they have some things to teach us. And the fundamental premise of computer graphics and the video game industry is that all the entire 3D world can be brought, projected onto a 2D screen using a bunch of 4x4 transformation matrices. You combine them in various ways to get the positioning that you want. Anything like rotation, skew, or even translation, or if you want to resize one compared to the other to bring things up front on the z-axis, it can all be expressed with the series of these multiplication transformation matrices. And that is exactly the trick that Famous uses. What Famous does is it takes your code and creates its own render tree. So rather than relying on the browser's inefficient render tree, it actually takes your own render tree. It creates its own render tree. And then if you look at how animation works in the browser, every paint cycle that you can register a callback function that gets called whenever the browser does the next paint cycle, which is about every 16 milliseconds for a 60 frames per second, which is considered the benchmark for good UI. And what it does is it does the render tree and it renders the render tree. When you do this fairly frequently, say every 16 milliseconds, it gives you the notion of unobstructed motion. And that's how animations are created. So let's take a simple example of an app that's built, derived off of our app. And it's basically, it has a scroll view. And this is your, whenever you're taking actions on the customer relationship management side, whenever you're updating a deal view, it gives you an activity feed. And on the other hand, we have the home screen where you basically have course as logo rotating. And this was more to show you how the physics works. So let's actually look into this app and see how exactly you structure it. So the first is you need to plan out your render tree itself, right? And so you have a header view, a content view, and a footer view. And the way it works in famous is you have views. So if you've looked at UI development, you basically have views and the views as sub views and ultimately you have like basically rendering elements, right? And it's sort of similar even with this framework. And what you use to move views around is called modifiers. So let's look at the header view. And the header view is basically, it's a surface, right? And the surface is famous for, speak for a div element. And what it does is you use the modifier to position the div element. And if you look at the div that's generated, you basically, if you notice very carefully, you have a Matrix3D WebKit transform. And Matrix3D is basically a W3C API that tells how you're going to use this 4x4 matrix that we spoke about to position it correctly, right? And this, because this is the reason it's important that it's a W3C standard, is because now you can expect every single browser to support it going forward. And so what you see over here is you basically had an almost identity matrix because this was at origin and you actually didn't need to move it anywhere. But now let's go into the footer view. Footer view comprises of two sub-views, the home view, the home tab view, and the activity tab view. And the only difference between the header view and this, first of all, it's, you're using an image. So it's an icon. And just the same way a surface corresponded to a div, an image surface corresponds to an image tag. But the only difference between this and the header view is that you actually want to translate it to the bottom of the screen. And so as you see, what we've done is we've added a modifier and it translates it 430 pixels. This works for iPhone 4. But the point is this would be a variable that's proportional to your screen size. And as you can see the 3D transform matrix, it actually moves it by 430 pixels. Now let's go into more complicated animations. Let's talk about how you do the spinning logo. So if you look at the spinning logo, now instead of translating it to the bottom of the screen, you actually want to rotate it. But the only thing is you want to rotate it as a function of time. And that's exactly what we're doing. So you actually take date dot now, and that gives you the most current time. And it keeps incrementing every time the request animation frame is called. So every time a paint cycle is generated. And what you do is you rotate it a little bit more every time the paint cycle is generated. And so long as you do it at 60 frames per second, it looks like the whole logo is rotating. And if you look at the DOM itself, right, if you look at the div that's actually the HTML element that's actually generated, it's looking like a whole bunch of numbers because it's basically sine theta and cos theta based on whatever your theta being date dot now minus initial time. And so what you see over here is that you've got a fairly complex animation based on something that is actually easy to reason about, not just for you, but for the guy who comes in and reads the code later. Because in any reasonable application size, a code is going to be read at least four to eight times for every time it is written. And that's just something you should design for. Now let's talk about tab transitions. So for tab transitions, you basically saw that every time we click on one, a one view is brought to the front and the other time it's replaced with a different view. So how do you address that issue? And so basically if you look at the code, it says that if I click on the home tab view, then show home tab and hide the activity tab. If I click on the activity tab view, let's show the activity tab and hide the home tab. So let's refactor this code a little bit and have a variable called state. And I just make state zero or one. And then say my display function of the view is proportional to either state or one minus state. So what this does is establishes a constraint that only one of these codes will be, one of the views will be visible at any given point of time. And how do we bring the view forward or backward? We basically change the opacity. So this is like sort of a CSS property, but we change the opacity from zero to one based on which one is clicked. And then we bring it out up front. The reason you bring it up on the Z axis is because you want to capture the events on it. So if you're scrolling, you want to capture the click. You want to capture various events on it. Again, this is something that is fairly easy to reason about, not just for you, but the guy who comes in and reads the code later. So, but then what you see over here in the previous state is the state was either zero or one. So at T zero, you basically have the state as zero. And then the next time it's clicked, it goes to state one, and the next pain cycle, it automatically becomes the new view. The problem with that is it's very jerky. And jerky animations are not very good. So you want to make a smooth animation over it. So how do you make a smooth animation? And the construct that famous gives over here is actually called transitionables, right? Another thing I wanted to point out is this was basically a tap transition, but you can generically use this to synchronize various UI elements inside your screen. So say you swipe and you want to, you know, bring out a new view that has the delete action as opposed to your normal view which shows, say, your email, right? That is also a similar constraint to this. It's just a synchronization primitive across your UI. So now let's talk about transitionables. What does it do? It basically takes a number and says that from start value to end value, instead of making it discrete, I'm going to make it a smooth transition depending on a curve that you specify. So you can specify any kind of a physics simulation, see a spring action or something like that, or you could specify some kind of a tween curve, right? And so if you look at the example below, you basically start out the state as zero, and then you tell it, transfer it to state one, but do it over 100 milliseconds and use a curve called ease in these out. The curve itself doesn't matter, you could think of it as a spring animation, but the point is now you're doing it over 100 milliseconds, 100, 300, whatever, it's much more soothing to the eye. And so now you see that you basically, using famous, you've been able to construct very complex animations and yet reason about it in a very simple manner. And I think for us, we think this is like really, really powerful, right? And this is why we like this framework. So what about the other features? So we've spoken about performance and how famous impacts the layout engine and it goes a long way forward in solving the performance bottleneck, right? What about the other issues? What about the other pieces to a really complex app? And the first is modularity. So back when you were in college, you probably wrote programs that were about a couple of thousand lines and a lot of your classes were in the same file. And yet after your first job, what you would have seen is that they had strict code guidelines, like, okay, one class per file and not more than that. The reason for this is because, again, because your code is going to be read much more often than it's written, you want some kind of a structure around it for the guy who hasn't coded it for the first time. It's no different in JavaScript and this problem has been solved in JavaScript using AMD frameworks. We use RequireJS and the only thing you need to know about RequireJS is that if you look at a fairly standard view where you basically say I require the child view, so pull that in and the framework decides how to pull that in and then you compose yourself your own view based on your child views and you export yourself so if somebody else wants to do that, if you look at the famous tutorials, they actually include RequireJS along with all the tutorials. So it might give you the impression that you need RequireJS to run famous. That's not true, but it's just very good hygiene and so I think they've just included that inside by default. The other thing you need to build a really large scale app is some kind of a structure, right? So on the server side, you usually use design patterns like MVC, to basically create some kind of a structure so the code gets less complex and again, it's no different in JavaScript. So we use Backbone.js, it's not the only MVC framework, but we use Backbone.js. The question is, and this allows us to keep track, decouple the view code from the model code very standard MVC tradeoff and the only question is how do this play with famous, right? So if you see controller logic, there's no point writing a framework for your controller logic because it tends to be very application-specific. So we use Backbone.js, we use it only for the model. So then the question is, how do you combine Backbone.js with famous? And here's an example of a Backbone.js model. It's a very standard Backbone.js model that's built from the to-do app. Now if you look at Backbone.js, they actually have predefined views, events, right? So whenever a model changes, you can subscribe to either the change event or the change and attribute event and then re-render your view based on that. It's no different for famous, only you replace the Backbone views with your famous views, right? And so you basically pass in the model into your view as an argument and then every time your model changes, you re-render your famous view and that's where you basically combine Backbone.js with famous, there really isn't that much it fits in very well together. But Backbone.js is not like, I was going to slide with some people and they say, oh, is Backbone.js a requirement? It's not a requirement. There are people who are trying to build famous integrations with AngularJS, there are people who are trying it with ReactJS, although ReactJS is not a model framework, it's more of a view framework. And to mention some other integrations, you have it like the famous is trying to work with PhoneGap, with Crosswalk, Intel, that's basically. And these are the other integrations, right? Then the next thing we think we need is responsiveness. When I say responsiveness, it's an overloaded term. I don't mean media query responsiveness. What I mean is since we are building an analytics engine, you need to make sure that when you are filtering any data set, when you are slicing and dicing any data set, you don't want it to happen in your UI thread because then it feels like it's not performing. And then people complain about the quality of your app. The JavaScript construct for this is actually web workers. And if you look at web workers, the same wrapper comment that I made earlier, the wrapper argument, it applies over here. So it wasn't true in default Android browser. And so if you need to use web workers on Android, you actually need a more performant browser, a more performant rendering engine. And there are these various options that I mentioned earlier. Same thing for WebGL. We aren't really looking at WebGL right now, but if you wanted really good physics on it, you'd basically right now iOS 8 has actually opened up WebGL since some sense they've been dragged into the rendering. So if you wanted to use it, that's another reason, like another place where you'd actually need a better rendering engine. The next thing is offline access. So why do you need offline access? And that's because you're actually sending a lot of data over to the client side. And if you do it every time the user requests for, say, the latest sales data, if you don't send the diff and you send the whole thing over, it's less responsive and you're really chewing up battery life. And that just makes for a really bad experience for you. Now offline access is not a given, and this is something I've seen, especially with JavaScript developers who are coming from the Web world where you had a broadband connection between the client and the server. It comes as an afterthought, and it really needs to be engineered right from the start. This is a really cool... So I was searching for how do you simulate offline access, and I found this really cool picture. One of the advantages of this device is less than the wavelength of your 3G spectrum, you can simulate offline access. But more often than not, when you're developing, you need something on the emulator, and there's this tool at least on the Mac called Network Link Conditioner, and it allows you to simulate a network access as various kinds. Either it's a lossy network access, or it's not lossy, but it's low bandwidth various kinds. So we use something like that. And the last thing is debugging. And like latency, you want to talk about debugging on the 99th percentile, which is you don't want to say, can I debug the Hello World application that actually they show on the on the frameworks web page, but can I, if the hardest debugging problems I've ever encountered are like, only some customers are seeing this, and only some percentage at the time, and maybe they have a particular screen resolution. So you want to be able to say, can I debug things like that? On HTML5, right? Any HTML5 app, you generally tend to do most of your debugging on Chrome DevTools, right? And you basically set an emulation mode. And this has worked in the past because both Chrome and Safari use the WebKit rendering engine. But Google recently forked off WebKit into their own Blink engine. Needless to say, they did it because they thought the code bases would diverge. So the same assumption you held, saying that I can develop it on Chrome, on the WebKit engine on Chrome, and it will work similarly in Safari. Granted, there are some if conditions for mobile thing, but if the same condition doesn't hold true anymore. And this is another place where we see famous having an advantage. Because you're using the same rendering engine on both browsers, the chance that you'll see a problem, a bug in one of the frameworks and not in the other, is actually reduced. But it still remains scope for improvement. If you look at why LinkedIn moved off from HTML5 to native, they basically said a lack of tools, as cited a lack of tools as an example. And so I hope we've made the argument that JavaScript actually is ready for mobile app development but for the first billion users. As we know, like Android 1 and Firefox OS, there's a whole range of low-end smartphones that are about to hit the market or have already hit the market. And the question remains, what about these low-end devices? Will the same thing work? Will JavaScript be a useful platform on them? A point of note is that the cheapest low-end smartphone today, it's built by an Indian company called Intex. It actually runs Firefox OS. It's about 2,000 rupees. And so Firefox is definitely trying in this area, but there's a lot of questions that need to be answered. The first and foremost is does this actually have a GPU? Because if it doesn't have a GPU, it wouldn't matter if you're developing a JavaScript or native. You cannot have the same graphics, because if you take the same graphics that the GPU renders and render it on the CPU, not only will it be bad UI, not only will the UI be jerky, but you'll also drain battery life a lot. So, irrespective of whether you're hybrid or native, you're actually going to have to redesign the app if they don't have a GPU. And then the other thing you have to keep an eye out for is what kind of browser capabilities are you going to need, right? And this is very application-specific, so again, coming back to the point, here are some of the questions you should ask, and the answers will, of course, depend on you. Yeah. So, FIMS is currently being used by like a few companies. It's still in the very early stages, so like I like saying, it's sort of where Docker was like two years ago. They've raised about 25 million dollars in funding and they've got a bunch of people they're working with some big companies sort of like Intel and Adobe and all of these people, but the ecosystem is still in the very early stage, which is again something you have to consider when you're deciding to bet your company on this or not. And so, to summarize, I basically want to prove like, I basically want to make the argument that you actually have a JavaScript is becoming more performant. The interpreter is getting better. There's a lot of people who are trying very hard to make this push. You'll still find, depending on your requirements, whether you know, you're the connection between you and the client is really a 2G connection or not based on whether you actually need that kind of animation or not based on whether you need the model to be the same or not. You need to make your own decisions. These are some of the questions that go into whether it's right for you or not. And that's all I had for the talk, so open for questions. Hi, my name is Raju and now, can you hear me? Hi. Hi. My name is Raju and we are working on some technology for the presentation, but I wanted to know and how does it work with scalable vector graphics? Scalable vector graphics, SVG. Oh, okay. So if you actually look at if you look at famous, so the answer is I don't actually I don't know because we haven't had to evaluate it for scalable vector graphics. The reason excuse me, can you the reason because I'm asking scalable vector graphics is you have the two-dimensional, three-dimensional control far better than desktop GUI API. For what? Scalable vector graphics, you have a two-dimensional, three-dimensional graphical interface. 2D, 3D vector graphics. So you can create far more compelling graphics. So we are planning to develop a scalable vector graphics for a desktop as well as for the cross browser including this one. So I'm wondering how it fits into the Yeah, so I don't know directly about scalable vector graphics. We haven't had to use it. But what I do know is that even if you were doing say a 2D animation of sorts on the phone, you actually use translate 3D and just keep the process at zero. The reason you do that is because it goes to GPU. And that's sort of how famous it does it. I think they have in the roadmap for both WebGL as well as Canvas element, but I'm not sure. I haven't heard the scalable vector graphics. SPG is now part of all the HTML5. Now all the browsers are supporting HTML5. And as far as I know it is pretty good now. All the companies, no, no, I don't think famous is addressing it. My point is we haven't evaluated it. So I wouldn't... Hey, what's up? Oh, right here. So first question. By the looks of it, famous could actually become a really powerful tool for data visualization too, right? Yeah. If you merge the physics engine and use it to draw really powerful looking graphs. Right, so if you look at graphs, really interactive graphs, it's just the kind of animation in some sense. When you're filtering, you want that kind of transition. So absolutely it is. Pivot tables and data frames. And in fact, that's the direction which we are also headed because if you were building an animation engine, if you were building a data visualization library, you would need because so on the broadband world you could go to the server every time but if you look at what you want to do on the mobile device is send what's called a data cube over. So you want to send a whole bunch of data. I say that, okay, you are interested in a particular product and you're the VP of sales and you want to send it for all states in your region, right? And then the filtering actually happens on the client side. So it's actually a very good use case for something like that. And I had one last question. We loved the talk. We loved the slides. Could you share the slides? Yeah, absolutely. Super. Yeah, absolutely. Thank you. Thank you. Hello. Yeah, very nice presentation. You did, you know, raise some great questions about the framework. So I evaluated, you know, we evaluated the famous month back or so. Okay. And it wasn't very clear whether they actually provide you a cross-compilation environment to the native app or not, do they? Hmm. So they're actually working on that right now. It's called a famous wrapper. Okay. And so they are working on something and actually we are part of the beta testing program. Okay. So it'll be in a couple of weeks from now. They're working on something. I know they're working, trying to work with Intel on Intel crosswalk and Intel crosswalk is basically a phone gap but they render, they bring in the blink engine and I think they're trying to work with Adobe. It's definitely on their pipeline because they don't have a story if they don't have an Android story and they don't have an Android story if they do with the default browser, but I'm not a famous employee. So this is how we evaluate it. Today your app is actually just on the browser. It's not actually installable. No, it's actually, we're billing it for iOS first. iOS is compatible to a native even today? It's not compilable. It's sort of like we use phone gaps. So you basically... Oh, you guys use phone gap to wrap it. Yeah. So it would be phone gap. It wouldn't be cross compilable. Okay. So you wouldn't, maybe we should, I don't know what the definition of cross compilable... No, no, I meant, yeah, you can put it as a native app. That's what I was on. So you can use phone gap for that. Right. But it is not like you're developing Javas to sort of like M script and write. Sure. It's not like you're developing, because I'm really wary of that code. What a generated code is just gets hard to debug. Yeah, no, no, I actually shouldn't have used the word cross compilable. I meant, can you actually wrap it in a native... So you wrap it inside phone gap and what we are saying is that on iOS, people complain less about phone gap. Everybody, people complain, but people complain less. On Android, because it's a default browser, it's a real problem and there just needs to be some kind of a solution to that. But technically you can also use phone gap for Android today if you wanted to. And I think, like I was talking to Harish at free charge, he was saying phone gap also has options to get the latest browser. I think it's more of a trade-off, like it increases your app size, so you just have to decide which one. Okay. But you can. Thank you. Yeah. Hi. Here. Oh, yeah. So hi. I'm working with Nagra and we are basically developing JavaScript application on set-top boxes. Okay. So they are further more low architecture, what we assume. Right. So they are actually, they are developing on both HTML and SVG and we are relying on our framework, which we definitely want to move on something better. And for that, we actually decided to go for something like famous plus Angular, because the combination is available, but again, we come to the problem of memory requirements. Yeah. So I want some feedback, like, is it like if I go on debugging on both the frameworks, it's like a lot of times I get pain and I lose my application time over there. Right, right. So something there, if you can. So I would say that the memory usage would be proportional to the complexity of your render tree, right? So, yeah, so it would be something that you would have to, I would run a benchmark. And the reason for this is because if you look at where famous is trying to head, it's these phones, right? It's not going to be, they're trying to do this build-all for everyone, but ultimately if it makes a trade-off, phones are a more lucrative market. And it will be proportional to your render tree. So currently famous as they do about 500 to 2000 renderable elements. This is before WebGL comes out. And I would basically run a benchmark to see, because if you're right, like if it's too low, it basically falls back to the case of the low-end smartphones, right? And, like, that would be a whole different evaluation. And the other thing is, maybe WebGL transforms, like, I don't know if you guys have a GPU or not, but if it's not, then it's really not adding any benefit to you. So you can actually then take the same constructs they do, but, you know, like, perhaps you'd have to make different trade-offs. Because it's the same thing as the low-end phones. Like, if you don't have a GPU, it's not really adding that much benefit in my opinion. One related question you talked about frames per second, 60 frames per second. If the, apart from running famous, something else is going on at the background, which is heating up the CPU, does it somehow interpolate the, you know, you drop some frames and interpolate the frame transition somehow? So, right, so the way it works is it basically, so the browser basically gives you a callback for every bifidge which, a function which it calls every time the paint cycle happens, right? And what famous does it, it calls its rendering engine in that callback, right? Which is why there was a slide on responsiveness, and that's the reason. Because if you're actually doing a whole lot of work and slowing it down, there's nothing famous can do, because that's just how browser architectures work. So the way I would suggest doing a compute intensive thing is put it to a separate thread. So that's what web workers are for. So you don't want to overload your UI thread a lot with other kinds of computation. What you want to do is you want to put it into a different thread. That's also how you do native, by the way. So if you're saving a large quantity of data onto a system, you do it on a different thread, because you don't want to over tax your UI thread. And that's, you have to do the same thing. It's basically engineering. It's not a magic bullet, right? Famous is just making different trade-offs. So I would do that. Yeah, hi. Yeah. So you mentioned about famous being responsive, right? So that means Yeah, go ahead. So it means that it works for different resolutions. Yes, but I did add that I didn't mean responsive as in media query responsive. I meant more like the web view, like responsive as in the thing that he mentioned. Okay. But yes, it does work for different resolutions. And sort of, if you go back to the slide where I translated the photo view down, it was a number. It can very well be a variable, right? No, my question is actually, can it replace bootstrap framework in the sense Oh. So bootstrap, it depends on what you're saying, right? So if you mean the bootstrap JavaScript framework. So the CSS framework is more about presentation, right? Famous is more about the layout. So if you look at the slides, you actually use CSS classes, we use CSS classes to style it. If you look at the problem that comes with CSS, it's when you have to arm wrestle with CSS to get the layout exactly right. And that's the problem that famous solves for us, is the layout. And the presentation, we could use bootstrap. If you're not, we don't use it right now, but it could very well be done because what you're doing with bootstrap is sort of styling, right? And they've got it really good. In fact, the reason it's really nice is because people are used to bootstrap. So you don't have to, you know, have it. Thank you. Hello. Yeah. Hi. This is Ritesh here. I can see you have used backbone model. So I have a question related to that. So why you have chosen backbone model and why not Angular or you have created your own model? That is one question. And the second question is why you have not used backbone views and the templating which also do the same rendering kind of thing. Right. So the reason we didn't use backbone views is because we are using famous views for the layout. And that gives us a whole lot of advantage. If you look at backbone views, they're fairly light. They basically say, if you get this event from the model, then re-render this thing. And really it's about how you re-render it. So we felt it was fairly light and it wasn't, we don't want to have any complexity to it. Since we were using famous for the layout, why we use backbone model is because I'm just used to the MVC framework and it just helps me reason about it. So it helps me say for example go to the server and collect a diff and then like repopulate it. That's stuff that I would anyway have to do but it would be my code and bad code. I might as well rely on a framework for that. I was just thinking like why backbone model like is there any advantage of using backbone model in this way or something? Interesting story that I was talking about, Hari, she's a free charge and I was talking about backbone and he goes like, no, in fact backbone is really heavy. What are you talking about? And he's like, no, over the 2G connection, my app downloads in like say about 3 or 4 seconds and it's a different trade-off. So light and heavy is a very subjective term. For our application, we don't think it's very heavy. It gives us a framework, the framework that I'm used to on this side. So it helps me reason about it in a much better manner. That's why we used it. It would really, again, coming back to it, it's about asking the right questions. Depending on what the application is, it would actually, you'd have to make an idea about whether it's heavy or not. Sure. Thank you. Hi. This side. Are you? This side. Oh, hi. So what are your thoughts on JavaScript garbage collection with famous animations? We haven't hit the issue but I think they are incentivized to solve that because if they can't, if the UI becomes less responsive because they're collecting garbage collection, the whole thing won't fly. Having said that, the way they address the issue today is they limit the number of renderables, right? So they don't limit it, it's more of an advisory thing, but they say 500. And then when you benchmark against these 500 or 2000 elements, that's not that many objects. The reason I'm asking is because for the demos, it all looks very good. Right. But once you go into the big scroll view, it all gets messed up. So, okay, that's a great point. So, another interesting story. So, back in 2012, we were trying to look at hybrid applications, right? And at Salesforce, it actually makes sense to do something like PhoneGap because we have like hundreds of thousands of, you know, business objects. What's a record for me is a dealership for a car dealer. It's a patient. And actually, so scroll is a huge problem. And at that time, around that time, Mark Zuckerberg, like two weeks after we decided to do this, Mark Zuckerberg came on and said, the biggest mistake we ever made is betting on HTML5, right? And you don't, that is something that you don't need. The problem was, so Sencha, the guys behind EXTGS, actually went back and showed that you could build a performance a Facebook app. And the thing about infinite scrolling is that if you keep appending to the DOM, that is what causes it to slow down because you have a lot of elements on the DOM. And if you look at how table views are rendered on the native side, you basically have, say, 10 or 20 cells and you keep reusing them, right? So, your depth doesn't go beyond. So, if you look at all the infinite scrolling, anything that actually does perform an infinite scrolling today, they actually reuse these cells again and again. And that is what confirms it. If your scroller isn't doing that, you'll always run into garbage collection problem and that's just the wrong way to do it. So that is, if you're worried about scrolling, that's what I would say. And that's how they are implementing it. One more question. Any special reason I should switch to famous compared to already set 3.js as 3 renders? 3.js. Ah, okay. So 3.js is WebGL, right? And so the first reason is not every browser has WebGL. They have a CSS 3 renderer. So, no, it isn't. So, I'll tell you how we evaluated. It was more like in a post WebGL world does famous have a thing, right? Does famous have a story. And I don't know much about 3.js, but I think the language is like meshes and things like that. Really, the way we would evaluate it is how do both communities respond in creating components, right? So if you look at IOS versus Google's latest material design and one of them you press a button and it goes down and the other one it comes up, right? That is not the kind of stuff I want my engineer spending time on. And that any community that solves that, any framework that solves that going forward will be it will be the winner, right? Because no one has no one has ownership of something like matrix multiplication. Both can do it. Both will do it, right? And so basically it depends on what are the components what are the widgets that you can build. Can you like alleviate the fact that if I want to build a basic app, I don't have to worry about the discrepancies between IOS and Android because they are diverging. Guys, this is the last question because we need to move on to the next talk. I have one. Yes. Sorry. Yeah, all right. So that's the last question. Yeah. As per the said like if you use more translations, 3DR2D it takes more, it goes to GPU and drains your battery. Right. Okay. So if my app has got so many translations like that, how do you balance such situations? How do you sorry? How do you balance such kind of situations so that user never come to my app, drains his battery? Oh, how do you design for like the not running battery? Yeah. I would say benchmarking, right? Like, so one of the things I want to do is I currently have an iPhone, my next phone will probably be like a low-end smartphone only because there's a whole new like billion users coming on that. I would say use your app and if you are pained by it you would do it. In terms of technically how you would do it, you would try to reduce the number of animations or you would try to reduce the the number of renderables, right. So maybe increase font size or things like that. It's a trade-off that you have to make based on what your application is but I would say always to me at least battery life matters way more than whether I have a really cool animation going because I can actually keep track of the fact that, oh hey this app is going to GPS all the time so let me not use it because I have only 30% on my phone so users will give you feedback in that manner and I would personally I would cut out the animations if I ever found it was draining battery and the way I would measure it is to just use it. Okay. Thank you. Thank you all very much for your patience. Thank you.