Check out Freelance Remote Conf and React Remote Conf!

On YouTube
196 JSJ Tabris.js with Jochen Krause and Ian Bull
 

02:31 - Jochen Krause Introduction

03:21 - Ian Bull Introduction

04:01 - Tabris.js

04:48 - Tabris vs React, Cordova, and React Native

08:25 - Benefits/Advantages of Using Tabris

12:45 - Creating Panels and Flows

14:26 - Getting Started Experience

16:40 - Handling Updates; Live Updating

25:15 - Views (Declarative and Imperative UI)

29:09 - "Write once, run anywhere." vs "Learn once write anywhere."

35:21 - Why have other projects failed or not failed?

39:41 - What does it mean to be statically compiled?

40:44 - Styling: Creating a Middle Group that Looks and Feels Good (iOS vs Android)

47:51 - ES6 Implications

49:29 - Plugins

Picks

Star Wars Essentials (AJ)
Star Wars: The Force Awakens (AJ)
Thing Explainer: Complicated Stuff in Simple Words by Randall Munroe (AJ)
James Edwards: Making a Mini-Lisp: Introduction to Transpilers (Aimee)
Nick Saban (Aimee)
Lloyd Borrett: Bill Gates and Petals Around the Rose (Jamison)
Dan Luu: Normalization of Deviance in Software: How Completely Broken Practices Become Normal (Jamison)
Craig Stuntz: Programs that Write Programs: How Compilers Work (Jamison)
Microsoft (Dave)
Tina Fey (Dave)
thoughtram Blog (Dave)
Pascal Precht (Dave)
CES (Chuck)
The Modern Team (Ian)
Eric Elliott (Ian)
Thinking, Fast and Slow by Daniel Kahneman (Jochen)

Special Guests: Ian Bull and Jochen Krause.

 

Thanks for staying up so late with us. This will only take about three hours, so [inaudible].

Hey everybody and welcome to episode 196 of the JavaScript Jabber Show. This week on our panel we have Dave Smith.

Hello.

Aimee Knight.

Hello world.

AJ O'Neal.

Yo, yo, yo, coming at you live from Utah once again.

I'm Charles Max Wood from DevChat.tv. Quick shout-out about Freelance Remote Conf and React Remote Conf, so go check those out. You can find them at AllRemoteConfs.com.

We have two special guests this week. We have Ian Bull.

Hey there. I'm up in Victoria of British Columbia, Canada.

I started with the one that I knew I wouldn't slaughter. [Chuckles]

And Jochen Krause.

Hey, excellent. I'm here in Germany.

Awesome. You want to do a little bit more of an introduction? Who you are, what you do, who you work for.

Yeah, so let me get started. My name is Jochen Krause. I'm with EclipseSource. I have a Java background and have been involved with Eclipse. So, our company name is EclipseSource. So, we've been around in the Eclipse space for more than 10 years. And I've been very active in the Eclipse community serving in various roles. For example on the Board of Directors but also in some technical areas on the Architecture Council or the Runtime PMC. My focus has shifted since roughly five years. So, my main interest is mobile. And I think that mobile is transforming the software industry. And that's basically why we got involved in that space.

I'm Ian. Ian Bull. As I said, I'm up in Victoria, British Columbia, Canada, on the west coast here. I've worn many different hats during my technical career. I did a Masters' Thesis in reverse engineering and programming comprehension. I did a PhD in software visualization. Started some Eclipse projects, the Zest project back then, and then started working as an Eclipse committer and leadership roles there. I've been a tool smith, a framework developer, [inaudible] leader. But I think the underlying theme when I was thinking about this is I've always been very interested in making developers more productive. And that even continues now into the Tabris work that I'm doing. So, I've been at EclipseSource for seven years now. So, I'm having a great time.

So, tell us about Tabris.js. What is it? And did I say it right?

You did. Jochen, do you want to take the introduction to Tabris.js or do you want me to take it?

Go ahead.

Alright. Well, what do we say we are? We say we're the easiest to use cross-platform toolkit for kick-ass mobile apps. So, we're all about making developing mobile apps much easier, bringing JavaScript to the devices. Developing native applications. And oh, and applications that are not only easy for the developers to develop but look good and your users are happy to use as well. So, we want to make things easier for the developer and a great experience for the user.

Yeah, and with native applications we don't mean a native shell that runs a browser. We mean native widgets. So, it's the native controls of the mobile platform. We're using that to create the user interface.

So, if I understand it, this is in a similar category as Facebook's React. But you guys have been doing this a bit longer, right?

Yeah, absolutely. So, we started that development roughly two years ago. And we've been out with that before React Native. React is obviously also very interesting technology. It has a little bit different focus. It does not provide an abstraction over different operating systems. So basically, you get the same language but you have to write your app multiple times for multiple mobile platforms. And with Tabris.js you write… we have an abstraction over the platform so you write your app once and run it on different platforms. I think that's one of the big differences. A second big difference is that you don't need any specific hardware or you don't need to mobile SDKs for the platform. You can just use JavaScript and npm and Cordova. And we do the rest for you. We build the software for you. You can run it on your mobile device without ever touching any Objective-C code or any Java code.

So, just to be clear. You mentioned Cordova. And you've also mentioned React Native. And the difference between the two is that React Native actually works through the JavaScript bridge to the Objective-C runtime whereas a lot of these other systems use Cordova like Ionic or some of the others that are out there. So, does Tabris or Tabris.js run on… does it run over Cordova or does it use a JavaScript bridge?

It uses a JavaScript bridge. But we still can use or you can still use Cordova plugins for adding device functionality, not for adding UI. But if you… for example you want to the Bluetooth you can use a plugin that enables access to Bluetooth through JavaScript.

Okay.

And you can use a Cordova plugin for that, but no browser, no HTML. That's all native widgets.

Okay. So, just to be clear, you're in the same category then as NativeScript and React Native.

Yes.

Yes.

How exactly does that work? How do you expose Bluetooth functionality if it's just a Cordova thing? Do they expose that to JavaScript APIs already?

Yeah. So, Cordova does. Cordova exposes that to the web views and has APIs for accessing that JavaScript APIs. And we just use, expose the same APIs that now you can access in Tabris. So, if there's stuff that has dependency on web views and web UIs, you can't use any of those plugins. But there's a great deal of plugins out there with Cordova, Bluetooth being a good example. The camera plugins, plugins for accessing geolocations, network information, all those types of things.

