Overcoming JavaScript Fatigue

On this episode of Eat Sleep Code, guest Todd Motto talks about overcoming JavaScript fatigue. With dozens of new JavaScript frameworks, tools, package managers, and task runners in the ecosystem, how do developers decide on a framework and move forward with a project.

Todd Motto @toddmotto

Todd Motto is a Developer Advocate at Telerik based in England, UK. Todd is also a Google Developer Expert, runs Angular and JavaScript training workshops, speaks at conferences all around the world, contributes to Open Source and is heavily involved in the Angular community.

Show Notes

• Angular
• Front-end Application Libraries and Component Architectures
• 5 Steps for Learning React Application Development
• Javascript Fatigue via Medium
• JavaScript Fatigue: An Alternative Perspective via Medium
• What to Expect in 2016 for Kendo UI With Angular 2 and More

Transcript

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:22 EC: Today we're gonna be talking about JavaScript fatigue. Todd, I brought you on the show today because you are a new team member for Telerik and you're working with JavaScript and Kendo UI, and I thought it'd be a great time to talk about overcoming JavaScript fatigue. And let's talk about that in a moment, but first let's do some introductions, tell us a little bit about yourself and what you do.

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.

02:12 EC: Yeah. Alright man, so we wanted to talk about JavaScript fatigue today. Let's kick it off by explaining what JavaScript fatigue even is.

02:26 TM: Yes. So I think... Well, at the moment, there's this JavaScript fatigue you could probably do a search for it on a Twitter search and get new tweets on it every minute. I think we're just in this JavaScript boom at the moment where there's so many frameworks, and so many new features and tooling, and libraries, and all this stuff that's happening daily and everybody is sort of recommending new things to do. The day before yesterday I was... I'd recently switched over from using Sublime Text to using Atom, and obviously everyone has their own favorite text editor, but everyone's sort of like, "Why don't you try this, why don't you try this, why don't you try this editor instead?" And it's the exact same thing that happens with the JavaScript scene. You might say, "Oh, I've just built this on Angular." And somebody will go, "Why didn't you do in this, why didn't you do it in React? Why didn't you do this? Why didn't you use Flux?" Do you know what I mean? It gives a developer, especially a new developer, to the community like somebody who's come from a jQuery background that builds website to then joining like a software engineering team that builds software in a browser, so web application side of things, to make a jump.

03:37 TM: And then there's this kind of "Which way do I go down?" The path used to be quite clear a couple of years ago, there used to be a couple of frameworks that were sort of the industry leaders and then everybody kinda got a bit smarter and said, "Oh, you know what? I'm actually going to create my own framework or my own version of this framework, and I'm gonna make it 100 times smaller, that's my aim." And then React came out, and then Angular 2 is on its way, and there's all the tooling associated with it. I think instead of just maybe five paths that we had a couple of years ago, we have got 500 paths, and then we've got all the tooling around it. So that's my nutshell definition of JavaScript fatigue, is which way do you go, then when you choose a path, you then go another 500 paths so you can choose either with build tools and back-ends, and web servers, and all this kind of thing.

04:29 EC: Yeah, usually when you enter a space like this in development there's two leading frameworks, like take responsive web for example, there's Bootstrap and then there's Foundation. There maybe some others like Skeleton in a few smaller, less widely accepted frameworks out there, but when you go JavaScript side of things, I mean you've got just a ton of different frameworks out there, if you're coming from, like you said just jQuery into this new space of 100 different JavaScript frameworks to do ideally the same thing. I mean the end goal is to build an application, so all these things are designed to get you to that end goal, to build something. And there's so many choices out there and it leaves people kind of doing nothing because they're trying to decide which framework to use and they're... What we're gonna talk about today is how to kinda tackle the situation.

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.

It's like a continuous cycle and I use Angular as a good example because it fits in nicely with this story. And I think that it gives you the feeling like you're forever chasing, so you'll feel like you've never actually completed something. And I think that's not a bad thing. I think learning new technology is fantastic, it's just when there's so much choice and so much evolution on such a rapid and fast scale, I think it's definitely even off putting for some people. And there's a lot of community members who write articles like there's too much JavaScript, we need to turn it down, and this kind of thing. It's interesting to see the community responding to it cause we know it's an issue, but we're all trying to come up with different ideas. Even if we don't need to build something, somebody will build something. So it's just adding to this what we call the fatigue, it gives even more choice.

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.

07:47 TM: Yeah, and I think that's something that we can always keep in mind is that, yes, there might be a new version of something, but the framework itself isn't paying our wages. [chuckle] It's what we deliver with the framework, or even if we're not using a framework, it's a rarity nowadays to go plain JavaScript because we'd have to build a lot of things ourselves. However, it's not Angular itself, I use Angular again as the example that is paying the wages, it's the customer who's paying for a product, or it's the customer we're giving a service to. For example, if you're a developer in a software house, for example, that you've got a four month project and you might decide to switch framework between projects, but then you've got a completely different skill set and if you have to come back and start changing what you'd consider a legacy application, 'cause as soon as the application is built, it becomes legacy because you can build it so much better in a different way, because these tools are just ever-evolving.

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?

09:20 TM: Yeah, Angular is an interesting one because Angular 1 never really said,"Okay, you need to install a build tool, you need to install this." It gave you just a JavaScript file and just an HTML file and you could create this Hello World example. Whereas we then started seeing this boom during Angular 1's lifetime, that was Grunt and Gulp and NPM and all this things that have just rapidly evolved and become the de facto like way and standard of doing things. Like if I want to run a local development server, I want live reload, I want my SAS compiled, I'd want my JavaScript compiled and linted. And there's a lot of tools that we add on to Angular.

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?

