JavaScript Questions
===

[00:00:00] 

Emily: Welcome back to PodRocket, a web development podcast brought to you by LogRocket.

LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics. Try it for free at LogRocket. com. I'm Emily, producer for PodRocket, and today we're answering your questions about JavaScript. We're here with our panel of experts to answer the questions that you, the listener, have sent in to us.

Before we get into all the questions, let's start and welcome our panel. First, we have Josh Goldberg, open source maintainer, Microsoft MVP, and speaker who's working on TypeScript ESLint. Welcome back, Josh.

Josh: Super, thanks for having me.

Emily: Next, we have Colby Fayok, Director of Developer Experience at Cloudinary and GitHub star. Welcome back, Colby.

Colby: Pleasure to be here.

Emily: Next we have Paige Niedringhaus, Soft Software Engineer at Blues Wireless, and one of our very own PodRocket hosts. Welcome back, [00:01:00] Paige.

Paige: Hey, I'm glad to be back.

Emily: And finally, we have our other PodRocket host, and LogRocket engineer rounding out the panel, Noel Minchow.

Noel: Family.

Emily: So let's jump into the questions. We're going to go through some general questions.

We have a bunch of questions on TypeScript, and we have some ecosystem. questions. So let's hop into our general questions. First, we had a listener say to us, , prototypal inheritance is weird. Object oriented programming is arguably a gimmick in JavaScript. So should JavaScript more move towards a clearer architectural approach?

Noel: , I don't know. It feels, this is, I don't know. Gimmick feels like a very strong word. If so, is like every dynamic language, not really object oriented is probably the question that I would then ask. So how one writes JavaScript, sure.

You can like, I think if you're in a code base that you're maintaining yourself, you can write very object oriented [00:02:00] JavaScript and there's nothing stopping you. It might not be quite as. is like you're writing a static writing in a static language, but that is the nature of the beast. I don't see this like fundamentally changing anytime soon, but who knows, so maybe I don't see it happening though.

Paige: . I think it depends largely on who the developer team is that's writing the code. I think a lot of developers who are coming from more strongly typed languages like Java may feel a lot more comfortable writing classes and prefer to do that for JavaScript as well. But if you are a person who learns JavaScript first or is just more comfortable in that, then You know, functional programming seems to be extremely popular in the last few years, react leans towards that now.

And a lot of the bigger JavaScript meta framework. So I really. I think it depends a lot on what you're using as your framework for JavaScript as well as what your team has a preference for, has [00:03:00] experience with. I don't think that there's, like Noel said, I don't think there's really a right or a wrong way to do it.

I think it's based a lot on your preferences. Because JavaScript works both ways, which is the nice thing about it. It's pretty flexible in that regard. Whatever seems to make more sense to you as a mental model, I think is the more important thing, not. Having a prescribed right or wrong way of doing it.

Colby: I think there's some interesting points there, because some of the past teams that I've worked with, depending on the stack that they're ultimately familiar with. So the one team, for instance, was a really strong in Rails, and being able to see them try to apply those same concepts in the JavaScript world, versus just what I was traditionally used to, really actually helped me learn some new concepts, because I wasn't used to thinking it that way.

But it is interesting to see that dynamic. But ultimately, I do like the idea of having more Best practices, if you will, and guidance from a language level perspective.

Josh: Yeah, I take issue with calling it gimmicky. It's not. Like, how else would one do[00:04:00] class based inheritance in a language with a paradigm like JavaScript? I'm sure there may be a better approach now that we've had decades to iterate on it. I think there's a difference between classes and object oriented in its terminologies.

They just happen to very commonly be used together and as has been said it largely varies by team, by area, by frameworks you're using, how much classes and or object oriented programming you're doing. Yeah, I don't know. It feels like the ship has sailed on this one. JavaScript's not going to fundamentally change its classes and it, we, the chance to do that was quite a long time ago.

