Episode 007: Considerations for Choosing a JavaScript Framework

Angular? React? Whatever the flavor of the week is? There's a lot that goes into a decision of which JavaScript framework to choose - or whether to pick one at all!

Transcript#

Claire:

Hi.

Steph:

Hey,

Claire:

I'm Claire

Steph:

and I'm Steph.

Claire:

And this is Word Wrap.

Steph:

So these days the modern web can strongly seem like it's weighted towards a JavaScript world. And there's also a decent amount of debate in what framework you should pick, or if you should pick a framework.

You've heard us talk before that we are both fans of sticking close to vanilla web technologies as you can. But of course there are reasons where a framework is going to make your life easier. So we'd like to kind of look at what some of those decision points are to help you in making that decision.

Claire:

Yeah. So I think it comes down to a lot of different things, but first thing is what is the problem you're trying to solve. If you're just trying to solve, you know, like create a brochure website or, um, and by brochure website, I mean, like, you know, a portfolio website where you have like about you and then like what you've worked on and, you know, maybe links or something like that - probably don't need a JS framework for that. Um, really don't need, you know, just a big old React library or anything like that. You could probably get away with - and I would probably recommend - something that is more like static site generation, like Eleventy or something like that.

However, I find myself using frameworks most when I'm at companies, which is in my opinion, the reason why they exist.

For example, Angular probably shouldn't exist in a personal capacity. Um, it is very much a business needs to get business done kind of thing. I dunno. Maybe, maybe I'm wrong about that. That's fine. That's my general feeling. And then react was, and it can be, and it, and it generally is marketed towards this, but it's supposed to be similar to web components in terms of like, you know, very small things, but it just generally gets overridden with like, you need routing and you need state management and you need this and you need that. And then you end up becoming Angular.

Uh, and so, yeah, really the, the first question you have to ask yourself is what is the purpose of this website. And whatever you choose, you know, if you use a JavaScript framework, you're kind of locking yourself into like an ecosystem. Or at least making it harder to jump from ecosystem to ecosystem. Um, even though it is just JavaScript, it's more complicated than that when it comes down to it.

Steph:

Yeah, you're totally right. Um, and, I think that there's a, the gray area comes when your... in terms of using it for personal stuff is - obviously personal stuffs like a super great way to learn those frameworks. Which, of course that's, uh, you know, that usage of it is encouraged. Um, but I heartily agree with your point on if it is for maybe like a client and literally all they need is a form as the only functionality on there. Well, these days you can get by with doing that with something like Netlify where you slap a data attribute on it and they take care of the rest. Um, you know, you might still need a small library. Um, if you need assistance providing any validation on that form. So, you know, things like that,

I think that's where it's becomes harder to decide "Do I need a framework or not?" Is sometimes you get into those situations and realize actually this functionality is more complex than I originally thought. I've definitely encountered that in my past life. Um, but in my past life, the only tool I had readily available due to organizational structure was jQuery. And that was fine. Right? And we all got by with that for a very long time.

So, um, in today's world, you know, what would you say are some additional kind of consideration points of what you know about the frameworks out there?

Claire:

Um, I mean, uh, for some reason when you say that first thing comes to mind is performance. But I also think barrier to entry is another thing. Uh, you specifically mentioned clients and I think that's a really big point to make because for a lot of client like freelancer relationships, that relationship ends at a certain point. And they have to maintain it or they have to use it and like possibly scale with it.

So, you know, it's not just a, Oh, I know Angular. So I'm going to create their site and Angular kind of thing. It's got to be more of a "What is the client going to be able to use after the fact? After I'm out of the picture and I've moved on to a different client, what are they going to be able to do?"

If they tell you they're really good at HTML and they can do that stuff, um, maybe a static site generator is probably pretty good. Like, you know, some folks have made some pretty complex websites out of static site generation. And there might also be the aspect, like in my case, you know, when I was really learning Java script and I was really learning like the ins and outs of a lot of different like language functions, like how to work with arrays, that was all in an Angular context.

So although I was writing JavaScript, I kinda like didn't know how to get to the point where I was manipulating arrays and stuff like that. And so I would fall back on Angular and be like, okay, I know how to do it in this context. And if that's the case, that's understandable. I think there are ways to mitigate, like, passing that off to a client.

Steph:

Yeah. And in my own experience, trying to deal with that too, um, the point about what do you have as knowledge? Obviously, that's a huge factor when you're trying to approach a project. Um, for example, I, I also, in my learning didn't really, really learn JavaScript until I started working with React. And then I sort of ended up learning both kind of side by side. And then kind of as a side effect just of what else I wanted to do, kind of picked up Node and things too. But, um, for React, um, for what I was having to do with that, what you said really struck me because that's how I really actually learned to work with arrays. And I've said before, arrays are pretty much the thing that you work with most often, if you can learn to work with arrays you can conquer whatever programming language you're trying to do I think at the end of the day.

But yeah, that handoff can be a unique part of, of this decision and, and what's required.

So again, to your point, like frameworks being used in teams, well, then you build like essentially that institutional knowledge, that team knowledge, and you kind of have a living way to pass on what's happening. Documentation of course is always recommended and we all usually are scrambling to do that at the last minute. I know I have in a lot of situations! Um, but yeah, all very good additional things to think about that maybe sometimes you get knee-deep in a project before you are like, "Oh yeah, whoops. I need to hand this off." Or maybe what I'm doing here is a little more convoluted and I need to document what the heck's happening.

Or maybe I've locked myself into a corner too, and I can't scale it or change what's happening, which I think is another, that that's going to hit you regardless of technology or framework, um, as a possibility.

Claire:

