DAVE: Thanks for staying up so late with us. This will only take about three hours, so [inaudible].
CHUCK: Aimee Knight.
AIMEE: Hello world.
CHUCK: AJ O’Neal.
AJ: Yo, yo, yo, coming at you live from Utah once again.
CHUCK: 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.
IAN: Hey there. I’m up in Victoria of British Columbia, Canada.
CHUCK: I started with the one that I knew I wouldn’t slaughter.
CHUCK: And Jochen Krause.
JOCHEN: Hey, excellent. I’m here in Germany.
CHUCK: Awesome. You want to do a little bit more of an introduction? Who you are, what you do, who you work for.
JOCHEN: 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.
IAN: 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.
DAVE: So, tell us about Tabris.js. What is it? And did I say it right?
IAN: You did. Jochen, do you want to take the introduction to Tabris.js or do you want me to take it?
JOCHEN: Go ahead.
JOCHEN: 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.
AJ: 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?
JOCHEN: And you can use a Cordova plugin for that, but no browser, no HTML. That’s all native widgets.
CHUCK: Okay. So, just to be clear, you’re in the same category then as NativeScript and React Native.
JOCHEN: Camera. [Inaudible]
IAN: 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.
JAMISON: 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?
JOCHEN: 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.
JOCHEN: 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.
JOCHEN: 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.
AJ: 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.
JOCHEN: 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.
IAN: 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.
DAVE: 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?
DAVE: 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?
JOCHEN: 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…
DAVE: Ah, oh, but I have to host it?
JOCHEN: You have to host it, yeah.
DAVE: Makes sense.
IAN: 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.
DAVE: That sounds really cool for experimenting with new ideas. Do you find a lot of people use it? Like is it pretty popular?
IAN: Yeah, it is.
DAVE: [Chuckles] 30 years later phones can do what computers could do in Smalltalk.
IAN: That’s what our Smalltalk friends tell us.
DAVE: Oh, they’re very smug about it, aren’t they?
IAN: They are.
JAMISON: What if they’re just making it all up?
DAVE: Oh yeah, we used to do that back in the 80s.
CHUCK: Oh no, no, no, no.
DAVE: Sure you did, Smalltalk guy.
CHUCK: Smalltalk did all that stuff and yes, they’re all smug about it.
JAMISON: I want to make up a fake 1940s technology that just…
JAMISON: Makes everything we do now pale in comparison.
DAVE: We did that back in the 40s.
JAMISON: [Inaudible] the kind of smugness.
CHUCK: 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.
JAMISON: It just developed the rest of the application off of that seed.
DAVE: [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?
IAN: We can, with Tabris, can get Apple to change…
CHUCK: Won’t happen.
IAN: To give into something?
CHUCK: Won’t happen.
IAN: I’m retiring at that point.
AJ: Well remember, it’s Tim Cook now. It’s not Steve Jobs.
CHUCK: Won’t happen. So, here’s the deal. Here’s the deal, right?
DAVE: But seriously, Apple effectively approved Tabris indirectly. And they’re letting people do this now. So, they’ve effectively given that concession already.
CHUCK: Right, but…
DAVE: Do you think that that will have broader implications in the future?
AJ: 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.
DAVE: What do Jochen and Ian think?
IAN: 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
CHUCK: I could see that, too.
JOCHEN: Yeah. So, maybe they turn off the possibility to update on the fly but then they will have to speed up.
JOCHEN: And if…
CHUCK: They’ll have to streamline something.
CHUCK: 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.
JOCHEN: 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.
CHUCK: 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.
CHUCK: 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.
JOCHEN: 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.
JOCHEN: And that might be an option. But we also are thinking about introducing something simple in the meantime as a declarative UI mechanism.
IAN: 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.
JOCHEN: 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.
JOCHEN: 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.
JOCHEN: So, what do you think about Angular 2?
JOCHEN: Mmhmm. I’m with you. I’m with you. And it’s nothing that we will put off for a long time.
CHUCK: Yeah. Well, and it’s a work in progress. I’m really curious to see what you come up with.
IAN: We just, we want to get it right.
IAN: 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.
CHUCK: Yeah, totally fair.
IAN: 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.
IAN: And we’ve been pretty successful.
CHUCK: Hey, it works.
DAVE: So, one of the things you said earlier was that Tabris is write once, run everywhere. Is that what you guys said?
IAN: I don’t know if we said that, but it’s one of those types of platforms.
DAVE: Is that a philosophy that you guys…?
IAN: Yeah, I would think so.
DAVE: 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?
JOCHEN: 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.
JOCHEN: Independent Software Vendors.
JOCHEN: 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.
DAVE: [Chuckles] I noticed how you didn’t name that one.
DAVE: The worse comes to worst platform. Let’s just leave it at that.
DAVE: [Laughs] That’s when the worst comes to really, really worst.
JOCHEN: We have a Canadian on the call.
IAN: I spent eight years in waterloo right next to the Research in Motion. That’s what Blackberry used to be called, buildings.
DAVE: Oh, nice.
JOCHEN: 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.
IAN: 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.
CHUCK: 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?
IAN: 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.
AJ: 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.
AJ: 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.
JAMISON: That’s the dream, right?
CHUCK: Yeah, it’s not always that simple though.
JAMISON: I was going to…
CHUCK: All the way down to the…
JAMISON: Oh, go ahead Chuck.
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.
JAMISON: 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?
JAMISON: 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.
CHUCK: 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?
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.
AIMEE: 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.
IAN: 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.
CHUCK: 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.
JOCHEN: Actually, there’s also Xamarin. And I think these guys are pretty successful in their ecosystem, which are Microsoft developers.
JOCHEN: And they use C#.
CHUCK: Yeah. And Xamarin I believe also statically compiles
DAVE: What does it mean to statically compile?
CHUCK: 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.
IAN: Yeah, you write in one language and cross-compile off to the different…
IAN: The different platforms that you want that on.
IAN: 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.
IAN: So, you’re still going to… now you need both. You’re not getting away from Xcode if that was a problem.
IAN: 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.
AJ: 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.
JOCHEN: 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?
CHUCK: So, you can override the styling, right?
IAN: But often you don’t want to override the styling I think is the point.
IAN: 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.
IAN: 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.
AIMEE: 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.
IAN: 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?
JOCHEN: [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.
DAVE: I imagine it’s a lot easier to fork two apps than to merge two apps in to one.
JOCHEN: Yes, yeah.
AIMEE: That makes sense.
CHUCK: 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.
DAVE: And yet the mainstream right now is to write two apps.
DAVE: 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.
CHUCK: 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.
CHUCK: Having talked to many, many of them…
CHUCK: Most of them don’t think about it at all.
AIMEE: [Inaudible] wondered up there just like…
AIMEE: Yup. [Laughs]
DAVE: All day long.
AJ: They’re too busy making money to even consider whether or not you are.
CHUCK: 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.
DAVE: 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 cross-pollination 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?
IAN: Absolutely. I think so.
JOCHEN: Yeah, I’m not sure about the native developers. I mean they will try to defend their ground.
JOCHEN: But then, I am pretty, yeah, positive…
DAVE: But there’s so many of us.
DAVE: We’re like orcs.
DAVE: 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.
CHUCK: Why not? It’s cool.
DAVE: 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.
CHUCK: So, can you write Tabris with ES 6? Just add a build step?
IAN: 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.
IAN: 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.
JAMISON: 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.
CHUCK: Yeah. I want to write mine in Type Coffee ClojureScript.
JAMISON: You are so free to do that. That’s the great thing. You can.
DAVE: Although by calling it legitimate, I feel like I was just called a bastard.
AJ: Sorry Dave. It’s just how I feel about you.
DAVE: I still love you.
JOCHEN: Yes, absolutely.
JOCHEN: 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.
CHUCK: 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?
JOCHEN: I mean that’s a way, how we consume it also in the build service.
DAVE: Chuck, are you cuckoo for CocoaPods?
CHUCK: [Laughs] I really like it.
DAVE: That was an 80s joke by the way, for those young ones.
DAVE: Back when we had Smalltalk and Cocoa Puffs.
JOCHEN: I remember…
JAMISON: Cocoa Puffs were the best cereal because they’re old. That’s how you knew they were the best.
DAVE: [Laughs] And they had sweet message passing.
CHUCK: Yeah. CocoaPods is based on RubyGems and Bundler. So, I’m pretty familiar with how that all works.
IAN: 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.
IAN: Yeah, absolutely.
CHUCK: 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.
[This episode is sponsored by Thinkful.com. Thinkful.com is the largest community of students and mentors. They offer one-on-one mentoring, live workshops, and expert career advice. If you’re looking to build a career in frontend, backend, or full-stack development, then go check them out at Thinkful.com.]
CHUCK: AJ, do you want to start us with picks?
AJ: 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.
DAVE: There’s a new Star Wars movie?
CHUCK: I’m sure it hasn’t made any money. And nobody’s seen it.
AJ: 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.
AJ: But it’s just like lots of really complicated and weird stuff like the sun and food heating radio box.
DAVE: [Laughs] A microwave.
AJ: And shared…
DAVE: Is that the XKCD guy by the way?
AJ: Yeah, yeah.
AJ: 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.
AJ: And sky boat pushers use special blowers that use air they’re moving through…
AJ: To feed their fire.
AJ: 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.
CHUCK: Right. And that last one was a jet engine, right?
AJ: I think it was.
DAVE: The plane. Jet plane.
CHUCK: No, it was a sky boat pusher.
DAVE: I thought it was a podracer.
AJ: It’s actually really indistinguishable from a podracers. But I think it was a jet engine.
DAVE: I think you’re right, Chuck. I was wrong.
CHUCK: Alright. Aimee, what are your picks?
AIMEE: 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.
DAVE: Is he the coach for the Alabama football team?
AIMEE: 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.
CHUCK: I am now waiting for your blog post, Aimee. How football is like figure skating.
AIMEE: [Chuckles] I don’t know if that would ever come.
CHUCK: Alright. Jamison, what are your picks?
JAMISON: 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.
My next pick is an article called the ‘Normalization of Deviance in Software: 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.
My last pick is related to Aimee’s pick actually. It’s a talk. I went to CodeMash last week which was good. And this was probably one of my favorite talks there called ‘Programs that Write Programs: 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.
CHUCK: Alright. Dave, do you have some picks for us?
DAVE: 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…
DAVE: [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.
CHUCK: 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.
CHUCK: A lot of them.
DAVE: Any Smalltalk? That’s the only thing I write.
CHUCK: Yeah. There were no hipster APIs that I could find.
JAMISON: I’m just excited for the Internet of Baby Things.
CHUCK: 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…
DAVE: I don’t buy it. The 4K TVs don’t do Smalltalk anyway. So, screw it.
CHUCK: 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.
JAMISON: How would you fit Smalltalk in 4K though?
IAN: We can make it fit in 4K.
DAVE: How many D’s does a 4K TV have if there’s 3D TVs?
DAVE: 4K, oh. It’s so complicated.
CHUCK: So confused.
CHUCK: Alright. Ian, what are your picks?
IAN: 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.
That’s my picks.
CHUCK: Alright. I forgot how to say your name.
JOCHEN: Jochen. [Chuckles]
CHUCK: Yeah, you. Go ahead. [Laughs]
JOCHEN: 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.
CHUCK: 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?
IAN: 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.
IAN: Jochen, any?
JOCHEN: I also have a blog. I rarely use Twitter so that’s probably not the best channel for me.
CHUCK: Okay. Where’s your blog?
JOCHEN: I’ll send you a link at EclipseSource.com.
CHUCK: Okay. We’ll go ahead and wrap up the show. Thank you all for coming. Catch you all next week.
[Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]
[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit CacheFly.com to learn more.]