Camera. [Inaudible]

Yeah, camera. All those things you can get access to because they expose the same JS API, expose the JS API and we just make the same one available to our developers.

So, you touched on this a little bit. But what's kind of the main benefit of using this over something like NativeScript or React Native? You said one of the benefits is writing it all in the same language.

What would you say the other benefits are?

A big benefit is ease of development. I can write an iOS application without touching Xcode. I can do it without a Mac. And so, I can get something up and running very quickly cross-platform. And in addition to the toolkit that we provide, we also provide an online service for doing the builds automatically for you. So, you can connect it right to your GitHub account and it will pull down your JavaScript code. It will build you an APK for Android and you can download that and install it right on your phone and it will do the same and build out an iOS application as well. And you can take that and test that right there or build your release version and publish that right to a store. So, it makes getting started very easy. We have Windows, or starting Windows support as well. [Inaudible] And we have one up and running now. So, we have iOS, Android, and Windows all in one. So, you write it once and can try it across all those different devices.

And it's fairly performant. Actually, it's very performant in the way that we've done it. So, we're running iOS or JS Core on iOS. And we're using V8. We've actually started another project called J2V8 which is a set of V8 bindings for Java. So, you can use V8. It exposes the V8 API to Java developers. We've open sourced that project as well. That's one that I did last year. And so, that makes… so we use that for our JavaScript on Android. So, we get as good a performance as V8 gets on Android. And we're using Chakra which is, I think it's being open sourced very soon, for Microsoft. And that's their new JavaScript runtime which I think is powering their new Edge browser and all of that. Are there any other advantages there Jochen, that you can think of?

Yeah, it's a very concise API. So, we've been building platforms since a long time, since more than 10 years. And we know about the value of a concise API. And if I look at the amount of code that I need to write an app, I think we are… Tabris.js is very, very good in respect to that.

And then as well, we get access to npm packages that are JavaScript npm packages you can just include in your app as well. So, if there are things out there that you're already familiar with from Node.js development, a lot of those things you can pull in and use in our apps, in Tabris.js apps as well.

We have a mindset. I mean, we've been in the Eclipse space for a long time. Why is Eclipse very successful? Because it provided the platform that many people could plug into and extend it. And everybody could focus on the stuff that he does best. And so, when we started building a mobile platform we looked at the ecosystem. So, Cordova minus the UI capabilities is a very, very big ecosystem. We looked into npm. Npm is a huge ecosystem. And we try to find ways to enable people that are in those ecosystems, enable the code that lives there, to work together with our solution.

So, we provided some W3C APIs, for example XMLHttpRequest, we offer that in a standard compliant way so that libraries that are using XMLHttpRequests will just work with Tabris. And we're doing the same thing with Canvas for example or with timers or with multiple W3C APIs. And I think that's a different mindset. So, other people go out and think they can create their own ecosystem. And probably they can. But our mindset is play well with others. And so, I think you will find that in Tabris.js that we work well with others. And if you have experience with these technologies you will feel home with Tabris.js.

So, it sounds like the story for the JavaScript developer is really good here. There are some differences obviously, but if you've worked in Node and you've worked in the browser or even you've worked in the browser and you worked in Internet Explorer, you've come to expect some differences. What I'm curious about now is it sounds like whether I'm an iOS developer or an Android developer, the UI experience is different from what I may have used before. So, tell me about that, creating the panels or the flows. How is that in comparison to iOS or Android or whatever?

Basically, I mean we have an abstraction. So, our abstraction is Page. And the Page is a page on iOS and a page on Android. It looks and feels like the native Page or like a native panel. And actually, navigation is not that different anymore. I mean, you do have that back button on Android and we do have handling for back button. So, you can intercept back button calls. But otherwise the navigation is currently pretty close between those platforms. It's often more the visuals so that you can swipe back on iOS. But there's no code involved. So, you open a page and another page on top and if you want to go back you can just swipe the page to the right and then you get to the page that's below. So, I don't think that you need a lot of code in those, with respect to that.

So, in regards to the experience with iOS I do have Xcode which sometimes is an asset and sometimes is a liability. But in looking at it as an asset, it gives me a way to visually drag and drop some elements. And it's very Visual-Studio-esque in that sense of getting started doesn't feel super intimidating. And so, I'm wondering if you guys have tools that give you that kind of experience or if it's more the web experience where you try it, you refresh, you try it, you refresh.

Probably much more, well to the [latter]. And I think that's one of the big advantages because it is so easy to just dynamically load code and run it. So, we actually provide a web-based editor. And you can go right on that web-based editor. And we have a tool, an app you can install that will just connect to that editor and get your script, whatever script is in that editor, and load it on your app. And you can just start hacking in that editor and right on your app you just hit refresh and you'll get over-the-air update of the new one. And you can just try things out and mess around with that. It's much less code than Xcode or Objective-C or Java. And the JavaScript API, it's pretty small. So, it's pretty easy to get something up and running very quickly. A button is 'create button' and now you have your button on your page. And you can set some different layout properties of where you want that to be anchored to. But it's the experience is very similar to what someone who has web dev experience would [inaudible].

Yeah, but it's not the Adobe tool stack type of experience that you're getting or the Xcode experience where you drag and drop stuff. You write code.

And you can use whatever tools you want. I said we have a web-based editor but you can use Atom on your local machine if you want. If you're an Eclipse developer you can use that. I do most of my hacking in vi and that works well for me. So, we're not saying you have to use any one particular tool. If you have a text editor and you can host a file, then you can connect to it over HTTP and just fetch that. And try it, refresh, try it, refresh. But again it's real native code that's running on there. So, it downloads that script and then executes that script on your device.

So, while we're talking about the concept of making changes and getting over-the-air updates, do you also provide the ability to do over-the-air updates for apps that have been installed and are running on user devices?

Yes. That was one of the first features that we added after our 1.0 release. Because obviously with the first large app out there, there was a bug in it. And it took us a week to get that, or our customer a week to iron out that bug. And so, that was the first feature for our 1.1 release. Many people don't know that. But if you have JavaScript code and you don't alter the application massively then you're allowed to exchange functionality in an app that has been published. So, that's legal if it's JavaScript code run by JavaScriptCore. And so, we have that capability to load code on demand and update the app. Basically restart the app and then it's picking up that new code.

