060 - The state of JavaScript

We bring you the audio from our recent state of JavaScript panel with Pluralsight authors John Papa, Joe Eames and Jeremy Morgan. Their fun conversation covers topics including:

• JavaScript’s bad rap

• Do low code/no code advancements threaten developers?

• Is there a right or wrong JS framework to use?

• Which JavaScript frameworks = which Star Wars characters

If you enjoy this episode, please consider leaving a review on Apple Podcasts or wherever you listen.

Please send any questions or comments to podcast@pluralsight.com.

[00:00:00.000]

Hello, and welcome to All Hands on Tech. Today's episode brings you the audio from our recent state of JavaScript panel with Pluralsight authors John Papa, Joe Eames, and Jeremy Morgan. Their entertaining conversation covers topics like JavaScript's bad rap, if low-code advancements threaten developers, if there's a right or wrong framework to use, and even which JavaScript frameworks align with which Star Wars characters.

 

[00:00:37.876]

Hello everyone, and welcome to JavaScript: Opportunity, Challenges, and the Future. Today I have Joe Eames and John Papa with me, and we're going to talk about everything JavaScript. How are you guys doing today? 

 

[00:00:50.063]

Amazing. Thanks for having me. 

 

[00:00:52.405]

Fantastic. Thanks.

 

[00:00:53.696]

Awesome. So let's jump right in, and either of you can answer this, either way. What first got you hooked on JavaScript as a language, and why are you still using it today?

 

[00:01:05.824]

My first experience with JavaScript was back when I was working with a tool called Visual InterDev in the late '90s that I actually, I wrote a book about a long time ago. And it was a product that eventually got merged into Visual Studio product line. But what stood out to me at the time was, I was doing things like VB and C and other languages as well, and Java, and Microsoft had this thing called JScript. It was like a flavor of JavaScript. And I started wondering, first of all, why would I ever use the web? What's the web for? Why do I need a JavaScript language? Why can't I just use VB on the web? And that was my first interaction with it. What got me hooked on it was the whole idea of, it's so simple to use. For me, I love how easy it is to use, how many places you can use it, front end, back end, and all over the place. And that's kind of why I've had a tumultuous relationship with over the decades with it. There's been times where I left it for a while, we got separated, but then we got back together, and now we're married again. 

 

[00:02:13.114]

I cannot believe you dropped the name Visual InterDev. I remember that. I'll bet it's been 20 years since I've heard that name. Man, my story's, my _____ was relatively similar to John's. I don't remember doing much JScript when I started doing Visual InterDev. I was doing some VB at the time, but I was also doing, I did some FoxPro. There was the foxisapi.dll for making websites with FoxPro. That was some cool stuff back then. Yeah, I had a really, during the first decade of the 2000s, JavaScript was like, you use it just to validate a form field or something, and I tried learning it couple of times, bought a couple of books, and hated it. And then somewhere in the jQuery, the heady days of jQuery, I started playing around. And then for me, I ended up, and I think this was around '08 or '09, I said I want to do something totally different. And I knew that in front-end web development it was the Wild West. Things were changing. There was lots of stuff coming out. Through '06 and '08 there was just lot of crazy things that started appearing and showing up, and I was a big, big, big time believer in engineering practices and testing. And I said, I want to go do front-end web development, but I want to teach people that are doing it how to do engineering and unit testing and that sort of thing. And so I just made a very conscious, huge career shift. Rather than being a C# developer, I said I'm going to be a JavaScript developer. And I remember my boss when I told him, hey, I'm going to quit because I'm going to go find myself a job doing JavaScript, and I want to do JavaScript 70%, 80% of the day. I remember my boss saying, you think there are jobs like that? I ended up finding a couple things, ended up even contracting for Pluralsight for a while, which is where I discovered Angular. But I think I went through that phase that was right in there where I said, I'm just going to dig into this and learn it. And that was what caused me to start ultimately loving JavaScript. And I had a lot of people that were doing C#, friends that were doing C# or Java or something else, and Ruby, and said, man, JavaScript is just a piece of garbage. And I said, you have to view it the right way. The languages that you're looking at are like a 7 Series BMW. They're fast, they're comfy, whatever. JavaScript is like being on a motorcycle. And so you don't complain that you don't have air conditioning when you ride a motorcycle. You don't complain about where's the seatbelts. It's an entirely different thing. It's a different experience. So that's for me what JavaScript was. You can just throw things around and duck punching, we call it--duck punching isn't a popular term for it, but I like the term duck punching. But the ability to make anything look like anything else in JavaScript, those were cool things. How I fell in love with JavaScript was through that process. 

 

[00:05:35.207]

Interesting for me is like when I call my first marriage to JavaScript is, in the early days, I did a lot of contracting work at my own company doing consulting, and a lot of times I ended up using it was because people had unique requests, like creating a website entirely JavaScript coding so it could run disconnected offline. Which, running offline programs 20 years ago was complicated, to say the least, and JavaScript helped. And the reason I left JavaScript originally was not JavaScript. It was because of the browsers. It was because to write something that worked in all the browsers, which you can't control when you're consulting if they're using what browser or what version. There was no evergreen concept back then. It was awful. You'd have to double or triple your estimates. And it just made programming in it unrealistic. There was no server-side JavaScript, there was no jQuery at the time. And to me, the time I got back interested was when jQuery came out. jQuery gave us all the vehicle to say, not make JavaScript better, but to make it easier to work across the browsers. That was one of my initial feelings about jQuery. I had no problem writing JavaScript; I had a problem writing DOM object API language. That was the issue. If I wanted to show a pop-up box in 4 browsers across 6 different versions, I got 24 if statements trying to figure out how do I show you a pop-up box. It was awful. So to me JavaScript was never bad. It was, the browsers had to catch up with where we needed to be. I'm a huge actual fan of the language. I don't ride motorcycles. I did it once 25 years ago. Ran into a fence, almost cut my arm off, and don't do it anymore. So to me, JavaScript is just like a BMW if that's the car you like, Joe. I think it is a BMW. It's just that maybe there's no guardrails on the road. But I'm dedicated enough to stay on the road anyway. I'm going over the Golden Gate Bridge. C#, Java, they have guardrails. JavaScript, there's no guardrails. There's not even a person at the edge waving at you to say you might go into the bay. But to me, JavaScript's just one of those fun languages which lets you do what you want. I do think it gets a really bad rap.

 

[00:07:50.242]