Emily: Next question. Someone said, I've heard about JavaScript's ability to work with an event delegation model. Could you explain what that means? And also, if it's related to multi threading, multi processing using JavaScript.

Paige: So it has next to nothing to do with multi threading and multi processing with event delegation. It really has more to do with the way that , let's say you have a list of objects [00:05:00] like a checklist of things that you want to cross off or add to. Update all that good stuff instead of having to put an event listener on each individual object in the Dom, you would instead say, here's a parent container that goes around all of those objects and you would have the event be the thing that would trigger that, that event listener that's on the parent container, for instance, so it just cuts down on the amount of.

event listeners that you have to have in the DOM at any one time. It makes it easier if you're creating or deleting different things in that, in within that parent container. It's just a more performant way to handle large lists of things that could be changing or that the user could be interacting with in some way.

So it really Just is a way to handle, yes, I have a lot of things that could be changed, but instead of them each having their own identifier and way to interact with [00:06:00] them, it's their parent that has that identifier, and then it just knows based on their ID or some other way, this is the thing that's been clicked, and this is what I should try and do now that it has been clicked.

Noel: Yeah. I'll just add don't overcomplicate this one. If you're writing front end code and you're like putting click handlers on high up things, like you are using. Delegation. There's not that much magic happening there, so.

Emily: Our next question is a linting question, which I think Joshua like, what is the best approach to enforcing new linter rules on an older project without over and cumbering engineers who must touch that code?

Josh: I would sure hate to over encumber our already overly encumbered engineers. I love this question. Thank you. Whoever asked it. Great question. First of all, I'd say learn linters are changing every so often. And most teams I've, in my experience, most of the developers aren't super familiar with what each of the lint rules do, what the difference between say the linter, the formatter.

The type checker are. So it's helpful [00:07:00] just to have a, whatever your team calls it, presentation brown bag and so on, to get everyone on the same page. But yeah, what I normally do is if I'm on a project that hasn't redone its linting config in a while they're two alternate approaches. One is the do everything all at once, which is to wipe the config, save it somewhere, start from scratch using the recommended presets of slint, type two slint, react, whatever languages or frameworks you're using.

Get it as strict as you could possibly want it, with all the awesome things you might enjoy, and then disable rules on a per line, per file, per config basis, depending on how many violations they have. For each of the rules that are giving you a lot of pain, you can set up a meeting with your team to discuss.

Are these rules actually valuable to us or should we just shut them up and ignore them? Another approach could be to start adding in things incrementally. Like if you, let's say, aren't using the React hooks rules and you're on a React code base, you could try just that plugin and again disable rules on a per line, per file, per config basis as you need.

[00:08:00] Lastly, though, I would encourage teams to set up some kind of communal standard, depending on how big your company is, you might have a web platform team or not. But having the choice of what rules get enabled become a communal, we all care and participate, rather than one small group of very opinionated people forcing their opinions and cumbering us with them.

I definitely recommend the communal approach. Oh, and there are a few good tools for this. My favorite one, I think, is called ESLint Nibble, which lets you, it has a little tooling around it, incrementally adding in ESLint rules. Ta da!

Colby: Yeah. My interestingly, my minds went immediately to the formatting aspect of this the effects of the linting which is not so much on the TypeScript side, but on the code style, so trailing white spaces and things like that. And the. It brought back a memory of a younger more naive Colby, where I implemented a linting that everybody was down for, but it linted a bit too much in every single commit and that frustrated some people not being able to actually see the code changes.

[00:09:00] So you want to try to make sure that you're also not just doing blanket formatting unless you know you. talk to the team and everybody's understanding that you lint it all at once, get through it, or if you're doing it incrementally. But just try to think about how that affects code reviews beyond the actual just linting itself.

Noel: what I've seen done in the past on like big projects with lots of files where they didn't want to overhaul things. You can utilize tools like Git as well. So like, have lint rules where you just , take your Git diff output and pipe that to the linter on changes so as you touch files, those are getting updated but you're not like trying to take on the whole code base at once Google it around.