So, when a Tabris application starts on a user device does it actually check a server to see if it has the latest code? Or does it do that by some other means?

That's all up to you. We basically provide a mechanism but not an implementation. So, you have to… you can set up a URL and…

Ah, oh, but I have to host it?

You have to host it, yeah.

Makes sense.

Or you can package everything up in an app and it's completely static and that's what you get. And so, it's really up to you. We provide the toolkit and some technologies there to do that. And whatever works for your app is what we recommend.

So, at the risk of getting too deep into this topic, I do want to ask one more question. And that is that a friend of mine who's working with React Native on iOS is also doing live updating in a very similar method to what you describe. But he's using a third-party service to host his JavaScript code. And the app when it wakes up, it checks in with his service and sees if it has the latest code. And if it doesn't, it updates. But the method for updating he said he actually has to crash the app or he has to instruct the user to do the double home button tap and then swipe the app away in order to reload it. Do you guys have that restriction? Or do you somehow manage to work around it so that you can update in a more seamless, user-friendly way?

We can do it in a seamless, user-friendly way. So actually, we have an app in the app store that's called the Tabris.js developer app. And the developer app allows you to load code. Ian mentioned that for example from an online editor or from your computer or from any place on the internet and run that. So, we have that basically built-in in the core of the framework that you can create a new context, a new JavaScript context and just run some code in it. And because we have that ability, we can also basically restart an app which is not a complete restart of the app. It's just a complete new JavaScript context and an app running on that.

And a Tabris.js app actually has a number of snippets and examples built right in, and it does that. That's essentially, you start it up and you can connect to our Scratchpad to download the code there or you can try one of the examples right on that. And that works by loading the code from that example and then starting that one, starting a new JavaScript context right there. And so, you can mess around and play with it and see the code there. But that works that exact same way. So, it gets it, loads that context up with that particular snippet, and then starts running that one.

That sounds really cool for experimenting with new ideas. Do you find a lot of people use it? Like is it pretty popular?

Yeah, it is.

Yeah.

Yeah. It's a great way to get started. In addition to doing that we have, you can hack online with the editor. We even have a developer console. You can slide it in from the right. So, you can do console log and get stuff there. And we've just started adding support there for keyboard support. So, if you have a hardwired keyboard to your device, you can actually make changes to your app on the fly. So I can say, “Okay, put me a new button on this page,” hit enter on my console and a new button now appears right on there. For those people familiar with Smalltalk from years ago, they say, “Oh we had that back in the 80s.” But now we've brought that to mobile devices with JavaScript.

[Chuckles] 30 years later phones can do what computers could do in Smalltalk. [Laughter]

That's what our Smalltalk friends tell us.

Oh, they're very smug about it, aren't they?

They are.

What if they're just making it all up?

{Laughter]

Oh yeah, we used to do that back in the 80s.

Oh no, no, no, no.

Sure you did, Smalltalk guy.

Smalltalk did all that stuff and yes, they're all smug about it.

I want to make up a fake 1940s technology that just…

Makes everything we do now pale in comparison.

We did that back in the 40s.

[Inaudible] the kind of smugness.

Yeah. I would type in Chuck is the boss and then I could hear all the gears whir and then it would do awesome stuff.

It just developed the rest of the application off of that seed.

[Chuckles] So, while we're talking about live updating of your apps in production, this is a philosophical question. But as we say these things, those of us who are in the iOS world I'm sure are going, “That's so cool” and Android users are going, “So what? I can push updates to my users whenever I want because my Google Play Store is a lot more flexible and willing to just let me publish that.” Well, to a certain… you know, we're not quite talking about that level. But what I wanted to ask was do you foresee in the future a time when Apple just has to give in because of tools like Travis and React Native that have this live update baked right into the frameworks so that you can push updates so quickly and pretty much bypass the approval process. Do you feel like this walled garden of Apple having to approve every app that goes into the store is eventually going to crumble?

We can, with Tabris, can get Apple to change… [Laughter]

Won't happen.

To give into something?

Won't happen.

I'm retiring at that point.

Well remember, it's Tim Cook now. It's not Steve Jobs.

Won't happen. So, here's the deal. Here's the deal, right?

But seriously, Apple effectively approved Tabris indirectly. And they're letting people do this now. So, they've effectively given that concession already.

Right, but…

Do you think that that will have broader implications in the future?

I think it may work the other way. I think what will probably happen is you're going to have Tabris or some of these others, I mean all of them can do it, both the Cordova and the Native systems. They can all do it because JavaScript is considered a static asset and therefore can be updated on the fly by your program. So, somebody's going to abuse it, right? Somebody's going to have little kitties on the screen. And then boom! Hijack. Or, boom! Ads, or something. They're going to abuse it in a major way. And complaints are going to come back and then Apple's going to come in and they're going to lock it down. That's what's going to happen in my opinion.

I don't think Tim Cook's Apple is that way. I mean, he introduced the USBC charger, the first thing that Apple ever has that isn't proprietary to them. So, I think that Tim Cook's Apple, personal opinion, I think that they'll give in more.

What do Jochen and Ian think?

I think it's less likely it's the technology that's going to make them give in. I think it'll be some big business. At some point, I don't know how the banks are doing it. But obviously when they find a bug in their mobile apps they have to have that out there immediately. And when Big Bank of America comes to Apple and says, “When we find a bug it's got to be fixed within 12 hours to all of our users. We don't care about your process that you have,” they're going to have a much… that's where Apple will have to change and do things. And I'm sure they already are in talks on how that kind of stuff happens

I could see that, too.

Yeah. So, maybe they turn off the possibility to update on the fly but then they will have to speed up.

Yeah.

And if…

They'll have to streamline something.

Yeah.

Yeah, because to get your app in the App Store in the first place takes, if you're lucky it'll take a few days. But usually it takes a few weeks.

Yeah. I mean I was actually, when iOS 9 came out a lot of apps were broken. And we've seen app reviews within 24 hours but that was only for a week or two. [Chuckles] And then it went back to normal.

Yeah.

Most of those were during the beta, and that was frustrating because iOS 9 is clearly in beta and people were leaving poor reviews, which wasn't really fair because it was the OS. The app developers didn't even have a chance to update it.

Yeah.

