Support Word Wrap
Interested in sponsoring the show? Get in touch on our sponsorship form.
You can also become a patron with a small monthly contribution which will help us pay for necessary services to keep a podcast running. Thanks for your support!Support Word Wrap on Patreon
and I'm Steph.
And this is Word Wrap.
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.
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.
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?
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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!View All Episodes