Today's episode is sponsored by Delighted! Delighted is the easiest way to gather feedback from your customers. Sign up for a paid account at https://delighted.com/tea and receive a $100 credit today!
Today's episode is sponsored by Delighted! Delighted is the easiest way to gather feedback from your customers. Sign up for a paid account at https://delighted.com/tea and receive a $100 credit today!
Don't forget to subscribe in your podcasting app, and leave a review in iTunes!
Today's episode is sponsored by Delighted! Delighted is the easiest way to gather feedback from your customers, and view the data in a real-time dashboard. Sign up for a paid account at http://delighted.com/tea and receive a $100 credit today!
Delighted is also hiring Front-End engineers! Head over to http://delighted.com/jobs to find out more.
Hey, everyone, and welcome to Developer Tea. My name is Jonathan Cottrell, 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 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 that'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. And there are a lot of great opinions on the subject. I will try to include some good write-ups in 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. First, 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. Now, 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, right? 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. JavaScript might be jQuery. You know, 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. 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 Ember. If you are familiar with Ember, you know that Ember basically wants you to do everything in your whole application a particular way. Now, the lines are not always perfect. 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. So 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. And typically, that's not going to happen. That's not going to happen. That's not going to happen. That's not going to happen. That's not going to happen. That's not going to happen. That's not going to happen. That's not going to happen. That's not going to happen. 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. So 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. Sometimes 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 your customers to use Delighted. 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. 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. Plans start at $25 a month, but if you sign up for a paid account with the 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. 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 loadable framework is not that great. The 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 the importance. The different 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% slowdown in rendering speed as a result of using a framework, then I want you to ask yourself, does that matter? Right? And the gut reaction says... Well, yeah, of course it does. 500% slowdown is a significant slowdown. But the only real correct answer to this question is that it depends. It depends on what that 500% slowdown actually means to the user. If the application was somehow loading in 50 milliseconds, let's say, and now it's loading five 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 going to be a 50 milliseconds. It's 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 an animation at a frame rate of 60 frames per second, and suddenly it's only one-fifth that speed, which would be a 500% slowdown in performance, then you've 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 today. And the last tip for today. The last 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 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 course. So, let's take a look at how to learn the language of Ruby. 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 it. So, how do you learn 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 language. So, let's take a look at how to learn the language of Ruby. And let's start with the first step. So, let's start with the first step. So, let's start with the first step. 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. And we'll talk about this more on the next episode of Developer Tips. But 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. And if you're interested in learning more about developer tea, 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 tea. 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.