I would agree, and that was actually the point I was going to make. There was a time, and know that both of you have been developing for a long time also, but the perception towards JavaScript was really bad for a long time. People were disabling JavaScript in their browsers. And I feel like the browsers were at fault, as you just said, John. The browsers were at fault because you had to develop all of these different things for all of these different platforms. And then people were developing disruptive things like popup ads and scrollers and all these crazy things. So there was a point in the early 2000s where I definitely said JavaScript is on its way out. It's gone. I can't wait to see what replaces it. And then all of sudden, bam, Ajax, jQuery, things like that, and then it kind of came back. And that also came from the browsers, so it was almost like, and correct me if I'm wrong, but I feel like the browsers almost killed JavaScript, but then the browsers brought it back with V8 and things like that, popup blockers in Firefox. Then all of a sudden JavaScript became cool again. Is that kind of how you guys have experienced it also? Am I way off?

 

[00:09:01.153]

Yeah, more or less.

 

[00:09:02.061]

Yeah, I agree. I think there's just lots of ways to look at it. And languages are easy to pick on, let's be honest. And we tend to as technologists to go through, I won't even say just developers, but technologists, we tend to gravitate towards the ones we like. And Joe and I have had this chat offline before, and I'll raise it here quick to see your opinions, Jeremy. But I feel like the biggest lie we tell ourselves in technology is that one thing is better than the other. Like JavaScript's better than C# is better than Java, or React's better than Angular versus Vue, or any of those combinations. And the reason it's a lie is because we try to tell people in these arguments why something is better. But really what's happening is we're actually just saying why we like it better, why it appeals to you better. Because what I use and what Joe uses and what you use and what the listeners are all using, whatever language it may be, it works for them. Who am I to tell somebody who's got a job doing VB 6 and supporting some major government operation for the last 20 years that they need to get off of it? They've got a job and a career, more power to them. That's what they should be doing.

 

[00:10:11.961]

That's funny. I think that one of the worst things that ever happened to the frameworks was TodoMVC.

 

[00:10:18.291]

Oh that website that's like the, let's make everything in a Todo app and see what it looks like?

 

[00:10:21.955]

Yeah, it's like a compare and contrast. Oh, that's the most ridiculous concept to me in the entire world.

 

[00:10:29.294]

I don't feel differently, but I'm curious why you feel that way? Can you share?

 

[00:10:32.221]

Well, the biggest thing that I hate about it is it shows a tiny application. Nobody builds tiny applications. Pick the worst technology in the world, you can still build a tiny application in the world's worst--and when I say worst now I'm feeding into exactly what you said is wrong, which agree. But let's say, I'm going to pick on ABAP. ABAP, and if you want to open up a screen, you have to number it. Screens are numbered. You can't even name screens. They're numbered. That's a hard thing to get through. So I'll pick on ABAP. But even in ABAP you can build a tiny app. Tiny apps are not what matters. What matters about a language you choose or a framework is what happens 50,000 lines in with 10 developers. Those things are the things that matter. Outside of that, when you don't get to that range, that's not what TodoMVC shows. It doesn't show that at all. You don't get to see the experience, the wide variety of all the pros and cons and finally realize that no matter what you choose, there's stuff that's going to be awesome and stuff that's going to suck. 

 

[00:11:38.001]

I have a minimum bar for creating an app, and TodoMVC doesn't meet it. You know why? That minimum bar is, it must have a save button somewhere. And even TodoMVC, literally, you enter something, and it just magically saves and goes to the database and everything just always works. I'm with you there on that. But yeah, I think you have build larger apps. And probably the bigger thing for me is, shipping code is the most important thing for most people out there working with technology. It's not how beautiful is the thing that I have created today. I wish it was, but we get paid to ship code. 

 

[00:12:15.416]

Exactly. What problem are you trying to solve is generally the best question to ask in the beginning. That's the popular interview question, I'm sure as you both know, for software engineers. What's your favorite programming language? And from the very beginning, from the first time I heard that, I'm like, I don't know. What are we doing, what are we working on? And I think that's pretty valid also, when you have Java programmers who are like, oh, there's all these terrible things, but we're not trying to build the same kind of apps for Java with JavaScript, so it's kind of irrelevant at that point. From an engineering standpoint, like you mentioned, Joe, do you think there are some valid criticisms of JavaScript, some anti-patterns that exist in there? A lot of people bring up loose typing, comparisons, things like that. Are there some bad patterns in there that are legitimate criticisms that people should consider if they're building a large application?

 

[00:13:15.068]

That's a tough question, just because the easy answer is to say absolutely and lay out five bad anti-patterns. I think John's analogy of driving down the Golden Gate Bridge, JavaScript is the Golden Gate Bridge without rails, without even a person warning you that you're going to ride off into the bay is very apt. You can shoot yourself in the foot. I don't know, John, did you ever see that blog post from so long ago, How to Shoot Yourself in the Foot in 10 Different Languages?

 

[00:13:42.637]

Yeah, absolutely hilarious. They pop up every once in a while, yeah.

 

[00:13:46.925]

I think you can talk about, we could certainly talk about several different things. Types, missing types is one of the most common things that first comes up, as loosely typed as it gets, but JavaScript probably…

 

[00:13:59.559]

Let me pause you there, Joe, and I know you have an opinion as, why is not having types a bad thing?

 

[00:14:05.349]

Well, I'm not necessarily saying I think that not having types is a bad thing, but a lot of people say that not having types is a bad thing, and there is a very valid piece to that. I mean, geez, just a little while ago, I was building something, I had to build it in Vanilla JavaScript. And I mostly do TypeScript now. I like the types generally. I really loved typeless when I first standard JavaScript, but I've drifted back to preferring TypeScript. But it definitely helps you avoid---it gives you better IntelliSense and a various number of things. Now there are definitely IDEs that help out a lot with that, with different languages other than JavaScript where it's a little bit easier without the types. Even so, Flow does an okay job. Visual Studio Code does an okay job. But it definitely does, I think it's a reasonable statement to say that it objectively reduces development time on anything beyond a minimum-sized project. That being said, I still think it's okay to choose not to use types if, for whatever reason, a variety of number of reasons. But you've just got to understand there are some things---you could say the worst thing is not understanding the cost, but it also is true to nobody can understand every possible cost when you make a decision to choose x over y. Because you're not choosing x over y; you're choosing x over every other letter of the alphabet. If you choose React, you're also not choose Vue, you're not choosing Angular, you're not choosing MooTools. You're not choosing all those other things, and all of them have their own benefits and costs, and nobody can know everything. But I do think it's reasonable to say you should spend some time building with types so you understand what you're not doing if you prefer not having types. That's pretty reasonable to say for most developers after you've gotten a little bit of time in there.

 

[00:15:55.668]

