 Welcome, everyone, to the death of display adapters in Linux. Actually, welcome, everyone, to the death of right ones run everywhere. My name's Steve Lacey. I'm a mobile developer and software engineer for Fractal. We specialize in open-source software and have over 250 projects, including Gulp. This is my first time at this conference. Most of the others from Fractal came here last year. So to start this off in a good note, especially after all the display adapters, and if we could take a moment of silence, that should be enough. A ulogy for hybrid applications. So quick question, how many of you have developed hybrid applications? OK, actually, I should step back. A hybrid application is a mobile app which is inserted into a web view and can run on multiple operating systems. It's just a regular, other angular backbone or react application, put in a HTML with all the assets and runs on an app. Well, the team at Fractal have been developing multiple applications. And considering that we write, react, and have in the past written backbone applications, we needed to create mobile applications that use the same language that we used. So I was the person who dug into that. And here's my story. So for the goals of writing hybrid applications, you wanted to use one code base for multiple apps. You want to be able to use the same code for your iOS as your Android. You wanted to run across the platform. And this also includes BlackBerry and other devices. And you want to use HM5 technology commonly found, such as, well, HTML, JavaScript, and CSS. It was a great idea. You could build pretty much anything you wanted as long as it ran on a browser. It should, technically, run in a web view. The history of write once run everywhere. Hybrid frameworks. The first main player in 2008 was called Quick Connect. Largely obscure now. It was a system or a small library for interfacing your web view with the native components just through a bridge. Shortly after that, PhoneGap was created. Then Adobe buys PhoneGap, turns PhoneGap into an open source called Cordova, or Cordova, sorry, and creates a cloud-based build system. Why? And then this company comes out with their platform doing a very similar thing. They fix some of the issues and they added an actual UI. And then Trigger.io, the most recent one, came out. Also cloud-based. And it tries to fix some of the issues found in PhoneGap. The most important thing between PhoneGap and Trigger is Trigger uses the core PhoneGap. But Trigger has the plug-in registry mostly built by Trigger itself, and as well as other open source ones. And there are many others. A total of over 100 hybrid libraries and applications systems were developed from 2008 to 2014. Well, some of you may have heard of the UX gap. There's a gap between iOS and Android. It's pretty drastic. And if you develop an app, as most apps are developed, they're developed first and primarily for iOS. It's currently still the largest app store, if I don't need to be corrected on that. But when they're built and shipped to iOS store, or the app store, and you need to develop your Android version, usually since it's running PhoneGap or any of the other hybrid systems, you just drop it onto the Google Play Store. It ends up looking very strange, as I'll have some examples. And the issue with writing hybrid applications and doing two operating systems is UI controls are completely different. Android has the action bar, and an app drawer iOS doesn't. You have to add custom libraries to that. And with that, you then start adding plug-ins. And you hack-patch a plug-in for iOS to get it to run. And when you're still designing that, you have to recreate components that are normally available in core. And you usually use in CSS. And everyone knows CSS is just the best language out there. That was sarcasm. Design issues. Has anyone here built any application for desktop that has some form of animation and tried to get it to run on a mobile phone smoothly? Is it easy? Not exactly. You don't have to try to enable hardware acceleration if it's supported. And especially when you're doing hybrid applications, you're not using the latest version of Chrome in the web view. It's still a web view, which is a web kit. There's also a lack of the native feel when you open a hybrid application. You usually can tell if it's not native, because the controls are slightly different. You click a button, it has a different effect. It doesn't have the exact native feel. And when doing so, to create the native feel, you end up spending a lot more time actually creating the UI elements. All right, so I went on to, in this case, phone gaps, since it is one of the most popular of the hybrid systems. And I went to their showcase and found some applications. All right, so here's one. It was the iOS app. Looks pretty good. I don't see too much wrong with it. But I found this screenshot on the Google Play Store. And the next one, also on the showcase, I have no idea what it is. It's called Posey. And my favorite feature, which everyone should implement, is double menu buttons on the top corners. It really, really, really helps. Well, what about code issues? You're building for iOS, and now you're building for Android, and you're putting the code base together. You either have a very simple app that you managed to create the UI to flow across the two platforms, or you end up having to add conditionals in your code to check whether it's iOS or Android. And with that, you end up having a larger and larger and harder to maintain and harder to update and scale code base. And when you need to add custom features for one version, you then have to add even more conditionals and more plug-ins. The core. For this presentation, I'm going to be using FongApp as the main example, as the core FongApp is using other systems, and it is rather popular. Here are some core system issues that you would find with hybrid applications. There's single thread. All your UI, your UX, is running the same thread at any of your data. And plug-ins are all communicating the same thread. You only have one type of API to access and manage your native. It's whatever that plug-in designed it. And you're also dependent on finding plug-ins. If you need a custom system, you then have to build it in. The web view. This is the container or wrapper where your actual application is running. It's single thread. Single thread means that all UI, UX, and any data is all running on the same thread. Any DOM computation is now slower. Animation starts to get choppy. It also has poor memory management. Any rendered animations are all running the DOM. Any libraries that you use for your application are not designed primarily for a mobile browser. Mobile browsers have, desktop browsers have a tremendous amount of memory and RAM. They could have up to four gigabytes in some situations depending on what the cap is that you set on your OS. Now, mobile devices don't. In some cases, they have 25 megabytes, 50. And some of the newer phones have up to 120 if you enable the flags. You only have that much memory you can actually put stuff into and do video arranging or anything, especially Canvas. Well, there's some quick fixes for that. For Android, Java, you can run this on your plug-ins side and run whatever you need to do on your web view. And for iOS, here's a very simple function for catching the memory flag warning. But there's something about these. If you're writing a higher application, you probably do not want to be writing a more native code. Well, then, after I've bashed hybrid applications, what are they good for? Any ideas? Prototyping. They're excellent. It's really, really efficient if you're creating a quick prototype or proof of concept for you to create the UI, stick it in a page file, add all the assets, drop it into a higher application and run it on the phone. You can show your proof of concept. And if it's a project that needs to be approved, you can get it approved before moving on to the next level. Well, now what? Considering that higher applications cued us some uses but don't seem to cut the bill and you still don't want to write Java or Swift or Objective-C, what are your alternatives? Well, rather recently, Facebook introduces React Native. And they came up with this. Learn once, write anywhere. The idea behind learn once, write everywhere is you learn one language and one system. In this case, the framework is React. And you can write it anywhere. This means you will have two code bases. You'll have one for iOS and one for Android. And if they ever support others, you'll have one code base of that. This does mean that you will have to spend up to probably 75% of the time as you are going to be running and building one app and then the other. Obviously, core elements and components will cross over. But they do have slight differences. Now, if you haven't already known anything about React, the immutable state makes it excellent for storing the state in the DOM. React also runs on the V8 engine. And as I'll explain in a later slide, what the differences between React and some of the alternatives are. The gestures and UI controls are actually native. It's not HTML. It's not CSS. And it's not imitated. Some important notes relate to React Native. There's no web views, no CSS, no HTML. And you don't have to worry about a web view or web kit versioning in two different operating systems. And here's a simple example to create a button in React. If you are familiar with JSX, inside the return statement, you're returning the JSX button. And just styles is a very simple JavaScript object that you're in searching. And then you create the element. Now, when they first came out with React Native, we were all the guys at Fractal who create lots of React applications. We had pretty much one reaction when we heard this. Now, there's some gotchas with React Native. First of all, you can't use it yet. It's still in alpha. It's not released. And they haven't actually set a date for when they're going to release it to the public. Plus, you're still going to have to wait for Android if you want to do two platforms. Well, your team needs to build an app now or in the next six months. And you need to learn the application system framework behind it. And you don't have to wait for React Native to come out, even though it might look good. Are there alternatives? Yes. Native script. Has anyone here heard of it, actually? OK, native script was pretty much in private beta until this conference, actually until tomorrow, sorry. And it uses a similar JS Engine concept to React Native. Inside its core, it has a V8 engine. And it runs the JavaScript in the V8 engine to produce the native elements. Here is an example of native script. If anyone here has developed Android or iOS, you may notice that the naming system is very similar to actual native. And you pretty well create the element. You start adding the properties. And then you stick it into your layout. You can also use templates with native script. It is XML. And unfortunately, my code view removes the capital letter on every element. So the page is capital. All those are supposed to be capital. Now, there are some gotchas. It's still in beta, pretty much alpha, as they're still adding support for multiple systems. I spent a while with it using both their cloud system to have an environment for you to edit and create the apps in the cloud, another cloud system. And they have a CLI where you can run it just like PhoneGap. It has some quirky bugs. One of my favorite bugs when I tried to run it and build an Android app was it said, iTunes is not installed. I'm not exactly sure why they record iTunes. I like to awesome. And the CLI is written in TypeScript. If you're a fan of it or not, it works. Now, the JavaScript engine running inside an apps might sound familiar. What about another player in this field, Titanium? It has been created and has been around for a while. It runs the engine very similar to React Native and native script. And it appears to be very similar. Well, why is it not popular? It actually is quite popular in Enterprise. If you have used eBay, that is written in Titanium. I actually decompile the app to find out for sure. And yes, Titanium libraries are inside the app. Here is an example of Titanium to create a button and also the actual template for it. As you see, it's very similar to native script in its styling. There's some gotchas. The documentation is very large. And in some cases, it's hard to follow, especially when you're trying to get started. It has a different support. It doesn't have as large of an open source following as some of the others, especially PhoneGap, which is hybrid. And its technology is slightly different as it uses a framework called Alloy for its whole templating and its whole UI. For the roundup, if you wanted to choose a system for building native applications, you can choose multiple options now. One in particular that I would look forward to, and I actually want to see what they do with it, is React Native. Mostly for the newer field, it has a large open source following, and it has multiple components that will easily be created and accessible. Now, for the future of these application systems, it all depends. I'm quite sure that after these three large players that put things into the field, we're going to see a lot more purely native compiler, not compiler, sorry, runtime environments for mobile applications. And it will increase the playing field and make it much easier to build apps in the future. Thank you.