Yeah, you can. Find some different configuration options to not have to try to knock it all out at once.

Paige: Yeah, one interesting thing that one of my teammates did was he wrote a script that would run with our github actions So every time a person pushed a new PR commit or anything like That would actually run through the whole project Count the amount of lint that was there and then run through the PR and count if we had added any lint [00:10:00] with the idea being always try and at least have the same amount of lint.

If not remove a few while you're going through. So it, it took a little bit more manual work and he is really good with shell scripting. So he wrote the entire thing with a shell script to just go through and lint like that. But. It's really easy then to look at the output, find where the lint errors are, or just, fix a few as I'm going through adding a new feature or changing something in the code base.

And slowly but surely it'll continue to improve. So that's also something that you could do if you want to.

Josh: I love that. I saw a talk recently about how the LinkedIn folks did it. It was from, pardon the pronunciation, Chris Wing, or Chris Wing, from LinkedIn. They had a whole dashboard set up for that, which I would love to know if it was done with pure shell scripting. That sounds very intense. I, yeah I also have previously used linting and other kind of infrastructural incremental improvements as excuses to pair or [00:11:00] mob program with people, which is, I think, a generally really good team practice.

It gets you communicating with each other, better personal rapport, better progress. It's like a pull request review as you write the code. It's nice.

Colby: Are we team commit hook or are we team CI for formatting? I'm personally commit hook.

Paige: I am personally format on auto save in VS

Noel: Yeah. If you can get the, if you can get the rules set up, so all devs like hit control S and it happens, I feel like you end up with less of those like grossness things happening in the tool chain, but that isn't always practical for large teams. And I get it. 

Josh: Yeah, fun fact. I'm strongly team on save and on commit hook and make sure it gets done in CI. But indefinitely typed, which is one of the biggest repositories on GitHub in the public. We actually decided not to add it on save. Sorry, an on commit or a CI check for formatting. We just run the formatter every time there's a push to the main or master branch.

And the reason why is Novice developers or people who are new to the project tend to have a hard [00:12:00] time with these tools. So even a tool that runs Prettier or Deprint or whatever in CI and then pushes a commit some people don't understand the concept of get, push, and pull. So in open source land, that can be a little more difficult.

Fortunately, if you're on a team with people I sure hope you have the ability to mentor folks to the point where they can work with that stuff. But it is a little different in the open versus, corporate.

Colby: I've always liked the idea of the pre commit hook because it allows somebody to write how they want, so maybe they don't want to use semis. They should be using semis, but if they don't, at least the formatter will pick that up and not have to create that extra commit or whatever downstream.

Emily: . Next we're going to talk about performance. This listener said, Optimizing front end performance is crucial. What are some advanced techniques or tools you'd recommend for improving the loading speed and responsiveness of JavaScript driven web applications, especially when dealing with dynamic content and animations?

Noel: Yeah, this is a tough one. Cause it's very It's very situational. Like it just depends on what the project is doing and where these performance impacts are coming from. You can use the [00:13:00] browser tools, like use your in browser tools, assuming this is just like a normal web app.

You can run your lighthouse report. It might give you some stuff that's like easy, low hanging fruit that you can take a peek at.

Paige: Server side render as much as you can. If, use Next. js, use SvelteKit, use Astro. whatever doesn't have to be dynamically generated on the client don't, if at all possible. There's, there are so many ways, but as Noel said, it's really, it depends a lot on what is causing the performance slow down to first contentful paint or something like that.

Is it a giant SVG? Is it something that you can maybe scale down? Or is it an animation that you can lighten up? There's, it really depends on what the issue is.

