Podcast: Ionic 2, AngularJS 2 and the future of hybrid apps – Mike Hartington

Today we’re joined by Mike Hartington, Ionic Developer advocate. We’re discussing what’s new in Ionic 2, Angular 2.0 along. Also, how to build you apps to ensure a smooth upgrade and even whether or not you should wait for the 2.0 release for your next web app.

If you’re interested in staying up to date with the latest developments, be sure to check out the 2016 Angular Summit¬†taking place in May, 2016.

Transcript: 

[intro music and recording]

Michael Carducci:

You’re listening to the "No Fluff Just Stuff" podcast, the JVM conference series with dozens of dates around the country, and there will be one near you. Check out our tour dates at NoFluffJustStuff.com.

[end recording]

Michael:

Hey everybody, we’re here at the Angular Summit here in Boston, Massachusetts. I’m joined here with Mike Hartington.

Mike Hartington:

Hi, how’s it going?

Michael:

Mike here is one of the big brains at Ionic.

Mike:

Yeah, you know, kind of just a developer advocate, work on the core team, work on the framework and go around talking about it.

Michael:

Listen to that modesty. Well, tell us a little bit more about what you do, and then we’re going to dive in to some Ionic 2 stuff and see what’s coming up and what cool, new things are out there.

Mike:

Most of my day-to-day ends up being working with other developers that are out there, helping them in their development process, writing docs, building demos. Just going around to different events, speaking about Ionic, and speaking to developers in general.

Michael:

You’ve got a talk tomorrow morning?

Mike:

Yeah, 9 o’clock, 9:00 AM on the third day, about Ionic 2 — what we’re doing, things that we’re thinking about doing, general directions with the framework.

Michael:

Tell us a little bit about that. I don’t want to any spoilers for the talk itself. Actually, I think this comes out after the talks’ event. It would probably be OK. [laughs]

Mike:

So big changes with Angular, obviously. Angular 2 essentially is a complete rewrite of the entire framework. It brings all these cool changes and all these cool new features, rebuilds things instead of having to implement them again. Angular is just building up standards that are already there now, big things like ES6 and TypeScript and all these cool new things that people are doing.

Essentially, Ionic 2 is going to adopt Angular 2. With that, we have a chance to take something that was already great and already easy and essentially gave superpowers to developers and make it even easier, but still at the same time make it even more powerful, more expressive and just take everything that we had, essentially push it to 11.

Michael:

Right on. What are the challenges that you’re dealing with right now with the known end-of-life of the Angular 1.x?

Mike:

Some of the challenges are the general question of, do I wait for that with Angular 2 and Ionic 2 or do I just build my app using V1 right now?"

Michael:

That is the big question.

Mike:

Yeah, obviously, build it right now. If you have something that you needed get done and you need it soon, use V1. Use Angular 1 and Ionic 1. They are there. They are stable. They’re out. Why wouldn’t you use that?

Another big question is, how can I best prepare myself for this drastic rewrite? A lot of this actually comes down to just following some of the best practices. You can avoid doing complete rewrites. Essentially, by making sure that every single bit of your code has been split up into individual pieces.

JohnPapa has probably the best style huide about Angular project structures. Now where one directory or say a home page or a home state has the view, the controller you have to associate with that file and everything that is about that page in your app is there in that directory.

We can start working, make sure that our projects are structured in that way. We can start working with "controller as" syntax. That way we are not using $scope anymore and that will translate really well into Angular 2.

Michael:

I don’t think we should we be using $scope anyway.

Mike:

No. All the issues that come with it, always use "controller as." I’m a recently converted to "controller as" syntax after hating it for so long.

Michael:

That covers a lot of the Angular. What about anything specifically you want to do within Ionic?

Mike:

See, the kind of beauty about it is that Ionic is just a presentation layer. A lot of the work that’s going to happen, all of the changes that are going to happen with Ionic are going to happen internal and the developers really won’t see it.

What they are going to see, templates here and there, and some mark up may change, but the overall structure and templates that they have, those should be able to stay roughly the same. A lot of it comes down to the Angular code and being able to write things using TypeScript or ES6. If you can start doing that now with your project or migrating in that direction, you’re going to be a lot better off.

Michael:

It sounds like as long as you’re writing good, clean, best practice Angular code right now, you’re not going to have too big, too much of a headache ahead of you, if you want to rewrite everything in Angular 2. But that brings up a really important question.

So Angular, if I’m working on project right now in Angular 1.x and Angular 2 rolls around, do I even really need to drop everything and make everything 2.0 friendly?

