Hey everyone and welcome to Developer Tea my name is Jonathan Cutrell and today I'm going to be talking about the great framework debate. This is going to be a two part episode. As I started planning the episode I realized there's a lot to talk about here, a ton of content to get through and I don't want to short you on that content so I want to make sure that we we cover it thoroughly as much as we can in a short format like Developer Tea. Thank you so much to today's sponsor Delighted. Delighted is a fantastic way to get feedback from your customers and they are hiring so we will talk more about Delighted later on. Delighted is offering an incredible deal for you and we'll discuss that as well but first I want to jump directly into today's topic, Frameworks. When should you use a framework and why and when is it a bad idea to use a framework? This has been a topic of hot debate. It's been circulating the web especially in the last week or so for front end web developers but it is a common topic of debate around a lot of other spheres all the time within software development. There are a lot of great opinions on the subject. I will try to include some good write ups and the show notes but today I'm going to share my opinion and this will span into the next episode as well because the subject isn't simple, it's not cut and dry. There is no single answer to this question so I really want to dive in and talk about what we mean when we say framework and then give you some ideas for how to make those decisions. Let's define what a framework is because I think for the sake of discussion today we want to go a bit beyond the strict definition of a framework. Typically frameworks are defined as a collection of code that supports a particular way of building applications. Frameworks are often very opinionated but they can be a little bit loosely structured. The most important part of a framework is that it enforces some kind of organizational structure or a way of doing things, a way of building things. This is in contrast to a library which is basically just a collection of methods in a reusable package that you can install or bring into your project. For example, a library and JavaScript might be jQuery. jQuery doesn't enforce the way that you do things. It only enforces a particular syntax to call the functions that are in that library and it is a library of functions or a library of methods and perhaps a library of classes. Whereas a framework might be something more like Embur. If you are familiar with Embur, you know that Embur basically wants you to do everything in your whole application a particular way. The lines are not always perfectly clear. For example, staying in the JavaScript world, React can be considered both a library and a framework depending on how you choose to use it. For today's discussion, we'll consider both frameworks and libraries relevant to this discussion. Because ultimately what we're talking about here is abstractions or sets of methods that you and other developers can rely on but that you don't build yourself. Typically, these libraries frameworks are available in some sort of open source format or in a community developed format. Sometimes that's not necessarily the case but a lot of the time that is the case. Why would you choose to use or not to use a framework? Why would you choose to use or why would you choose not to use a library? Well, I want to give you a few tips to help make the process of choosing a framework smoother for you. Use frameworks are a great idea and sometimes they're an absolutely awful idea. So I want to jump straight in. I'm going to give you two tips today and then in the next episode I'm going to give you three tips today. But before I jump into the tips, I want to talk about today's sponsor, Delighted. Delighted is the fastest and easiest way to gather actionable feedback from your customers. They have a super simple and elegant way to get feedback via email. So no long surveys, it's just a simple one question survey that's delivered directly to the user's email. One question surveys have far more engagement than long, multi-question surveys. It offers a real-time dashboard where you can see all of your customer feedback, you can filter the data, and ultimately you build insights to understand the trends and understand where to improve. But of course, Delighted has also built a Slack integration so you can see real-time customer feedback directly in the tools you already use. Now let's say you have your own application and you want to be able to automatically send requests for feedback at just the right moment. Well, Delighted has built a REST API just for that reason. Plan start at $25 a month. But if you sign up for a paid account with a special link, Delighted.com slash T, which you can find in the show notes at spec.fm, you will get a $100 credit on your account. That's equivalent to four free months of the entry-level plan for free. So make sure you read the show notes at spec.fm and visit Delighted.com slash T to get your first four months, $100 credit on your account for free. Now Delighted is also hiring engineers. They are hiring for people to work both in their Palo Alto office or remotely. If you're interested in this, make sure you check the show notes for a link for information about that as well. Thank you once again to Delighted for sponsoring today's episode of Developer Tea. So I want to dive right back into our talk about when to use a framework, when not to use a framework and some tips to help make that process of choosing a little bit smoother for you. A number one, remember that everything should be filtered based on the individual circumstances of your project. Every bit of information you get about that framework needs to be filtered based on the individual circumstances of your project. So what does this mean? Well it means that not all values have the same bearing on all projects. Let's say for example that you're building an administrative dashboard for the browser. And you're wanting to pick a framework and there's one framework that has a long load time because it has a lot of assets and the other framework that is really fast to load but the rendering performance is not that great. Well the initially loaded assets will be cached on the user's machine. And so if you're looking at these two frameworks then you're probably going to be less concerned about the initial load time than you are the rendering time of your application. But in contrast if you're building a product storefront you'll likely want to optimize that initial load time because most customers will be seeing the product page for the first time. They won't have those assets cached in their browser and statistics say that load times have a major impact on a user's ultimate decision to even stay on the page much less to make a purchase. So remember all we're talking about here is the context of the particular project. If you have a project that needs to load in for the first time very quickly then that means that your choice of a framework or your choice of a library may be highly dependent on that particular fact about your project. The values for each project, the important parts of each project are different from each other. Of course the best frameworks are the frameworks that optimize both for load-in speed and for rendering speed. They are not mutually exclusive especially when it comes to browser frameworks. So keep that in mind as you go forward. If you have a 500% slow down in rendering speed as a result of using a framework then I want you to ask yourself does that matter. And the gut reaction says, well yeah of course it does. 500% slow down is a significant slow down but the only real correct answer to this question is that it depends. It depends on what that 500% slow down actually means to the user. If the application was somehow loading in 50 milliseconds let's say. And now it's loading 5 times slower. Well that's only 250 milliseconds. And if you work in the web for example you know that anything less than a second is pretty fast. In fact it's very difficult to perceive much of a load time difference between 50 milliseconds and 250 milliseconds. However if you are rendering a animation at a frame rate of 60 frames per second and suddenly it's only one fifth that speed which would be a 500% slow down in performance then you gone from 60 frames per second to 12 frames per second. This is a very clearly perceptible decrease in performance. Your animation is going to be awful at 12 frames per second. So again we're going back to this idea of context. You can't take these numbers and just shove them in front of a board of people making decisions and then hope to come out on the other side with a well informed decision. You have to talk about the context and the actual implications of what it means for you and for your users. And my second tip for today and the last tip for this part of this episode is to learn the language itself. Learn the language itself. Learn the language or the languages the framework is built on. Unfortunately it is all too common that we go into a framework and we learn the way that that framework does things but we don't actually learn what is happening in the language that that framework is built on top of. If you don't have any idea how the methods that you are using could possibly be written. For example if you are using Ruby on Rails and you use something like has many in a model and you don't know how has many could could be implemented then you probably need to take a step back and learn the language of Ruby. It's easy to know what the effect of a particular line of code is but if you only know the effect and you don't understand the implementation then you're going to be left out in the cold if that framework ever changes and if you ever need to change to a different framework. If you write code only because of its convention or because it comes from documentation or you read it on a stack overflow post or if you're reading error reports and you don't understand them until you Google them. If you have to Google something before you have any idea what it means then you probably don't understand the syntax of the language that you've learned. And you haven't really learned that language. If you don't master the language you are only mastering the framework and if you only master the framework you're locking yourself into a possibly very rigid structure and that has a lot of risk. Now for some situations this might be okay but in large part learning the language is much more flexible in the long term. Learning the language gives you the opportunity to shift and change with whatever your requirements are on that project. So a good practice here is to start by looking at the code that you're writing inside of the framework and ask yourself how you would implement that code yourself. How would you go about creating the methods that are underlying those particular pieces of the code that you're writing that are based on that framework. If you can't answer that question then go and take a look at the source code of the framework. We'll talk about this more on the next episode of Developer Teabut if you don't understand what the source code is of the framework that you're using then you probably are using it without fully understanding the cost. And we're going to talk a lot about cost in the next episode of Developer Tea. Thank you so much for listening to today's episode. I hope that you are enjoying Developer Tea. Thank you to Delighted. If you are a product owner or if you're a developer check out Delighted. They have a fantastic service for gathering user feedback and viewing that feedback, getting data, exports from that feedback and actually creating insights from objective feedback rather than subjective opinions. So go and check it out. Delighted.com slash T. Thank you again to Delighted for sponsoring today's episode. And thank you for listening to Developer Tea. If you want to make sure that you don't miss out on the second part of this episode or any other episodes in the future make sure you subscribe in whatever podcasting app you choose to use. Thank you again for listening. Make sure you leave a review on iTunes if you are enjoying the show. That is by far the best way to help other people just like you find Developer Tea. Thank you so much again and until next time, enjoy your tea.