So, I have something that I want to bring up that is… I was looking through the documentation on this and I was like, “No, no, no, no, no, no. Please don't do this to me.” So, if you look at NativeScript and the way that they do their views, the way they do their views is you have this XML markup. Which isn't gorgeous and I don't love it either, but the way that I see Tabris doing its markup or its views is you basically create a page object and then you append the other views to it. So, you have your buttons and text and everything else that you append to it programmatically. And every time that I've used a framework that does this, it has been super painful. It's impossible to test. And it's just… you have to remember all of these gazillion options instead of having a simple markup for the view. So, tell me why I'm totally wrong to hate this. [Chuckles]

You have to wait until our declarative UI is coming, which will be soon. But some people hate it, imperative UI. And there are lots of reasons to hate it. But maybe we grew up that way and imperative UIs also have some benefits. But I agree, declarative is nice. And we actually have been pondering about using Angular for that. But I mean, Angular 2.

Right.

And that might be an option. But we also are thinking about introducing something simple in the meantime as a declarative UI mechanism.

But we won't be getting rid of the imperative one. We will then be offering both. Some people do like it. It is fairly powerful when you need to embed your logic right into it there. So, mixing logic and declaratives and templates doesn't become pretty either. So, it will stay and we'll have, yeah we're going to have a declarative one on top of that. And that's what we're… it's one of the big things we're focused on right now.

Yeah, and another reason why we haven't moved forward on that one is that declarative UI only makes sense if you have a good data binding as well.

Mmhmm.

And we really tried to avoid [inaudible] and create everything on our own. But that's closely related, declarative UI and data binding. So, we really want to make the right choice here.

Yeah.

So, what do you think about Angular 2?

Well, I'm a fan. But I have a whole other show on Angular. And I've been playing with it and I've been really enjoying it. So yeah, I'd be happy with that. I also just want to point out that I can also see that this is simpler than the other system that I used, particularly in JavaScript that did things this way, which was Ext.js or E-X-T dot J-S. You wound up nesting all this stuff instead of doing a dot append to. And it just turned into a holy mess. And so, I can see that this is a little bit nicer in the sense that you set up all your objects and then you append them to the right place. And that may not be as painful. But overall, I just had this reaction because I had a year of pain where I dealt with this in another framework, namely Ext.

Mmhmm. I'm with you. I'm with you. And it's nothing that we will put off for a long time.

Yeah. Well, and it's a work in progress. I'm really curious to see what you come up with.

We just, we want to get it right.

Yeah.

Because it's one of the things that we're… and again this might be the way we've grown up with Eclipse, we don't like to break people once we've put it out there.

Yeah, totally fair.

And we've been building widget toolkits for a long time. And trying to maintain backwards compatibility. And then you come up with a better idea tomorrow and say, “Oh, but now we're going to break everybody.” So, we'd like to get it right.

Yeah.

And we've been pretty successful.

Hey, it works.

So, one of the things you said earlier was that Tabris is write once, run everywhere. Is that what you guys said?

I don't know if we said that, but it's one of those types of platforms.

Is that a philosophy that you guys…?

Yeah, I would think so.

So, some of the other competing toolkits in the space like React Native, React Native says learn once, write everywhere. Which means instead of having one codebase that universally runs on all phones, you instead have one concept or one framework that can be used to build apps independently for iOS and Android. And they don't even support Windows Phone at all, which is just totally out the window there. Haha, pun. Anyway, in reality have you found the write once, run everywhere to be effective at building UI, native UI that looks and feels great on the two different platforms, at least Android and iOS?

Yes. So, it doesn't mean that 100% of the code is identical. So, that doesn't work. You have to come up with I would say between two and five percent of your code needs to differ between the platforms. It doesn't mean that everything is the same. But the amount of code that is identical is huge. And so, we have a lot of experience with that. What's really important is that you can enable developers to make each platform shine. And that a platform shines, very often that's small things. It's the small things that make the impression. And that you need to enable. But the bulk of the stuff is just the same everywhere. And so, if I change your question a little bit, can you write better apps if you target each platform individually? Yes you can. There's no doubt about it. So, our customers are mainly ISVs and enterprises.

CHUCK: ISVs?

Independent Software Vendors.

Okay.

So, people that write software for warehouse management and yeah, all those software companies out there, and they have to serve more and more platforms. They still need to serve a desktop. They still need to serve a browser. And now they need to serve iOS and they need to serve Android. And if worse comes to worse, they need to support another mobile platform.

[Chuckles] I noticed how you didn't name that one. [Laughter]

The worse comes to worst platform. Let's just leave it at that.

Blackberry.

[Laughs] That's when the worst comes to really, really worst.

We have a Canadian on the call. [Laughter]

I spent eight years in waterloo right next to the Research in Motion. That's what Blackberry used to be called, buildings.

Oh, nice.

Okay. So, and these guys need platforms that enable them to be very productive. And they don't need a consumer-grade, like get the last three percent of the app. They need apps that have good usability that look good, that feel native on the platform, that are easy to use. And that's what we can achieve with write it once and run it on multiple platforms. And if you want to do… if Google wants to do an app that's consumer and they have hundreds of teams and millions of users they can for sure write a better app if they go native. But then the question is do you really benefit from writing it in one language because you still need to learn all the platform-specific API. So, I'm personally a little bit skeptical about writing in the same language but with different API. I'm not sure that this really helps a lot. That's my take on it.

And we do have support for platform-specific properties and things. So, if there are particular properties that are available only on one platform you can enable that. You can [inaudible] that and say, “Okay, let's turn on this particular shadow,” or whatever it is, “this effect that we want on this platform.” So, you can get some of those platform differences and do those. But Jochen's absolutely right. If you wanted to do everything on that, then you've got to learn both platforms and maintain multiple mobile apps.

And then actually, if I want to go in the full depths and breadths and I also want the tool support, then I want the code completion support in my IntelliJ IDE to find out what exact properties I can set and which exact methods are there. And then I don't want to be in a JavaScript editor and guess which type of string I have to type.

So, just to be clear, Ian you were talking there for a minute about being able to conditionally load different platform features. So, does that mean that in the same codebase I can say, “If I'm on Android load this and if I'm on iOS load this” instead of doing two different builds and two different codebases?

Yeah, you would do it in one. It's not so much load. It's if on iOS, set this particular flag, this header that's just not available on Android or something like that. Yeah.

