Is it worth switching to another tool?

When new tools and packages come out, there is usually some buzz around the launch, and how it solves all the problems of the old tool. Should you switch? How do you know when it's worth it? What are the potential downsides of switching? We talk through a couple examples and share how we approach these decisions

Want to see what our coding standard looks like?

Toss a coin in the jar if you enjoyed this episode. We really appreciate it!

Creators & Guests

Host

Aaron Saray

Host

Joel Clermont

What is No Compromises?

Two seasoned salty programming veterans talk best practices based on years of working with Laravel SaaS teams.

Joel Clermont (00:00):
Welcome to No Compromises, a peek into the mind of two old web devs who have seen some things. This is Joel.

Aaron Saray (00:08):
And this is Aaron.

Joel Clermont (00:16):
Aaron, I know you're a fan of just jumping feet first into the new hotness, shiny tool.

Aaron Saray (00:23):
Oh, yeah. If it's shiny, give it to me.

Joel Clermont (00:26):
0.0x. No, but there is a churn we've all seen in web development of tools coming and going. And maybe it's not even a tool, maybe it's a package. But I thought today we could talk about sort of our method for evaluating that and just kind of our approach to when is it time to replace a tried-and-true tool with something new.

Aaron Saray (00:52):
Never new things, let's just keep it. I just want to do functional PHP inside of my HTML. I want HTML 3.0.2 so I have to make all the tags capital. Oh, what was the question you asked?

Joel Clermont (01:09):
All right, I guess we're going to have a little bit of an uphill battle here. No. I mean, I don't know if you want to get into some specific tools. It might be easier to discuss this, do you have such a tool in mind or should I pitch one to you?

Aaron Saray (01:22):
Well, I'm going to pick on a different ecosystem. I'm going to say the NPM versus Yarn sort of thing.

Joel Clermont (01:28):
All right.

Aaron Saray (01:29):
First of all, I should say that with my assumptions, they're all assumptions, they're based off of some of the facts that I've used them. But I'm not a Yarn... I didn't make the package Yarn, I don't spend a lot of my time in Node land and all that kind of stuff. So, I welcome for you to tweet at Joel and tell him how wrong I am.

Joel Clermont (01:50):
Wow, that was quite the hedge. That's good.

Aaron Saray (01:53):
But, no, I remember historically NPM would install your packages but it didn't have a lock file as we're so used to now. The problem there is you could specify your semantic versions that you're willing to accept, but let's just say you did ^4.0. You're going to get 4.0.3 on one install and then 4.1 the next time because that's the new packages. It solved the issue, which is I kept in your semantic versioning you requested, but it never sort of locked down. If you wanted to lock down, you had to put the specific patch versions in there to make sure that NPM installed what it was supposed to. That was one issue.

Joel Clermont (02:37):
First of all, that sounds horrible to me and I don't remember that era. But just out of curiosity, did people commit their Node modules to the repo then? Or they just lived with the versions drifting?

Aaron Saray (02:49):
I can't remember exactly, but I do remember you got more down to like if you need something specifically or you're worried putting the patch version.

Joel Clermont (03:02):
Okay. Just be more specific as to what you're targeting. All right. A little aside there. What else?

Aaron Saray (03:010):
The other thing was the ecosystem back then, there was a lot less caching, there was a lot less of these services available where everything is kind of distributed and all that kind of stuff. An NPM install, even now takes some time, but it took quite some time back then because slower server setups, all this different stuff. There was a new tool that came out called Yarn, which meant to solve a number of these things. It had multi-threaded downloads, it could unzip multiple things at a time I think, it wrote its own yarn.lock file. It would basically do what we now know is the right thing to do, and all these different things. There was a lot of use. I honestly, I didn't adopt it as soon as I should have because I didn't spend a lot of time in the JavaScript world, so I didn't really understand their issues. It was basically composer without a lock file. Like, when I first started using composer there was a huge question, like "Do you commit your lock file?" or not?

Joel Clermont (04:05):
Oh, sure.

Aaron Saray (04:06):
Looking back at that, that's crazy that we had that conversation. Of course, you commit your lock file. Like, what's the deal here? Yarn was a tool that solved a lot of the problems that we were looking at. So, people started using that a lot more and it was sort of compatible. It was mainly compatible, if not a hundred percent compatible with the NPM sort of world and all that. But as time went on, NPM started getting better, and better, and better. It basically addressed all of the issues that I had or that people had. I mean, there was problems... I'm sure there's a lot more than I'm kind of glossing over. But the point is, as time went on, they learned from other packages. NPM learned from Yarn, did things better, and now I am using NPM again because it is the older granddaddy of everything. It's been around longer and it was the reason... or it was the way that everything was set up so I'm going back to the source because it now has the tool sets I need instead of going down in some little fork. Now, there's probably more stuff being brought into Yarn than I know about but it's not solving any problems for me so I'm going back to the more traditional tool set. Because in the last couple years, it's solved any of the problems I had and it's the traditional one that things are aimed for. The rest of the things are kind of an add-on.