Colby: And I feel like I have to say something about images and videos, given who I work for, right? No matter a lot of the frameworks we have built in ways to optimize your images and videos and making sure that you're loading them efficiently as well. So making sure you're [00:14:00] loading them lazy loading and responsively and all that stuff, just to make sure you're delivering as minimal as you can, which will go a really long way.

Cause generally images and videos can take up the vast majority of the page size, depending on how much you're actually serving.

Paige: Actually, that's a good reminder, Colby, that just made me think of something else, whatever you can defer in terms of loading onto the page at first in terms of, and I'm thinking of like third party scripts,, like any of those analytics and user tracking tools that you might use to better understand how your users are interacting with your website.

Defer all of that as much as humanly possible. And a lot of frameworks now give you options to do that. Next. js I know has a strategy for loading scripts that I think is called Lazy Onload. And there's some other ones. But whenever possible, just make sure that third party stuff that really isn't critical to a user interacting with your website is pushed off of [00:15:00] the main path as much as possible and just stick to what needs to be there for the website to work.

Colby: And that reminded me of another thing even yet. Even lazy loading the scripts. Or dynamically importing lazy loading scripts. Not actually importing those. And I don't actually know how that works under the hood. But being able to only asynchronously import it when you need it. Or for instance, if you're loading a YouTube video and it's down on the page, you can only load that YouTube video once somebody's actually going down using something like Intersection Observer.

Emily: uh, We had a listener say that one of the areas I'm currently struggling with is mastering asynchronous programming patterns in JavaScript. While I'm familiar with Promises and AsyncAwait, what are some best practices for handling complex asynchronous flows and optimizing performance?

Josh: Have you tried linting? TypeScript

BS Lint has a few good async, or promise, or thenable oriented rules that'll help you at the low level. That won't help your entire application architecture, but I've seen those rules catch quite a few small mistakes. Especially no floating promises, and no misused [00:16:00] promises.

Paige: One thing that I would say promises are fantastic and it's great that you as a listener have a good understanding of them. Promise. all is a really useful tool to have if you have multiple promises that you need to get data from, but they don't necessarily rely on one another. You can just have them all go out at the same time.

touch the data, bring it back, and then render it as one large piece of data or, format it however it needs to go. There's things like throttling and debouncing, so instead of a user typing in one letter and you go out and try and auto complete it, you wait some milliseconds to actually try and Go find that phrase once they have finished writing something, or they have stopped to think about, what the next thing is that they're going to search.

There's caching, there's lazy loading, there's code splitting. There's a lot of things that you can do once you realize that you have some performance issues or [00:17:00] things that you want to improve in terms of load time. It just depends on how you would like to go about solving it. Those are some of, I think more of the popular and a lot of libraries offer these kinds of things built in or very simply easy to access.

So I would start looking at those kinds of things to help you with your large asynchronous operations.

Colby: Yeah, and if you're doing a lot of concurrency too, you might want to consider using a library that helps limit how many requests you're actually trying to make at the same time. Something I've used lately is PLimit. He's a common GitHub open source creator. I forget his name. But it's, what it's going to do is allow you to specify how many at a single time, how many requests, or asynchronous, How many promises you want to execute at a single time.

That way, every time one finishes, it goes on to the next and basically creates a queue that you don't have to manage yourself, that the library will handle. But if for instance, you're hitting the same API 20 times, but they only allow, 10 per second or whatever. That's a good way to manage not spamming that end point.[00:18:00] 

Emily: Next question. What are some recommended methods and tools to help someone debug? Is there a flowchart one might follow to understand how some systems work to get results when developing an application?

Josh: I really like taking a debugger especially if there's some kind of end to end test inside the application source that you can run with a debugger running. If it's a web app, I'll typically use the Chrome, yum, or Firefox dev tools. If it's a command line, I'll use VS Code, node dash, inspect, dash, BRK.

is a good flag that you can search for and see related resources to. But also reading the unit tests if they exist is a really nice thing, and also good pairing with breakpoints. Those, I, one of the reasons why I really like, in many cases, having a lot of unit tests is because they can explain to you discreetly what each part of the application does, and then you can piece those together too.

