JOE:
Hola!
SHAI:
Como Estas?
KATYA:
[Chuckles]
JOE:
Muy Bien!
SHAI:
Ah, este, Joe Eames! Ho, Ho Eames.
JOE:
[Laughs] It's Jose!
SHAI:
Jose.
JOE:
Ho, with extra H, with extra Ho.
[This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco and New York and LA get on JavaScript developers providing to put the salary and equity upfront. The average JavaScript developer gets an average of 5-15 introductory offers and an average salary of over $130,000 a year. You just can either accept an offer and go right into interviewing with the company and neither with that any continuing obligations. It's totally free for users, and when you're hired, they'll also give you a $2,000 signing bonus as a "Thank You" for using them. But if you use the Adventures in Angular link, you'll get a $4,000 bonus instead. Finally, if you're not looking for a job but know someone who is, you can refer them to Hired to get a $1,337 bonus if they accept the job. Go sign up at Hired.com/AdventuresinAngular.]
[Does your team need to master AngularJS? Oasis Digital offers Angular Boot Camp, a three-day, in-person workshop class for individuals or teams. Bring us to your site or send developers to ours -AngularBootCamp.com.]
[This episode is sponsored by Wijmo 5, a brand new generation of JavaScript Controls. A pretty amazing line of HTML5 and JavaScript products for enterprise application development. Wijmo 5 leverages ECMAScript 5 and each control ships with AngularJS directives. Check out the faster, lighter and more mobile Wijmo 5.]
[This episode is sponsored by Digital Ocean. Digital Ocean is the provider I use to host all of my creations. All the shows are hosted there, along with any other projects I come up with. Their user interface is simple and easy to use. Their support is excellent. And their VPSes are backed on solid-state drives and are fast and responsive. Check them out at DigitalOcean.com. If you use the code “angularadventures” you'll get a $10 credit!]
JOE:
Hello everybody! Welcome to Adventures in Angular podcast Episode number 46. Today on our panel, we have Lukas Reubbelke.
LUKAS:
Hello!
JOE:
And, Katya Eames.
KATYA:
Hello!
JOE:
I'm your host, Joe Eames. We have a very, very garishly dressed special guest...
LUKAS:
I thought he was going to say handsome...
JOE:
[Laughs]
LUKAS:
Like garishly handsome...
KATYA:
[Laughs]
JOE:
Garishly handsome guest, Shai Reznik.
SHAI:
Hi guys! Hello again! I didn't know I need to be dressed up for this occasion so I'm currently sitting like without... No! It's all family episode so I won't say it. So, hello!
LUKAS:
[Incomprehensible]
JOE:
[Laughs] Yeah.
SHAI: [Laughs]
JOE:
Shai, you may already not know from his ng-wat talk @ ng-conf 2015, which was an amazing talk. If you haven't seen that, I had to recommend that you go and see it. And today, we're going to be talking about Preparing for Angular 2.
LUKAS:
Yeah. Amazing!
JOE:
So, let's get started. First off, Shai, we’ve got to talk about a little bit about Angular 2 and stuff that you've done with it and then let's start talking about how people can get prepared for when it comes out.
SHAI:
Coolness! So for those of you didn't listen to the last episode I was on, I'm Shai Reznik. I run online training school called HiRez.io. The first video I did as a short tutorial part of a course was "How To Prepare Your Code To An Angular 2.0". This was meant to be a free course or this was the plan, and it will be a free course under the HiRez.io website. Part of it will be on YouTube and then the other part would be on the website but it will be free.
I got to Angular 2.0 like everyone else starting in with the ng-europe announcement where we found out that Angular 1.0 is going to be killed.
JOE:
Violently!
SHAI:
Violently. That's around the time that I got curious about Angular 2.0 and I knew that they were trying to have a joke with it, and it didn't go so well. We learned since then that it's not going to be dead, it's going to have migration path from 1.X to 2.0. And I work as a consultant with a few enterprise companies building large-scale applications. My first goal was to understand how can we leverage our current Angular 1.X code and prepare it for the future so the migration process to Angular 2.0 will be as, I don't know, less painful as possible if I can phrase it like that.
JOE:
Let's talk about that "painful, less painful as possible". Obviously, it could be more painful, but it's not going to be as simple as just flipping the libraries from Angular 1 to Angular 2.
SHAI:
Yeah, but it never is from any breaking changes to a version to another. It's never like flipping a switch, but there are stuff that you can do. Nobody can predict the future; stuff are changing constantly every hour these days in Angular 2. But, you have some solid principles that, I think, are here to stay because they're mainly based on ECMAScript 6, which is pretty solid and will be the future and will be how we are going to code in the future.
JOE:
Let me jump in here, Shai, and just ask you personally. What do you feel about the radical change coming in Angular 2 that it's not just a very small iteration on Angular 1, but actually a completely non-backwards compatible change. What do you think of that?
SHAI:
I think it's an inevitable step. Why? Because, as I said before about ECMAScript 6, if you look towards the future, our code will change, will have different APIs. And the smart thing, I think, that the Angular team did is to align themselves to the future and not try to diverse from it. So, I think a lot of the radical changes that we see are the Angular team's efforts to try and stick as much as they can to the ECMAScript 6 spec. People are complaining because every change, I think, people will complain about and I don't think that a lot of people, at least that I'm talking with, really dig in and read the why and hows behind the whole Angular 2 thing. But, I think it's not if you compare it to ECMAScript 6 like Syntax; the stuff they are adding is stuff that you want to see in ECMAScript
7. I think that historically, this was the thing with Angular. Misko and Igor, when they first started working on it, I think Misko started and Igor joined him, they always said from the start that they want to build the future JavaScript that we can all use right now.
JOE:
Future framework, you mean.
SHAI:
Yeah, future framework and the future APIs that we could use in the next version of JavaScript. If HTML 5 or whatever you want to call it, I think they did it with Directives, if you look at it now, the web components and the Polymer and stuff, they did it before it was like official spec and what we are all going to use in the future.
So, I think they are doing the same thing with Angular 2, with Annotations, for example. They are aiming for -- I think that the Annotation is part of ECMAScript 7, if I'm not mistaken.
JOE:
Yes. Yeah, they're Decorators.
SHAI:
Decorators, yeah.
JOE:
There's actually a really interesting article I just read. I can't remember, I think it was Pavel who wrote it. He's talking about the difference between Annotations and Decorators. Annotations were basically an idea about the Angular team. And then they got together with Yehuda Katz who he had been doing some work on a similar idea, basically just a metadata that you can add to a class in JavaScript. And he had come back and said, "That's a good idea. What you're talking about is very specific. What if meet up more generic?" and so he came up with this Decorator proposal that's now an official proposal for ECMAScript 7, or is it JS 2016, is it what we're suppose to call it?
SHAI:
[Laughs] Yeah.
KATYA:
[Chuckles]
JOE:
So yeah, his idea -- sorry to cut you off -- his idea does what Annotations does and more, and it's kind of cool. It's that little article by Pavel, I'll put it into the show notes. It's a very good read if you're interested at all in that.
SHAI:
I feel like a prophet when I read this stuff because it's a glimpse to the future; how things will probably look at one year or two years. Nobody knows. They [incomprehensible] or living in changes so much so nobody can really tell what will be here, what we will write in 2 years, if there even will be a... I don't know... What will be the fashion in that time or the hottest new thing and stuff like that. But, the basic principles of Architecture and Web Developments or Programming in general are here to stay if you look towards the future.
I think, to make it less painful means that in terms of visualization if you look at your code, if you have a team of 20 developers that are used to writing their code in a certain way, when you introduce new concepts to them, it sound maybe silly, but I think it has a lot of power in it. If something maybe have a slightly different syntax but kind of look the same so you can put it side by side and tell the developers, "Look, this is that and this is that and this is that thing," and compare both of the code blocks, I think it makes it a lot more easier to get a better grasp of what is the new syntax is all about if it looks the same for starters. And then, you introduce the new concept and build like ladders on top of each other. I think, this is part of what I meant before about less painful migration path, and this is part of it.
Another part is building as much isomorphic JavaScript code. So trying to build your Controllers or Services as much as pure JavaScript or ECMAScript with as little as the framework bindings in it so you'll have Classes or Functions in the ECMAScript 5 that you can just Unit Test and have signal responsibilities and just plain JavaScript object to do one thing that you can later maybe change a little bit and make them work in future versions. I think this is also another part of making it less painful.
When I thought about my clients first and how can we -- I had clients with existing code base and I had clients with new projects that they just starting with Angular so they want to make it as future proof as possible. You don't have the silver bullet but you can try and make it as close as possible.
So, identify the few things that you can do in order to make it as close as possible to the future, in my perspective. I can share the outline or if you want to get into more specific stuff.
JOE:
I just want to backtrack a little tiny, you mentioned something about taking teams and lining up codes side by side and explaining this as this at that at that, they're reminding me down out at ngvegas Patrick Stapleton was part of a talk of all things creating D3 Components with Angular 2 and TypeScript. They actually did a very interesting thing where he brought up side by side code of Angular 2 and Angular 1 -- Angular 1 Directives and Angular 2 Components -- and kind of compared them and showed us somewhere that could be. I think it's a great talk and it was a great example of doing exactly that showing how quickly you can learn Angular 2 by comparing Angular like saying Angular 1, same concepts in Angular 1 that the concepts in Angular 2 and looking at the code side by side. Again, I'll throw that talk into the show notes.
SHAI:
That's a good question. I have [laughs]... I don't know if I told you this story before, but I have a funny story from, again, related to ng-europe announcements. Did I tell you this in the last episode? Or, no?
JOE:
I don't remember, but maybe you did.
SHAI:
No, I don't think so.
JOE:
Just tell it again. Everybody, whatever audience is listening, certainly some of them haven't heard of or sort of forget.
SHAI:
[Chuckles] No, it's okay. So I was sitting at home watching the ng-europe videos with a bag of Doritos on my belly like just turning the screen and feeling excited about watching, what's up with Angular. I was seeing the video and I was working, I think, with 4 clients simultaneously as a consultant at the time and I was watching the keynote and watching all the jokes about we're going to kill the Controllers, we're going to kill the $scope and stuff like that. I was like looking at the screen and my jaw dropped and I was like not thinking about it because I got the jokes, I thought it was cute, but I thought about my clients and how they are going to react to it because I imagine the reaction and the chain reaction afterwards. I was like getting a call from one of my clients and later on from the others. But one of the clients then, I was like grabbing my head and I was trying to explain and getting worried questions and I was like with the phone, "No, it's okay. No, no. Yeah, I know I told you to use Angular... No, you don't have," me explaining them like, "It was a joke, relax. No, please, don't go back to GWT, it's okay, you can still.." [Laughter]
SHAI:
"You can stick with Angular..." [chuckles] so I trained myself with answering this question afterwards when talking with new clients and guys from the JavaScript community here that were keep asking these questions. So I think that a lot of people are emotionally worried about this change simply because they don't invest the time into reading what these change is all about, and I understand why they don't invest the time because nobody have the time. We pick our ideas and our understandings from headlines, from blogs, from what people say. And all the bloggers' fear during that time was, "Oh my god! Angular is dead!" [laughs] "They're going to stop the support and they're going to kill everything!" I was getting this everytime and I'm trying to explain to people, "Listen, it's not dead. It's a good change or changing stuff that the hard part that are currently in Angular 1.X and they're making them better. If you will read what the changes are all about and what is the motivation for these changes, you will get it that it's okay, it's good, it's a good change." Only after I talk with people and explain them the changes and why they are so important and that they're not going to kill the current 1.X branch because it's the most popular framework currently of web development, you have a lot of big companies are relying on this framework and the support so they're not stupid. They're going to keep supporting it because they don't want to burn themselves in the JavaScript community. If they're going to pull the plug one day on everyone, that will cause a lot of damage and they know it and they know their responsibility. So I did the parody movie about it. You guys see this one? I called it a very, very short introduction to Angular 2.0, and it was my answer to all of the worried question that I got. I'll put a link so you guys can see it. I think it's a good parody, but I'm not very projective.
JOE:
Shai, I'd like to jump into kind of like the "meat" of getting ready for Angular 2 and the things that people should be doing with their code right now. Can we start talking about that? [Laughter]
JOE:
We should end it now.
SHAI:
Yeah, let's end it now. Okay, I'll start it by outlining what I think are the key parts that you can start doing and if you have any question, if you want to zoom in on part of the stuff, let me know.
The first thing you can do talk in the beginning of this episode is to try and write your code as similar as possible to the future code. This was my first episode that I did talking about only this comparison between 1.0 code and 2.0 code and ECMAScript 6. This is the first thing you can do. In order to do it, there's a bunch of stuff you can actually start using right now and most of them are in John Papa's Style Guide. And John Papa... Lukas, John is here now, right? You do a good impression of John.
LUKAS:
It's me John Papa!
SHAI:
Hi, John! I like your Style Guide [laughs].
LUKAS:
Graci! [Laughter]
JOE:
John's also a plumber. [Laughters]
JOE:
Part time plumber.
SHAI:
[Laughs] So yeah, a lot of stuff are in this Style Guide. First of all, using the IIFE, the Immediate Invoked Function Expression to wrap your files and use the $inject annotation to simulate the Annotations you will have in the future. All of these stuff helps us minimize or reducing our indentation level. As you can see from examples of ECMAScript 6, you see very flat code structure, classes, and everything is pretty flat. If we'll look at ECMAScript 5 code, we usually have this pyramids of doom that everything is nested especially with the array notation in the Angular components when we want to inject stuff. This is one thing you can do right now to flatten your code structure. My next video is going to talk about how to do it.
Another thing you can do is stop using $scope. Only if you really, really need it like if you want to add a manual $watch expression, you can use it, but stop using it. And the way to stop using it is to start using the Controller as syntax so you make your Controller your actual binding object and not the $scope. In that way, you can bind directly on your Controller object. That way you get also a code that's much similar to the future because in the future, we won't have $scope. In Angular 2.0, we won't have $scope. There are other benefits of not using $scope especially for beginning developers that don't really know it that well yet and the implications of what $apply does in the Digest Cycle and stuff like that and can really hurt the performance of the application if they misuse the methods on this object, on the $scope object. So it's another thing. Because usually, people copy and paste solution from Stack Overflow and they don't really know the implications of copying and pasting. So this is not a reason to only use $scope when you need it.
Another thing people can do in terms of Directives is start building your application, your Templates, start breaking them into what I call "Sections". In Angular or in the future in general, we'll have Components, Web Components. We're starting to see now with Polymer and React, Angular 2 also will have Components. It's like Directives, but which had a dome and all this greatness. But now, with some simple flags that we have bind to Controller and stuff like that, we can simulate not 1 to 1, but we can trans-simulate how things will look like. So in terms of our Templates, I can bet that most of the Templates right now, 1.X code which is I think 100% of the production applications now, you will find their long Templates with a lot of DIVs and HTML and stuff like that, like really, really long Templates. For a long time, I was also trying to figure out how to make Templates less suck in terms of lines of code and the complexity they have and I try to solve it with solutions like the UI-Router where you can have like nested UIViews to implement your state machine and bind your Controller to the View, which Controller to which Template. For a long time, I was using that. And once I realized that the future is going to be Templates that are pretty much build out of Components. So instead of DIV and Section and stuff like that, we will have the Menu and the Product View, and all these DSL (Domain Specific Language) that describes our Components in our application, I realized that it hit me like, yeah, it's like Clean Code! You guys know Clean Code, the book? It talks about when your Function gets long, it's a code's mill so you need to see if you have like one responsibility and it's a hint for you to break your function into smaller functions that convey what's the story of this function. The same thing can be applied to Templates with this Component approach. So if I look at a biggest Template and see 200 lines of Templates code, I can probably identify it as a code's mill and maybe think, "Okay, maybe this stuff should be like the Menu and maybe this stuff should be like a Tab, like this Component, that Component," stuff like that and then break it into smaller Components. And instead of using UIView or UI-Router to solve this problem, which its responsibility mainly is to connect the correct route to the correct component, the main responsibility I think of the UI-Router is dealing with the routes and not maybe hold the logic of which Template needs to go with which Controller. For my experience, I didn't encounter that much, this narrow that you have the same Template with different Controllers and stuff like that. Usually, they go together, in my experience. Maybe you guys have a different experience.
So, if we think of our Templates in this new way, I like to separate it into, our Directives, into 2 main parts or types. One type of Directives I call "Sections", which are non-reusable Directives. The other type is "Components", which are reusable Directives. The Components, I can pick and embed them in every Template that I choose and they will work; I can plug in their data, I can hoop to their Method Hooks, and it will work just like a Select Box. But Sections describe the nonreusable section in my application like Pages. So a Page can be constructed out of several sections that describe the Page. We can use Tools like the UI-Router to decide that one of the Sections is a replaceable section and it can be replaced different Components depending on their specific routes. But in general, we can architect our application by thinking of the mockups we get from designers as Sections and Sub-sections. That way, you can start and create your Directives and divide them into those 2 types -- the Components and the Sections. If you do them right now, your whole perception of how you develop Angular changes because you stopped using nginclude, you stopped using ng-controller, which is a good thing because they will be gone in the future. So it's a good idea to stop using them right now. And you get a whole easier Template when you look at it because you don't see a bunch of these, with ng-include and ng-controller or ng-view and need to guess what's go where; you just see a semantically beautiful Template that described your application.
do:
If you want to build Section Directives, you should use the Directive Definition just to connect the Controller and the Template and add the 3 properties like BindToControllers, Isolate Scope like scope object and controllerAs, and that's it. You have a Component, a Section Directive that you can use, and you just can treat each Controller and Template like you did the ng-include and ngcontroller. So it's another step you take. It's not like easy as just putting a bunch of ng-include or ng-controller or tie down in the UI-Router or the state provider and stuff. But currently, an extra step you take but totally worth it in terms of the mental shift you need to do in order to prepare yourself. And as I understood and I'm following it very closely in Angular 1.5, I spoke with Pavel about it and
I think he mentioned it in his talk in ng-conf, they are going to introduce -- there is a proposal for Angular.component alongside Angular.Directive, which does basically the same thing as I just described but without the [incomprehensible] code of BindToController through an Isolate Scope and controllerAs; you'll just get the Component and you just need to describe what the Template is and what the Controller is and you will get a syntax similar to Angular 2. And this was my rant about Templates. [Laughter] SHAI:
Do you have any question? I can describe more thing if that can do.
JOE:
No. I think that was a really good explanation. We do need to wrap up here soon.
SHAI:
Okay.
JOE:
Because we kind of hit all the main points here.
SHAI:
Yeah, I can just sprinkle some more [chuckles], just headlines of stuff and not get into it.
So another thing you can start doing is drop, if you don't actually really need JQuery or jQLite, you can start using the Native Query Selector and just scrub JQuery because Angular 2 won't have JQuery. You can start also using .service. I was a big fan of .factory for using services, but I think that .service is much more, maybe, suitable for the future so it's another thing you can do.
Another thing is watch closely to the new Angular router, which is supposed to be backward compatible and work with 1.0 and also 2.0.
And another big thing, and this I think you will like because I heard last few episode where you talked about it, start using ECMAScript 6. Start using Tools like the Babel, or typescript-compiler, but start using...
JOE: webpack.
SHAI:
What?
JOE:
I like webpack.
SHAI: webpack.
JOE:
Yeah, use it with Babel.
SHAI:
Okay.
JOE:
Love that.
SHAI:
Awesome. So start implementing these Tools, the transpilers into your current development flow. And if you're not using Tools like Gulp or Grunt or something like that, start using it because it's really easier with Tools like [incomprehensible] where you can generate and get like a pre-made gulp-file or grunt.file with all the best practices and start adding it. You can literally have pre-built gulp-file with BabelJS which is a ES5 to ES6 transpiler already baked into and running and you can have like a good running example set up in 10 minutes. You can analyze it and see how you can fit it in your current workflow, and start using ES6 now so this will probably make your migration path much, much less painful. This is another stuffs.
ES6 or... I'm waiting for TypeScript 1.5 to come out and then I'll start to look at it, but these are a bunch of tips you can do. As I've said, I have a pre-course that I will go into more depth about how to actually do this stuff and what's the benefits and the why's and how's and stuff like that.
And another general tip is to make sure you keep up to date with podcast like this or newsletters like ng-newsletter and blogs and the documentation. Angular is doing a good job, I think, of trying in every conference and every blog and stuff like that to share as much as possible about the future plans and how things will look like to calm down everyone that it's here to stay. And I really like what Brad and Igor said in their keynotes that there will check the statistic about the new Angular 2.0 website, which called Angular.io and the old one, and only when the statistic will show that no one really, really low percentage of people are using the old version or 1.X like I don't know in 2 years or 3 years from now, I don't know how much time it will take, only then they will drop the support on it. I think it was a good step to calm everyone down that Angular is here to stay and yup, that's it [laughs].
JOE:
Well, awesome!
SHAI:
Yeah.
JOE:
Alright, well, let's move on to our picks. Shai, we've really had join you on there. Kat, do you want to go first with the picks?
KATYA:
Sure. I guess my pick is "Princess Bride".
JOE:
The Princess Bride.
KATYA:
Yeah, because no matter how many times we watch it, we keep watching it. [Laughter]
KATYA:
How many times have we seen that movie?
JOE:
A lot. We watched that movie a lot here. Awesome. For my pick, I'm going to pick "Visual Studio Code". I've been using it recently just ground with some Angular stuff and some other stuff, and some Noodle editor. It's very similar to Sublime. It's cross platform. I really liked it. I thought it's neat, it's sleek, it looks good, it works well. I still kind of learning this keyboard shortcuts for it, but I've really enjoyed this.
That will be my pick for today. Shai, how about you?
SHAI:
Oh, you put me on the spot!
JOE:
Uh-huh!
SHAI:
Just a quick tip, for those Windows users who like better command-line tool, I use (when I work on my desktop) a tool called "Console 2". It gives tabbing and stuff like that. It's a free little utility that gives you better, I think, command-line support if you don't already use Webstone with the built-in terminal [chuckles]. So this is my pick.
JOE:
Cool! Awesome. Well, thanks again for being on the show, Shai. We really appreciate it. As always, Angular 2 is very hot topic so we're grateful to have you on. Lukas, unfortunately, had to drop off the call so I'll speak for him and say thanks. And for all the other panelists, of course, they weren't able to be here, but thanks for coming on. We appreciate it. I'm sure we'll see you again on the show before too long.
SHAI:
[Chuckles] Okay, thank you, guys! It was fun.
JOE:
Alright. Yup! Take care, Shai. See you! And we'll see everybody next week!
[This episode is sponsored by Mad Glory. You’ve been building software for a long time and sometimes it gets a little overwhelming; work piles up, hiring sucks, and it's hard to get projects out the door. Check out Mad Glory. They are a small shop with experience shipping big products. They're smart, dedicated, will augment your team, and work as hard as you do. Find them online at madglory.com or on Twitter at @madglory.]
[Hosting and bandwidth provided by The Blue Box Group. Check them out at bluebox.net]
[Bandwidth for this segment is provided by Cache Fly, the world’s fastest CDN. Deliver your content fast with Cache Fly. Visit cachefly.com to learn more.]
[Do you wanna have conversations with the Adventures in Angular crew and their guests? Do you wanna support the show? Now you can. Go to adventuresinangular.com/forum and sign up today!]