 Good evening, I think this is the last talk of the day, hope everyone has a good session. So today I'm going to be talking about hybrid desktop applications and what this means is the ability to create native applications which runs on your users' desktops and devices which are powered by HTML5, the user interface. Now before we begin, let me introduce myself, my name is Anirudh and I've co-founded a company called Razerflow, I'm the technical lead over there and I've been working for three years and after numerous changes in the technology stack, ultimately we've settled on HTML5. Now I've got a lot of experience with the front end and the back end and this is something that, now why am I even talking about this? Now one of the things is we had a problem ourselves where the only solution out of it was to build a desktop app which is run, like which the user interface in HTML5. Now to do that there are plenty of options out there and we spent a lot of time evaluating a few of them and finding out what were the options were there and I just wanted to share whatever we learned with you. Now this is exactly what we do, we've got a tool called the Razerflow dashboard framework. What it does is you basically pull your data out, you give us your data and it builds you HTML5 dashboards which work all the across all the devices without much of a headache. Now in other words it just lets you build a bunch of charts and tables and stuff like that. Now one of the things that we did decided early on when we were doing a technology refresh was that we're not going to be going in for supporting all the older browsers because we knew the future was in HTML5. Now this meant that by essentially focusing primarily on modern browsers we could do some pretty interesting stuff like for example we could do offline access, your data comes in offline and like next time you're somewhere on a flight it's going to work. And we could do notifications such that if your data changed it would give you notifications, we do automatic updates, streaming and some other stuff. Now I'm pretty sure everyone who's familiar with HTML5 know that all the stuff that we want to do right now is already available, you've got HTML5 application manifest offline, you've got notifications, HTML5 notifications, you've got automatic updates and all this other stuff. Now here's the real problem, our problem is that the proper product goes mainly to developers. Now they use it to build tools for their users. Now sometimes, sometimes their users even if they're on IE9 or IE10, they refuse to switch to a completely modern browser like Chrome, Firefox, Safari or even IE11 which has a much, oh right, the problem is most of them didn't switch to browsers which had all the features we were looking for. Now most of them were on browsers with most of the features. So the funny thing is when we talk to a lot of these users, they perfectly find downloading an application that runs on their desktop with an EXE kind of thing. But nobody is comfortable downloading a new browser because I mean let's face it, it's about switching an entire browser. So what we felt was the only way out of this was to pretty much disguise a browser, ship an entire browser to them and disguise it as a desktop application. Now to do this, people who wanted advanced functionality would be asked to download a separate tool and so far we haven't completely launched this yet, but from whatever initial feedback we've gotten from talking to people, it's so far been good. Now that's essentially what I'm talking about is our use case. So we had a genuine use case for this and we wanted to figure out the solution which worked. Now let's talk about why you would want to build an app like this. What kind of benefit does it bring in? Now there are certain reasons why you might want to build a desktop app rather than a web app. So the first one of course is extreme IO. You can't build, if you've done a Photoshop or a video editor or one of these kind of things which need to do a lot of IO, it's sometimes or actually most of the times much faster to write to the hard disk directly rather than write to the cloud. The other option is it works offline and it's not just about storing your resources, your assets offline, it's just about everything runs truly offline. And one more option is for sometimes the beginners, it's much more comfortable for them to just have a desktop application that they can run. And also sometimes it just is a better choice. You have to use your own good judgment. Now essentially a hybrid app theoretically means that it's run on native technology but the UI is built using web technologies. Now this fact of using a UI, so first of all I was talking about why it's better to build a desktop app than a web app, when it is better. Now why is it, if you have a hybrid desktop app, now you've got your app front end over here. You've got your app front end which is run by a HTML renderer, whereas your app back end uses your operating systems or some other cross-platform library to do things like network file system and hardware and things like that. Like for example if you want to do things like playing multiple sound files or doing some other more complex sound or video stuff that's not supported in HTML you can do this. Now there are some huge benefits of using HTML versus desktop graphical toolkits. Now when I say desktop toolkits I mean things like WPF, WinForms and all these other things with menus and buttons and things like that. So the first of it is if you're already a web programmer or you already have a web designer, web person on your team it's usually much more quicker for them to build a UI for this. The next thing is it gives you completely fluid layouts. Now one thing that desktop apps aren't very good at is a lot of text and usually you need to get a lot of other libraries for it, HTML is way better at it. You also get a lot of really good UI libraries that you can download, purchase, some of them are open source, some of them are commercial. You can use whichever ones you want. Another benefit is you've got a lot more control over the look and feel of your application because everything is controlled using CSS and this means that you can usually change the entire look of the application overnight and it looks more consistent across platforms something that you do not get out of most other systems. The other thing is graphics and I mean graphics, I mean the ability to quickly draw graphical shapes on the screen. Now I know that desktop interfaces have got things like Cairo and other stuff and cold draw for Mac and stuff like that but fundamentally SVG and Canvas are just much more faster not in terms of performance but in terms of being able to prototype. It also gives you direct access from the rest of your application to this and you've got some lovely libraries like Backbone, Ember which do this model, view, view, model pattern which allows you to build application with less code. But on the other hand we were that there are some benefits of using regular desktop toolkits versus HTML as well. First of it is consistency, the thing about having a consistent web application is that it works exactly, your users already know a little bit about how to use it before they even use it. Like for example everyone's used to a file menu and edit menu and stuff like that and if the menus are in the same place where it is, which is in the case if you use a desktop toolkit your users feel more at home. The other option is you've got better 3D and gaming, now that's just something that is pretty obvious but I'm getting pretty sure that very few people over here do hardcore 3D gaming applications. The other option is actually static layouts. So here's a very interesting thing because most of these desktop layouts were originally built to build, like it was built from the ground up to do interfaces. Now we're actually going and you know as web developers we're trying to recreate this and recreate interfaces, some of the stuff the web does do better. But on the other hand one thing the web is actually pretty bad at is making a layout which like when you resize the browser it still remains consistent. For this you need to do a lot of JavaScript magic or you need to rely on third party libraries like EXCJS, Kendo or one of these other ones to really take care of the heavy lifting for you. That said, let's look at a few people who are already doing this. Let's look at a few people who already have HTML UI for their desktop applications. The first one is Adobe Brackets. This is I think would probably be one of the most popular ones around. Now what this is, is a HTML, CSS, JavaScript editor written in HTML, CSS and JavaScript. Apart from that being a pretty catch attack, it's allowed the developers of brackets to quickly iterate and add functionality at a pace that most other editors have not been able to. The other thing is it's also it's sponsored by Adobe. It's term transitioning to another product called Adobe Edge Code. But so another one is Google Web Designer or actually it's designed primarily to help you make ads which are animate and stuff like that but run on HTML5. But on the other hand you can use it to make CSS animations, HTML animations as well. Now if you look at the UI you know a lot of people might in fact think it's something like Photoshop but in fact the entire UI is built in HTML. Now this gives them you know the ability to ship the same app on Mac and Windows without significant effort between the two. One more is Steam. Now Steam what most people don't know in fact it looks and feels so much like a regular desktop app. Most people don't know that a majority of Steam is actually powered by WebKit. Now Steam is a game delivery platform and what that is, it's by Valve and the guys who made Half-Life and those games. Now what this does is it basically handles a lot of stuff like you know downloading several gigabytes of stuff and doing all sorts of things. So all of that's handled by the native code. Whereas on the other hand the entire UI feels fluid, it feels flexible and all of that's handled by the UI. And this is one of the perfect examples in my opinion of when it's a great idea to have your native code handle all the heavy lifting and your HTML handle your UI. Another one is WonderList. So this is a pretty popular app which again most people have on so the same they have the same app running on their browsers on your desktop on pretty much any scenario you want and it looks and feels the same and this is again thanks to HTML5. Now let's say you have considered it and you want to do you want to build an app which runs on your desktop. Now these are some of the options that you have available to you. Now I will be going into detail for some of them which we felt were good. There are actually several others. Now this is something that this is an idea that's been around for a while and this is something that people have been thinking about and talking about for a while. So now the fundamental thing is if you want to if since we have so many options and I'm trying to convince you which one is better for you and which one's not there needs to be evaluated. And to evaluate it what we decided to do was we're going to build one single application across several different platforms. This is inspired by the to do MVC project which aims to test different MVC frameworks by building the same app in multiple things. So you can see which works better and now what we do is we just built a very simple text editor. Now it can just open save files. It doesn't sound very fancy but here it actually tests some very significant aspects of the entire application. The first aspect that we want to test is how well can it integrate with the native stuff. Like how can it talk to the file system. Is there a way to talk to the file system and native stuff without really any major work. And the second thing is how can you add extra JavaScript assets. So we use a tool called code mirror which was a JavaScript library which enables you to have a small text editing kind of thing inside HTML. So these are mainly what we try and evaluate. Sorry. So the first thing that we look at when we evaluate it is compatibility. Now if we do write an app which so one of the things that we do with HTML is we don't make it look the same all across. This is the problem that we also see with when people use phone gap to build phone gap or one of these kind of things to build it for different mobile devices. People prefer to have native experiences. So obviously this means that in case if you do build something using HTML you want it to support as many platforms as you want. You want to have the maximum payoff to the effort that you put in. So we do look at what all platforms will it support. The second thing is we look at how much native functionality can we access. Now essentially one of the problems of being a browser is you're in sandbox. Despite how much ever JavaScript and HTML may evolve you're still inside a sandbox. There's a lot of resources you have no access to. Now can we access more of it using this particular model. Now that's one more thing that we look at. The second thing which we look at which is a very important thing is productivity. Fundamentally it all comes down to turnaround time and by turnaround time I mean if you just make a change how much time will it take for you to see if the change worked or not. The second thing that we also see is how much time will it take for an average person to set up a project not just you know not just if they're provided instructions but if they're just trying to set up one from scratch how will they do it. And the third thing is integrate well with build systems like a lot of people prefer lighting things using things like less and coffee script and things like that. It doesn't work well with them. And the last thing that we look at is deployment. So in deployment what we mean is you've finished your app you've built it and now you want to ship it out to your users. Now how do you do that? One of the things is the Mac Apple App Store came out and now a lot of applications are distributed through the Mac App Store. So that's a major thing because App Store has a set of sandboxing requirements which all of your tools have to be compatible with. And one more thing is do your users have to download anything extra. Is there any extra stuff they have to do before they run through your installer. And one more thing is how easy is it to update your application. Now because obviously one of the benefits that we all enjoy as web developers especially if you're running a SaaS kind of product is it's very easy for you to update something and all the updates are pretty much streamed out to all of your users instantly. So first of all let me talk about Node WebKit. This is one of the tools available one of the most popular tools available for building desktop apps in HTML5 and it's popular for good reason. Because it usually combines the best features of Node and the best features of WebKit and gives a tune upon nice lovely package. Now let me just give you a small these two lines over here. Can I just get a quick show of hands how many people are JavaScript developers over here? Okay so if you've all worked with Node do you know that whoa. So you know that in web development it works in a very standard format you know you've got your server which has all of your business logic and stuff like that you've got a client and they communicate through some kind of flaky protocol like REST or SOAP or WSDL or something like that but what happens is you always have two separate places where you're running your code even if you run Node.js you're running JavaScript on the server JavaScript on the client but here with Node WebKit you're actually doing the first line the first line actually runs on Node which reads a file from your file system the second line takes the same variable and it uses jQuery to append it inside of a page. Now what's happening over here is something you know which many of many people including myself thought impossible you're actually you know doing something right on the native level on the JavaScript level and it's a seamless bridge you don't have to worry about serializing your objects you don't have to worry about you know figuring out ways to share code it's always the same thing. Now this means that you know this means that Node WebKit has some really good benefits the first benefit is that it's extremely easy to get started so much so that you know you can just read the read me and you can get started within a few minutes now it's also pretty straightforward to package and deploy now they've got a command line tool which means that you can just you know run it against the command line tool you can just tell what assets you have it's going to package something up for you and you can distribute it to your users straight away the third thing is it also imports assets very easily now this is extremely crucial because if you're running a web app and especially if you're trying to you know figure out some way that you can sharing your code between your website and your desktop application you want to be able to have a way to share your assets well now a lot of times what happens is a lot of systems they have a separate registry for your assets this means that you know you need to go add your asset into the file system and then into another folder and into another file an XML file and things like that now that becomes a problem especially when people check in code and they don't update the assets and also sometimes you know it's it's pretty tricky a lot of these guys who do HTML5 applications have a lot of problem with assets now the downside is actually that you're constrained to node now for example there's no native functionality in node to play a sound file there is no native functionality in node to you know do a lot of things and for example if you want to have you have a library written in C which you want to you know use there should be technically ways to use a certain node packages and other libraries and node which basically go directly to the server I mean a lot of these node libraries which are written in C and you know allow you to run native stuff but we had some trouble getting them to work but fundamentally this means that just think about it as you have all your browser stuff but also you have your node stuff and it's usually a lot more tricky to get everything else and one major problem with node webkit applications as from whatever we read on the official site is that you cannot upload this to the app store this is because it uses some apis which are marked as private by apple this means that you have to if you're planning to sell this on the app store or something like that this is not something you can use now with the scorecard for node family is it scores pretty well now this means is is open source it's well maintained and you're back in the JavaScript as well it's pretty straightforward setup as I told you the problem with packaging and distribution is that it's not very readily compatible for a lot of things because it just does not give you one single binary that you can ship out to your users like multiple binaries you need to write another shortcuts and things like that it's it's not very straightforward for users but if you're using it for like a temporary hack it is very easy to get started with the next thing is actually chromium embedded framework now this guy is the biggest most you know powerful one so a little history about chromium embedded framework a lot of people get confused between chromium embedded framework or cef and the chrome app store or chrome desktop apps or something like that now what google's done very very greatly which has created a lot of confusion with people is they've enabled you to write a chrome extension which runs directly on your desktop I mean it looks like okay fine it looks like a regular desktop app you've got your shortcut you double click the shortcut it pops up and you know you've got your app writing or running over there now that's one very major difference between this and that now cef does not require you to have chrome installed because the funny thing about chrome is you've got your browser with all the browser chrome which is the back button the address bar and stuff like that now this is the same chromium code base with nothing it just has a browser directly now this means that you need to do a lot of stuff on your own you need to do things like cookie management and some other difficult stuff on your own but you need to write it in you need to write the entire back end in c++ or objective c you need to compile it and rewrite it differently for each platform that you're trying to support now so to help you clearly understand whether cef is the right tool for you or not I made a little flow chart so first thing you need to ask yourself is do you really know c++ or c objective c really well if you don't sorry the other thing is think about it whether your app back end is really heavy or maintained I mean maybe not right now but see you know two three years in the future you guys are trying to build something and the app back end is something insanely big and you're trying to recommend this to your engineers and if it's not just it's not worth the effort I think is be really 100 percent sure that you're experienced with native code there's not something that you can just pick up you know just like that and only once you're sure about it even then it's a maybe you have to take the call really carefully right but on the other hand here's here's the thing we just could not figure out how to copy a file from the file system to the texture we just could not we spent almost like three four hours at it but we had no idea how to make the native stuff talk with JavaScript stuff we just we just got confused and we were trying to compile it half the time but there are some benefits to from cef the first of all the fact that everyone uses it I mean adobe brackets uses it steam uses it and you know a lot of these big things all of them use cef primarily because it's stable it's well maintained and it has this ridiculous chromium standard of engineering which you probably don't get with most other software products the other thing it does it gives you a huge amount of flexibility like for example the recommended way of starting out the cef is that you're to compile the entire thing which includes compiling webkit I mean this literally it takes you you know it's a four gigabyte thing which gets compiled and stuff like that but ultimately it gives you so much control you want to disable enable certain parts of webkit you can go ahead and do that the other thing is you've got complete native access this means that when you're running on c++ you can load any shared runtime library you can ship your own static dynamic libraries but long story short anything that you want to do with the computer that you want to make the user's computer do you can have it done now the doc the downsides the documentation is not so great I'm just saying that I'm taking a leap of faith when I say the documentation is not good because I couldn't find the documentation at all the other thing is you need a really strong native application background and there's no Mac App Store support according to a lot of people who we saw but again we couldn't find a definitive answer to this but on the other hand it's open source it's well maintained and uh it's the pin and it's it's pretty painful to set it up and uh you need to drive different back in code for different systems now Tide SDK was this thing called Absolute Titanium so Absolute Titanium started out for mobile and desktop and eventually they started focusing more on mobile and on the other hand they broke off and now they have this open source thing called Tide SDK now Tide SDK actually allows you to have Ruby, Python and PHP on the back end one of the three and it also has a really nice app manager tool which allows you to quickly you know just get started just you know it's like a wizard uh it's like this so you just go ahead over here you say this is my name of my application blah blah blah which modules I want which language modules I want and then it's ready it gives you everything it's all like you know HTML boilerplate on steroids that kind of stuff and it's pretty straightforward you know but the only thing is you need to use a completely different API so you need to read the Tide SDK API documentation you need to you know pull out the stuff and once you do uh you should be fine now the down the good side sir it's very easy to straight like package and deploy stuff you can submit to the mac app store you can get assets pretty easily but you can also come up purchase commercial support which you know is actually sometimes a good thing but the downside is you're limited by Tide's API so sometimes uh their API is not very comprehensive so I have we weren't able to exactly explore how to if there are ways to work around it or like you know extend it and there's no native uh integration but overall it fared pretty well and we were pretty happy with Tide SDK from what we saw so Adobe AR is like the most common popular one which was there for a very long time now this guy is where the first to start and I'm pretty sure everyone's seen some Adobe AR live program in their life one time or the other now it also includes flash player and apparently it supports mobile but we couldn't spend enough time checking it out uh it's pretty straightforward so now the code for that as well like the code to essentially load a file in the Adobe AR was pretty straightforward and it follows conventional JavaScript stuff now the good side is it supports more platforms allegedly now one of the biggest problems with Adobe AR which is a deal breaker for people like me and probably even a lot of other people is the fact that you need to your user need to download a separate runtime you need to first download and install the Adobe runtime and then afterwards you can install the package so this means that you're pretty much giving your branding and your value wrapped up inside Adobe is a branding and package which is something that you know is a problem at times the one more thing is there's no good there's not a very good debugger at least we couldn't find one but overall it was pretty good oh sorry this this is a mistake over here so there are a few more options over here like one of them is Qt now Qt2Kit was originally built in 1999 it has a lot of history you can read the Wikipedia page about it but it is great for building GOI applications and it works cross-platform and it really works cross-platform it's not just you know marketing strategy or something and one of the things you can do is you can actually combine Qt with the native widgets and stuff like that and you can combine it with the web view this means that you can have your menu bars and stuff like that but all the real heavy lifting is handled inside a web kit browser which is pretty cool now and you can do the only problem with this is here to embed resources using what is known as Qt resources module where you have to set up an XML file and stuff like that it's a little tricky but I mean nothing that you can't figure out so another option is GTK web kit so GTK is also one of the oldest tools that have been around it's been around for a very long time it's very mature it's very stable it also has the same strategy you can have your buttons and your menus and stuff like that which different solutions now the only problem with this is it sort of works best on Linux and from what I've seen usually GTK apps on windows and Mac are not as good as they run on Linux but they're still there there's still a lot of apps that run on GTK now one really cool thing about GTK web kit is they have this thing called geobject introspection which long story short allows you to write and use the APIs offered by GTK and build GTK applications from a variety of different languages so in all life period if you want to use something slightly different if you want to use C sharp and build it and you want to target Linux you can just use GTK now the problem downside one of them is distribution is a little complex because the documentation is not as much as the ones that are there in the proprietary or other products now cf python so cf python is basically a python like a chromium embedded framework with python glue this means that you can pretty much have a bridge between python and javascript now we found that it's like so I mean well cf you know it just makes you question whether you know anything about computers or not cf python is a little bit more easier it's a little complex to install you know you got to do with all this pip and stuff like that which is not and you got to do a lot of compiling but you can mix it up with other ui and if you're into python you want to really have a solid thing in python and you don't want to do cf cf python is a pretty good option so one of the things is to summarize I'm going to start summarizing right now but what we realize is you can't have one winner now because everyone's requirements are different now for this we decided there are going to be three winners for the entire thing we've got the heavy weights which means you're going to do a lot of IO you need to do like some pretty fancy stuff on the browser and then you've got your desktop edition which means that you've got your regular application for your software and you just want to give someone a copy on their desktop as they can run and do stuff and the last one is quick and effective where you just need to quickly you know quickly build a proof of concept and send it out to people and stuff like that now for the heavy weight category I actually picked cf because even though it's difficult there's a reason like if something is really that difficult but still that popular there must be something around it and the more I read about it the more I saw about it it's just that the amount of functionality it comes with things like a p2b stack and network libraries like incredible amount of libraries that you can actually use and extend and give more performance it has its own build tools and stuff that it takes a little while to get into it but if this is your primary bread and butter it really makes sense to look thoroughly into cef the other thing is it has a very strong good chromium heritage and you know that is since it's like pretty much one of google's most important business line applications it's not going to break very frequently so you can trust it and you know that it's going to be around for a long time unlike a lot of other open source projects which just can just be abandoned at any given day now for the desktop edition actually picked tight SDK because it's pretty easy to get started and if you really plan your thing very quickly and you use PHP Ruby or Python one of these three platforms you can actually figure out a way that you can have your server side running and you can have the client side running and you can figure out how to share a lot of the stuff and you can have enough which runs offline and runs online and it gives you a lot more flexibility to do certain things that you can't do with our platforms now for the quick and effective one node webkit is the best i mean node webkit in one word is just refreshing because you know you can build an entire desktop app in a single file you can put a html you can put your css javascript all the stuff over there and you've got an entire desktop app which runs on your desktop it's pretty cool if you ask me now you're going to be limited but what nodejs can and cannot do but if that's not a problem for you and you know enough about node that you know you're not going to be it's not going to be a problem you can go ahead and do that so finally coming back to me what do we use for a hybrid app technology so believe it or not we chose cute now the reason we chose cute over a lot of these other platforms that we saw was a lot of them were great because you know they're geared for getting up quick and dirty and just getting it out there but there's certain other things that we needed so we wanted stable quality and good commercial support and the second thing is we wanted to have apis to interact with stuff like system tray minimize the tray and a lot of other stuff which a lot of the uh systems did not give now cute has a long legacy and it's been around for such a long time so they have things for even things like this now one of the problems is uh and also the ui around the browser so for example we've got a setting dialogue and all that stuff which looks and feels more or less like native dialogues so we feel that this might be better for our customers instead of instead of having everything inside the browser itself and the last thing is on windows installs can be scripted using installation builders like nullsoft nsis install shield and basically where you click next next next and keep and it works now these are problems that we've seen with cute so far and this is something that you'd probably see with most other systems now the webkit to native bridge is not as good as we expected now the downside is you've got some stuff on your server side like on your back end and you want to you know make it communicate back and forth it's not as seamless as you think it is or not not and you can't even you know make it like a json thing because uh your back ends written in c++ and c++ is terrible with json the other thing is the qwebkit functionality was not very well documented not as much as the rest of qt and we could not get the javascript debugger working properly we wanted to have the ability to run the chrome type of inspector right inside the system and it has to be recompiled every time there's a change in the javascript or csr this means that it takes about five or like five to eight minutes for us to you know for it to recompile everything and we also have to manage memory manually which is a problem because you know you need to create and delete objects and things like that it's a problem if you're coming from the javascript world so that's the other presentation i'd like to thank my team for basically doing all the work and figuring out how to build it in different platforms and i just went ahead made the slides so the code's available so you can go to github.com slash razor flow and you have a meta refresh underscore braces repository it has a code for all of the platforms that i talked about and some which i didn't even talk about uh and there's also wiki which contains detailed installation notes and uh like screen shots and stuff that which you can download and that's it yes um performance wise which was a better like sorry performance so we could not do a thorough performance now if you're talking about performance you've got many different aspects of performance that you can talk about now one of them is going to be performance of the native side so for example if you're going to write direct c or c++ code obviously that's going to be better than something written in javascript but when it comes down to fundamental like the website the html performance i'm guessing they should all be around the same because most of them use webkit webkit and v8 or one of these common things now my guess would be chromium embedded framework would be the fastest because that has a lot of optimizations and they have the fork of webkit called blink which is probably an all uh improved further but if you're targeting performance i would suggest looking to cef okay and for you know when you are packaging the application you need to include the complete webkit also right for the user if the user doesn't know so how do so that will be that will increase the size of the whole package right so how do you manage it so look nowadays you've got people with really fancy internet connections so if you've got a 15 mb or even a 10 mb download so usually what happens is webkit's a pretty big library webkit's an extremely big library and you've got webkit you've got all of these things and now you've got two options now you can do either static linking or you can do dynamic linking if you do static linking you can just give them one dynamic one complete executable but if you do dynamic linking you can either a hope that there's a webkit already on the system or we package it along now what i've seen is the like size obviously is going to be a big deal but this is something that you just cannot avoid because you are sending all of this stuff the other option is again to use what is already available on the system uh then you know you're going to have a much more smaller size so but then again until webkit comes until microsoft start shipping webkit default with windows you're going to have to embed it till then yeah no actually it's a little different because then again you know chrome has an automated background downloader and stuff like that there's some other stuff but uh yes it is going to be big in fact if you really compile webkit yourself it almost comes out to around 1.5 gb of shared objects it does all that compression and some really cool assembly magic to shrink it down so yeah yeah i have a question here straight straight go on can you see me wait wait right in front of you oh yeah cool cool oh sorry thank you so and we're creating hybrid applications the general interaction between the java script and the native native features like hard disk or playing music so the interaction between java script and this these features how you generally manage it it is some framework or so in your custom which right so now there are different options that happen now for me personally i found node webkit the best uh this means that now some of them have a separate a separation of concerns where your java script on separately and your native side runs separately so some guys for example what they do is they allow you to uh run a small local server directly and your application talks to your local server just like how they would in a normal web app the other thing is for example chrome embedded framework does something very different where you need to extend v8 your application latches on to v8 so your real program native language like native uh business logic is extended to the java script language itself so in fact it allows you to do certain things like for example if you want to do heavy mathematical processing so you can literally call that function and it gives you back the same stuff so to be very honest the real problem is not to actually communicating back and forth it's actually about object serialization and object parameters like for example if you've got your json sound script generally deals with json so this means that your uh yes your native section should output an object which can be read by now transferring objects between the two is pretty straightforward it's about figuring out a way the which language they speak making the common language now on web json is that common language nowadays before it was xml and stuff like that but now json does not work over here so there are other native uh ways so you have to extend v8 you have to extend java script object and stuff like that so i was just wondering how much of a concern has it been about reverse engineering and security because i know i know for sure that adobe air the the packaged assets are pretty much out there in the file system for anybody to just go look into and you know try to figure out and stuff like if i'm doing what with an api i wouldn't want to store my tokens in plain text for everybody to see so we have you what are your thoughts around that so that's actually a lovely question now one of the things you need to understand is when it's on the users thing since no matter what happens ultimately when your program is loaded into memory they can always patch into the memory no matter what encryption scheme that you have once your program is already patched into memory you can just go into the memory dot over there and read it so your oar secret tokens are not secure so if you're shipping your oar secret tokens as a part of your package you're pretty much compromised right over there now that that said like most of these other things like for example qt and webkit and all these guys they actually have a way to embed resources inside the inside the executable now even that also you can fit in linux there's this uh command file strings which you can pretty much run on a binary and extracts all the utf 8 grid strings and usually that's enough to pull out all of the java script files right there all the support for qt right now because earlier nokia was supporting it great so uh interesting question so qt originally started with a company called troll tech which got acquired by nokia and now there's a company called digia which have acquired it from nokia it's a little bit of uh i don't know i've not followed it very closely but there is definitely an option to get commercial support and one of the things that so many companies are so heavily invested in qt it's one of those things that you're pretty sure is not going to go away for a while uh so you can go ahead with qt thank you guys