Joel Clermont (05:34):
Right. I mean, it's kind of an interesting topic, or this is an interesting example, because Yarn is meant to be essentially a drop-in replacement, right?

Aaron Saray (05:44):
Mm-hmm (affirmative).

Joel Clermont (05:44):
Like, it works. Even if the implementation details are different it's supposed to do the same thing. NPM install and Yarn install are supposed to do the same thing. I don't know, are there things you can't do if you start using Yarn? I don't think so. It's fully compatible, maybe there's some weird edge case.

Aaron Saray (06:05):
Yeah, that's the core of the argument or the discussion I'm having here is that, there's probably a few things in both sets of tools that you can either do or can't do with that tool. Very small, unique edge cases, but why introduce the edge cases of I'm not able to do something if I don't need to introduce that and why introduce more features than I need? Because more features is more surface for things to go wrong and all that kind of stuff.

Joel Clermont (06:26):
Yeah. So maybe the lesson for this one is, if you just stay on the old tool long enough it'll fix the problems and you just don't have to move. But no, I-

Aaron Saray (06:36):
It either fixes it or it goes away.

Joel Clermont (06:38):
It goes away, yeah. Because I think recently, I even brought this up, if I recall there was a project, we joined that had both a package lock and a Yarn lock. And I'm like, "What is going on here?" I think it's pretty easy to agree you shouldn't have both, right? You shouldn't have some people on your team using Yarn and some using NPM. It just seems chaotic to me. But we looked at it, said, "Oh, is Yarn worth it? Which one are we going to pick?" We went with NPM for all the reasons you just said, but please don't use both. I think that's a pretty safe non-controversial topic.

Aaron Saray (07:10):
But I don't want to just pick on JavaScript.

Joel Clermont (07:13):
Sure.

Aaron Saray (07:14):
And to me, there seems to be a lot more of tools moving around, a lot more excitement in that ecosystem compared to Laravel and PHP. But there are PHP packages and things like that, which we've had to consider too.

Joel Clermont (07:30):
Oh, I have one in mind and I will name names here. So, this one has to do with enforcing a coding standard. For a long time, you and I liked PHP_CodeSniffer and there was some philosophical reasons for that. I don't know how deeply we want to go into this right now. But the basic idea is Code Sniffer was primarily to report on issues and you had to fix them. Whereas the other big tool in the PHP space is PHP CS Fixer... These names are so similar, I hate it. But its philosophical approach was, fix stuff. Like, if you know what's wrong and it's a tool and you can fix it just fix it. And for various reasons we preferred the other approach.

Aaron Saray (08:16):
Well, I think I can add some context here. You know, we talk a lot about how both you and I have different backgrounds. I came from a place where I had multiple developers a lot of times. I also have a passion, I hope people can see this, for teaching developers. I want to help make them better.

Joel Clermont (08:30):
Sure.

Aaron Saray (08:30):
And I want to instill good values, especially in our junior programmers that are like, "There's just so much information there. How do we decide what to do?" So many people are pulling it when you say you're a programmer they're like, "Oh, great. Fix my million-dollar thing." You're like, "Well, I'm just learning," you know? I had this passion for kind of making things a little bit more harder and teaching people the proper way. Then after that you can pick the tool sets that you want or whatever. So not only, at the time that we picked a tool, there was some feature differences. But for me it was more about in my mind since I worked with developers with pull requests and all that kind of stuff, I wanted them to be responsible for all code. Because I wanted them to understand that everything they do had a reason and everything they did had some impact. And I never wanted to hear that, "Well, that's just what the tool did." Even to these days if you say that to me you better watch out.

Joel Clermont (09:27):
I've learned.

Aaron Saray (09:28):
But, yeah. I mean, obviously code sniffer could apply some fixes, not all of them.

Joel Clermont (09:33):
Yeah.

Aaron Saray (09:34):
But that was probably one of the reasons why I picked that tool. With CS Fixer, you can do a dry run, you can do a check and all those different things too. But it was just a default sort of mentality or process thinking that was right for where my context was coming from.