11:23 TM: Yeah, that's a difficult one. It's learning what Grunt gives you. So in my opinion, whether I join a company and they are using Grunt over Gulp, that's exactly what happened in my previous role. So I was using Gulp, I was using all the latest stuff, two jobs ago and then I switched jobs about a year and a half ago and then we were actually had this huge system which was using Grunt and once you go, "Oh, they're not using the latest thing." It makes you wanna obviously use the latest thing but then at the end of the day, you've got a Grunt file which is hundreds of lines long with a complicated build systems with mature plug-ins] And there was a lot of people who were adopting Gulp which is obviously the new sort of standard that sort of older brother to Grunt and you got a lot of people adopting that very early on. And there was a lot of breaking changes, there was no plug-in support and there was people creating bridges so you could use Grunt plug-ins inside Gulp and that become a kind of mess. But now Gulp has matured and that way in the exact same thing where everybody's using NPM and Webpack for example. So instead of having your JavaScript and images and all these kind of compiled with Gulp they would use MPM scripts and Webpack. And it's the exact same thing. So Gulp replaced Grunt in a mainstream majority sense and the same thing I think will happen with MPM and Webpack.

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.

16:35 EC: So we have all of these things going on in the JavaScript space. We have package managers, micro-frameworks, big frameworks like Angular 2 and React going head to head. If we're trying to get up to speed on all this stuff, how do we relearn this new JavaScript space without getting the JavaScript fatigue.

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.

18:35 TM: And then, you could even go and build your own router but don't open-source in, add to the JavaScript fatigue, but just to understand the core concepts of it. So when you look back, let's say you decided to look at the first version of the Angular 2 new router, and then go, "Okay, yep, I get how routers work, how you're gonna look at React Router and gonna look at Ember." And then, you give it six months or a year, and let's say the router becomes stable, you can then say, "So okay, so I know how to do routers. I know how to set dynamic views, I know how to run the components. I know how to change the URL." And then, you can pick it up very quickly. So this is what I've kinda been doing.

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?

19:37 EC: I don't know. Like, 30. [chuckle] I'm kidding, of course. Going back to GitHub, should we maybe find some of these JavaScript projects and open 'em up and take a look inside the code, or maybe contribute to them if we can?

20:00 TM: Yes.

20:00 EC: What are some other things that we can do to kinda get on board this stuff?

20:04 TM: Yeah, I think one of the initial kind of hurdles for... Or let's say I'd never contributed to open source, so I might want to... I've been using React Router, for example, when I noticed that there's a bug, I might wanna go and fix it. But then as... Which kinda adds to this JavaScript fatigue. Because you need to know how to then go onto the React, the repo for the router. You need to then download it. You need to run it all locally, do all the installs. You then sort of go, "Oh, I don't know how to write unit tests or React test." So then, you have to go and learn this. By that time, somebody's fixed the problem. [chuckle] Yeah, so it's trying to get your skills to a level.

And I think you can be put off by it. Certainly, if you contribute into a very, very big project like if you're coming into the scene and you are just learning JavaScript, you're not gonna go and push an issue fixed to Angular 2, for example; whereas, you might go and find a lazy-loading JavaScript library, which has got 10 issues and it's a bit smaller. You can actually have a conversation with the owner of the project. And you can learn how they do tests, and you can learn how to push the test, and you can make sure all the build passes. And then, they can merge in and they can encourage you and even help you so you become better at this open source platform. Then, you can sort of take a bigger step and take a bigger project; and then eventually, end up something like Angular or React contributions.

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."

However, when I then published it and tweeted about it, it went quite crazy to be honest. It had so much good feedback, loads of comments, and it was featured in NG Newsletter. So, I think you can underestimate your own knowledge at times, and what you consider everybody knows, they absolutely don't. I guarantee if I ever wrote an article on how to write a four-loop in JavaScript, there are millions of people in the world who will search for that one day. So, it's also thinking about the people who don't code yet, or are coming into the code world that need that initial step. And if you can give them that, then perfect.

28:35 EC: I think it helps you build a base to get over that JavaScript fatigue hurdle, and get focused on something to write about those basic things, and move on from there. And one thing that you need to remember with all this JavaScript fatigue stuff is to not get caught up in the latest and greatest thing. At the end of the day you need to get work done, so you need to find something and settle on it. There's always gonna be the next big thing. It's like trying to have the latest and greatest smart phone, there's always gonna be a new one in six months. So, there's always gonna be that new framework, JavaScript, great thing six months down the road. But you can't keep delaying your project for months, because you're anticipating this new thing to launch. You need to pick something and run with it. Grab Angular and build something for God sakes, you need to get work done.

29:37 TM: Yeah, and I think we can... One of the worst things at the moment with this whole fatigue thing, isn't just the framework side of it, it's the whole tooling wrapper. We are a community that is now reliant on preprocessing tools of some kind, aren't we? We say, "I would never set a project without NPM. I would never not use Goal Pro, Grunt or Webpack. You see what I mean? We create all these boiler plates and none of them do not have some kind of build or tooling around them. It's kind of essential part of everyday work now. And I think if you go back to writing JavaScript and refreshing the browser yourself, that's now considered like a legacy practice and nobody does that anymore. Or at least that's not the way the community is going.

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.