I like where you're going with this, so let me throw a devil's advocate at you both. I've been building, this could be me and it actually is me in this case, but it could be anybody. I've been building JavaScript apps for years, and I've deployed many JavaScript apps that had no types in them whatsoever that are used by tens of millions of users on the web, ones that you may have been using out there. And those apps work. So are you telling me that I did it wrong, that everything I've done in the past is terrible and now, I know you're not, but you know. It's like, I've been building stuff like this for years, TypeScript hasn't always been around, so all that production code I wrote, are you telling me that I'm worthless and I need to go now do a different career?

 

[00:16:36.261]

That's such a beautiful point to make, really, about this. Because the only thing that matters is that we get working code out there. And notice, the term "working" needs to be a little bit vague because, not bug-free, working code. That is by far the most important thing, if the app's out there and it works. I will tell people all day long, you should test. That's been a core belief of mine since the early, early, early 2000s when I first learned and taught myself unit testing and test-driven development. You should test, you should do unit tests. I love Cypress, I'm an ambassador for Cypress. They'll sometimes say this thing of you don't need unit testing anymore.

 

[00:17:15.944]

The island of Cyprus or the technology?

 

[00:17:17.403]

Both. I love the island of Cyprus. No, the technology, the testing tool, fantastic testing tool. I love it so much more than Protractor or other tools that are similar to Protractor. Protractor's probably the biggest, most common one that's out there right now for that other than all the Java ones. But I love Cypress. But they will sometimes tell the story that now that you've got Cypress you don't need unit tests. I totally don't believe in that. But I will say, as much as I tell people all day long, you need to test, you need to learn how to test, you need to how to unit test well and do unit tests and other types of tests. My most successful project that I ever built, and when I say successful it's not by monetary terms but as a developer I felt like it was my most successful project, had 0 tests in the entire code base. Because it was a moderate-size project I built entirely by myself. And knew the code so well, what I was building, that a lot of the value that I got out of the tests. So here's me violating something I say all day long. And so to your point, all that mattered was that I got working code out there and made that work. Adjust the team, adjust the process, whatever, make the code work. So if you don't use types, fine, don't use types.

 

[00:18:31.595]

You think testing makes up for that in a way? Because I'm one of the people, I love types, and I don't say that having no types makes junk code or anything extreme like that. But like the deterministic style of knowing that this piece of data is going to be this type all the way through the lifecycle of programming. If it's not, something will break. However, you can achieve that, as you just mentioned, with tests. You can make sure that that type stays exactly what it's supposed to be throughout the entire lifecycle. So does testing, in your opinion, pretty much eliminate that giant complaint?

 

[00:19:07.953]

I have a strong opinion, and I want to hear what John says to this.

 

[00:19:10.345]

I say no, absolutely not. I think they're for different purposes. While you can test for type existence, I think that works. But to me, and these are two different conversations, types and testing, to me, but if you're looking to figure out do I use types, what we're really saying is TypeScript, in this particular case, with JavaScript because I think we're---while there's Flow and other stuff as Joe mentioned, I think that is the predominant one that's won that space. But why? Why do you want TypeScript? I'm not suggesting you don't. To be very clear, I am a huge TypeScript user, I'm a huge TypeScript fan. I worked for Microsoft. I like TypeScript. I've got a course on Pluralsight on TypeScript. Go check it out. So we've got all this great stuff, but why? Why do you want it? What are you hoping that it's going to do? To pick something that Joe said, and I think this is a valid reason to use TypeScript instead of JavaScript, but it shouldn't be your only, in my opinion, is the tooling. So we're touching on how there's some great tools out there. If you use plain old JavaScript, you can get great IntelliSense and features and little red lines under stuff in JavaScript that'll give you information like WebStorm, VS Code, and some others. But if you're only goal is to get better tooling, if you use TypeScript, yeah, those platforms will use those types to tell you when you've got an object passed into an array by accident, etc., I think there needs to be more. I think there needs to be more than just great tooling because the tools have gotten so good. A great example of this for me was, one really large project I worked on, I took it after we wrote it in I think Angular 1.4 and JavaScript 6 years ago, something like that. And I took it later, and I turned on, when TypeScript had a feature of you can compile JavaScript. In the tsconfig setting there's like an allowJs or something like that, some setting. When they introduced that I said, I'm kind of curious. What would happen if I compiled this really, really large JavaScript app with TypeScript compiler, how many type issues would just pop up? And this thing's in production at the time. 

 

[00:21:21.033]

How many lines of code was it?

 

[00:21:22.259]

I don't know how many lines of code, but I can tell you it was 150 developers. So it was really, really large. 

 

[00:21:28.468]

Wow.

 

[00:21:28.654]

And the thing was in production for like a year and a half or 2 years when I did this. And I can't remember the number of issues that came up, but the TypeScript compiler was having field day when I ran it through there. And all the stuff was fixable in JavaScript. It was stuff like I mentioned where I passed a function in, or an array into an object, or a string to a date, or stuff like that, which, as long as---the test didn't break, because as long as I called them a certain way, everything was fine. But God forbid something gets through there as a different type somewhere, the whole thing would've been very unpredictable. 

So I think that---I'm not disputing this, that there's value. What I'm disputing is that I don't think as developers we ask the question why enough, and I think we should ask it more than once. Why do we want this thing? What are we hoping to get out of it? Where do we want to be? And I know it sounds existential, but when you're being paid to do this, I think it's important to do these questions and do these "what if" scenarios.

 

[00:22:31.207]

So I do have a question here from the audience from David, and it's kind of a long question, but I'll see if I can summarize it. I think it's a good one. So the question is, where do you honestly feel the market is in reality across the industry, as far as older tech, the percentage of older tech versus SPAs, for instance? And it says, if you were to watch Twitter, you see it all as SPAs, you know, everything React, Angular, Vue. However, in real life, like on-prem and _____ in reviews, devs are still doing MVC, Web Forms, things like that. Where do you guys think the percentages are right now?

 

[00:23:10.824]

I have no idea. I would look to Gartner or Forester or any of these big agencies to look at numbers. I think Joe and I and Jeremy, the best we can offer to folks is what do we see specifically. In my world, what do I see? I know that there's literally millions of people doing JavaScript these days, and we talk to a lot of them. I know that when I was doing, I've done database stuff, I've done back end, I've done n-tier, MVC. I've been through all the different languages and patterns in the last 25 years, and I feel like the perfect storm of the internet and social media coming together and then where the web has evolved to a place where we're no longer having this conversation of C# versus Java. We're now having this conversation of, it seems like, front end or back end. And to me it looks like the web in general, and I include mobile development in this too, has just such a huge presence. Does this mean there's no back-end jobs? Heck no! there's a ton of them out there. And like that big project I mentioned with 150 devs, they weren't all front end. A lot of them were building back end and APIs and Dockers and containers and, things like Kubernetes didn't exist at the time, but manual ways to do stuff like that. And there's lots of space out there.

 