Colby: I know console log is a running joke and I'm all for that. But seriously, like it's also important not to overthink [00:19:00] it. If you have a serverless endpoint that's failing for some reason, throw a try catch around the logic and log out the error and see what it is. It's a simple mechanism, but it could help, identify exactly what's happening.

Paige: Yeah, more often than not, console log is still the first thing that I reach for when I'm trying to figure out why something isn't working the way I expect it to. But then, to Josh's point, debugging is also great, and it's really made leaps and bounds in terms of how easy it is to add breakpoints in the console and step through code.

Even cause I've done it before in backend services and Java services, and it was great using some of the tools that were available then. But it really has gotten a lot easier to do it in the browser as well. So I would definitely recommend that as a next resort. If console logging hasn't helped you figure out what the issue is before.

Noel: I think people, most people probably know this, but not everyone does is like debugger is a keyword in JavaScript. Like you can go [00:20:00] write a debugger statement that the browser will then respect. If you don't want to go find the file on the front end and open it in DevTools and you have it open, just like type debugger, refresh the page and you'll hit that breakpoint.

It'll just work. It can be a big time saver. If you don't know that's possible.

Paige: Pro tip.

Noel: Yeah. 

Josh: Two things. One plus one to the console log being, I console log constantly just incessantly all over the place, whether it's debugging unit tests or just figuring things out. It's a huge part of my life. Also, and I'm sorry if this comes across to anyone's condescending, I don't mean it as read the code.

It's real tempting to look at a large thing and not understand it at first and feel like, oh no, I don't know what's happening, someone help me. But reading code, like really deeply reading code that you did not write and you do not understand is a skill that can be hard at first but is really valuable to try building up.

So any combination of the strategies of debugger, debugger semicolon, console log, reading the thing, working with someone else to explain it to you, that's all really good stuff to, to practice.

Colby: Absolutely. Like even just simply, you can usually find the function name that's failing, right? Go to the [00:21:00] open source repo for that project and just search for that on the project. And you can start to trace where that's coming from.

Emily: Great tips. And before we go into our TypeScript section of our questions, I just want to remind everyone that this episode was brought to you by LogRocket. LogRocket offers session replay, issue tracking, and product analytics to help you quickly surface and solve impactful issues affecting your user experience.

With LogRocket, you can find and solve issues faster, improve conversion and adoption, and spend more time building a better life. Product. All right. So let's move on to TypeScript and JavaScript questions. The first one a listener asked, will we continue to need TypeScript? Is JavaScript going to accommodate declaring types so that we can do away with the transpilers and so forth?

Josh: Sorry, what is TypeScript?

Colby: I 

think we just let Josh has entire section, right?

Paige: , I think that we [00:22:00] covered this a little bit already in saying that the JavaScript ship has sailed. I don't think JavaScript is ever going to have types built into it just because there is so much JavaScript powering the web now, and it would break so much of the internet if it.

Suddenly did support that. So I don't think so. 

Noel: Is an ECMAScript proposal. And this may be what this listener is referring to. And that I guess at least my understanding of that proposal was that the goal was to make it so the things executing JavaScript recognize what type declarations are and essentially ignore them.

So like we could write our, we could write TypeScript or something akin to it, like very similar TypeScript or like flow or something and then. We could just run it without needing to transpile, which is like maybe a more interesting discussion and like maybe we will, but we'll still effectively be writing TypeScript at that point.

We just might be able to skip a transpilation step. So I guess that could be cool is maybe my answer, but I don't know if it'll hugely matter in our [00:23:00] day to day workflows.

Josh: Yeah, it's important to disambiguate here. There is the syntax of TypeScript, which is a bunch of stuff added onto JavaScript, and essentially acts as comments in your code, which is what the ECMAScript proposal is suggesting, built in those comments into JavaScript. And then there's the type checker, which is...