So, what I've always wondered, because the idea of Tabris sounds good to me. Design a great experience once and run that on multiple platforms. And I don't get why people go through so much time and effort to make their iOS app look great and then they're like, spend I don't know, about as much time as a three-year-old would on a coloring project for their Android app. [Chuckles]

And you'd get like this terrible Android experience. So, the idea of, if I could design it once and make it great and deploy it on all platforms rather than saying, “Well, we're going to spend the 20,000 dollars on iOS and then…” I don't know, this sounds like a better deal to me.

That's the dream, right?

Yeah, it's not always that simple though.

I was going to…

All the way down to the…

Oh, go ahead Chuck.

To the view layer, the APIs are different. Some things you can build and they'll look the same and other things you just can't.

I wanted to ask you why you think other projects that have targeting this exact same problem have failed. Or, they just haven't failed but I feel like none of them have really taken off in a big way. And the gold standard still is to build it native. Does that question make sense?

Yeah. I mean, there are some frameworks from, let's call it the past, that haven't really made it. But I see two main reasons. Performance, which was yeah, just so bad that you simply couldn't build anything useful with it from my point of view. And the other one is you need platform parity and at least some of the old platforms that I'm aware of, they've been pretty good on iOS but terrible on Android. And then it's really not worth the effort. And then we have the new breed of multi-platform JavaScript platforms like React and NativeScript and Tabris.js. And they're just new. They're barely a year old. I think it's too early to judge how successful they are going to be.

Oh yeah, yeah. I didn't mean that they haven't been successful yet. I guess I'm just saying this is a problem a lot of people have attacked already.

Right. Most people who are writing iOS apps are writing them in Objective-C or Swift instead of going with a platform like Tabris or NativeScript or React Native or Cordova-based. Is that what you're driving at, Jamison?

Yeah, I don't even know anything about the numbers. But I feel like most of the apps I use are definitely native apps.

That's kind of the experience I have. I have a couple of people that are sort of interested in building stuff for mobile. And they just don't… are not into this at all. They just want to go Swift all the way if they're doing iOS.

But you said something interesting there. Most apps you have installed are native. And I mean, this is a native app. You get a real APK that will be installed. So, if you use a Tabris app, the Tabris.js app running on someone's phone, you're not going to know. A Cordova one's a little bit different. That is a web view and we're not in that bucket. But I think for these types of apps, I don't think I would know if I was running a React app, a React Native app. It's going to look native on these devices. So, from an end user's standpoint that's where we really want to stand out and say, “Yeah, this is something that your users are going to love to use. It's going to feel the way they would expect the apps to feel on their phone.” But for the developers yeah, it's new.

And I think that's, maybe that's the challenge for a lot of people is getting it out there, letting people know that these technologies exist and getting over those fears that they've had in the past that the performance was just terrible. I mean, that's one of our big focuses, has been on performance which is why we went with a V8 implementation for example. First implementations used Rhino and that lasted about two weeks. And we said, “This isn't going to cut it.” And so, we dropped that and we brought in V8 for that.

Yeah, I just want to pile on here that yeah, the native JavaScript bridge type app frameworks haven't even been possible except for the last year or so. And so, when you heard a lot of the issues with these other apps it was mostly based on the web view apps. And the web views weren't optimized to serve up those kinds of apps. But now that you can do all of the native stuff and you can make the native calls over the JavaScript bridge, yeah they feel native.

Outside of JavaScript, has there not been another language that tried to target both, like C++? Or another framework that uses a language to target both?

I know that RubyMotion has. But it statically compiles. So, it's a different approach. It statically compiles to runtime on Android and iOS. And you have to do a few different… sometimes you want to squint at your code a little bit things to make it work on Android. And that's the only other way I've seen it approached, is where it statically compiles to runtime.

Actually, there's also Xamarin. And I think these guys are pretty successful in their ecosystem, which are Microsoft developers.

CHUCK: Uhuh.

And they use C#.

Yeah. And Xamarin I believe also statically compiles

What does it mean to statically compile?

So basically, it compiles using LLVM to the bytecode that runs on iOS. And then it compiles however it has to compile to run on Android and I don't know the details there.

Yeah, you write in one language and cross-compile off to the different…

Yeah.

The different platforms that you want that on.

Yeah. Where in this case, it's actually the JavaScript with NativeScript and Tabris is interpreted on the machine and then any calls that have to be made to the runtime gets sent over, we talked about it a few times, the JavaScript bridge that allows native code to be run on the other end.

And those cases, not only do you need, you'll need tool support for whatever language you're writing it in, you're probably also going to want the tools around for the language you're compiling to.

Mmhmm.

So, you're still going to… now you need both. You're not getting away from Xcode if that was a problem.

Yeah.

You need to understand that and the code that you need to understand is probably something you never want to look at. And now you've got to take that to build out your apps and things. So, the tool support there seems like a big challenge.

So, back to the look and feel. When I think Android apps, I think gray and green. When I think iPhone apps I think white and outlines. And so, even though it's native, how do you create something that's a middle ground that fits the look and feel of both? Because if I was using Android and I have an app that looks like an iPhone app it might not feel native to me, and vice versa.

No, you just put that into separate files and load it per platform, if we're talking colors. And a lot of the other stuff is actually platform defaults. So, take a text input on Android for example, it doesn't have a box anymore. It's just a line that's below the input. And on iOS usually it has a box. But you don't have to do anything. That's just the default. Does that make sense?

Yeah.

So, you can override the styling, right?

Yes.

But often you don't want to override the styling I think is the point.

Right.

You want to use the default, the platform default. So, they don't look exactly the same but the text box looks like it should look on all other iOS apps. And if you just leave everything the way it is and it looks the way it should look on all other Android apps if you just leave it.

Mmhmm.

We do get the case where some people say, “Hey wait a second. I want these to look exactly the same. What's going on here?” And that becomes bugs sometimes people file. They say, “You know, I ran this on iOS and I have a box around it and on Android I don't. What's going on?” And that's because they are two different platforms and we want to maintain the native look and feel of those platforms. So, you can override it if you really want to make them look the same. But I think the point there was that often you don't. You want them to look the way they should look natively.