Mike:

No. That’s actually a really good point. That’s actually a really good point. Mango team has gone through hoops to get us that way. Angular 1 app can run at the same time and even inside of an Angular 2 app. They kind of talked about some of their migration plans, their migration paths for people. You can do it like a complete rewrite all at once, or you can start doing it piece-by-piece.

That’s where we are expecting most people to go. Running an Angular 2 app but inside of that, running an Angular 1 app. Then as you get used to it and learn the syntax and learn everything about it, you upgrade bits and pieces of your app.

Maybe you have a login controller. That should be easy to just migrate over. Since it’s just a controller, it essentially becomes a class. It should be pretty easy to migrate that. Then you can keep going when you find the time or as you learn more.

Michael:

The whole, "Well, I’m not going to start now because Angular 2 is coming out in the offing. I’m just going to have to rewrite everything anyway. I’m going to use Frameworkx."

Mike:

Yeah.

Michael:

That’s kind of a straw man argument, is what you’re saying.

Mike:

Yeah, it’s an extreme. The people say, "I’m going to stick on 1x all the time." That’s one extreme, or people say, "No, I’m just going to wait and build with Angular 2." That’s another extreme. They can work together.

Michael:

Ultimately, everything is going to change. I remember when Prototype was the thing. A few years later, everybody’s using Java kit. All the cool kids were using jQuery. Suddenly, "Why are you using prototype?"

Now all the cool kids are using Angular. They are probably moving on to some framework that we haven’t heard of yet.

Mike:

[laughs] Some obscure thing that just got released.

Michael:

That’s right, because they were into it before it was mainstream. [sarcastically]

Man, thinking all the way back, I remember using YUI.

Mike:

Y-U-I?

Michael:

[laughs] Yeah.

Mike:

That was years ago.

Michael:

2006, I think, is when it went end-of-life. This also isn’t our first time that a framework has drawn a line in the sand and said, "From this point, things are going to change. You’re going to have to make changes to go with it." If I remember correctly, jQuery had a big major release that broke some of the older stuff.

Mike:

The one to two?

Michael:

Yeah.

Mike:

It goes back. If you have to look at a life of a project, a lot of it depends on, "What does the language offer? What does the market look like out there?" In respects with jQuery, dropping support for older browsers was a smart idea because those browsers…

Michael:

There was a lot of legacy code.

Mike:

The code base was probably a lot better for it. With Angular, it’s going to be the same thing. Angular 1x came from a completely different time where, 2009, 2008, browsers were completely different compared to what we have today. Our standards have greatly improved. We no longer need to recreate these things.

We have a standard API for working with classes instead of saying, "Oh, we’re just going to create our own controller instance." No, we have actual classes inside of the language now, properly, or a cleaner syntax for them. If you look at anything it’s all about if we make this a huge breaking change, it’ll benefit people in the long run.

Michael:

To some extent, you have to admire the courage. Obviously, if you’re Google it doesn’t take that much courage to say, "All right, we’re doing it this way." On a side project that I work on, Google has just, in the last 12 months, decided that they will only allow apps to communicate with the Google platform with OAF, that they were going to completely eliminate userpass, IMAP, and things like that.

I just got my first support ticket from user on that saying, "Google is saying that you’re not a secure app. What’s that all about?" Now I’ve got to go rewrite a bunch of stuff in OAF, but I should have been paying attention. That’s definitely my fault.

They can do that. Looking at the state of technology, there is so much technical debt and there is so much legacy. Everything, the whole landscape has changed so much. So much legacy stuff that changed and maybe there is more that we’re going to need to see more of anyway.

The legacy support, for example, being able to do content negotiation in browsers to support all of their encryption formats, these things like that have exposed huge security vulnerabilities and that’s a pervasive problem, so maybe we just need to see more of this whole attitude that we’re going to break things from time to time and create it good.

Mike:

And Angular team, we may look at them and say, "Why are you breaking all my APIs? This is so horrible." It’s like, "Yeah. It’s bad for us, but you also got to think about the Angular team inside of Google."

Google has crazy amounts of apps that are written in Angular. For them to break all of that and not really, but, " Oh, we needed to break it." They’re going to piss off some of their co-workers.

Michael:

They are kind of eating their own dog food in that regard.

Mike:

Yeah.

Michael:

The other thing though, that I think is interesting is yes, having Google behind Angular gives it a tremendous amount of clout, but one of the biggest decisions for me if I’m going to choose a framework is the developer community.