Significantly more complex, way more difficult to write and needs to be, taught a little with a lot more depth than the syntax. For types there are projects that use just the syntax for types that exist already in JavaScript. There's this community standard called JS Doc and then uses the TypeScript type checker without ever using any typescripts syntax.

So the two do not necessarily need to go together. You can actually write types of code with the typescripts syntax without type checking it, which is a real pain in the butt. So yeah, I'm excited about this proposal to add types as comments to JavaScript. But the type checker part of what TypeScript provides is, as Paige said, not going to be added to JavaScript [00:24:00] anytime soon.

Years and years decades.

Emily: Next question, , what is a good way to package a library for both JavaScript and TypeScript?

Colby: Doesn't that just work when you, isn't it compiling to JavaScript? When you do that, my naive answer.

Paige: Well, I was going to say, I think that Colby, I think you're right. It does compile down to JavaScript. But one thing, cause I've actually tried to build a library recently that was compatible for both. One thing that seemed relatively easy because it started out as a JavaScript library was to just add a D dot TS file that has the types.

So you can install them separately if you need them in a TypeScript project. But if you just want the JavaScript base library. That's available too. Just have it as have the types as a separate library, which I've seen a lot of libraries do and allow people to install it if they need to.

But if they don't, they just have to install the base library. That's 1 way you could go about it.

Colby: Yeah, my understanding was always that when you're using a project even if it's vanilla JS, it's still the [00:25:00] same project. But once you click on the TypeScript on your project, it basically can just suck in all that extra goodness, right?

Josh: Yeah, as long as you have the corresponding entries in your packages, JSON, if you're doing ECMAScript modules, things are good. The TypeScript team shout out to them. They just published a huge guide on their website, the typescriptlang. org website. I think it was led by Andrew Branch that explains why ECMAScript modules are a whole thing, how it got there, and how TypeScript deals with it.

So I'd highly recommend that documentation resource.

Emily: Going back to performance what are some advanced TypeScript compiler options and settings that can significantly impact build performance and output?

Josh: TypeScript shouldn't be a bottleneck in your build system. It often times for folks in larger projects is. I would suggest reading through the TypeScript Lang. org docs on this. You might be missing something like strict true. or isolated modules. I always forget what that one is called. In general, if you have a giant project, I'd recommend using TypeScript project [00:26:00] references to split up different pieces of it so that they can be individually cached and rebuilt.

TypeScript project references let you have a different TS config for different areas of your project, like how Monorepo lets you define different packages. And then lastly check out some of the work the Bloomberg folks have been doing. I forget the name of the talk from TypeScript Congress.

I hope we can link it in some notes somewhere. But they're working with the TypeScript team on adding much more cacheable, parallelizable TypeScript builds to TypeScript. So that type of stuff is exciting. But again, that's for the huge megacorporation scales. The vast majority of projects TypeScript type checking should not take a significant amount of your build pipeline compared to say building a production website or optimizing images.

Not that you should be optimizing images every build. That seems like a lot.

Paige: Yeah. I really, I don't think I've ever thought about trying to speed up the TypeScript portion of my web apps, to be honest. It's never seemed to me to be a performance issue. So it might also be one of those things [00:27:00] like don't try to optimize for it until you actually see it being an issue. Just to optimize for it.

Emily: Final question in TypeScript are there specific bundling or tree shaking techniques that developers can use to optimize TypeScript output in their production builds?

Josh: This isn't a TypeScript question. This is a JavaScript question.

Emily: Good thing it's a JavaScript episode.

Josh: TypeScript is just an extension on top of JavaScript that lets you do things with types. It doesn't significantly change how you're writing your application, for the most part, unless you're doing some weird stuff. So if you're talking about techniques for tree shaking and bundle optimizing with JavaScript apps, then yeah, use something like Webpack Bundle Analyzer.