[00:24:35.681]

Yeah, I pretty much echo that same statement. I think the worst place, and this is true regardless if we talk even about tech, the worst place to get information and fact is any kind of social media platform. 

 

[00:24:51.954]

Don't make any life decisions based upon a tweet that Joe or I respond to.

 

[00:24:56.987]

Right, yeah. That's a horrible place to find things. Yeah, I'm going to guess the web is probably 80% WordPress. And then of the last 20%, 1% of it is what we might call modern JavaScript. And the other 19% is probably these sites that were built in previous iterations of technologies that have been around longer than the last 25 minutes since the latest JavaScript framework has come out. And so I think a good example of this is, is it me.com, the new email system that's everybody's going gaga over that the Rails people… 

 

[00:25:37.675]

I think it's HEY.

 

[00:25:38.729]

HEY, hey.com, there you go, hey.com. They specifically built this in a non-latest flavor-of-the-week thing. They did it with Rails. It's relatively server rendered with a little bit of client-side interactivity. And there were some great threads of people pointing out what they saw that it didn't do because it wasn't built on a JavaScript framework. Very cool interesting stuff. But I think another part of that point was it seems like the older stuff, the non-current way to build things is a little bit easier to learn. And I think a good comparison here is serverless. Serverless is now, if you pay attention to Twitter, all development is now happening serverless. Node is dead as a server platform. .NET is dead as a server platform. Java's dead as a server platform. All it is is lambda functions running on Azure and AWS. But it's funny to see all the articles that are coming like, oh, my gosh, it was so hard to get this application to run serverless, and people are realizing that there's no magic bullet out there. And so serverless is definitely not going to be 90% of all development next year, neither is frameworks. jQuery's probably still the most popular framework that's being worked on by developers today, my guess is. And WordPress is probably the most popular web technology being worked on today, my guess is. And Java, and I just talked to a company that had a 5-million-line Java app, web app. Think about the number of people that are still doing Java today. Regular old server-side JSV.

 

[00:27:14.647]

We should read Jeremy's section of this at some point to talk about anecdotes about really crazy things we've seen _____. I'm sure we have stories too. You made me think of some.

 

[00:27:23.616]

Yeah. So, again, don't feel bad if you're not doing the latest and greatest. We live in an industry that is resumé-driven. RDD, resumé-driven development. Go out and find the job that's doing the latest framework so that you are marketable. That matters. As a developer you should be considering that and thinking about that but never look at it as a point of shame that whatever technology. If you're still building VB 6, you do you.

 

[00:27:49.564]

I'm curious to ask you a question, Jeremy. Joe made me think. He mentioned this harder than that, or this is easier, when he was talking about serverless and back end and front end. In general, JavaScript, because that's the theme, what makes something easier or harder? When you see that or you hear about it, what does that even mean?

 

[00:28:09.204]

Easier or harder, I would say your ability to develop, like you said, push code. That's what really important is pushing code. I think there are certainly platforms as you go down like C++ and assembly language, if I were to write a web app in that, it might be an amazing web app, but it would take me 5 years to do something that either of you two could whip up in Angular in 10 minutes. So when I say easier, I think of immediately easier to learn, easier to push stuff out. That's pretty much the two most important things.

 

[00:28:45.998]

And I think most people would agree with those two ideas. I think both of the spectrum, easier to learn, easier to actually deliver. But let's make up a fictitious program. Everybody who's watching this and listening, if you have questions about it, please chime in with it and we'll answer these. But imagine we just get all tasked, every one of us got tasked to build an app. This app is an order entry app for the web. Now go. Go build it. You've got a month by yourself to go build this. The decisions we each make from front end to back end are going to be dramatically, wildly different across the board. And what will drive us to make those decisions? Experience with those things, comfort level, knowing the confidence that we can deliver in that time frame. Does it mean we use stuff we already know versus new? Maybe not, if we feel confident we could learn something new in that thing. Now let's make it concrete. Jeremy, not knowing anything about your skills on the web, let's say we asked you to build it in Svelte today with serverless with Azure Functions. Could you go do that? Would it be easy for you to deliver and to learn?

 

[00:30:00.661]

I have never even touched Svelte, so I have no idea. I like the Azure Functions idea, so…

 

[00:30:09.629]

Now is that because you know Azure Functions but you don't know Svelte?

 

[00:30:12.447]

That's exactly what I was going to say. The things that I know---but if I were given a choice, I would probably hop into Vue or Angular or something just because it's easier for me. And another question for you is, am I developing it by myself or as a team? Because I think there's a difference there.

 

[00:30:30.901]

What does your team know? let's say Joe knows Angular and you know Vue and I say, hey, guys, we're going to go build this is Svelte today. Is your team experience an important factor? Is it the only factor? No. I guess what I'm getting at is, I think the easy and hard thing is something that everybody should think about. Because learning something and the time to get up to speed, maybe you spend a couple of days. What if I told you within 2 days you could, technologies x, y, and z, learn that stuff in those 3 days, and then build something over the next 6 months that's amazing, versus technologies x, y, and z that you already know and spending the same amount of time building the thing. Would that change the equation to they're both easy then? Really what I'm getting at is, I think asking if something is easy is a trap. Because what's easy for you, what's easy for me, and easy for a learner on Pluralsight, some people might take Joe's testing course and go, that was easy! Another person might go, that was awful. That was the hardest thing I ever saw in my life and I had to watch it 8 times. And I think it's not the skill set, it's not the intelligence, it's not the dedication. A lot of it is just, there's different kinds of learners, different kinds of developers out there.

 

[00:31:46.876]

Yeah, I would agree with that.

 

[00:31:48.087]

Tell me I'm wrong. I want to hear you say I'm wrong.

 

[00:31:53.362]

Well, the way that you defined easy, I'm a little bit down with. Like easy to learn, I don't think is the criteria. I go back to---but I'm going to say that easy is important, and it is critical, but the flavor of easy that---what I see as easy is easy to reason about, easy to understand. And these are the things that Uncle Bob and Martin Fowler talk about, that kind of easy. Can you conceptualize the code? Does your framework help you conceptualize? Let's throw out a theoretical. You can build something crazy and big in a million lines of Vanilla JavaScript, but to me that is definitely not as easy as building the same thing in Angular. I was building, oh, my gosh, what was the JavaScript framework right before AngularJS that was really popular?

 

[00:32:51.131]

Knockout? Ember?

 

[00:32:52.115]

No, the one after Knockout, between Knockout and Ember.

 

[00:32:54.518]

Backbone?

 

 

[00:32:55.155]