Joel Clermont (09:52):
Right. Again, I think over time this is another example of tools kind of converging because they both have the opposite flag now where you can run them in whatever mode you want. But one other reason we liked code sniffer was there was that third party package, Slevomat, which just had almost every rule I would ever think of, like, "Oh, it'd be great if we could enforce this," it was built.

Aaron Saray (10:20):
By the way, I hope the pronunciation isn't SlevMo or something like that. We're just totally butchering it.

Joel Clermont (10:26):
I hope so too, that's a good point. But we did recently, very recently, within the last few months, make the switch and start using CS Fixer instead. And in this case, we had some very specific reasons. I mean we'll share them, that's not the necessarily the point of this episode to convince you, the listener, to switch if you're using code sniffer. But just our thought process through it. It wasn't like, "Oh, let's just do it." It was like there was a reason for it. One thing I really liked about PHP CS Fixer is that its configuration was actually done with PHP, right? Whereas in code sniffer, it was an XML file. And it's not about, "Oh, XML was gross and old." But it's about being able to maybe dynamically do things. And the switch we made also is in the context of trying to build our own official standard that we use across our projects. And being able to do that in PHP is a lot easier than kind of layering it on with an XML file and a bunch of rules and then maybe some PHP underneath the hood in code sniffer. So that was one of the big ones for me. Would you agree with that shift?

Aaron Saray (11:38):
Well, I would. And it's funny because you mentioned that I was a big holdout because, I'm going to go back to some of the JavaScript world, I was a big fan of Grunt as a build tool and then Gulp came along. So, the difference between those two... I mean, many, many differences, but one was a configuration with files and the other one was JavaScript Gulp... You could do JavaScript configuration. And now that seems to be either JSON files or JavaScript exports, it seems to be the way to configure JavaScript tools now. But at the time, I was enamored with Grunt's way of doing stuff, which is, "It's just configuration, you don't have to write code," even though I'm a programmer.

Joel Clermont (12:18):
Sure.

Aaron Saray (12:19):
The XML file really felt nice because in my mind I was like, "Well, this is a different language than PHP," so that it's just configuration and we don't have to worry about any code standards in our code standard configuration and all those different things. But as I realized, as we looked up there, for me at least, there was no difference once I just opened my mind. I'm like, "Well, they're just tools. So, what's the big deal?" If one has one type of configuration versus the other, it doesn't really matter what the tool actually do.

Joel Clermont (12:52):
Yeah, that's true. I mean, I don't know if I would necessarily rule a tool out just based on how it was configured. But in this case the fact that it was PHP made what we wanted to do with it a little bit easier. It wouldn't have been impossible with code sniffer but it was certainly easier with CS Fixer. The other thing too is that over time, CS Fixer added more and more rules, right? So that idea, "Oh, we can't do this in one but we can do it in the other," that, I don't want to say it went away but it was diminished. That was less of a reason to not use that tool. Then I guess maybe, I don't know if you're going to agree with this, Aaron, PHP CS Fixer is more widely used than Laravel world, right? So, it's the default, even if you're using Laravel Pint... Pint, I don't know.

Aaron Saray (13:35):
Pint, I think. Because... Pint verses Lint.

Joel Clermont (13:36):
I think you're right. I think it is Pint versus Lint. But it's using PHP CS Fixer under the hood. So, we don't necessarily pick something just because it's the default. But I do think we would want to have a strong reason to deviate from the default. We like doing things a way that will be familiar to maybe the developer that joins after us or the client's team that we're going to hand something off to. So that was part of the thought process as well.

Aaron Saray (14:07):
Yeah. I think there's a lot of reasons why you might not just reach for the shiny. You know, we covered a few here but that's really kind of the concept is just think about it as, "What is this new thing going to give us that we actually need?" If you're just curious about it don't work it into one of your clients or your company's projects. Do a little side, little project and try it out. I have a number of different folders in my sites area, in my projects area, which were a Laravel 10.0 install or Laravel 9.0 install or something like that. Where I installed, it used Valet just to run it. Because I'm just trying to do something real quick and I put in a tool set I want to try out. Maybe it's a new S-P-A-T-I-E package. I know I shouldn't-

Joel Clermont (14:55):
I know how that's pronounced because there was just a tweet where it was two words and there were pictures. Spa-Sea.

Aaron Saray (15:02):
Spa-sea, okay. I get it.

Joel Clermont (15:04):
Now you'll never forget it.