Completely agreed. I, I think, yeah, it's very interesting that you brought up like team dynamics and stuff because I actually chose... at my current job I'm I currently am working on a new Angular app and it's completely new to our company. Like a JavaScript single page application is like completely new. And I actually chose Angular specifically for this purpose of utilizing their standards and their documentation to kind of build a team culture around the code that is being created. So that, theoretically, it should lower the barrier to entry.

However, I know that the barrier to entry is also artificially higher because of a framework. But eventually the thought is, is that, you know, folks will be able to speak the same kind of like code style language, and we'll all kind of write similar code so that, you know, we all kinda know the expectations that are, are, are there. I think that's a big point of framework decisions, as well as that, you know, from an architectural standpoint, although X framework might have an issue you know, with this or that it might be overcome by the amount of benefits that it has to your team.

And that, that the same goes for React, same goes for Vue. Same goes for any kind of JavaScript framework. Like there's this added point of, you know, what the team already knows. Like if most of your team knows react, it's probably counterproductive to go to Angular. You know, it's, it's at the end of the day, it's, it's one of those things where it's like, you know, the technology kind of speaks for itself.

But yeah, to echo your point, I think we all fall into that documentation hole. And that's actually why I really liked TypeScript because it kind of self documents at least a bit, um, of what, uh, would otherwise need documentation.

Steph:

Yeah so I know that occasionally, um, we have some lovely listeners that are new to web development and that obviously makes the choice extremely more, uh, confusing and hard to make. So, um, earlier I mentioned that, you know, I would say a rrays or something to focus on, like, what are those core things like, regardless of what you may end up choosing, what you may end up being hired to do, like, what are those core things that you need to know?

Like you mentioned TypeScript and you may not always use TypeScript, but knowing the differences between different types of things like strings and integers, like those terms. Um, if nothing else I think then so that you can successfully Google, um, what those things are and how to do them all. Add one more before I let you, um, say some things, but, um, things like, uh, different operators. Um, so how to - like a ternary operator or the nullish coalescing some of these things are kind of have crazy, crazy terms, but them earlier you maybe can encounter them the more effectively you can learn to wield them and simplify your code in some cases. Which I'll quickly say simplification may not always be good, but anyway, we can hit that at a different, a different episode. But yeah, Claire, what, what else? Other things like are those core things you should learn regardless of framework for JavaScript?

Claire:

Yeah. I think that's a great point that you made of a around arrays. Like I find, you know, a lot of different things in the wild and JavaScript end up being an iterable. And that not - might not also - might not always be an array, but it might be like a DOM list, a DOM node list, or it might be, um, you know, uh, object or even like newer things such as sets or maps. Right. And, and these are all keywords that you can go, you know, search on MDN or something. And if you're not familiar, MDN is Mozilla developer network, a great resource for documentation on kind of the - the building blocks of the web.

Yeah. Operators specifically are something I'm actually very weak at. I have a hard time trying to figure out what two question marks mean, uh, in relation to like, you know, what a variable is. Um, I actually learned two exclamation points is, uh, the, the same as saying variable and then making a ternary and then returning true or false based upon that. Um, which I felt kind of silly that I didn't know that before, but we all don't know what we don't know. And you know, that just come, it comes up when it comes up.

Uh, but I would say one of the biggest things that you're going to have to know, no matter what is traversing the DOM and trying to figure out how to get a specific HTML element. And then working with what you get from searching for that specific element. Um, and what all the things you can do on a specific element.

So for example, let's say I wanted to find every input on a page and I wanted to change its value to dog. I can do that with JavaScript. However, and I see a lot of folks do this, they might also think that the attribute, uh, in the input element, uh, the value attribute would be updated to be dog. And that's not true. That's just the initial value. So I don't want to get too far into the weeds, but the DOM is different from the HTML that is written. Uh, and you know, that can be a little bit of a disconnect, but if you play around with it, um, you kind of figure out that the DOM is like the living, you know, what's going on in the browser at any point in time. And the HTML in some frameworks might just be what happened when you initially loaded the page.

Steph:

That's a super, super good point. And, um, I'm really glad you brought that up because as someone, a little farther from being a beginner, I forget that that's, that's really what's happening.

And honestly, when you look at the frameworks, that's the core differences. How are they treating DOM manipulation? How are they allowing you to hook in, to manipulate the DOM?

And between React, Vue, and Angular I mean, that's at the top of the list of the difference between those frameworks when it boils down to it.

Claire:

Yeah. So I think, you know, we've talked about a lot of high level things in this episode and, you know, we didn't forget all of the other ones like Ember and Svelte, and I think there's quite a few other ones that are smaller and are all the rage, um, like Alpine JS and couple other ones. I would expound on those on the reasons why I have reservations about those in other episodes.

However, whatever framework you decide to use, try to understand what the framework is doing for you. Because at the end of the day, you might find yourself writing vanilla JavaScript, and relying on something that a framework did for you.

And at the end of the day, a framework is vanilla JavaScript doing something for you already. So dig down into kind of how that works and try to - try to figure out, you know, what all that means.

Uh, most of these frameworks are open source or all at least have their, uh, um, source code on GitHub. Um, sometimes I just go peruse the Angular or the React, uh, repos and just see what's going on. Um, so if you're curious, do that as well. Awesome.

Steph:

All very good considerations. And as always, you can hit us up on Twitter @WordWrapShow, because we know that this is a topic that they, lot of opinions. Um, but if you kind of have been teetering on wondering which one to look into next, um, we hope these considerations are something that can help you. And we'd love to hear more things that you have found valuable when seeking out a framework for yourself.

Steph

Thanks for joining us on another episode of Word Wrap. Be sure to subscribe on your favorite platform, or pick up the RSS feed on wordwrap.dev. You can also catch us as @wordwrapshow on Twitter. Until next time!