Backbone. I'm building in Backbone. I discover AngularJS and I'm literally cutting the number of lines of code that I write down by 90%. The new thing takes 10%. To build the same thing takes 10% as many lines of code in AngularJS as it did in Knockout. And I don't know whether or not I considered AngularJS to be easier to learn than Knockout, but it was definitely easier to think about, to conceptualize the framework. And I'm talking about a framework, but languages and frameworks do not have a clear dividing line. Languages, the technology choices that we make matter here. So I do think that easy does matter when it comes to that idea of being able to conceptualize your code. And the team, to your point, has a ton to do with whether what you build is a dumpster fire or not. If you're playing a drinking game, if you're up for playing a drinking game, whenever we play dumpster fire, take a drink. I'll drink my soda here, my Mountain Dew. But, yeah, I do think that matters. I do think easy matters from the perspective not of necessarily easy to learn, but easy to work with, easy to rationalize about, easy to think about, easy to conceptualize, componentize development, that sort of stuff. Some things are better at that than others, and I do think you can almost say objectively they're better/easier.

 

[00:34:14.185]

Yeah, I don't think any of them are easier to learn than others, to be honest. Because I do believe, I've seen people pick up Angular, and they're like, man, this just makes sense to me. And I think, arguably, people say Angular sometimes is harder to learn than React or Vue or Svelte, for example. But I've seen people with Angular, this is just the easiest one to me. And the think the "to me" part is where I'm focusing. It's relative. Everything is relative to what your experience is, where you're coming from. A good friend of ours, Dan Wahlin, an author on Pluralsight, he often tells me about how he used to go do training at companies quite a bit, and I used to do it with him but he's more recent at it, where he would teach folks who were recently in Java or C# how to use things like TypeScript. And they would pick up Angular much faster than they were picking up web frameworks that didn't have TypeScript baked into them because of the typings that they were comfortable with. That doesn't mean Angular was easier; it was easier for them. And I guess whatever I'm getting at is, I'd love it if we could toss out this whole idea of it's hard, it's easy, it's too complicated.

 

[00:35:20.339]

We've got a ton of cool questions that have popped up here.

 

[00:35:22.532]

Okay, let's get to the audience.

 

[00:35:24.486]

Yeah. What are your thoughts on low code and accessing JavaScript, JSON with something like Microsoft Power Automate? So I think the question's about low code technologies.

 

[00:35:40.721]

Love it, not for me, but I love it for people who don't want to work in the code. Think about all the new people and all the news jobs that are going to be created in the next decades. I sound like I'm working on the West Wing now with Martin Sheen. Think about all the new jobs we're going to open up when everybody can write applications with Power Automate or other tools. I think it's amazing. Remember Microsoft Access back in the mid '90s and how many people created applications who had no technology experience? That's not a bad thing. That's a good thing.

 

[00:36:11.786]

That's another way that social media can steer you wrong. I see a lot of developers railing against no code on social media, and I disagree with it. I agree with you, John. There are a lot of smart people in the world who are not technical, and this bridges that for them. So you have somebody that's extremely intelligent, creative, does great in our field. They've never written a line of code in anything. If they can grab one of these and start solving their problems with it, I think it's awesome. I don't think it's going to get rid of anybody's job or dumb down things too much or any of the criticism you see on social media.

 

[00:36:51.107]

I think I disagree with you two fairly fundamentally on this because---and maybe if I expanded into another point about what it really means to be a programmer. The idea that if you're smart you can build applications given no-code solutions, I disagree with because there's another aspect of building applications that doesn't matter what your relative intelligence level is, whatever that may even mean. But you cannot build applications, low code, no code, anything, if you cannot think through the process, though a highly logical, and when I say logical I don't mean street logic, I'm talking this highly logical. When you sit down as a programmer and you break down, when the data comes in, here's the places where it can happen and here's my trouble parts, you understand what that is like as a developer, if you've been a low-code developer your entire life, as long as you can go through that process that can help. But getting a business product-type person who hasn't done that mental exercise enough in their life to have honed that skill, and I don't know if this is a skill that can be learned or not. I've seen indications on both sides of that that it can be. But whatever it is, there is this process that you need the developer-type mindset to work, whether it's low code or not. And so if you have that, that's why I say, I always say, there's the idea that AI is going to program for us and all that sort of stuff, it's all garbage, or that we're going to make applications that business users are going to be able to now get rid of all developers. I think that's wrong. I think that's foolish. Developers' tooling is going to just get better and better and better. I mean, again, look at my AngularJS example, 10% of the lines of code of Knockout. You can call that low code when you cut down the number of lines of code by 90%, and you can get lower and lower and lower code. But in the end, you still have to think logically about the needs of the application, the user experience, how the data flows, that sort of thing. If you can't think through those things, you're not going to be able to build an application of any moderate complexity.

 

[00:39:05.142]

You have to know your problem. You have to know your problem and how to solve it. But I want to be careful where I definitely differentiate here, and maybe I don't differentiate. But I want to make it clear that what I'm saying is there's a really big tent out there, and right now only, picking a number, 10 to 20% of that tent is full of technologists that are in the industry today. I think there's a huge amount of space in this tent for people who aren't like us, who aren't like Jeremy, Joe, and myself, and others on Pluralsight today, maybe there are some that I haven't met yet on there, but who are the next wave of technologists, who are people who maybe don't write code, but solve problems. Maybe there's new ways and new ideas on how to do it, people who know their business problems well and can follow through using a Salesforce application to create forms to enter their data, process, and do what they need. And that's why I want to get away from, in my mind, that tent isn't just developers, but it's everybody who has an interest and a passion to do it and also has a business problem to solve. That's why I like these tools. And Power Automate's just one example. I mean, these things, there's plenty of tools out there that let people who have not necessarily done technology for 20 years jump right in.

 

[00:40:21.749]

Yeah, absolutely. And I agree to your points, Joe, for sure. From a developer's standpoint, one of us might look at that application and say, my gosh, this terrible. But does it matter if the problem is being solved for that person? If they built an app to where any of us would look at it and be like, oh, that's a giant anti-pattern. That's terrible. But if it's solving their problem every day, does it matter? I don't know. That's just one of the questions. I have another question here. What do you all think of Deno JS? Do you see it as a replacement of Node? I know that both of you have worked pretty extensively with Node and are probably familiar with Deno.

 

[00:41:06.480]