Angular has a thriving developer community. If nothing else is evidenced by the attendees we have this conference, but it’s definitely one of the major players. It’s seems to me that that would be kind of risk to alienate that developer community and risk them saying, "You know what? Screw it. We’re going to switch over to React or whatever some of the newer fancier frameworks that are out there."

Mike:

Right. It’s less about wanting to alienate people and more of just wanting to make sure that the code our community members will write is going to code that they can carry for a few years. They can carry a lot longer than what they would currently have to write, and that they can also make sure this code is performing, this code will last. It will run really well and it will be easily maintainable down the road.

There’s been moments in that Angular 2’s development where they’ve said, "We’re not going to do this." Then enough people on the community have gone back and actually commented and say, "No. We really should do this. This is a great idea. Maybe we can re-think the implementation, but keep the syntax similar," and that’s changed the Angular team’s mind.

It’s like, "OK. We can see the benefit of this. If it’s familiar syntax and it’s easier for people to kind of pick up on, yeah, let’s go that way."

Michael:

Right on. I want to go back to Ionic for a little bit because I was having one of the road show stops. In the keynote we were talking a lot about mobile development. The opinion of the presenter was that really if you want to build anything mobile, you need to go native, aside from very niche apps that are of dubious value.

I thought that was a bold statement because my next mobile development product project is definitely would be in Ionic. It seems to me that maybe I’m not doing anything fancy with UI and graphics, but all of the native functionality, all the hardware functionality that I want in OS, functionality that I want is accessible.

I don’t know. What are your thoughts?

Mike:

If we’re going through a performance standpoint solely, how do we write an app using website technologies or native, we really want to get the best performance. We just skip native and write assembly.

That’s kind of the main ways I can say. Performance, it’s going to be something that you can worry about, but if we want the best performance you can do it soundly.

Going back to, "You can’t make a decent app using web technology or any apps that works this way. It needs to be done in native languages," not really. We have so many apps that have been submitted to us to the app store who are app store kind of showcase. One of them in particular has an app called "Sworkit."

Michael:

I’m not familiar with it.

Mike:

It’s a circuit workout app. There’s one guy, Ryan Hanna who developed it as a side project and it’s gotten so popular and its gotten so many great reviews. It’s been featured on the iOS app store.

Michael:

Wow.

Mike:

It’s been featured on Google Play.

Michael:

He’s in both of those. He didn’t need to write it once in objective C or Swift and once in Java or trying to kind of half way get there in JVM or in some cross compiling platform.

Mike:

Yeah. He had one code base that he was able to maintain and work with and then export out an IPA or an APK for Android. This is something that people can make quality apps using website technology, but it is not replacement for being a good developer.

Michael:

Yeah, or having a good eye for UI, a good understanding of UI or UX, whatever we call them these days, but being able to design something that’s nice.

Mike:

Right, good touch with design. If you can have a poorly designed and poorly performing native app just easy as you can have a poorly designed and poorly performing hybrid app. Saying one language is better than the other, when your basic kind of app, 90 percent of the apps in the store are crud apps, simple data driven.

They just need to update that data or display that data. There’s really no need to create a native app for that.

Michael:

If you’re pulling data down from a service, and posting data back up to a service, the UI is not your bottleneck.

Mike:

No. A lot of it just your actual process of fetching data and pushing data, or your actual the amount of data that you’re trying to pull down.

Michael:

And then everything on the server side too. Your database can be a bottleneck.

Mike:

That too.

Michael:

You know whatever your cloud infrastructure could be a bottleneck. You would have to get everything pretty tight before you’re like, "Oh. I really need to shave a few more milliseconds of with this."

Mike:

Right. There’s many different places where you can look for optimizations before you think maybe I should have picked a different language stack. Like you said, there’s many different places you can look for.

Michael:

Awesome. Thank you for being with us Mike, and look forward to checking out Ionic II.

Mike:

We’re going to be doing some developer early releases and hopefully again a preview that’s pretty soon.

Michael:

How do we get on a list for that?

Mike:

Just kind of find us follow us on Twitter at Ionic. Follow me on Twitter @mhartington. Get in touch with us. We want people to try it out and we want to get people give us their feedback.

Michael:

Right on. Thanks again Mike, and you heard it here. Check it out.

[outro music and recording]

Michael:

At No Fluff Just Stuff we bring the best technologists to you on a roadshow format. Early bird discounts are available for the 2016 season. Check out the entire show line up and tour gates at No FluffJustStuff.com.

I’m your host Michael Carducci. Thanks for listening and stay subscribed.

Leave a Reply

Your email address will not be published. Required fields are marked *

*