Yeah, I have a question that might be somewhat naive since I'm really not very familiar with this space. But as we were kind of talking about earlier, going fully native or like this is semi-native [chuckles] I don't know, however you want to call it. As a newer developer I've been, it's been drilled in my head that the code I write should be do one thing and be very concise. And I know when we had the NativeScript people on they talked about in their views they're using XML. And you have flags for the different devices. So, I guess my question is, and Chuck might be able to answer this because of him doing a lot of mobile, at what point is it a trade-off decision where you have just a bunch of logic in order to try to have code that runs everywhere? And so, the app if it's very large and you have all this logic, it becomes more complex as opposed to just writing two different apps that are native and then the code in those are more concise.

Well, I think in our case I think what Jochen mentioned earlier, two to five percent maybe is the kind of difference you'd be looking for, for platform differences. And really, if it's about styling then we can… the neat little trick we do is just put all the styling in the file and just load that file dynamically at runtime depending on what platform it is. So, the logic and everything is exactly the same across the platforms, at least with Tabris.js apps. You don't have to start saying, “If it's Android do this. If it's iOS, do that.” It's really just about the small parts of the styling that you might want different. Does that answer what you were getting at?

Yeah.

[Inaudible] Put a different way. So, if the differences are as big as you are thinking they can get, then you can still write two apps. There's nothing wrong with that, yeah? If you get to that point where you find your app is getting too complicated because you have to switch case or distinguish between the two platforms then you can still do that. There's nothing wrong with doing that. And usually that's not necessary.

I imagine it's a lot easier to fork two apps than to merge two apps in to one.

Yes, yeah.

Probably.

That makes sense.

Yeah, but the other thing is that most phones, if I hold my iPhone up at a distance and AJ holds up his Android phone at a distance, all things being equal they're going to look pretty similar. They function pretty similarly. So, unless you're doing things that really dig into the differences between the two platforms, you're probably not going to have a major problem with that. But if you do and you're deviating half of your code then yeah, split it to two apps.

And yet the mainstream right now is to write two apps.

Yeah.

Every mobile app development team I know which is not a ton but it's a fair sample, they have two different teams. One for Android, one for iOS.

Yeah. But I did like the point that was made that you could conceivably fork it and write two Tabris apps and one is Android and one is iOS. And with the module system in Tabris you could conceivably also then have your shared logic in some modules that you just load into both.

Yeah.

I wonder if iOS developers look at people trying to write iOS apps in JavaScript like we look at people using CoffeeScript. [Laughter]

Having talked to many, many of them…

Most of them don't think about it at all.

Okay. [Laughter]

[Inaudible] wondered up there just like…

I can just see armies of iOS developers just wringing their hands about these JavaScript losers. [Laughs]

Yup. [Laughs]

No.

All day long.

They're too busy making money to even consider whether or not you are. [Laughter]

Yeah, it's not until we start stealing their jobs or competing with them for users is it even going to register, I don't think.

Well, those days are coming, I'm pretty sure. I mean, Ian and Jochen do you guys believe that over the course of the next year or two we're going to start seeing more of an ecosystem crosspollination between let's call them native app developers, your traditional mobile app developers, and traditional web developers who are now going to start making a foray into doing mobile app development?

Absolutely. I think so.

Yeah, I'm not sure about the native developers. I mean they will try to defend their ground. [Chuckles]

But then, I am pretty, yeah, positive…

But there's so many of us. [Laughter]

We're like orcs. [Chuckles]

Unless they get Apple or Google on board, it just won't happen. And the more apps that do more things that more users want, the happier they are. So, I really agree. I think to a certain extent JavaScript's going to move into there. Some people are going to really want written in the technology that the company that built the platform designed for the platform. And other companies won't care. And we'll find some balance where that all starts to even out.

These frameworks like NativeScript and Tabris and React Native, they're so new. And yet I already know a good handful of people who are formerly web developers with no mobile app experience putting native applications into their various mobile app stores. I mean, it's incredible.

Why not? It's cool.

It's super cool. I just wonder, I wonder if the tide is going to come in, you know? Of the [laughs] orcs, orc armies of web developers.

Well, I also wonder what implications that has for things like ES 6 where we need the JavaScript that we can rely on. And ES 5 is something that is implemented even on the phones correctly.

So, can you write Tabris with ES 6? Just add a build step?

Yeah, as you know JavaScriptCore doesn't support ES 6. So, you can… actually, you can do everything at build time. But you still need [shims] then for runtime.

And on the Android side, we're using a slightly older version of V8. Although we can swap it out at any time. I'm just waiting to do that. But there's no point in moving one platform forward if the other one's not ready. So yeah, do it with a build step.

Mmhmm.

And shims there is perfectly fine. But the Android stuff, we [inaudible] swap it out. And you can do that fine on the Android side of things.

Yeah. We're all waiting for ES 6 on JavaScriptCore.

Which to be fair is the life of a web developer, too. Everyone that uses ES 6 now transpiles it. So, that doesn't feel any different to me.

Yeah. I want to write mine in Type Coffee ClojureScript. [Laughter]

And I just want to write mine in actual legitimate JavaScript.

You are so free to do that. That's the great thing. You can.

Actual, legitimate JavaScript meaning ES 6?

Although by calling it legitimate, I feel like I was just called a bastard. [Laughter]

Sorry Dave. It's just how I feel about you. [Laughter]

I still love you.

I have one more question. I'm coming to this from some experience in React Native and I know you can write native components and then kind of expose them to React Native. And that's one way you can make use of the expert iOS or Android [inaudible] that can do all the heavy lifting and then expose them to the teams writing JavaScript. Is there support for doing that in Tabris as well?

Yeah.

Yes, absolutely.

Yeah, that's where… yeah. Cordova is basically our answer, Cordova plugins. You write them natively, in the native languages, so in Java on Android or Objective-C or even Swift, and build out a Cordova plugin and expose the API that you want your JavaScript to call. So, not only can you do that and share that. You can take the huge ecosystem that's already out there of those plugins. As long as it's not using web views, you're free to use it.

Okay.

Yeah. Basically you have to tie into the widget hierarchy. So, we provide some API that you need to implement to become part of the widget hierarchy.

So, you said Cordova plugins and I'm wondering about CocoaPods. So, do you have to build a Cordova plugin for the CocoaPods that you want to bring in then?

Yes.

Okay.

I mean that's a way, how we consume it also in the build service.

Okay.

Chuck, are you cuckoo for CocoaPods?