I don’t see anything as a replacement of anything. I can't think of a technology you could tell me, maybe I'm wrong here, where you say this technology can replace that. I just don't believe in that. I think, again, big tent, big space. The guy who wrote Node effectively wrote Deno or Deno, however we pronounce this, which, ironically, it's the backwards spelling. You just take Node and---anagram, right? But you take that and, I think it's cool, I think there's a lot of neat ideas in it. But let's go back in time, Node 10 years ago, when it was first starting out, or 8 years, I can't remember the exact time frame. It's 2020 and I can't remember what I did yesterday. But you look back at this stuff, Node wasn't a place I wanted to live and put my platforms and hang my business on when it first came out. I wasn't going to do that. And I don't know many people who did right away. So to me I think it's great to explore new ideas. And maybe it's time, Joe, we talk about how I disagree in JavaScript flavor of the week.

 

[00:42:10.932]

Nice, okay. 

 

[00:42:12.689]

And I think you're 100% wrong, man. There is no JavaScript flavor of the week anymore. You were around, you had hair, so did I, when every week, literally, there was a new thing, Batman, and Robin, and Superman, and I'm making this up now. But there were all these different frameworks and tools out there every week. Can you really say anymore than React or Vue or Angular is new? And those are the three biggest ones. There's Ember. I mean, the newest one on there that's really got any play, any mindshare, my point is probably Svelte. And even that's been around for a couple years now. So is there really any more of this new innovation? I mean, what's happening with JavaScript? I'd almost look storage JavaScript as, is it stale? Is something like Deno the thing that's going to kick it in the pants? 

 

[00:43:04.159]

Right. Yeah, no, interesting point.

 

[00:43:06.630]

No, you're supposed to say, no, I'm wrong.

 

[00:43:11.041]

Your criteria of does it have traction? Yeah, there's the big X-45, whatever they are, with traction. But I don't know, when was it, a few months ago, Alpine.js. Somebody's throwing that out. It's a better version of…

 

[00:43:24.614]

Or Redwood, yeah.

 

[00:43:26.250]

Crank, Crank.js. That's another one I saw. Redwood, yep, Redwood. I feel like the CMS scene is going through their flavor of the week phase right now.

 

[00:43:36.308]

Yes.

 

[00:43:36.449]

With a new headless CMS coming out every day.

 

[00:43:39.851]

To be fair, not as many as there were in the JavaScript heydays of the---you fall asleep for a week and you come back, and your thing's gone.

 

[00:43:47.651]

But I think you're---at least your point of, are people freaked out about the newest framework that's coming out, is that going to be the next biggest thing? I don't think people are looking that direction by and large anymore. But I still do think there's some possibility that we're going to see somebody come up with something.

 

[00:44:07.227]

Oh, yes.

 

[00:44:08.053]

I mean, AngularJS did something I don't think anybody anticipated was going to happen. And we haven't seen that---React did not do it. No matter what a React true believer would say, React did not do that to that same level. React just stole some big piece of what was there. But AngularJS just came through and just really dominated new web development for some time.

 

[00:44:35.905]

You're talking about inflection points in JavaScript, right? 

 

[00:44:38.290]

Yeah.

 

[00:44:38.453]

The way jQuery disrupted the entire JavaScript and web ecosystem.

 

[00:44:43.226]

Yes.

 

[00:44:43.632]

Agree, Angular did the same thing, because when AngularJS came along, there were literally 50 different tools. I built a what Dan Wahlin calls a Frankenstein framework. I built my own out of nine other tools, Sammy.js for my routing, and Knockout for my data binding, and jQuery for rendering and animations and GreenSock. It was a nightmare to keep 9, 10 things together. Angular was a disruptor, and I wonder what the next disruptor's going to be. Do we know what it is yet?

 

[00:45:16.852]

I don't know that we know what is yet. Is Svelte maybe? Svelte's unique enough compared to the others, but it doesn't seem like it.

 

[00:45:25.204]

To be fair, I love Svelte, I love Vue and React too. I think React changed the game. I think Vue changed it a little bit. I think Svelte changes it in a more fundamental than those two did by saying, we're not going to send a web framework to the browser. We're going to compile it on the server and send your JavaScript up there. But I don't know if any of those 3 are the disruptor yet in the way that we saw 10 years ago.

 

[00:45:52.817]

Yeah, could it be some compile to JavaScript thing? But Elm came along, and Elm is an amazing language. And it has its state management sort of like baked into in a way that is really unique.

 

[00:46:05.793]

But I'll bet you 8 out of 10 developers out there listening probably have never used or touched Elm.

 

[00:46:10.151]

Yeah, probably a reasonable number of them haven't even heard of Elm. So, yeah.

 

[00:46:14.848]

I only know it because of you, frankly, and our conversations offline.

 

[00:46:18.513]

Yeah, I talked very positively about it, even though it didn't do that. It wasn't an inflection point by any means. So will something else come out? Will it be a transpile to JavaScript thing, or will somebody else just have the right idea that will make everybody go woah?

 

[00:46:34.649]

Or is it Deno, Deno?

 

[00:46:37.207]

Is it Deno? 

 

[00:46:39.456]

What about WebAssembly? That's actually one of the next questions, is about WebAssembly, but that doesn't really have…

 

[00:46:45.191]

Nope, again, it's another friend who gets invited to the tent, but it's not going to fundamentally change what we're doing, in my opinion.

 

[00:46:50.923]

I thought for a while it could've, but no.

 

[00:46:54.351]

I think the beggest, beggest? the biggest aspect of Wasm, WebAssembly, is it's going to invite people to the web, it is inviting people to the web who previously wouldn't have come or were having a problem with based upon their experiences. For example, .NET developers who didn't want to deal with or they knew JavaScript but they just, you know, I know C# this well. I know JavaScript this well. I can get the job done, but I'd much rather prefer, much more effective up here, I think WebAssembly's going to get people like that an invitation to the tent where they're going to hang out and party a lot longer.

 

[00:47:32.574]

There's a question about, will Web Components replace MVVM frameworks? I think that's an easy answer: no.

 

[00:47:39.297]

Yeah, Web Components. I mean, Web Components is going to save the world, man. They're just, everything's a web component, but a web component, again, is a piece of an app. It's a very important piece.

 

[00:47:51.229]

I would use a quote from one of my favorite Christmas shows, Elf. You sit on a throne of lies, Web Components.

 

[00:48:01.536]

Watched that movie the other night. Love that movie. I love Web Components. And Vue, React, Angular, Svelte, all these things use some. But to say everything is a web component and there's nothing else left over, I don't agree there. 

 

[00:48:17.957]

Here's a cool question for you, John. Robert Lee asks, there's a lot of emphasis, and I assume what he's meaning is the two of us, talk about getting a product into production, but maintainability hasn't been mentioned. My issue with JavaScript written the way that John mentioned is that it's hard to maintain.

 

[00:48:32.890]

Why? What's hard? What's hard about it?

 

[00:48:37.039]

Hard, hard is quantity of time, like pain. You've had those jobs where you've maintained an application and it was painful. And you've had those jobs where you maintained an application and it was less painful.

 

