Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and today we're going to continue our discussion on frameworks. We talked about frameworks in the last episode. We talked about a few tips for when you are choosing whether or not to use a framework in which one you want to use. Number one was remember that everything should be filtered based on the individual circumstances of your project. You have to have that context to be able to choose a framework. And number two, you need to learn the language that the framework is built on. You will see this opinion on pretty much everybody who knows what they are doing. They will tell you to learn the language first and learn the language thoroughly before you use a framework that is built on that language. So today we want to continue that discussion. First I want to thank today's sponsor, Digital Ocean. If you are looking for a cloud hosting solution, Digital Ocean is a fantastic opportunity for you. DigitalOcean.com, we will talk more about them later in today's episode. But first I want to jump straight into today's topic and continue giving tips on how you can choose frameworks and be more careful and more intentional about choosing frameworks. We talked about on the last episode that frameworks really win we say framework. What we're talking about is any set of code that wasn't written by you that you are using in your project. Typically a framework is defined by a holistic way of doing things. And we discussed Inver as an example. Another example of a framework in the Ruby world would probably be Ruby on Rails. And it has a lot of opinions about how you structure your application, how you think about the models and for example most frameworks may have something like MVC attached to them or another paradigm. And that is how you know the difference between a framework or a library. But really frameworks and libraries come with some of the same restrictions, some of the same thought processes that you need to go through before you pick it up and put it into your project. And we've been talking about those things. Again, the first tip was make sure you have context and filter everything based on the values of your project. Number two, you need to make sure that you learn the language that the framework is built on. As an aside, if you are a web developer, then you should be an expert in JavaScript, HTML and CSS. Those are the languages that make up what you do. So learn the languages. Those are important. And number three, the first one for today is to know the cost of the framework. Now I don't necessarily mean the literal monetary cost, though that certainly can be a part of the discussion when you're choosing a framework, but I mean the cost of using the framework. This can be broken down into many different categories. For example, the cost for you and your team today, which should also consider the cost for the client today. Number two, maybe the cost for you and your team and the later maintenance stages of the product's lifecycle. So once you've finished that initial build and you're into feature development later on or maybe you're into managing bugs later on, that framework can be costly in managing those things. And another category of cost is the cost for the people that are using the product itself. Now very often we kind of pit these against each other. We have the cost for me as a developer versus the cost for the people using the product. Where frameworks usually make my life as a developer a little bit easier, but they may make the project a little bit bloated. They might cause some performance problems. And those are usually the way that we kind of pit frameworks, the values of a framework against each other. Now if the framework makes your work significantly easier to do today, but the framework isn't maintained into the long term future, it may not be the best fit for a project that requires long term maintenance. Naturally that makes sense, right? No one wants to maintain Corpse Code. No one wants to write in a framework that no longer exists. So if your code is likely to change in the future, be certain to choose a framework that will continue to be developed in the future as well. At the very least you need to choose frameworks that have a plan for supporting legacy code. They have a plan for supporting when that framework is no longer actively being advanced. At least it has some sort of support system for code that is still using the framework as it was built in its final stages. Of course there are technical costs that you should consider as well. Will this framework cause the initial loading size of my application to be overly bloated? This is probably the most commonly cited problem with frameworks is that they cause the code base to be larger than necessary. Another question that you should ask on the technical cost side is, is the code base of the framework secure? Another question, does the framework have performance bottlenecks that transfer into maybe higher server costs or laggy rendering on the client? If you're developing a native app, do they transfer into larger native application builds? Those are the kinds of technical questions that you want to answer. If I decide to change to a different framework in the future, does this framework require me to use patterns that are unnecessarily unique? And if so, how badly will this prohibit me from being able to flexibly adopt a new framework in the future? This is a massively important point. You need to choose a framework that doesn't stray from common conventions in that language. And that's actually number four. So this kind of is a bleed over from number three. The technical cost of having a framework that has really specific and unique conventions that are highly unique to that particular framework. I recommend choosing a framework that doesn't stray for common conventions, especially conventions in that language. If you choose a framework that goes against the common conventions, then change in the future away from that framework. Number one, is going to be much, much harder. You're going to have to basically rewrite the entire code base. Secondly, if you choose a framework that has really specific conventions to that framework, then you're going to have a hard time adopting new developers into your processes. It's really difficult to get people who have a set number of conventions for a particular language to come in and work on a project, work inside of a new framework with all new conventions. That's really difficult to do. There is a common language that kind of supersedes the average framework. It supersedes when we're talking about frameworks, we don't have to talk about the specifics of the syntax. We can talk about patterns. We can talk about design patterns. If the framework you are using has their own design patterns, if they've strayed away from common design patterns for software, then you're going to have a hard time having strong discussions about your code with people who don't have that specific domain knowledge. Choose frameworks that don't stray away from common conventions, from common design patterns for that particular language. Obviously, you can tell that this is something that I have a lot of thoughts about. I want to take a breather and talk about today's sponsor, and then we'll dive back in to talk more about frameworks. Today's sponsor is Digital Ocean. Digital Ocean is a fantastic service that you can use to get cloud hosting, solid state drives up and running, and less than a minute. I use Digital Ocean, and I love the product. Plan start at $5 a month. You select the region. You select what kind of Linux install you want to have, and you can deploy in just 55 seconds. It's super simple, beautiful interface. Digital Ocean is invested in the development community. In fact, they have tons of documentation written by developers just like you about how do you use Digital Ocean services to accomplish the things that you want to accomplish. Very specific technical articles, really good tutorials. You probably have read a Digital Ocean tutorial at some point before. You may not have even known that it came from a company that actually does hosting as a product. Go and check it out. There's a special link in the show notes to get you $10 off your account when you sign up for a new account on Digital Ocean. That is basically like getting two months 100% free on digital ocean.com. Thank you so much again to Digital Ocean for being a long time sponsor of Developer Tea. So I have one more tip for you all today when you are choosing a framework. That tip is to not ignore the code of the framework. This may seem obvious, but you shouldn't view a framework as a black box. Not all frameworks are created equal. That code that is inside of that framework, each and every line is important. Frameworks just like any other code can have bugs. They can have poorly executed ideas. Quite often, especially in open source, frameworks are not built by a single person. They may be vetted by a group of like-minded individuals, but ultimately the code for one file very likely was written by a different person than the code for another file. Many people have probably touched this code. Not all parts, therefore, of a framework are created equal either. Some parts may be newer and thus maybe a little bit less battle-tested. Some parts may be lacking in documentation. But there may even be parts of the framework that are considered experimental. Now on the contrasting side of the new, there may be parts of that framework that are close to being deprecated. There may be multiple parts of the framework that do similar things. The maintainers of that framework may be looking to unify all of those disparate pieces into one API. If you use something that is close to deprecation, you may end up having to go back and refactor that code whenever that code ends up being deprecated. So you have to be very careful to not look at a framework as a black box. You can't ignore the code that is in that framework simply because it has the title of framework. You shouldn't trust the entire framework by default. You shouldn't trust the entire framework if you trust one part of the framework. Be critical of the things that you choose to bring into your projects because they do have an effect on your code. You cannot ignore the code in the framework and act like it is a well-tested plugin that is absolutely guaranteed to work exactly as it says it will work. That is not necessarily true and you should be critical and aware of that if you are going to be a responsible developer. So treat frameworks like you treat your own code in many ways. Now of course, because frameworks have the opportunity of being vetted by many people, usually larger frameworks have people working on them full time, you may not necessarily have the time to be able to vet that framework fully. So you have to be able to assess whether or not you think the people who are responsible for that framework are actually taking care of it. Does it have a large number of people testing and running it through its paces? Does it have an open documentation structure? These are the kinds of questions that you need to be asking when you look at the code for a particular framework. I hope this has been a helpful discussion for you, especially if you've been trying to decide what kind of framework to use or whether or not to use a framework. Remember, it always depends on the context that you are in and keep all of the things that I've mentioned in this episode in mind. Thank you so much for listening to Developer Tea. Thank you to today's sponsored digital ocean. If you are looking for a cloud hosting solution, check out Digital Ocean. You can get $10 for free today and have your first server up and running in 55 seconds, incredibly fast SSD servers in the cloud digital ocean.com. Thank you again for sponsoring Developer Tea. If you are enjoying this episode and you want to make sure that you don't miss future episodes, you can always subscribe for Developer Teain whatever podcasting app you use. To read the show notes for today's episode, go to spec.fm, make sure you leave a review for Developer Teaon iTunes if you're enjoying the show because that is the best way to help other developers just like you find and enjoy Developer Tea. Thank you so much for listening and until next time, enjoy your tea.