Charles: Hey everybody and welcome to episode 112 of the Adventures in Angular Show. This week on our panel, we have Ward Bell.
Ward: Hello, hello.
Charles: Joe Eames.
Joe: Hey everybody.
Charles: John Papa. Lukas Ruebbelke.
John: Hello Ward, John, and Lukas.
Charles: I’m Charles Max Wood from devchat.tv. If you missed it, we just had Angular Remote Conf. You can still get the videos. Just go to angularremoteconf.com and I will have that all linked up so you can get the videos. Today, we’re going to be talking about upgrading from Angular 1.0 to Angular 2.0.
Joe: Don’t call it upgrading, call it migrating.
Charles: Before we get to the bin of this, I want to challenge the premise a little bit. Does everybody need to upgrade to Angular 2.0?
Lukas: Absolutely not. No.
Charles: Or are there instances where people can just, “Hey, I’m Angular 1.0, I’m good.”
John: Everybody but Lukas should upgrade?
Joe: You should stay.
Lukas: I get a hall pass.
John: He loves it. He loves Angular 1.0 so much. Anyway that he’s going to teach us how to downgrade from Angular 2.0 to Angular 1.0.
Ward: If it was legal to marry Angular 1.0, Lukas would marry it. Definitely not everybody should migrate to Angular 2.0. I certainly have some strong opinions on who should and when and why but I’m interested in what other people have to say about to this as well.
John: I’m interested in attacking your opinions but I couldn’t do that until you have wisdom.
Joe: Alright. First off, we should frame this so that everybody knows I’ve been like eye balls deep in Angular 2.0 migrations for several months now. Been working through at migration on a reasonably sized code base, nothing huge. I’ve got a lot of experiences with huge code bases as well. I’ve been able to extrapolate what I’ve been learning about migrating a medium size code base to what it would be like to migrate a large size code base.
I’ve worked with Ward in the documentation team to refit what the original plan was for migrations and make some changes that would work better for large code bases.
Lukas: Joe, before you go further, can I challenge you on what does the word migrate mean?
Joe: Okay. Yeah, good thing. Let’s define that word, work independency is I can. There is a product that Angular 2.0 has released, it’s part of Angular 2.0. It’s called NG upgrade. Its core piece is this upgrade adapter component.
What that allows you to do is actually run Angular 1.0 and Angular 2.0 side by side. The point of it is when you have an Angular 1.0 application that you want it to move slowly to Angular 2.0, the speed I guess is relative depends on how quickly you move, you want to move it to Angular 2.0, you can use these components that they’ve provided.
It allows you to run Angular 1.0 and Angular 2.0 side by side in the same application. They can share state and change detection. It can share services. I can get into exactly what they can share. That takes a minute to describe. It allows you to make a migration of your applications.
Rather than I’ve got to rewrite it, there’s probably three clear choices that you’ve got when you have an Angular 1.0 application and Angular 2.0 is not released, you’re running what to do. Obviously, option one is to just leave it alone. Just keep it in Angular 1.0.
Option two would be to completely rewrite it. Just close the doors on your Angular 1.0 application, maybe leave it running for the time being, but rewrite in Angular 2.0. When Angular 2.0 application is up, you replace the Angular 1.0 application with the Angular 2.0 application. That replicates all the functionality.
The third option is to migrate, which is to take your Angular 1.0 applications. Start using these new pieces, start running Angular 2.0 within the same application itself and slowly move the application basically piece by piece, page by page, sort to say over from Angular. In fact, I should even say page by page release piece by piece from Angular 1.0 to Angular 2.0 until at some point.
Maybe within that, I think there are definitely two clear choices that will happen here. One is, that at some point you finish everything off and you do have an entirely Angular 2.0 application. We’re going to see a lot of applications that get partially moved and never get fully moved. They’ll live like that forever with part of that app running in Angular 1.0, and part of it running in Angular 2.0, which again I believe is totally fine.
Ward: We may have to contest that. I do think that in broad strokes are you. Those are your big choices. There are places in between.
Joe: Yes, absolutely. A lot of places in between. That is a nut shell what migration does. Running the two side by side within the same application and then moving it.
John: Joe, you’ve done a few of these already. I know a lot of teams are retorting this. Is it worth it? Migration is just a nice word for saying you’re going to have an Angular 1.0 and Angular 2.0 app living together was chance. Is an end result something that people can live with long term?
Joe: Absolutely. I’ve been working with it. I think it’s fantastic. I think that the way what they’ve come up with exceeds any expectations I had. In fact, if we could go back and look at old episodes of this show, we would hear me saying I believe that everything they’re talking about with NG upgrade is a whole dog and pony show smoke.
Mostly I was talking about people publishing on their blogs that, “Hey rewrite your code in Angular 1.0 to look more like Angular 2.0 and it’ll make your migration path easier.” I thought that was a whole bunch of malarkey and a bunch of baloney.
What they actually came out with that allows you to migrate not only exceeded my expectations of what they would do, but it also made it so that there is a lot of validity to that idea of spending some time rewriting Angular 1.0 code to look more like Angular 2.0. Not specifically just to look like it, but there’s specific things you can do that will make the migration easier.
Ward: And would make your Angular 1.0 code cleaner. It has an immediate effect as well. Before we even go there, because this show really is about that tooling and the apparatus that you’re about to describe. I feel what John is saying, or rather is hinting at. I want to put a bold face on it, which is that it may actually be easier. I hope you’ll put some partial to this idea. Just simply say, the clean way to do it is to bite the bullet and redo it in Angular 2.0.
Before you gag, everybody out there who has a big Angular 1.0 app, I want to speak from a certain kind of experience, which is not that we have taken in Angular 1.0 app and convert it to Angular 2.0 but that we have taken another app written to the entirely different technology which theoretically should be harder and simply re-done it. We consider that to be the prototype, the definition of what the application ought to be able to do and used that as the occasion to completely rewrite it in Angular 2.0. I’m talking about an application with well over 200 screens, and 300 entities in it. That was possible within a three month time span.
Lukas: Do you know what they did with the number of lines of codes that was in that? May two our screens in indicative but not necessarily right.
Ward: Right. I don’t have that stat. That would be good but since it was in another technology, happened to be Silver Light, it’s hard to make a direct comparison. I could tell you what the final lines of count were if I knew what they were and I shall come back and find out.
I don’t think it’s an open shot case. I’m not making the statement that one shouldn’t be paying attention to what we’re about to learn. Rather that you need to be able to assess both the time that you have to bring this off and where you think your future development is going to go, take a swing at it. One of these will be the right choice for you.
The other thing that I was going to push back that Joe said that worries me a little is the idea that I will forever have an Angular 1.0 and Angular 2.0 hybrid. He’s certainly write that it will fall out that way. Is that desirable? Is that the okay thing? Because if that means that you have to have a team that is conversion in both Angular 1.0 and Angular 2.0, and figure out where the seams are and how they come together, I’m not sure I’d want that cloud raining on me for the duration of the project life. I know that’ll happen, we all know that it’ll happen. You’re run out of budget or whatever it is.
Joe: Ward, you’re going to need a team whose very self-aware of how to live in both world at the same time.
Ward: Exactly. I find that worrisome. That is almost the biggest threat to me. The biggest warning sign that suggests that what Joe is about to tell us is something you should approach with suitable caution. Now that we framed it that way, clearly, Joe, you’re excited about this.
Lukas: Hold on. Can I just address a fundamental assumption that I think is wrong. That is you’re talking about Angular 1.0 being one world, and Angular 2.0 being another world. I would push back in that and say when you write Angular 1.0 in an Angular 2.0 style, the difference between those is not worlds apart. It’s actually very, very similar to the place where you can actually pick up pieces of it and use it interchangeably in an Angular 1.0 app or an Angular 2.0 app.
I just want to make this point that I don’t think that they’re worlds apart but actually very similar when you write your Angular 1.0 applications in a specific style, the biggest one using ES6 classes and modules.
John: Can we put a pin in that one. We get about to that because I would love to discuss that one as well.
Ward: Before you leave it, Joe, would you please tell them that when they’re running both, when you’re running the hybrid you are carrying the load of both frameworks, both mentally and physically.
Joe: Let’s talk about performance later. Let’s put a pin on that one as well. What it’s like during the prep time period when you’re running them all together, performance wise and so on.
Let’s go back. The original thought was what apps should move on a box of circumstances. You give this example of a very large app, you migrated within three months. I think you and I Ward are probably on the same page, although we might fall a little bit away from each other on the spectrum as far as maybe optimistic versus pessimistic.
My experience in working with applications large and small, and many large companies, the applications size has a lot do with it but the company has even more to do with it. Where you’re at and what it’s like, I’m sure you guys have all seen this exact scenario. There’s really the key indicator as to what you should do. You have to take your application into consideration there but it really is resources that your company, the management attitude in your company about these types of things.
My experience has been definitely a lot more pessimistic. I’ve lived many, many, many times in the world of applications that have been maintained, add infinitum while waiting for budgetary approval for the the big rewrite. Features pushed off, and pushed off, and pushed off unnecessarily. Pushed off by me, I’ve been into the place where I have said I will not touch that application. If you ask me touch that application, I will leave and I will go somewhere else. I will not maintain that application and then I was only one of two developers. It meant that nobody could do anything to it. I’ve been in that situation before. I’ve seen all the sides of these.
I think that companies tend to be far too optimistic, especially developers, in their estimations as to what they could do. It comes down to if you should rewrite or if you should not, is how long will it take you. While you’re doing it, what will be the cost on your business? If it’s going to take you a month, you should almost for sure rewrite it. If it’s going to take you three months and you know it’s only going to take you three months, I guess you should probably rewrite it. My guess that most people that say it’s going to take us three months have no idea how long it’s going to take them and it’s really going to take 9 to 12 months.
Let’s talk about what it’s like in that nine to twelve months while you’re trying to do a rewrite. There’s been some really brilliant talks and blog posts about the same exact thing about the grand rewrite, Uncle Bob Martin has talked about this certainly before, I’ve listened to him talked about this a couple of times.
In the case where you’re rewriting some very critical, very important applications, that rewrite drags on 9, 12 plus months, you’ve got the existing application that is critical that has to serve the users and you got the new application. That existing application does not live in a vacuum. You’re business needs change. You got to a new feature that’s got to come out. It’s got to come out for the existing application that cannot wait. It cannot wait nine months for the new application to come out. You have to go and add that feature to the old application. What does that mean? That means that the resources you’re spending writing the new application get drawn away. The longer that you take doing this, the more resources will get drawn away while you have to add this new feature to the old application and fit it on the new application. You already expect out the existing features set based on the existing application. Now, you just add the features, you got to fit that one in twos. You gotta write that feature now twice.
Whatever time period you’ve got, both of those applications running, you are now writing those features twice. That of course doesn’t exist for everybody but in that scenario it can become hell. It can make a drag on forever.
Ward: I agree. My only extra comment would be if you’re looking at it and you’re scheduling something out as a nine month event, maybe you shouldn’t be leaving Angular 1.0 at all.
Joe: That’s interesting. I would definitely offer a counterpoint to that and disagree with that in not necessarily universally but there are definitely cases. Maybe I think a lot of cases where that’s not true.
My point would be if you are listening to this show, you’re thinking we could rewrite our apps in three months, you better rethink it. Your idea of three months is probably nine months. By the time nine months comes around, there’s going to be enough bloat that happens to both sides of it. That’s going to be 12, 15 months. Potentially, the common scenario where the new app is ultimately just abandoned because it’s just never getting done. Everybody just goes back to the old app, you spend nine month of your life wasting your time writing an app that will never see productions. I hate seeing that scenario. This NG migrate really is built to address that.
John: I think anybody who considers rewriting an app, forget the technology, we’re talking to migrations strategy here. Before you even think rewriting an app you have to really think about, “Am I doing this for the technology? Am I doing it for the business purpose?” Because if you’re doing it for the technology, most cases in my experience, I never say all, but most cases that’s not the right reason. That’s usually a desk trap. Doing the business reason is better.
Joe: There is one overlapping concerned there. That is hiring devs. Remember the scenario I was just talking about that I would not touch that app. This is because it was an app written in ASP, not asp.net, ASP. This is like 2006, 2007, or whatever. I just wasn’t going to waste my time building a skill set in a dead technology.
John: I agree if that technology’s been dead for a decade, yes. But if that technology has been dead for three days, I don’t think so.
Ward: Let me throw another wrinkle into that, which is often the compelling business reason is that the Angular 1.0 app that you’re talking about, you didn’t do a really great job at that. It grew as a ball of mud because nobody really knew what was needed anyway. You see this as an opportunity to redo it right this time and get on to the new technology, and position yourself for new hires. There’s a potential confluence of a business reasons why this is a good thing.
John: Business is business.
Ward: John’s right. It’s always business reasons. I think what we’ve all done collectively here is give the consultant’s answer to any question, it depends.
John: Joe, I’m a developer. I love and I agree with you. Really, most what you and Ward saying. You know what, I’m bored. I want to know what the changes are that I have to be aware of to get to the migration.
Joe: Alright. If I understand it correctly, you want to talk specifically about what it’s like to migrate from 1 to 2 now.
John: Yeah. I’m being tongue and cheek. Tell me, what are the easy things? What are the things I have to do? Where are the gotchas?
Joe: There are some pretty heavy gotchas to begin with. What is really cool about this whole NG migrate, or NG upgrade, upgrade adaptor and how this migration plan works is that it allows you to migrate a piece of time. We’re going to come back to that app living forever in Angular 1.0 and Angular 2.0 as we talk about this.
From a very high level, let’s talk about Angular 1.0. Angular 1.0 has quite a few different pieces. Controllers, directives, services, filters. Those are your four main pieces in Angular 1.0. We’ve now got this thing called a component in Angular 1.0. Really components is just syntactic for a directive. We’ve only mentioned four but really the one of those pieces of directives actually has three different kinds of directives. Structural directives which is like Engineer P and NGF. You really don’t write those yourself. It’s not our own code you need to migrate.
You’ve got component directives which are directives that are represented by an element. They have a template. They exist somewhere on the page. They have some display that it goes along with them. Then you got your decorative directives which are things like NG-click. You might write a few of those but mostly you’re going to write these component type directives. That’s why this new component function is so awesome in Angular 1.5. It just wraps all that up and makes it nice and neat.
You got component directives. For people that have done Angular 1.0, you’ll probably face a scenario where you’ve got to point where you aren’t sure if you wanted to do a sub controller, or top level controller, or a component directive. You really weren’t sure which, should I piece this page in the more directives, and more components, controllers, I’m not really sure.
Those two things, controllers and component directives, really serve the same purpose. Their analogous piece in Angular 2.0 is the component. Services have an analogous piece in Angular 2.0 which is services. You’ve got the decorative directives in Angular 1.0. They have an analogous piece in Angular 2.0 which are called directives. Filters have their analogous piece which is pipes. Of those things, there are some of them that you can now with NG upgrade share between your Angular 1.0 and Angular 2.0 app at the same time.
Let’s talk about the simplest case which is services. If you go in and do the steps that allow you to start using this NG upgrade so that you are in the migration path, you’re now running Angular 2.0 and Angular 1.0 side by side. You can take one of your Angular 1.0 services, you’ve not touched any of your code really yet other than saying, “I now want to run the two together.”
You got this Angular 1.0 service that can now service that can now handle components on both sides. It can be inside a controller in Angular 1.0 and inside a component in Angular 2.0.
You can do the same thing with component directives in Angular 1.0. You could tell that component directive, “I want you to be available to Angular 2.0 so I could have an Angular 2.0 component.” Let’s say that you have this Angular 1.0 component called user info. It’s represented by the element user/info. You say, “I want to upgrade you.” You’re not rewriting at Angular 2.0, you’re leaving it alone in Angular 1.0. You just let the framework know that it’s now available to Angular 2.0. If you have this Angular 2.0 template, somewhere in there has its own tag user/info, it’s really calling into Angular 1.0. That part of the DOM is going to be owned by Angular 1.0 where the parent part will be own by Angular 2.0.
You now have these Angular 1.0 pieces that are now available to Angular 2.0. You can do the same exact thing backwards. You can write an Angular 2.0 component and make it available as an Angular 1.0 component directive. If you take that same user/info and you completely rewrite it in Angular 2.0, all of your Angular 1.0 pieces that still refer to that directive can still refer to it. You have to change them very little, make some small syntactic changes to how they talk, how they call to it past data in.
The same thing with services is if you write a new Angular 2.0 service, you can make that service available to all your Angular 1.0 services, and controllers, and component directives. Just make it available in Angular 1.0 service.
It makes this very nice smooth piece. Imagine you’ve got this application that’s got 200 pieces between controllers, component directives, services. You could slowly one piece at a time take it and migrate that one piece from Angular 1.0 to Angular 2.0. You downgrade it so it’s still available in Angular 1.0. You slowly move that as you go farther and farther. Now you’ve got 180 of them, then most pieces don’t even need to be downgraded anymore, because those 20 pieces that are left over only use a few of the new pieces. Pretty soon, you’ve migrated them all over, you’re not downgrading anything, you can finally just turn Angular 1.0 off.
It’s very smooth. It’s really awesome but the actual technical path work. It’s really great. There’s a couple of bumps in there. One is the decorative directives, they cannot be shared. You have to completely rewrite them. Same thing with filters. Filters and pipes, they can’t share the same code bases. You gotta keep those in parallel. Generally you write very few of those things in an application. Having two of them simultaneously side by side is probably going to be a fairly small issue.
Ward: Yeah. With filters and pipes, there’s almost stuffing in those things if they’re done with it anyway.
Joe: Generally, yeah. I can imagine somebody throwing together some pretty complex crazy ones. In most cases, they’re just going to be simple there could be easy to rewrite.
Ward: Yeah, it’s the directives that are going to do you. The directives that manipulate the DOM directly, which is a typical thing to do in Angular 1.0. That is the tarpit, don’t you think?
John: Or controller bloat too, or any bloat. How many apps have we seen in Angular 1.0 where we all talk about styles and patterns, where you just say just have a couple of functions and keep things light in separation. When you open up a real app, sometimes you have a controller, services, got 2000 lines in it. It’s doing eight things at once. Those are the things that scare me. It has nothing to do with migration, it has to do with oh my gosh, how do I unravel this.
Ward: Yeah. That’s the let’s push the reset button on this project anyway.
Joe: Yup. That makes you definitely want to push that reset button a lot more when you go to places like that. Those will be really hard to move over, those big balls of mud. They’ll get really hard to move over.
There’s a few gotchas in there. There’s also some gotchas that I’ve definitely seen. They’re going to be really common.
Angular 2.0 uses observables and Angular 1.0 uses promises. The tour of heroes, examples that’s up on Angular 2.0 website, the little walk through. It actually turns all its observable into promises, just mostly uses them as promises. Just quickly turns them into promises and use them that way.
You could do that but you’re missing out on potentially some functionality of observables. That can be a little bit of a challenge in dealing with the friction, that disparity between observables and promises. You think well observables have this two promise method that just simplifies everything. When you really get right down into it, it’s just not quite that simple. There are definitely real world use cases where you start scratching your head a little bit and you happen to figure things out. Especially when you got a service that is uses all promises, your typical service that wraps your HTTP calls. It’s using all promises and it’s Angular 1.0. You make a call on Angular 2.0, that’s okay. Angular 2.0 can use those promises.
You migrate over to Angular 2.0. What you do, you have to rewrite it using the new Angular 2.0 HTTP which returns observable. You just turn it back into a promise, or do you leave it ash an observable which case you have to go to all your Angular 2.0 pieces which were now using promises because they were talking to Angular 1.0 code and rewrite them so they’re not using observables.
Ward: I have an instinctive answer to that.
Joe: Go ahead.
Ward: My instinctive answer if you leave at its promises because since you haven’t structured the rest of your code to take advantage of observables, there’s no advantages to it. What you maybe saying is that there are opportunities to go beyond refactoring to achieve the goal of going to Angular 2.0. There maybe opportunities that you’re missing, that observables afford then you want to rethink the way user interactions goes, which is a completely different statement. Unless you’re investigating that, if you’re just trying to get there, I can’t see a reason not to go to promises, can you?
Joe: I think that the thing with promises is definitely very valuable. I can certainly think of some reasons to go to observables but the most common case is HTTP. HTTP with very few exceptions returns one results. Promises are just fine.
When I’m writing Angular 2.0 and I start using promises, I feel like I’m missing in the boat, or downgrading myself a little bit. I feel a little odd when I’m doing it. No, I mean it’s a compelling reason to just stay with promises.
John: Joe, if I’m migrating, stick with the mindset and persona we’re talking about. If I’m in the migration mode, I’m already thinking about my first goal to just not break anything that’s already there and extend the functionality. In that sense, maybe, I’m not doing this for now, I don’t really know, but if I wanted to do that maybe I probably wouldn’t want to be involved in learning, and adding something new, and just want to really keep what I’ve got. I can see the point of if I’m doing this, maybe stick with promises on Angular 2.0 just for the short term of it until I get the migration moving. If I want to dabble in the RX pool, because I see value there, absolutely go for it. I don’t know if I’d go wholesale RX for migrations because neither doing two things at once.
Joe: I definitely agree with that. Focus on just staying with promises. Keep an eye open for when observables but know that there’s this mismatch between Angular 1.0 and 2.0. The more you do dabble with observables while you’re on the migration process, the more it will come to back to bite you.
You have to at least for a little bit because the Angular 2.0 HTTP we’re tying this observables so you got at least quickly turn it into a promise.
Ward: Which is easy. If I sum it up, I say let’s do one miracle at a time.
Joe: That’s one of the big gotchas. The other big gotcha is routing. As of right now, I really hope that this changes, but I’m not 100% sure that it will. As of right now, you are stuck using the Angular 1.0 router so long as you have your application in both modes with Angular 1.0 and Angular 2.0.
When you finally get all of your code moved over to Angular 2.0, ready to turn Angular 1.0 off, you have to take this big giant step. Up until that point, the steps are actually as small as at least the code that you’ve written, as small as you can make them. If you got a 2000 line controller, migrating that form Angular 1.0 to 2.0 when it’s time is going to be hard. That’s going to be a big step. That’s going to be fought with oh, we broke something. That’s the developers fault.
Up until that, the framework and the tools that are in place allow you to take the smallest steps that you yourself can take based on the size of your code. At the end, you got everything moved over, you’ll still have all of your routes in Angular 1.0 and you now want to switch them over to Angular 2.0’s routing. That is going to be a case where you’ve got to turn the whole application essentially off. You gotta make it so that it no longer works at all with Angular 1.0. You rewrite the routing in Angular 2.0 which is not a simple straight forward thing because of how, if you you’re using a lot of guards, the resolve method in your Angular 1.0 routing, you got to do similar things in Angular 2.0. They’re very different.
You got to redo all of that stuff and then you can finally turn the Angular 2.0 back on. That’s going to be a big step. That one’s going to be fought with something’s broken and I’m not really sure what.
John: Joe, are you saying that you can’t keep Angular 1.0 routing in Angular 2.0 routing living in the same application as of today?
John: Okay. Just making sure.
Joe: Yeah, as of today you cannot do that. All the routing has to be Angular 1.0. That may change. I really hope that it does because it will make this whole thing easier. As of right now all the routing has to be have by the Angular 1.0 router, or the UI router, if you’re using the UI router.
Ward: Let me pile on because with some real experience or at least I think relevant experience. There was at one time a now known as the deprecated router, it was a completely different router than the Angular 2.0 router in one of our applications. We have the same sizable one we’re talking about. We had to move it from the deprecated router than new router which is essentially the process you’re describing. Essentially, you throw out the old routing all together and bring in the new for an existing application of many 100 pages. I don’t remember how many routes but it could have been a 100 routes for all I know.
That was not fun. That was a week of effort. Even if they make it possible to run the Angular 2.0 router over the Angular 1.0 world, I don’t see how that’s going to relieve you of this exercise. You’re going to have to go through it at some point because you certainly don’t want two router systems. Are you suggesting that holding that hope there be some way to keep both the routers in the same applications for a period of time?
Joe: Yes. That would be my hope. If that’s become possible. I don’t obviously like other things, it’s not ideal. If you could migrate one route at a time and then check, make sure the app still works, test it, that we didn’t break anything, then migrate the next route to the new router. When you’re all done, now you got nothing left in Angular 1.0 anymore. That would be maybe your last piece. Or maybe you do that as you’re going along. I think that would be very ideal.
Ward: I would not hold my breath for that one.
Joe: I’m not, I’m not. I heard some whisper somewhere that that was something that they were going to look at. We actually talked about this last week.
John: We’re talking about migration.
Ward: I thought I was here.
Lukas: Or sorry, that was the announcement episode.
Ward: Right, I thought what I heard there, we tear what we want to hear.
Ward: What I heard was that it was a question about whether you could use the new router in an Angular 1.0 app so that you could decide to use the exact same syntax and style of routing and the whole modalities that are in the new router in your Angular 1.0 app. That’s what I had heard, that’s what I thought I’d heard Peter, Beck and Darwin before but I could be wrong. It never occurred to me as it occurred to you because you’re in the trenches that there would be some way to have both routers intersect in some useful way.
Joe: I was definitely reading between some lines. Jules did say in our announcement episode on Angular 2.0. Jules said that the upgrade adapter, NG upgrade was something that they were going to be looking at doing more to. For me, if they’re going to do anything, that would be the thing to do.
Ward: That would be an amazing back bending gymnastics.
Joe: Yes, I imagine. But to their credit.
John: I want to see Joe in more using gymnastics that he could do.
Ward: It’s not pretty.
Joe: What they built with the upgrade adapter is an amazing backbend of gymnastics. I’m just completely amazed that they can make these Angular 1.0 services work in Angular 2.0 and vice versa. I think that’s amazing. What they did is genius.
The original plan for migration long ago was you would migrate a route at a time. People quickly realized that was going to be hard because any given route might use a service that’s used by 35 other routes. You migrate that one route, all of a sudden you got to write that service in Angular 2.0. Everything within a specific route would be either Angular 1.0 or Angular 2.0.
If you have a service that’s used by all of your pages, you have to have that service in both places. You have to maintain both sets of code. Pretty soon, you’ve got 50 services that are all maintained by both sets of code and 50 different subcomponents, that user info panel that you use on 80% of your site. That’s now got to exist in Angular 1.0 and Angular 2.0 simultaneously. All its bug fixed, all of upgrades of feature, that was horrible. What they’ve got today is awesome. This ability to I got the service. I don’t want to move it over to Angular 2.0 yet, great. I’ll just mark it as upgradable now Angular 2.0 can still use it but I don’t have to rewrite it.
That would bring me to that whole point about apps that could live theoretically forever with Angular 1.0 and Angular 2.0. Again, this is the pessimist in me. I think it’s very realistic. There are companies out there who are going to say, imagine this, you’re a developer at a corporation, you have the opportunity to say, “Look, we’ve got this Angular 1.0 app, Angular 2.0’s been out now for two years, or three years, whatever it is. Our Angular 1.0 app is still going, it’s still working fine. But we’re still upgrading it, and migrating it, and we’re having a little bit of difficulty maybe finding developers who want to use it, whatever.” You propose, “Let’s run the migration process so that it works with Angular 2.0. Let’s just do new features in Angular 2.0 and evolve the existing Angular 1.0 features as one.”
We have no plan to go back and rewrite 100% of our features. We’re just going to do new features in Angular 2.0. It’ll make some people happy, it’ll let us use more modern tools and techniques. Management buys off on it because the overhead of that is extremely low. Now, you have this application that lives forever in Angular 1.0 and Angular 2.0. I think that’s very realistic.
Or another scenario, where you’ve got an application that you start migrating, hoping that you’re going to migrate it fully to Angular 2.0 and the resources just run out. It just turns out that it’s taking too long, there’s business priorities change. It’s like we can’t go back and rewrite everything. There’s pieces that just aren’t important enough for us to rewrite so you move on.
I think that’s a very realistic scenario. In fact, I know a very large company, very prominent company that has a huge Angular 1.0 application that still has about 20% of its code written back bone.
Ward: There’s no question that it will happen, Joe.
John: Joe, I want to expand of one of your scenarios because that segregates you. I know something about large Angular 1.0 applications. Let’s say I’ve got one, two, or many super large Angular 1.0 applications in production on public websites, doing business. Let’s say I run, let’s buy wardbellsclothes.com. That’s a massively popular website. It’s operating in Angular 1.0 and it’s really attracted me as a business owner and developer to say, “I just want to leave my Angular 1.0 investment alone, but continue to expand by adding new features to this web app in Angular 2.0.”
Let’s say that that works out and I get around to routing as you mentioned, I still use Angular 1.0 routing. Do I need two different build processes then? How do I deploy these things? Still keep the existing app deployed the way I’m doing with my regular devops process, then now have a new build that deploys Angular 2.0 app, or do I have to shimmy my Angular 2.0 build into the deployment of the Angular 1.0 app?
Joe: I would assume you’d send me the bolt together. Builds are so funny. I’m not talking just like, “Hey, you got web pack.” I’m talking like a real big complex production build for a big app. It’s far greater than I just have web pack in there. So much bigger than that.
John: Most people don’t have web pack for existing apps too. That’s relatively new. We’re talking about our MPM over the crazy stuff.
Joe: I think that most people will find that it’s best to just take existing build process and incorporate the Angular 2.0 part into it. Very early on, you turn your Angular 2.0 code in the ES5 code. It just goes down the same funnel at that point as your Angular 1.0 code does.
In fact, I believe it’s very advantageous to go through and turn all your Angular 1.0 code into TypeScript really quick. Make that a big part of your build process.
John: What about module loading there in that case? If I take my Angular 2.0 code and turn it into ES5, I’m not using module letters today, how do I do that?
Joe: When it comes turn in ES5, the modules are written into it. The system, I’ve been using system.JS. Its code is already included as part of that deployment so that it handles all the module loading for you.
John: Okay, you’re saying turn to ES5 and include system.JS so it helps you into the moduling. Gotcha.
Joe: Yeah. That’s been my experience.
Ward: Hey Joe, as a practical matter. What is the role of testing in a migration? Would you do end to end testing? What would you do so that you can have confidence that as you were moving forward to your app that still works?
Joe: Obviously whether it’s Angular 2.0 or Angular 1.0, you can still unit test each piece. Unit testing necessarily is quite a bit different between the two. As you migrate code to Angular 2.0, if you’re already been unit testing your code, you’ll want unit testing your code. You have to learn how to unit test with Angular 2.0 and incorporate that into your process as well.
The end to end testing I think is great. I think that most companies, let’s deal with the realistic scenario. Your existing company, you bought an existing product, whatever you’re doing to it now, you’re probably not going to fundamentally change that because you added Angular 2.0. It’s not.
Hopefully it would be nice if you could use Angular 2.0 as an excuse to say, “Okay, now we got Angular 2.0, we’re going to start unit testing everything and start end to end testing everything.” That would be great if that’s what you got to do.
Ward: I think that you don’t have to swallow, that’s a big thing to swallow. I’m going to suggest that what people consider doing, because it’s really easy to set a protractor test. I hope we’re going to have some documentation on that two different feature. That’s end to end test, you just start by having some smoke test at the point where you’re doing the migration. You don’t have to have a full comfort chair.
We’re just talking about something that make sure you haven’t fallen off a cliff. I could start with three, four, five tests. Before you know it, you add another one. You got something that helps build your confidence and build the company’s confidence as you do it. You focus those tests not on the whole thing but on the thing that you’re changing.
You make it part of your road map. Forgetting for taking over a portion of the old Angular 1.0. You say, “Why am I mad?” I’m going to build it right into the schedule. I’m going add four, five smoke tests in end to end testing which therefore doesn’t matter what technology you’ve got, whether it’s Angular 1.0 or Angular 2.0. Just to make sure that the before and after line up. I think that that should be part of your plan.
Joe: I agree with that. Absolutely. In reality, if you aren’t doing that already, you should be doing that regardless if you’re migrating or not. The migration is a great time and reason to do that if you haven’t been doing end to end testing already. Throw that in because like you said, because you’re a huge piece of confidence just know. I just migrated the, because the apps still works.
Ward: I’m going to tell you this is a time saver. The alternative is having somebody, and I’ve been watching this, somebody go back, and they are afraid to touch anything because then they have to test it again. They do and they got somebody sitting there playing like a typing monkey, a user monkey, clacking away on the keys. I think that it quickly repays itself to have just simply not unit test something, I’m talking that just simple end to end test to validate that you’re not falling apart.
Joe: Absolutely, absolutely. No doubt about it. When I was migrating the code base that I migrated, I had used the end to end test. I have some unit test but there are mostly for show, just to show like, “Hey, what’s it like to have a unit test. Have to change it as we change the code and eventually migrate it to Angular 2.0.” I didn’t have a big suite of test. It was a pain. Every time I changed something, I went back and manually tested it. Hopefully, I manually testing all the pieces that it touched because I don’t want too many test the entire application. It’s a huge pain.
I’ve been doing a lot of this work lately in preparation for a Plural Sight course that I’m putting out on migration specifically. Half of it’s out, the part where you prepare your code for Angular 2.0, your Angular 1.0 code you prepare it for Angular 2.0. The other half where you actually do the migration will be out in a couple of months probably.
Ward: I hope you have a module. I hope you have a module on this if you can squeeze it.
Joe: Yeah. Absolutely. I definitely will be including something like that. Almost for sure, I’ll include something like that. It is a great time to put in that sort of thing. Put in some end to end test, absolutely.
I wanted to just remind we’re talking about the course that I’m doing. I’ve got several hours just on preparing your code for Angular 2.0. There’s a lot that could be done to your Angular 1.0 app to prepare it for Angular 2.0 in a realistic way. I think there’s a lot of blog posts out there about—this is the time I want to get back to Lukas’ point really quick because we’re about to end. About writing Angular 1.0 and Angular 2.0 form and being able to transfer them over. I’ve done some migrations and seen what kind of changes actually help. I’ve seen people write blog posts about changes that I don’t think help. I want to talk about that really quickly as our final point.
Lukas: Hit me. Tell me everything.
Joe: You said, you don’t think that they’re very far apart once you get your Angular 1.0 code. I would disagree with that because I think that the fundamental underlying things with how detection works. I still hadn’t mentioned there’s of you mentioned this, when you do run Angular 1.0 and Angular 2.0 side by side, the change detection is actually integrated. If change detection happens on one side, it will fire the change detection on the other as well, and back and forth with some potential either bugs or exceptions that I’ve seen a couple places where that’s not happened but the changes detections happens.
I think that there’s still some real big fundamental core differences that anything beyond a very simple straight forward application. Yeah, you converted to an ES6 class, you can convert services to classes, and you can convert components directives to classes. You could do that and make it look a lot better so that when you do migrate it, in some cases you don’t have to do a lot of rewrite. I think the real complex, real business apps, we’re going to find that they’re just really far away. We do migrate them to Angular 2.0. There’s going to be a fair amount of stuff we’re going to have to rewrite in order to make it work in Angular 2.0.
I feel they’re farther part that what you seem to imply. I’m interested to hear your counterpoint on that, Lukas.
Lukas: Just to be clear, when you talk about Angular 1.0 and Angular 2.0 living together, that isn’t what I was referring to. I was thinking more in terms of like the shapes of the Angulars. I think you get a lot closer, I think once you are a lot closer, it’s a lot easier to say that, “Okay, we just went from one to the other.” Again, I think this is, we’re trying to basically take a really nuance complex topic and cram it into an hour. I think it really depends on a lot of things and how your app is segmented.
I would say first and foremost is I think people have this misconception that Angular 1.0 and Angular 2.0 are night and day different. I think because underlying change detection, I think yes, I think that does make the fabric a little bit different. From a high level from the shapes, that if you write Angular how we did three years ago, yes that’s significantly different. But when you’re writing modern Angular 1.0 using a part of different architecture, they’re very, very close. I’m hoping and I believe that you’re going to start to see those lines start to blur to where it becomes easier and easier to blend those together.
Joe: Well, it’s certainly been my experience that if you do take these steps where you write Angular 1.0 using TypeScript and ES6 classes, which I talk again about in my course and show exactly how to do this. There’s certainly a plenty of blog post that will talk about this as well. That definitely helps.
The moment you finally take an Angular 1.0 service or component and move it over to Angular 2.0, you’ll end up doing a lot more work than you would hope to. My guess is no matter how much stuff they back port into Angular 1.0 that would be true. Maybe I could be wrong. It’ll be interesting if we start seeing RXJS become a first class member of Angular 1.0. That could really start to make things different as well.
Lukas: Even a router that just worked seamlessly between the two where you can segment a route, that would be a big one.
Joe: Yup, that would be a big one too.
Lukas: Just a thought.
Joe: Yeah, just a thought. Alright, well I think we’re out of time, right Chuck?
Charles: I was going to say, I’m going to be that guy.
Joe: Be that guy. You don’t have to go home but you can’t stay here.
Charles: That’s right. Yeah, let’s go ahead and do some picks. Lukas, do you want to start off with picks?
Lukas: Yes. A show that I recently watched. I was just looking around Amazon Prime and I saw this new show called Eat the World by Emeril Lagasse. It absolutely blew my mind. Out of all the picks I’ve done over the entire 100 plus episodes, this is probably one of my favorite picks, ever.
The reason being is if you were to go watch this having a developer mindset and knowing the community around the development community, there is such a profound parallel between the experiences that Emeril has with these different chefs around the world, how he’s affected people’s lives and their careers, and just the camaraderie. It was really interesting for me to see this dynamic being part of a very vibrant and welcoming community that’s really done a lot for my career. That’s allowed me to serve them.
I thought it was just really interesting to see this dynamic that we are really familiar with in the context of food. Emeril travels around the world, spends time with his friends, is helping people promoting them and mentoring them. Phenomenal series, it’s like six episodes and I’m madly in love with it.
Charles: Cool. Ward, what are your picks?
Ward: I’m sorry that I threw a blank. Although I’m really intrigued by the Emeril thing. I have long said that if you like to cook, then you can like to program. I’m looking forward to give that series a try.
Charles: Right, Ward what are your picks? Oh no, not Ward.
Ward: You just gotta keep asking until I have some.
Charles: That’s right. Joe, what are your picks?
Joe: Obviously I want to mention again my course on Plural Sight which talks a lot, in depth, in huge depth about all of the steps that we talked through. It goes walks through migrating. A very realistic, this is actually production code application that I built. Migrating it from Angular 1.0 to Angular 2.0. The first half is out where it talks about bringing your code. The second half will be out probably by the end of October and November, something like that. I want to mention that.
As far as fun, I want to talk about this awesome movie about space travel. It is an amazing, amazing movie. Everybody should go out and see it. The Last Starfighter. I was over the store and I saw this Blu-ray of The Last Starfighter. One of the very first films to incorporate any CGI at all.
Ward: That was decades ago, wasn’t it?
Joe: It was decades, yeah. I don’t remember when in the 80s it was made but it was a long time ago. Great show. I’m going to force my children to watch it with me. I just have all this fond memories. I’m sure it’s going to end up being terrible.
Lukas: She’s got 80s hair.
Joe: Yeah. It’s got totally 80s hair, the main girl on it. I’m so excited about this kid that plays video games, he’s so good at it. It turns out the video games are recruitment tactic for this elite unit of starship fighter squadrons. They get this kid from Earth and he joins up this starship fighter squadron in space because he’s so good at the video game. Every kids’ dream, come on. I’m excited to watch with my kids. I remember it being great so I’m going to recommend it based on my recollection from 20 years ago.
Lukas: If you haven’t seen the movie, you can read the book, it’s called Armada.
Joe: I wish I could pick Armada but I got a little bit into Armada and I was just not impressed. It was nowhere near good as good as pretty Player One.
Lukas: We got a lot of heat for that.
Ward: I’m going to have tell you then the best of this list is Galaxy Quest which is
Joe: Yes, absolutely. Absolutely love Galaxy Quest. Maybe you do one of those for Star Wars, huh Ward?
Charles: Alright. I would go ahead and throw a couple of picks. I’ve been listening to this book series that I can mention it before. The books are by Terry Brooks. It’s the Shannara books. It turns out that MTV made a TV series on it which is fun. I’ve been watching those and I have to say the books are way, way, way, better. It’s fun to just watch and see some of these characters there even though they’re nothing like the characters in the book and the plots, pretty different. Anyway, it’s been fun. I’ve been enjoying that.
I’m also going to pick a new tool that I’ve been using, I’ve been using it over the last few days. I’m actually using it for Angular Remote Conf, it’s called Webinar Jam Studio. It is webinar softwares built around Google hangouts. The reason that I switched because I was using CrowdCast before. The primary reason was that I wanted HD video. CrowdCast has their own proprietary thing that just doesn’t give you HD video. I want to be able to provide that to people during and after the fact. I’m also doing a series of webinars. I want people to be able to get the webinars in HD. We used it for the Freelancer Show Q&A this morning.
I’m going to be doing a webinar tomorrow. As we record this, it would’ve been last week. You can get the recording. I’ll make sure everything redirects properly. It’s Five Mistakes That Are Keeping You From Getting Hired. Yeah, I’m just discussing what you need to do to make your job search that much more effective.
I have a series of webinars that I’m putting on for the rest of the year. We’re talking about apprenticeship programs, and using meetup groups forums, email lists, how to build and write your resume, how to do job interviews, how to become a corporate insiders so you can get hired, podcasting and blogging, building your portfolio, all of these stuff, open source, salary negation. If you’re interested in any of that, just go check out The Five Mistakes webinar. I’ll put a link that in show notes. That’ll show you where you can go to get access to everything else.
I’m also writing a book, it’s called Get a Coder Job. A lot of this material comes out of that. Anyway, definitely go check those out. Also go check out the videos from Angular Remote Conf.
Joe, are you doing some kind workshop that you want to promote while we’re doing this?
Joe: Yeah, kind of. I’m doing a little free workshop down in Fort Lauderdale. Just a half day workshop on migrating so go way in the depth from the stuff we talked about today. Actually get to some nitty-gritty and bones. It’s absolutely free.
Right now, not 100% sure for the whole week because I just haven’t see if there’s enough interest. By the time this records, I probably will have decided whether I’m going to hold it or what. You can go down there and check it out.
Go to ng-learn.com. You can pick up a free ticket if you can make it down the Fort Lauderdale. Saturday, the 8th of October. If the tickets are there on ng-learn.com by the time this comes out, then you’ll know that I’m actually having the workshop, if not, I’m not having it, I’m sorry. Maybe next time. There you go. That’s it.
Charles: Alright. Let’s go ahead and wrap up the show. Thank you everyone for coming and we’ll catch you all next week.