Make sure that you're not causing side effects in files. There's a side effects option, I believe, in Webpack and other bundlers. But again, this is a JavaScript thing. If you think TypeScript is causing you issues, Might be a misconfiguration on your end. You should be able to use the same transpilers, buddlers, and so on, JavaScript and TypeScript, ESBuild, [00:28:00] SWC, Webpack, whatever you're using.

Emily: . And we're going to move into JavaScript ecosystem questions. The first one came from a listener who said, How do we keep up with new frameworks coming out and stay up to date with JavaScript development? More broad, but... A lot of people did ask this question.

Noel: Well, There's this cool podcast you can tune in.

Paige: I was just going to 

Emily: rock it. 

Paige: it's great for keeping up but seriously, podcasts are something that I enjoy listening to tech podcasts that are front end focused. I subscribe to three, three or four different weekly newsletters that are just roundups of interesting JavaScript changes.

There's one that's react focused. If you're into react writing, react code. They gosh, they've got a lot of them just HTML and CSS and kind of front end in general. Getting just seeing what the headlines are, even if I don't read the articles [00:29:00] or read every article has been really helpful for me to stay up on what's new and great in the front end world.

Colby: I think it's worth also addressing The need to stay, up to date with the latest updates coming out and, if you're just interested in that, absolutely, try to learn as much as you can, but you don't need to make sure that your production applications at work have every single latest update, but that said, if you are just generally genuinely interested in learning this stuff, I really just encourage people to build something, whether that's one of the clone apps you'll see on YouTube, create a, I don't know, an Instagram client or something like that, or just rework your blog again.

Now, the amount of times I reworked my blog, just because I wanted to try a new framework. It's, it, it sounds silly, but it's an easy way to test it out. See if it's something you actually enjoy and learn all the tech that's involved in it.

Emily: I have a question for myself. I do find that Twitter slash X is usually the place I go to find people who are talking the most about what is [00:30:00] happening in not just JavaScript, but web development in general. Do we feel that This is still the main place where people gather to talk about things and release things and everything or do you see a shift in people moving other places?

Cause I follow all the newsletters, podcasts, all that, but I still do find that Twitter is the place where like you go to find things out before anywhere else.

Colby: I'll just use the word, unfortunately.

Emily: There.

Colby: No, there has been a few attempts at a shift, but nothing really stuck.

Noel: I think we might be on the cusp here. Like it feels like we may be getting towards the point of critical mass leaving. I think like just this morning it was like somebody like Slack spun down their official Twitter account or something. Anyway. Yeah. So we'll see. I don't feel like we're there.

Yet though, like it's fragmented. There's people trying stuff. You can tune in on other platforms, but nothing as a 

Paige: Yeah, [00:31:00] my, where are people going though is the question. Are they on Mastodon? Are they on Blue Sky? Are they on Threads? That's what I don't, cause I, I feel like I'm on Twitter a lot less and get a lot less. valuable content out of it, but I don't really know where everybody's going, or are they going to different places, in which case it will be much harder to keep up.

Emily: It does seem very fractured. So keep listening to PodRocket in the same vein. Another listener , said that they work , extensively with JavaScript frameworks and libraries like React, Next, 3JS. What are some of your insights about the evolving landscape of JavaScript frameworks and libraries?

What do you see these evolving in the future? What do you hope to see? 

Paige: There seems to be a very large trend towards, server side rendering is the biggest thing that everybody has been on about for the last few years. There seems to also be a pushback on [00:32:00] making frameworks simpler to get started with. Svelte is a great example of that, Astro, Solid. It's less of a barrier to entry, which was a nice thing about React when it first came out, but since has gotten a lot more complicated to be able to do well, I think.

So it seems like the frameworks are trying to make it easier for in, for beginners or for people who are less familiar with them to get started. And that's something that I really appreciate because, like you said, I want to try new frameworks, but if there's a whole set of documentation that I have to go through to even get a hello world stood up, it's probably going to be a lot less likely that I will try it and then continue to stick with it for any length of time.