[Laughs] I really like it.

That was an 80s joke by the way, for those young ones.

Yeah. [Chuckles]

Back when we had Smalltalk and Cocoa Puffs.

I remember…

Cocoa Puffs were the best cereal because they're old. That's how you knew they were the best.

[Laughs] And they had sweet message passing.

Yeah.

Yeah. CocoaPods is based on RubyGems and Bundler. So, I'm pretty familiar with how that all works.

Yeah, so the example though about the extending it for other widgets, we just did that as part of a proof of concept, also to show people how it's done. We built a map widget. And we could have built it as just part of our platform but we built it out as a separate widget that you just consume as a Cordova plugin and an example of how to do that. And now you have a native map widget on the different platforms. So, it kind of served as both purposes. You now have a map widget available but now it's also a reference implementation for how you can go about building your own custom widgets using a Cordova plugin.

I really like that idea that… well, people who are building Tabris apps are contributing back to the JavaScript community for everyone, you know? And in a good way, because you've got the separation of the view logic versus the controller logic. So, it's got benefits even if you're not using Tabris. Tabris being in the community is benefiting you.

Yeah, absolutely.

Alright. Let's go ahead and do some picks.

Before we get to picks, I want to take some time to thank our silver sponsors.

js}. Let's face it: errors cost you money. You lose customers or resources and time to them. Wouldn't it be nice if someone told you when and how they happen so you could fix them before they cost you big-time? You may have this on your backend application code, but what about your frontend JavaScript? It's time to check out {Track:js}. It tracks errors and usage and helps you find bugs before your customers even report them. Go check them out at TrackJS.com/JSJabber.]

AJ, do you want to start us with picks?

Oh, yes. Okay, so both the Belated Media 'What if Episode III were good?' and 'How Revenge of the Sith should have been' came out. So, those are two alternate ways that the prequels could have been awesome. Those are both out and they're great. The Force Awakens is pretty good. And obviously there are some criticisms. But I've read some of the articles online and I think that they're justly handled. But if you're a Star Wars fan then you've seen… there's no… yeah. If you're not a Star Wars fan you might still like The Force Awakens.

There's a new Star Wars movie? [Laughter]

Sweet!

I'm sure it hasn't made any money. And nobody's seen it.

I know. Also I'm going to pick the 'Thing Explainer'. So, it's this book that is lots of complicated stuff in simple words. So, I'm just going to open up to a random page here. So, you can guess what this is. Big tiny thing hitter. So, I'm guessing that this is the Hadron Collider that they're talking about. [Laughter]

But it's just like lots of really complicated and weird stuff like the sun and food heating radio box.

[Laughs] A microwave.

And shared…

Is that the XKCD guy by the way?

Yeah, yeah.

Yeah.

Shared space house. And then the explanations, I'll just read a little snippet here from one of the explanations. So, sky boat pusher. Sky boats like cars and sea boats are pushed by machines that burn fire water. Fire water needs air to burn.

And sky boat pushers use special blowers that use air they're moving through…

Nice.

To feed their fire.

And it's got the diagrams there. Anyway, it's just really cool of how you can explain complicated stuff to a person that only knows the thousand most common English words, excluding the swear words.

Right. And that last one was a jet engine, right?

I think it was.

The plane. Jet plane.

No, it was a sky boat pusher.

I thought it was a podracer.

It's actually really indistinguishable from a podracers. But I think it was a jet engine.

Yeah.

I think you're right, Chuck. I was wrong.

Alright. Aimee, what are your picks?

Okay. So, the first one is, it's a short article. It's actually at AngularClass.com. But it's called 'Making a Mini-Lisp: Introduction to Transpilers'. So, it was pretty short and I thought it was pretty good if you're interested in that kind of stuff like I was last weekend. Just trying to get a baseline for understanding this sort of thing since it's not something I'm really familiar with since I haven't gone that deep yet. So, that was good.

And then my second pick, because I said [inaudible] at the beginning I want to pick Nick Saban. I'm not necessarily some huge, crazy Alabama fan. But I really like Nick Saban. Just his approach to coaching and stuff reminds me of when I skated. So, that is my second pick.

Is he the coach for the Alabama football team?

Yes. He is extremely intense. And I love [laughs] watching his YouTube videos when he is doing drills and stuff with the players for practice. I don't know. I just really, really like him. I like his mindset to a lot of things.

I am now waiting for your blog post, Aimee. How football is like figure skating.

[Chuckles] I don't know if that would ever come. [Laughter]

Alright. Jamison, what are your picks?

I have three picks. The first one is this story about Bill Gates in the 1970s that I just liked. It's about this game called Petals around the Rose. It's just this puzzle game. And it's just kind of an interesting story about some famous people in computing history that I like. And then I gave up on the game. I just googled the answer. But if you like puzzles you might like the game that they describe as well.

How Completely Messed Up Practices Become Normal'. I've fallen into this guy's blog over the last couple of weeks. And he has a really large backlog. And all of his articles are interesting. But I particularly like this one. It's about how we oftentimes, weird stuff happens in software projects and at software companies that if you were an outside observer just looking in, it would look insane. And you'd wonder why anyone would ever do that. And he kind of goes through the process of how you end up in this horrible place and what you can do to maybe avoid it.

One particular wrinkle I liked is he talks about how when new people get hired at a company they'll often come in and just be flabbergasted about some broken process or crappy code or something. And then everyone else is like, “Calm down. It's fine. It's not that big of a deal.” And then they get used to it. And then another new person comes in and by that time, everyone is used to it again. So, you just slowly acclimate people to horrible, broken things. But you don't have to do that. You can get around it.

How Compilers Work'. I didn't do a compilers or programming language class in school so this is a thing that I just kind of always thought was magic. It's just a really clear introduction to compilers in a way that made sense to me and wasn't intimidating. So, I appreciated that.

Those are my picks.

Alright. Dave, do you have some picks for us?

Oh hey! Hey, how you guys doing? Pick number one. If you had told 10 years ago Dave that he would be picking Microsoft in 10 years, 10-year-old Dave would have punched you in the face because that's insane. But it turns out Microsoft, I would like to pick you this week. Because today is the day that we're recording this, January 12th, Microsoft is ending support for so many different old versions of Internet Explorer for all operating systems I care about. It's versions 8, 9, and 10 are all ending support today. And I just want to…