[00:48:50.199]

I will say, my all-time favorite thing I love to say is I can write the biggest piece of garbage in JavaScript. I can also write it in C# or Java or Elm or anything else you want to put it in. Maintainability has nothing to do with the language to me. It's about the process of shipping. If you tell me to ship it and don't test, don't plan, don't review my code, do all those things to get it out the door, don't write documentation, don't do nothing but just write the code and get it out the door, the odds are when that lands, I'm going to be maintaining that thing for 10 times as long as it took me to write it. And I know that's true because I've lived it. And I'm sure you all have too. Writing something in JavaScript does not make it harder to maintain. Might be hard relative to each of us. But I would sit there and argue for 100 years about that. It's all about the process of shipping code. Oh, come on, you're supposed to take his points. Fight me. Let's go.

 

[00:49:47.799]

I think if you write it in TypeScript it's easier to maintain. I'm going to put that out there, as a general rule.

 

[00:49:53.023]

Easier than JavaScript to maintain, yes.

 

[00:49:54.927]

Yeah, as a general rule. To your point, if you write it bad---how many 2000-line files are in the application has more to do with the cost of maintenance than whether or not you use TypeScript or JavaScript. But as a general rule, TypeScript's easier to maintain than JavaScript. Angular's easier to maintain than jQuery. jQuery's easier to maintain than Vanilla JS. I think there's a few general rules that are okay to throw in there.

 

[00:50:21.439]

And these are hard things to fight too, and fight meaning everybody leans on their experience, saying, well, I've shipped code and I've had this problem, and no matter what I've done it's always been that way. That's why sometimes it's good to sit down, and I have a great quick story to share about this. When I was at a company, we were looking to deploy and replace a mobile application within 6 weeks. It had to be done because security certificates were going to fail, the devices were going to no longer be licensed. It had to be written for the mobile web. So we had to write this thing. We wrote it in Ionic, to be honest, because we had to get it out there quick. We sat down with these developers and the teams and the process we used was very important. It was more important than the code. Didn't matter that it was Ionic. Could've been any of these things. The fact that we sat down and we reviewed the code, we made everybody demo with each other, the code review process where you can't ship code without somebody else looking at it and approving it, and a lot of other little things like that along the way that we had made it such that when this thing rolled out, right before Christmas when the busiest week of the year was hitting at a very large place I used to work, and millions of people were going to use it with tens of millions of dollars, they didn't have one bug in production. And it was nothing for me. I'm like, yeah, this is the way we ship code. But I remember afterwards, the business unit coming to us and going, this has never happened to us before. We always expect there's going to be like a month or two of, "you better be up and around the clock 24 hours a day when this thing breaks." It's about the process. And it's not because I'm really good at what I do. Everybody can do this. It's all about making sure you do all the things in the process. Now how do you learn that? Some people say agile, or some people say TDD and watch Joe's testing courses or whatch Pluralsight. There's lots of answers to it, but---now, sorry, you hit on a hot button. For me this is a hot button. JavaScript, 100% you can ship great code. 

 

[00:52:18.629]

All right, so I'm picking some pieces of some additional questions, I guess some are kind of related. I'm just going to take a part of one of these questions here. What are the limitations of JavaScript that would cause you to choose a different language?

 

[00:52:31.711]

If I wanted to do something on the server that was heavy computational calculation processes that had a, you know, go crazy on 100 database calls with business calculations and message queues and all that, I probably would use C# or Java on the server. That's what those things do really, really well. 

 

[00:52:52.523]

If I could get away with a server-side rendered app, I would for sure use Rails over JavaScript. This is more of a statement. I'm currently a pure JavaScript dev. I believe another point to the typing conversation is how far lint tooling has matured for writing straight JavaScript. So I'm going to turn this into a question. John, let's talk about tooling. Is JavaScript now---the tooling story today in 2020 is so much different than it was in 2010 and in 2005 and in 2000, right?

 

[00:53:33.285]

Oh, yeah. 

 

[00:53:33.846]

Although, Visual InterDev, it could've been the peak.

 

[00:53:37.401]

Those 1997 tools, man.

 

[00:53:39.891]

Yeah. So here's a pretty reasonable question. Going to do a typical modern app. What tooling do you feel like matters?

 

[00:53:51.220]

I would never enforce tooling on anybody. When I worked at Disney many years ago, one of the early choices we made is, we were talking about what things should we dictate that the company must use, and what things should we allow flexibility on. And one of the immediate things was, bring your own developer tools. You want to use Vim or Sublime or, VS Code didn't exist early in the time when I was there, any of those tools. And we had a list of about 11 or 12 that people were using. It didn't matter. So those are the kind of things---and the reason I say that is, choosing the tool, to me, and putting that, imposing it on a developer is like saying, yeah, you can have a job here, but you have to drive a Nissan Altima to work every day. And if you don't drive---and it's got to be blue. And it's got to be four door, and you've got to drive it this way and come in through this entrance. It's very limiting and constricting. There's a certain level of, we must follow a guideline that you have to have at a company. I do agree with that. But I think you have to give these developers and technologists a little bit of freedom to say, you know what, I can run in vi and Vim, but these other tools just hold me back. Or I love all the things in VS Code. But to me it's bring your own tools.

 

[00:55:08.479]

You're being wishy-washy on this. You're so vague about this. Come on, linting. I'm not saying that you would go into a project and say there's no linting, this is stupid, you people are all idiots. But you're running the team. You are writing the code, you're the lead dev on a team of 10. Do you put linting in? Do you let people say, do you let one developer say, I don't want to lint, I don't care what the other nine people say?

 

[00:55:38.898]

That's a different question. Yeah, if you were going to do something with linting, I wouldn't choose it. I actually had to do this at a large company. Picking rules. So when you go to GitHub, everything matches? Like your formatting style with _____, or your linting, or anything like that? You pick a certain set of those, and you allow for exceptions and deviations with teams. And the teams can do those things, but the key is whatever you check in with those projects has to have the same rules. Because who wants, a great example is, who wants to run a project where every time someone does a pull request every single file in the project is changed because somebody had a different linting setting? I'd just reject it and be like, sorry, no. But do I care that you used two spaces versus four, if it's on the same project? Yes. If it's all on the same project with a linting file? Heck no. Bring your own tools.

 

[00:56:32.918]

Spaces or tab, John? Which is it?

 

[00:56:34.524]

Me? Honestly, I don't care. That's not what I care about. Semicolons, I'm semicolons all the way though. 

 

[00:56:41.280]

Semicolons matter. We found John's line in the sand, semicolons.

 

[00:56:46.245]