Aaron Saray (15:06):
When it's a Spa-Sea package or whatever, and just to try it out for a little while first with your own kind of messing stuff around and see if it's actually going to be worthwhile. Because all these different new tools too are little loads on our understandings of stuff. Even if it helps you. Our job is to solve the business problems and get revenue in the door because that's how we get paid. Then these little things we can kind of do to figure out if they're going to save us time. But you need to figure that out as a good, responsible programmer, not just hope.

Joel Clermont (15:42):
That's a good strategy.
Aaron, I respect your opinion on coding questions. So, I thought I'd bring to you a question from outside the coding world. What is your opinion on how seriously I should take the expiration date on some food that's in my refrigerator?

Aaron Saray (16:06):
Well, it depends on the food. It depends on how close your bathroom is, it depends on your budget, it depends on who's in the house at the time, two to three hours after you're going to eat that food.

Joel Clermont (16:19):
Oh, boy. I wasn't even thinking of this.

Aaron Saray (16:21):
Yeah, there's a lot to consider with this question. What kind of expiration or food are you talking about?

Joel Clermont (16:26):
Well, let's take a simple one. Milk.

Aaron Saray (16:28):
I don't drink milk. You don't

Joel Clermont (16:30):
You don't drink milk. Eggs.

Aaron Saray (16:33):
Oh, do they have expiration date?

Joel Clermont (16:35):
Oh, yeah, they do.

Aaron Saray (16:37):
Oh, just to clarify for those who are not in the United States. We wash our eggs and that messes them up somehow.

Joel Clermont (16:45):
I don't wash my eggs.

Aaron Saray (16:47):
No, that's why you have to keep them in the fridge. In other countries or if you have a home, you don't have to put them in a fridge. You just grab the bucket, knack it, put it in a thing and it's fine. There's a-

Joel Clermont (16:59):
You have like a bowl of eggs on your counter?

Aaron Saray (17:02):
Yeah. I mean, not now. I don't have my own chickens but I'm just saying like back in the day. You don't need a fridge for them, but we do here.

Joel Clermont (17:10):
Interesting.

Aaron Saray (17:11):
I think that's probably why there's expiration dates. But I mean, I guess eggs do expire. I'm sure there's people who know what the heck they're talking about here that are just like, "What are you doing?"

Joel Clermont (17:20):
Yeah. For example, here's my take on it. If I look at the eggs and they expired yesterday, I'd be eating those eggs. Like, with the provision that they don't look visibly bad or you crack the shell and they're there's something horrible going on in there.

Aaron Saray (17:37):
Can't you put them in water too and if they float or they sink, one of the two, it tells you if they're bad or not.

Joel Clermont (17:43):
I think that's how you determine somebody's a witch.

Aaron Saray (17:46):
No, you build a bridge out of them.

Joel Clermont (17:49):
Okay. But I'll give you an extreme story. I was at a friend's house and, you know what? And this friend didn't have a lot of money and we were hungry and he had a dozen eggs in his fridge.

Aaron Saray (18:03):
How old were you?

Joel Clermont (18:04):
20. I was young.

Aaron Saray (18:05):
Oh, okay. I'm pretty certain you only have rich friends now with your heated bathroom floors and stuff like that.

Joel Clermont (18:12):
Oh, come on. These eggs had expired six months ago, all right? And I was a little leery. We ate them, they were fine. I guess it just kind of changed my whole opinion, I'm like is this a scam? If you open up milk, cheese, I'm listing all the things Aaron probably doesn't like, sour cream, you know they�re bad. You don't even have to get your nose in there. If they're bad it's-

Aaron Saray (18:36):
How can you tell if sour cream is bad?

Joel Clermont (18:39):
You just think it's bad all the time?

Aaron Saray (18:41):
Well, it's sour cream, right? I mean, isn't it always? It just gets more sour? It's like, how do know blue cheese is bad? It gets more moldy?

Joel Clermont (18:49):
Blue cheese is a tough one. Sour cream, if it has mold on it then you probably don't want to eat it. I still didn't get a read from you, Aaron. Are you in the camp that you would lend credence to an expiration date and maybe throw something away even if it didn't look bad just to be on the safe side? Or where do you come down?

Aaron Saray (19:05):
It depends on it. Like, meats

Joel Clermont (19:13):
Okay. So, I can make you an old omelet, but not an old steak?

Aaron Saray (19:20):
Mm-hmm (affirmative).
Do you want good coding standards for your project but you just don't know where to begin?

Joel Clermont (19:28):
Then head over to our GitHub repo, github.com/nocompromises, and check out our PHP CS Fixer Config.