No!

[Chuckles] It's like saying goodbye to a long friend. Anyway, I want to… actually, it's more like saying goodbye to a, never mind. Can't go there. So, I just want to pick Microsoft for having the gusto to really go and do something big like this and really open the doors to a new era. I think we really can't understate the importance of this move from a company that has, its bread and butter is backward compatibility forever and supporting things forever. They are taking a stand ending support for these old browsers, which I think is fantastic. So Microsoft, you've been picked.

My second pick is my favorite comedian which I'm reminded again recently watching some of her stuff, is Tina Fey. I just love Tina Fey. She says so much hilarious stuff and I'm a huge fan.

And my third and final pick is a little company out of Germany called thoughtram run by my friend Pascal Precht who really has done such a fantastic job for the Angular community. His writing, him and his partner, have written so many high-quality articles. If you go to thoughtram, just google thoughtram blog and just start reading, you'll be amazed at how well they explain things that you thought you understood fully but you didn't. But they do. And so, I want to pick Pascal. Also a good friend of mine too, Pascal. He's been in my home. Love the guy and I can't wait to see him again at ng-conf which is just coming up here in a few months.

Yeah, Pascal did an episode on Adventures in Angular. So, feel free to go check that out. And we did, we talked about the documentation and stuff.

I've got a pick. I'm mostly just going to talk about CES because I think there were some things that were interesting and cool there, besides AJ. Yeah, I was just walking down the aisles and I got stopped by AJ because his company was there talking about what they're doing, which is really cool actually. And I'll let him talk about that some time. But anyway, it was really interesting just walking through there and seeing how much stuff. There was a ton of Internet of Things stuff that was out there, everything from home automation, medical devices. There were smart everything that you can possibly wear. So, pants, socks, shoes, shirts. I didn't see underwear but I wouldn't put it past them. They had all kinds of stuff.

We just had a baby so I went and looked at the baby stuff. And they have little things that clip onto the baby's diaper and help you keep tabs on what's going on. So, if they need to be changed or if they have a temperature or things like that. Just awesome stuff. There was a whole section on 3D printing. There was also, like I said a whole section on the Internet of Things stuff and robotics was most of what I saw. In past years I've also seen all of the TVs, the smart TVs and the 4K TVs and the cars and the smart appliances and stuff like that, some of which is interesting and some of it really isn't.

If you ever go to CES let me know so I can tell you what to see and what to go have your wow factor and then not really stick around those booths because they're huge and nothing. Yeah, there was pet stuff too. There are all kinds of stuff. So anyway, if you're interested in what's coming out probably in the next three to five years, CES is awesome. It's a great experience. Book your hotel room way in advance. Yeah, I really see the Internet of Things stuff coming up here. So, I'm going to be trying to get more of that stuff on the shows, on this show and on the iOS show. Because most of the people I talk to, I'd walk up and talk to them. And they'd show me what they had and then I'd ask them if there was an API and they'd be like, “Yep, sure is.” So, you could program the robots or you could remotely control the robots or your home automation stuff was mostly API programmable. So anyway, really, really awesome stuff.

[Inaudible] JavaScript for the APIs?

A lot of them.

Yeah.

Yeah, a lot of them. A lot of them with JavaScript. Several of them were Java or C. But yeah, there were a lot of them that were programmable in JavaScript or in JavaScript and a couple of other languages.

Any Smalltalk? That's the only thing I write. [Laughter]

Yeah. There were no hipster APIs that I could find.

Lame.

I'm just excited for the Internet of Baby Things.

Yeah. I'm also going to warn you. If you're looking at 4K TVs there is no standardization. So, don't buy one yet. Anyway…

I don't buy it. The 4K TVs don't do Smalltalk anyway. So, screw it. [Chuckles]

Yeah, but the quality in my opinion is better than 3D TVs. Like if you're going to buy one, buy a 4K TV not a 3D TV.

How would you fit Smalltalk in 4K though?

Oh.

We can make it fit in 4K. [Chuckles]

How many D's does a 4K TV have if there's 3D TVs? [Chuckles]

4K, oh. It's so complicated.

So confused. [Chuckles]

Alright. Ian, what are your picks?

I got a pick here. It's TheModernTeam.com. It's a blog. It's run by a local Victoria designer. So, shout-out to something local here in Victoria. Articles about building exceptional teams. He's getting a lot of good guest posts. So, Ken Goldstein who's the CEO of SHOP.COM, a former Executive VP at Disney Online, he wrote a post. That was the most recent one. And really kind of getting in, talking about what made Walt Disney tick and how he demanded it so much of himself. So, seeing posts like that, that's really cool. That's my main pick there.

From a JavaScript side of things, I've been reading a lot from Eric Elliott. I'm sure you guys have mentioned his stuff before. Most of the stuff he has is pretty good in JavaScript. And he's starting a foundation to help homeless people learn to code. I said I like to help developers, but that's pretty cool, actually putting our stuff to good use. So, I think that deserves a shout-out there.

That's my picks.

Alright. I forgot how to say your name.

Jochen. [Chuckles]

Yeah, you. Go ahead. [Laughs]

I'm going ahead. So, my pick is not an easy read but it's pretty interesting. It's 'Thinking, Fast and Slow'. It's a book by a guy who received a Nobel Prize on Economics. He's a psychologist and explains how the brain works, which is extremely insightful. And he is also very skeptical about humans making decisions because they are usually biased and encourages more artificial intelligence or more algorithms being used. So, it's a very interesting read. You learn something about yourself and he really has some good ideas about how to run projects, how to cope with some of our deficiencies. Let's put it that way. That's my pick.

Alright. Well, if people want to follow up the two of you on anything you're working on or with Tabris.js what do they do?

I'm on Twitter. I-R bull, I-R-B-U-L-L. You can find me on Twitter. EclipseSource.com is our company website. We've got a blog there. You can find me under one of our many authors on that blog as well. So, ping me on Twitter or leave a comment on one of my many blog posts. And I'll try to get back to you. And TabrisJS.com as well. And that's where you'll find everything Tabris.js related.

Alright.

Jochen, any?

I also have a blog. I rarely use Twitter so that's probably not the best channel for me.

Okay. Where's your blog?

I'll send you a link at EclipseSource.com.

Okay. We'll go ahead and wrap up the show. Thank you all for coming. Catch you all next week.