That's what I see is making it easier for people to get started. And then as they get further along building applications or trying things out, then it starts to get a little bit more complicated or teaches them, new ways to do [00:33:00] things that are a little bit more complex, but ultimately result in a better experience.

So I think that there's. It's like having levels of investedness in frameworks, and I think that's a really cool way to approach it and try to, make it accessible for everybody.

Emily: Last ecosystem question. We got a lot of people asking this as well. But is it really worth learning React in this React crowded market?

Josh: Yes.

Paige: yes. 

Josh: Maybe. Depends on your situation. There are many good options here, and many of them are worth it. Can we define worth it? Is it, do you mean worth it compared to all the other options? We randos on the internet could not possibly answer that for any one individual. But in the abstract, is it generally a good thing to learn?

Yes, React, Svelte, Vue, Solid, Astro, Next. js, Remix, all of these things are fantastic things to learn if you have the time.

Colby: The only thing that I might add is that, react is always going to be a safe bet. One of the other ones might [00:34:00] be more interesting but it's just going to add a little bit more risk as the market's just not quite there.

Paige: If you want a skill that will transfer across a lot of different companies, jobs, roles, Knowing React is a very good one to have. A lot of people are looking for it. And if you can do it well, you'll be, you won't probably have an issue finding roles and jobs for you.

Noel: Yeah. There's still angular is still like probably the second most used framework and we don't even talk about that half the time anymore. So it's not like it's going to be react is going anywhere super quickly, like it's all there's room for lots of frameworks and tools here, so don't sweat it.

Emily: Uh, And I have one bonus question because I don't really understand what it's asking, but I thought it was funny and wanted to see if you guys understood. Does NPM really have to be a disaster?

Paige: Thank you. 

Josh: I take such personal offense to this question. It's not a disaster. It's not a disaster [00:35:00] in what ways there are flaws with MPM. For example, it's very difficult to ship like operating system specific distributions of packages, which is why if you MPM install SWC, you get like the Mac and the Linux and the windows distro versions of it.

But that's being worked on. I think it's very exciting to be a package manager right now. We have Yarn and pnpm innovating. I personally really like pnpm for my projects. I think, if anything, npm is a smash success. And it's an incredible achievement. And oh my gosh, can you imagine JavaScript without npm?

Paige: I think lately NPM's been getting some more flack because of things like malware and malicious maintainers taking over some popular packages, but I don't know if that's really any better in any of the other programming languages. I don't really keep up too much with the Python communities and PyPy or what's going on in Golang, so I can't speak to those.

But by and large, when you think of the amount of stuff that is on NPM and the amount [00:36:00] of time it has saved developers from having to hand roll all this sort of stuff on their own, it's a great. Great thing there. Yeah, there are gonna be some bad actors But that's just what comes with having a very large and successful ecosystem So you just got to take it and there's a lot of good people who are trying to mitigate those sorts of things So there's a lot of a lot more Benefit to it then I think that there is Messiness to it.

Colby: And I think it's easy to forget how accessible it's made building complex web applications for the world. It's, what Josh was saying, it's an amazing feat. And, there are some things that it can learn. If we think back, it learned a lot from Yarn and it tried to pull some of that knowledge into the core NPM.

And, hopefully that same thing will happen as we see other package managers, it'll shift and learn from its lessons or lessons learned. Thank you.

Emily: think that's a great note to end on. Thank you again, everyone for joining [00:37:00] the panel and answering these questions. And if you're a listener and you have a question about web development, be it TypeScript, React anything out there you can message me on Twitter. Or X. We're still here.

Emily K Kettner and I will link that in the show notes. And we might feature your question on a future episode. So thank you again, everyone. 

Paige: Us. Thanks for having

Colby: Thanks, everybody.

Noel: Thanks.

Josh: Thanks.