Ed Charbeneau: Hello, and welcome to Eat Sleep Code, the official Telerik podcast, I'm your host Ed Charbeneau and with me today is Todd Motto. Hi Todd.
Todd Motto: Hey Ed.
00:51 TM: Cool. Yeah, thanks for having me on the show. I'm a new member to the team as you mentioned. I'm over in England, I cover the developer advocate scene in the UK, and parts of Europe and hopefully a little bit further across the pond and over in the US. So yeah, I'm working on the Kendo UI side of things, we'll be diving into the NativeScript as well. There's also the React stuff, and Angular 1 and Angular 2 integrations, so I'll be heavily involved with. So, it's gonna be an exciting year.
05:31 TM: Yeah, I think it's probably the most interesting topic at the moment with regards to the norm technical code side of things, is what technical and code side do I actually go with? And you can sort of… Let's just assume you create an Angular application a year ago and you are 1.3 for example, you may have kept building, you had a back load of features, you kept building, kept building, and got to the point where you had finished those features but then all of a sudden you're two versions behind because Angular 1.5 is then out. But then you make that upgrade jump and Angular 2 is on it's way.
07:14 EC: Yeah, the developers that I know, the ones that I talk to when I go to conferences and things. These people are the type that wanna be on the bleeding edge, right? So they wanna learn all these new things, but there are literally so many. That you could spend all of your time learning all of the things and at some point you gotta decide on something, because you have to get your job done. Deliverables need to be met, so that leaves people in a sticky situation.
08:55 EC: So let's take ourselves in a position of we have a project that we worked on for say, like a year, heads down, we're not paying attention to the community, we come up and everything is changing. Where do we go from here? What are some of the things that we're looking at if say we've been building Angular for a year and now there's all these new tools out there?
I used to work in an engineering house as well, and we would extend projects and each project build would be slightly different to the last project that we built might take two months, or four months, or six months. And they would all have a completely different set up because the way that things change, meant that we had to change as well. Angular 2 is at that point now where there is so much tooling. We value the tooling, that it has to use the tooling that Angular aren't gonna give you something that you can instantly go and build with.
10:40 EC: Now, you mentioned some package managers in there, so Grunt, Gulp, NPM, all package managers. And if you think of those in terms of web technologies they're actually not that old. But people may think they've been around for a while. But if you're coming into this new landscape… Like even Microsoft developers are just getting introduced to some of these tools. And then you start reading about them people are like, "Oh, well, Grunt is dead, so don't use Grunt." But to you it's a brand new thing, but the web just called it dead yesterday. So what do we do there?
13:00 EC: And I just completely added to the confusion by calling those package managers. What I meant to say is task runners.
13:05 TM: Yeah, yeah, MPMs.
13:07 EC: And so if you really, really are new to those terms, I just really messed it up for you bad. So these are task runners for automating your build process, not installing packages. MPM is, but Grunt and Gulp, yeah, I goofed that one up.
13:31 TM: You too fatigued?
13:31 EC: Yes, the fatigue has set in. I can't keep all of the new names of everything straight. So we have Grunt, Gulp, MPM, Bower and a million others. And then we have a bunch of micro-frameworks as well like React is a big framework but what are some of the small ones that are out there?
13:56 TM: Yes. Quite interesting actually. I do a lot of polls and stuff on Twitter just to see where the industry is kind of thinking and there's a large amount of people who I'd say "Okay, so what would you use given the absolute free choice on a new project? Would you use React? Would you use Angular? Would you use Angular 2? Would you use something else?" And then I usually put "Others ( Please specify )". And you get a lot of people saying "Oh, I wanna use Rio. Have you checked this out? Why are you not using it at all? And then there's Vue.js, V-U-E.js. A lot of people say "You need to use this." And it's similar like when jQuery first started coming out that people started creating their own versions of things and there's kind of API copy of React and it's called 'Preact'. It's P-R-E-A-C-T and that's a very very… It basically mimics the React API, but it's very, very small. So the code's actually is really interesting to have a look through. I think when I tweeted the Preact code, somebody actually replied saying, "Oh great. Another framework for me to go and look through and evaluate." But I think it's more look what we can do, rather than this is like super production ready go and build like a Gmail in it.
15:15 EC: Yeah, and I know there's gonna be people that are listening to the show and they're like, "Oh, he didn't mention… " And they have like five other ones.
15:22 TM: Yeah. We'll get some comments. [chuckle]
15:24 EC: Yeah. One of those… We get this request a bit at Telerik too. I may butcher the name. It's Aurelia.
15:32 TM: Yeah, Aurelia.
15:33 EC: Yeah. That's another one that people are evaluating out there.
15:39 TM: Yeah. There's an interesting story behind that one. So it was built by Rob Eisenberg who was previously on the Angular 2 team, who then decided to leave and go back and start Aurelia. So yeah, there's a lot of competition. Most of it's friendly competition, which is great to see and where the Angular 2 team strive is they actually work with these companies. So they work with Microsoft and TypeScript integration and this kind of thing. They also work with Amber guys just to build an evaluated product for example, they might try out first rather than saying, "We think the industry needs this." And then they go and build something that the industry doesn't need. So they call it 'Prior Art'. So they'll actually evaluate the best things that they think are available in the industry.
17:01 TM: Yeah. What I mean, there's so many resources online and Angular 2 has been quite interesting because the first version of Angular 2 that was released to the public is a very different version than the current beta. So we're at beta nine right now. So those two are very very different. And if you've been following the API changes as Angular 2 is involved, you'll see that they've made a lot of breaking changes. They've changed the API quite substantially and it's trying to avoid playing catch up all the time. So if you want to be at the complete bleeding edge, you can obviously wake up in the morning or get on to get work and as soon as you got a lunch break or straight after work, you can then start looking at the API changes and tracking things that way.
Fortunately we've got great websites like YouTube and Pluralsight and all these online platforms where people can come learn from others. So I'm like say "Ah, the Angular 2 reach is ready, We're gonna do a screen recording. It's how we use it. And somebody will come and watch this." But then, in the next version, that might be out of date very very quickly, so it's trying to learn that ground-level. So if you don't know what router is or if you've never used one, you probably don't wanna go and start using a beta version of a router. So you might wanna learn a very, very stable one that's been around for a couple of years, evaluated a couple of routers, and see what they do differently, see how to set parameters, and get parameters, and pass them to API responses, etcetera, etcetera.
19:13 EC: So back there, you said something about build your own router. You're telling me that when I put a GitHub project up that that's not the next best open source framework?
19:26 TM: It could be, it could be.
19:29 EC: Every GitHub file I have is the next greatest open source thing.
19:33 TM: It's the best? [chuckle] And how many GitHub projects have you got?
20:00 TM: Yes.
20:00 EC: What are some other things that we can do to kinda get on board this stuff?
21:46 EC: Yeah, one thing that I've been doing a lot of, there's a lot of change in the ASP.NET space right now. So one thing that I do is bite off a small chunk, do a little test project of whatever the new feature or framework is that I'm working on. And then, write a blogpost about how I got it running, or how to integrate it with X, Y, or Z. And then, that becomes something that you can share with the community and help others learn while you're teaching yourself.
22:18 TM: Yeah, and that's something that I highly encourage people to do, is it doesn't have to be the best blog that you've ever seen. It can be the worst-looking blog on the web, but if it helps somebody out, then that's a tick in the box for a good deed for you for the day. And one, that's a good thing with sharing your knowledge in that sense so you can say, "Okay, yeah, I've overcome the React router or the Angular router, Component Router. Here's how to use it. Here's a quick video demonstration," maybe, or just a plain article about it. But then, you can also learn how to sort of dive a bit deeper into the API so you don't sort of just write an article saying, "Yeah, here's just create, 'Hello, world.'" You can actually, when you write something down, you really really understand it. And I think when you try and translate forcing your brain, so you say, "Oh, yeah, I know how to use a router."
23:16 TM: But then, when you try and explain it in words to somebody who's never used a router, and it depends on your target-audience for the article. So if there's like a, 'Hello World!' routing article, then it's gonna be aimed at someone who's never probably used it, and you might consider them in your approach to writing. Whereas, if you're doing, "Here's how to create advanced nested child views," then a beginner isn't gonna come across that post and probably digest it. They'll kinda gloss over it and maybe skip to another post. But in that sense, you can then create your own series of articles. You can create a beginner one, an intermediate one, and just have this flow where they flow together nicely. And that person who stumbled across your advanced from the beginning, in a month's time they might come back because they're hitting a problem that you had. And because you've shared that knowledge of potential fix or you've covered something that they didn't know, then it's another tick in the box, and you've saved them a job, and they might even follow you on your own Twitter as well.
24:18 EC: One thing I've found with writing blog posts like that is, you'll end up going back to that blog post yourself and reading it when you get stuck on something. There's certain one's that I've written that I've gone back to at least a dozen times like, "How do you do this again? Oh, yeah, I wrote a blog post on it." And you end up going back and rereading it, refreshing your memory like, "Oh yeah, that's done this way." Then you can go get on with your day instead of trying to relearn whatever that thing was. So even if you blog about it, it may not stick in your head, but at least you've put it somewhere where you know where to go find it.
24:56 TM: Yeah, exactly, and I think it gives you your own library of things where you've demonstrated a ground level knowledge. Also, we forget things, so you can come back to it in a year's time and go, "Oh, yeah." just as a refresher kind of thing. And I think obviously, we might not blog about everything to do with a specific framework, like Angular for example. We might not blog every single API, every single integration side of things, but somebody else might have. And instead of taking like a black box scenario, where you just go onto someone's website, like we used to when we started learning and copy and paste a piece of code and hoped that it works. We've actually understood the ground level workings of it, so that when we look at a more advanced implementation or a slightly different implementation that we need to do to fix a problem or a new challenge, or a new task at work, we actually have the initial knowledge to then say, "Oh yeah, I see how that slots into A or B." So I think that's really important to build up your own resource, and I think you dive a lot deeper into things as well by writing them out and explaining them to people.
26:15 EC: Yeah, and one thing that I catch myself getting into is, when I learn something I have the assumption that everyone else knows that thing now.
26:27 TM: Oh, yeah. [chuckle]
26:29 EC: Yeah. So, you're not gonna be the first person to learn something, and you're most definitely not gonna be the last person to learn something, so it's okay to get out there and write about something, even if you think other people already know it.
26:45 TM: Yeah, I agree. I think even what you consider, "Everybody knows this. I don't need to write a blog about it", is usually the complete opposite, because there might be a 100,000 people, let's say, that know Angular, there might be a 100,000 people that know React, but then there's billions of people in the world who one day might want to learn Angular or React, and they then don't know how to then get to that bootstrap stage. So providing people the bare basics that they need to get going, like for instance, I create a roadmap of things I wanted to blog about in Angular 1, and one of them was from the bare basics, is setting up your Angular module from the absolute beginning. It's what you need to do in Angular and the documentation says you need to do angular.module when passing a string name. And I was showing them some good practices, and how to do this, and the SETA syntax, and the GETA syntax, and communicating with modules, and avoiding global variables, and all this kind of thing. And you think everybody knows this like, "I don't need to write it, but maybe one person might find it good."
30:33 EC: Yeah. And we have a habit of declaring things dead. That doesn't always help us out very much. Grunt and Gulp for example, those things are in the ecosystem and we have projects that are deeply dependent on them. And we can call them dead as much as we want, but don't follow the hype. There's a lot of stuff out there running on those systems and it's gonna be around for quite a while whether you think it's the bleeding edge greatest thing or not. So you gotta remember, just 'cause somebody said certain technology is dead, it doesn't mean you have to abruptly stop using it. It's probably gonna be around for quite a long time if not indefinitely. I was talking to somebody earlier and said, "You know there's still plenty of people writing COBOL." [chuckle] Just because somebody said Grunt's dead, it doesn't mean that it's vanishing off the face of the web tomorrow.
31:38 TM: Yeah! It means that it's dead in terms of it's no longer future. It might not have a huge shelf life, but it might have two, three years shelf life and then it becomes deprecated and no longer actively maintained or developed. And the plugins and the ecosystems around it certainly vanish. But if you say, all this is dead let's no longer use it, it's because that person loves the cutting edge. They love the new thing and they will refactor their application. Then they'll write an article about how this is dead and how everybody needs to do this. And then somebody else will do it and then someone else will do the same thing. And you can do this with absolutely… If we had to rebuild Google Mail for example, we would choose a technology stack and by the time we've probably spent two, three weeks work on it, there's a new feature that we can use as a new plugin and reactor we could use if we were using React. There's a new API upgrade in Angular. We can constantly refactoring our application.
32:41 TM: And you could if you wanted to and you were chasing all the latest things, gets to a point where you're not actually gonna push an application to production. And that's where we're at. And it's like you said it, it's choosing your stack, remaining focused, but then delivering something, but also keeping an eye on the industry. For example if we decided to build an application today, me and you, we might say, "Okay, let's… " And Gulp didn't exist, we could say, "Okay, let's use Grunt. Let's get it built." But then while we're building it we say, "Okay, there's Gulp around the corner, everybody's using this, so if maybe we should use that Ed for our next project. And we go, "Yeah, yeah, that sounds like a good idea." So instead of going back refactoring all of our build processes, we're refactoring everything 'cause they do the same job. Yes, Gulp is faster, uses node properly, does all this and now is a more mature product with a bigger ecosystem around it. But it's waiting. I think it's a waiting game and you've gotta play strategically otherwise you're gonna drive yourself mad.
33:48 EC: Yeah. I think you wrapped it up pretty good. We'll just say, be bleeding edge on your own time, settle on some solid frameworks that aren't beta for your daily work activities and move on from there.
34:07 TM: Yeah, agree.
34:10 EC: Well Todd, I appreciate you coming on the show and talking with me today.
34:15 TM: Yeah, thanks very much Ed. And I think we've got the Angular 2 team or some of the Angular 2 team on the next podcast, am I right?
34:23 EC: Yup, yeah. We will have you back on and we will have interesting Angular 2 discussion with our next guest.
34:31 TM: Sounds good. Look forward to that.
34:33 EC: Absolutely. Thanks a lot man.