What about the most important question, folks? If you were a JavaScript framework, of the five or six top ones that are out there, which ones of those resemble which Star Wars character? Who would React be, Joe? I want to know. In the Star Wars…

 

[00:57:01.306]

Which Star Wars character would React be? React is Ahsoka. React is Ahsoka.

 

[00:57:06.577]

React is Ahsoka Tano. Why? And that's the female Jedi, right?

 

[00:57:10.067]

Yeah, yeah, yeah. Possibly my favorite character in all Star Wars, possibly. There's a lot of great characters out there. I think React is Ahsoka. I say Angular is Anakin, and so Ahsoka is what came out of Anakin, trying to take the best parts of what he learned. React was a reaction to AngularJS. 

 

[00:57:41.143]

Okay, so Ahsoka was a reaction to Vader, I gotcha.

 

[00:57:44.051]

Yeah. So Ahsoka and who she is is a reaction to Anakin. Look how meta this is getting. This is getting crazy meta.

 

[00:57:50.291]

See I don't think Angular could be Vader because that's Anakin, because he turns evil. I think Angular's more like Obi-Wan. Obi-Wan Kenobi was like this, I'm great at what I do, everything's here, I'm a teacher, I'm going to pave the way. But there's a path, and I'm going to slap your hand if you don't stay on that path, young Anakin Skywalker. And we unfortunately know how well that worked out.

 

[00:58:15.526]

I think Angular's Thrawn. 

 

[00:58:18.360]

Now you're getting niche where a lot of people have no idea what we're talking about.

 

[00:58:22.460]

If you don't know who Thrawn is, go read the books. All the books about Thrawn are, they're in my opinion the best Star Wars books maybe outside of the Republic Commando series. But the Thrawn books were great Star Wars books. And he was also in Rebels as well. But I think Angular is Thrawn. Angular's by far the most corporate-y of the frameworks, of the big 5, it's the most corporate-y. And Thrawn was very much, this is about order and structure. The most important thing is order and structure. Feelings are the least important thing. Order and structure matter. He's like Tarkin but without the evilness. Thrawn is just like, we have to have order and structure. The empire's good because it brings order and structure. That's what Thrawn was about.

 

[00:59:16.130]

I'm going to pick Svelte, and then you pick Vue after me. And for me, I say Svelte is an obscure, niche Jedi named Quinlan Vos. And for those of you out there who haven't read the books or seen some of the cartoons or movies, Quinlan Vos was effectively a Jedi who acted nothing like a Jedi. He was extremely powerful, very good at what he did, but he was kind of like the rebel, like the Fonzie from Happy Days, or if you're into that era, or even like the Han Solo was to the original Star Wars series. He's different, very good at what he does, but doesn't follow the same path as everybody else. And that's where I think Svelte is these days. It's got enough of the other frameworks where it makes you feel like those are comfortable. You can come from React, Angular, Vue and so Svelte and see things that make you go, I know that. But then once you get into it, you're like, the way this thing operates, it just dances to a different drum.

 

[01:00:13.161]

Trying to think of the Star Wars character that I think most fits Vue. I'm going to go with maybe Rex from the Clone Wars era. 

 

[01:00:24.121]

Ah, a clone trooper.

 

[01:00:25.066]

Yeah, so I think I would've made a really great argument for Ahsoka being Vue. Because similar to what I was saying, I see Vue as what people thought Angular was going to be. When people knew that AngularJS was dying, it was being replaced with Angular, I think people thought Vue, they were thinking Vue in their heads. And when they got Angular, it was different than what a lot of people thought it was, more structured, more process. They added more, they didn't remove it. And so Vue is what AngularJS, what a lot of people wanted AngularJS to become. So you can make an argument that it's Ahsoka, but I would say Rex. Rex is all about, just let's make sure that we take care of what needs to happen and take care of people, and people matter, and comradery. And so I think…

 

[01:01:17.296]

And it's not complicated. Let's just get the job done. That's Vue.

 

[01:01:19.805]

Yeah, yeah, exactly. Yeah, whatever it is, we can make this happen. So that's Vue.

 

[01:01:25.194]

Hopefully we haven't lost half the audience. Hopefully the audience enjoys Star Wars conversations. 

 

[01:01:32.464]

Oh, Han Solo, Vue could be Han Solo.

 

[01:01:36.112]

There you go. 

 

[01:01:37.435]

I know who Han Solo is, even in my limited knowledge of Star Wars. But is there any final parting thoughts either of you would want to give the audience here before we wrap it up?

 

[01:01:52.102]

It's been 25 years since JavaScript has come out, and it does get a bad rap. And know we talked a little bit about this, but I think it's really, really important. If you enjoy working with JavaScript, use it. Let it go in one ear and out the other when people talk bad about this. I've spent the last 10+ years just doing JavaScript. And before then, on and off based upon my first experiences with it. Whatever you're using, don't let somebody tell you it's the wrong thing. And I know it's hard when we're all of Twitter, myself included, talking about some cool new thing like Deno that we saw. But it's getting the job done. You've got to work to live, not live to work. So if 2020 teaches us anything, this stuff is not what's important. What's important is what you're doing in your life. So let it go in one ear and out the other. JavaScript's good, but if somebody is a naysayer, just let them talk.

 

[01:02:53.091]

I'm going to take a slightly different tack on that same thought. If you don't, JavaScript's good for your career. I'm going to put that out there. It so ubiquitous, it's so widespread, and there are things, like if you're going to build web apps, building web apps without JavaScript is possible, but it's difficult, more difficult than building it with JavaScript. Now I'm not saying just client-side rendered, like learn a framework, but JavaScript is extremely ubiquitous. So it's going to be good for your career to learn it, be aware of it, know it. It's good for your entrepreneurial endeavors, because being able to throw out a website and being able to get in and work with the JavaScript, the HTML, and the CSS is nice, helps out when you're doing your side project or whatever. So I'm going to go with, I'm going to put that up with JavaScript's definitely something that you should as a developer have a minimum, I don't care what kind of developer, you're the most scientific, using R, that's your day job, a little bit of JavaScript in there is easy to be able to throw up that website, to visualize whatever it is that you're doing. That's going to be my final though about JS and the web and opportunity speaking of name of this thing, opportunity. A lot of opportunities in JavaScript.

 

[01:04:05.478]

And one last final thought, go watch Star Wars.

 

[01:04:08.459]

Yes. Make sure you're watching the Mandalorian. That's good TV. That is good TV.

 

[01:04:12.932]

I feel like that might be directed towards me also.

 

[01:04:15.601]

I'm pointing at you, Jeremy.

 

[01:04:24.946]

Thank you for listening to All Hands on Tech. To see show notes and more info, visit pluralsight.com/podcast.