In this episode of The Rabbit Hole we welcome our friend Jacob O’Donnell to help us talk about the shackles of frameworks. We chat about why you’re feeling held back by these frameworks, why it feels like you’re being shackled and why they’re not making you deliver amazing products to your users. At the end of the episode we discuss freeing yourself from the shackles of a framework and what you’d need in order to make that happen. For this and much more, come with us down The Rabbit Hole!
Key Points From This Episode:
Transcript for Episode 95. The Shackles of Frameworks
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast in fantabulous Chelsey, Manhattan. I’m your host, Michael Nunez. Our co-host today.
[0:00:09.8] DA: Dave Anderson.
[0:00:10.8] MN: Our producer.
[0:00:12.0] WJ: William Jeffries.
[0:00:11.4] MN: Today, we‘re talking about the shackles of frameworks.
[0:00:14.6] DA: He’s holding me back.
[0:00:16.0] MN: never letting me go, what’s going on here? I don’t know.
[0:00:20.2] DA: Maybe Jacob will be able to tell us what’s going on here.
[0:00:21.6] MN: We have a guest, returning guest. Jacob O’Donnell back at it again.
[0:00:28.7] DA: Return.
[0:00:28.7] JD: Hey guys.
[0:00:29.9] MN: How’s it going?
[0:00:30.9] JD: Man, it’s going well, I haven’t seen you guys for a while.
[0:00:33.4] WJ: It’s good to have you back.
[0:00:34.5] JD: Thank you.
[0:00:35.0] DA: Are you still in your mid-30’s and living in Brooklyn?
[0:00:37.1] JD: You know, that’s interesting. I am still both of those things. I wish that time went backwards sometimes in like a yo-yo time. Balance between 35 and 22.
[0:00:51.6] MN: That’s a big yo-yo.
[0:00:53.8] JD: Yeah, I think that’s the perfect yo-yo between –
[0:00:57.7] DA: Yeah.
[0:00:59.8] MN: You came up with the topic of the shackles of frameworks and want to know your take on frameworks right now.
[0:01:05.8] JD: Being shackled by them.
[0:01:07.4] MN: Why, why do you feel like you’re being shackled, they’re not making you deliver amazing products to your users, you feel held back by these frameworks, what’s going on Jacob?
[0:01:16.9] JD: Well, I think by definition and they are kind of shackling you, right? The big difference between a library and a framework is the library you call into where the framework calls you. That’s fine.
[0:01:29.6] DA: Sounds like a bad relationship.
[0:01:32.0] JD: I’m thinking about that, would that be bad? You know, maybe you’re just on to follow all the time, yeah, maybe you're rooting for that.
[0:01:38.7] DA: That’s right, that’s fair. No judgment.
[0:01:40.1] JD: Yeah, let’s not judge here. But my problem with frameworks and what I’m seeing these days is that everyone sort of programs into them, all your code sort of fits into the slots of whatever your specific like framework sort of pushes you into so for example, in Rails, everybody knows, don’t put, you want to keep your controllers thin, make your models fat. Like tons and tons of code. Where most of – in places where that is shared knowledge, for the most part, what happens is people are jamming more and more code into the models. The models are getting big and every single one has some sort of god class.
The user class which is 700, 800m, a thousand lines of code and –
[0:02:27.1] DA: No but it needs a mix in, it’s fine. You know?
[0:02:33.0] JD: What I would like to see more of is having some code that lives outside the framework and so in Rails. It wouldn’t be your models, it wouldn’t be your controllers, maybe it’s like live or something but just sort of having your business logic, live in a plain old Ruby object like it’s not inheriting from many sort of Rails thing, it’s just, your business logic, all by itself, maybe it doesn’t know about the database, maybe your whole application could even like, if you wanted to switch from like a web framework to a command line interface like all the logic would still sort of live, would be portable because it’s not all mixed into these concerns.
[0:03:17.8] DA: If I got a ram or something like that, that’s kind of like leak into pretty much anything.
[0:03:23.2] JD: Yeah, it’s hard. I mean, I have a couple of times consciously try to keep like sort of outed a business logic and sometimes you feel like you're kind of bending yourself in half to abstract that away but you know, you can definitely limit, right? Versus like, if you have – if you sort of let the whole thing leak in there then you are tied to active record, versus maybe the only sort of interface that you allow, it’s like “okay, I will call save and I will call load or something,” you know? You’re really limiting your – the usage of your framework.
[0:04:00.1] DA: Yeah, I guess like, constraints can breed creativity in some ways.
[0:04:04.7] WJ: I thought you were going to just advocate for eliminating the framework all together?
[0:04:09.2] JD: No, they’re too damn useful. I mean –
[0:04:12.8] MN: You like the shackles?
[0:04:14.3] DA: That is true, there are a lot of reasons to use a framework.
[0:04:18.0] JD: Yeah, I mean, I couldn’t imagine like – I couldn’t imagine in good faith by going to like a job or client being – saying like, “Let’s just start from scratch. Don’t worry, I’ll code everything, I’ll rewrite web server.”
[0:04:33.3] DA: Bear metal.
[0:04:34.2] JD: Yeah, I mean, I definitely think frameworks are fine, they’re great productivity booster but the problem comes in that I just feel like there’s no domain layer, there’s no business logic that lives outside of the thing. Your whole identity becomes wrapped up in – I mean, you're breaking one of the fundamental rules of single responsibility whenever you have like all your business logic in the models or to give another example like I think now, with React and Redux which is a very common pattern.
Most people are shoving all of their code into the actions, a lot of the business logic is going there. Sometimes some in the react component itself But besides the ever present utils folder, there’s usually not a place to put business logic just like plain old Java Script or Ruby objects that encapsulate your business logic.
[0:05:27.7] WJ: Yeah, II think that when you’re working in a framework, there’s a tendency to try and put everything into the framework to fit everything into the existing paradigm.
[0:05:35.4] DA: Yup, you got a square hole.
[0:05:36.8] MN: Make it happen.
[0:05:37.9] DA: Fit that round peg in there.
[0:05:38.9] WJ: Just jam it in there, just push harder.
[0:05:41.4] MN: Yeah, make it happen.
[0:05:42.0] DA: Yeah.
[0:05:43.0] JD: that’s totally true. I mean, there actually are good reasons for that, it’s when everyone around you sort of expects a code to be there then you know to open up the code there and say, “Let me check the user model.”
[0:05:55.3] DA: Right.
[0:05:56.3] WJ: Everything’s in the user model.
[0:05:57.3] MN: Everything is in the –
[0:05:59.3] JD: It’s like gravity. I mean, there’s definitely something to having a shared language where like a Rails, every Rails developer knows where the controller is, every Rails developer knows how to use active record.
[0:06:11.6] DA: If you're adhering to that framework in that way then there’s not as many surprises.
[0:06:17.5] WJ: Well, I mean, I think there’s like a really clear criticism that you’ve outlined pretty well here which is that Rails at least in also Django and I think generally the old school MVC frameworks really push tight coupling with your database. That wasn’t always the case, right? It used to be that your database was another thing that you interacted with and that you would mock out. I think this is one of the smells in testing you see a lot in MVC frameworks where nobody bothers mocking at the database because it’s part of the model, it’s like, you can’t really unit test your model without including the database connection and so, all of your business logic, all of a sudden now has this dependency on the database.
I think there’s a really strong case to be made about eliminating that. There are probably other ways too in which you feel shackled by your MVC framework, no?
[0:07:08.9] JD: Good question. I mean, certainly, you know, shackled. Really honestly, I mean, a lot of the shackles come from sort of this social structure and team structure that you find yourself in like if you strike out, If Ii just did all my crazy ideas and I said “okay, you know, I think that there is some business logic like there is a store front object that can sort of be extracted from all this and just get all this logic by itself outside of the whole MVC pattern.”
My team mates might be look, “what are you doing?” I would need to fight for that and maybe I would win.
[0:07:44.1] DA: Yeah, I know what you’re talking about because everything is done like this. It’s not like no one does it like that, it’s because people are getting like comfortable with these ideas that are provided to them. “Okay, this is how this is done but you’re not looking at the bigger picture of architecture and scalability of the application,” like it’s a harder question to answer if you have to solve the problem that you’re proposing.
It’s kind of cozy just to be like, “I’m just going to put it in the helper’s file.”
[0:08:13.6] MN: Good old hopeless file, there to save the day.
[0:08:16.7] WJ: Yeah, I think it makes people lazier architects because working in an MVC framework because you think less about architectures and so much of it is prescribed to you. Then, that can get you into serious trouble because if you aren’t thinking from time to time about what the domain concepts are that you want represented in your app and how they’re going to interact, and especially when you're adding major new features, it involves a lot of new domain, you’re going to end up in trouble.
If you’re not having those conversations, if you’re not hitting the white board and talking about architecture and when it’s as simple as scaffolding yet another model it’s easy to skip that discussion.
[0:08:51.4] JD: That’s a really good point too because on the flip side, that’s a benefit to not have to think about and make decisions like every time you sort of have this sort of easy thing, I’ll just put it in models. That is one less thing to think about in programming and you definitely need to be able to reduce the set of things you need to program in.
You know, I do think that in this case, I would argue, it’s something to think about. I sort of contradict myself there but that’s you know, that’s normal.
[0:09:22.0] MN: That’s just how we do it in the Rabbit Hole.
[0:09:24.0] DA: As a software engineer, it’s complicated.
[0:09:27.4] MN: And it depends.
[0:09:28.5] DA: It does depend. End of argument.
[0:09:33.7] MN: I think when I hear like the term the shackles of frameworks, I find that frameworks change behavior like Syntax or the direction that that particular framework is going a lot faster than the way programming languages would normally write it. For example, we saw it recently with React where we were no longer inheriting from object but like using the extend Syntax and then you have to change it but it’s like, “We’re moving this way now” and like you feel like you’re being pulled towards a direction that you maybe may not agree with the community but you still have to forcefully do it because your application is written in this programming language or rather in this framework that you now have to model through and that I find can be a little bit not complicated but like you know, troublesome to deal with.
Like being tugged and direction that the framework wants to go. Yeah, we’re doing that now.
[0:10:28.9] DA: If you don’t like it.
[0:10:31.2] MN: Oops too bad, you can’t release yourself from the shackles unless you’re allowed to rewrite the entire application.
[0:10:36.3] DA: You just go to go to view. That’s the only option.
[0:10:41.2] MN: You know the pattern of using React and Redux and how you do things are very prescribed as William mentioned. If the community wants to do things a little differently and you know, now, React hooks are a thing and you need to update your React library to ensure you can use these things but your application’s not ready to be updated and then you're kind of screwed and you can’t use it.
[0:11:04.7] DA: If I want to learn how to write a program, I will like look at the language docs or like in Django docks or Rails docks and that’s going to be where I’ll see the prescriptions of the framework. But if I want to break out of that, where should I look to see like inspiration for what patterns are successful?
[0:11:22.4] JD: Uncle Bob has a talk that has inspired this that I will have to find the link to so we can link it. Where one of the approaches that he sort of advocates which actually, I think is a little bit over the top but definitely gives the idea is if you were to try and like write your business logic first and sort of wrap the framework around it. For instance, maybe even go as far as try and have like an alternative view. If you have a web app like you would also have a bash client.
I’m forgetting the word, shell client. To go to that extreme, to make sure that your application is actually decoupled from the web framework.
[0:12:06.3] DA: It’s like the API layer is just a means to get to the actual core of the application.
[0:12:12.8] JD: Exactly, right. You're completely separating all your business logic from the NVC and you’re considering yourself – you’re considering your framework as more of a library than the defining feature of how your code is structured.
[0:12:27.5] DA: Okay. You definitely need to have like, really strong sense of like architecture and the domain and all of that.
[0:12:34.2] JD: Yeah, it’s easy to leave these decisions to Rails, right? It’s very simple, you’ve got your models, your views, your controllers and things slot in where they slot pretty easily. Everyone sort of knows where to go. Then there’s that library folder which is kind of like everyone’ scratches their head a little bit and –
[0:12:48.8] DA: Why not, just put it there.
[0:12:49.9] JD: Yeah, maybe that’s exactly what I’m talking about but I often don’t see that heavily used, it’s just the helpers in the you tells.
[0:12:58.1] MN: The outpost, yeah. They definitely help.
[0:13:00.1] JD: Man.
[0:13:00.8] DA: I always need help when I’m programming.
[0:13:02.7] JD: You know who needs a lot of help is Steven Newman.
[0:13:09.6] DA: Called out.
[0:13:11.4] WJ: I’m kind of envisioning like a domain – like having all of your domain logic inside of a package that just gets imported, is that kind of what you’re going for there?
[0:13:19.3] JD: Sounds awesome.
[0:13:20.6] WJ: that would be an interesting constraint because it would force you to not use any of your NVC frameworks tools when you’re doing your domain logic.
[0:13:29.5] JD: Right, certainly, you know some of the display logic would still be available to you when you're like in your view and you want to monetize or whatever but it would be available as like sort of the shell but yes, as you said, the domain logic itself would be completely divorced from whatever framework you chose and if you wanted to switch your framework, it would be a monumental task instead of an impossible task.
[0:13:56.6] DA: What fun.
[0:13:58.6] MN: What do you think about like minimal frameworks instead of going with something like Django, go with Flask instead of Rails go with Sinatra?
[0:14:07.4] JD: You do need a stronger team to pull it off because as William brought up, you need to start making all these decisions like how do we want to structure our app if not model view controller? If every team member’s kind of doing their own thing then even if everyone is strong, then you’re going to have this mish mash styles and you’ll never know where to find things and you're going to get yourself into a mess that way.
You definitely, you know, I suppose in the sense what I’m talking about requires a stronger team because you really, you can make bad decisions. In programing bad decisions, they’re easy to do.
[0:14:42.8] MN: I like a code that I wrote six months later and it’s like what was I doing but you know, that happens. I’m writing the best at the time. The programmer’s oath.
[0:14:52.3] JD: How was the code you wrote today?
[0:14:53.8] MN: It’s great, it’s the best code I ever wrote. Six months later, “what the hell is that?”
[0:14:59.7] DA: I think this is better than the alternative looking back and like "wow, I’m so much better back then.”
[0:15:05.3] WJ: Yeah, really going downhill.
[0:15:07.7] MN: Are we just not going to use frameworks is that what you're saying Jacob? Free ourselves.
[0:15:11.4] WJ: Burn them to the ground.
[0:15:12.2] MN: Write our own?
[0:15:14.7] WJ: Unshackled.
[0:15:15.4] JD: You write your own then aren’t you back in the same spot? Now you're just tied to your framework.
[0:15:20.1] MN: That means, it’s your shackles though, it’s fine.
[0:15:21.8] DA: Yeah, it’s my Redux, yeah.
[0:15:24.0] WJ: There’s no need to reinvent the shackles.
[0:15:26.4] JD: No, we’ve got enough shackles, good enough shackles. Yeah, I mean, really what I’m advocating is look around your code base and if the only sort of files you have that are outside the normal paradigm for that framework are your utils or your helpers, then think about creating like a single file or object that has some sort of domain responsibility. Try it out.
[0:15:56.4] DA: You know, that’s how it goes.
[0:15:58.9] JD: Probably like pacemaker software is going to blow up, who can blame me?
[0:16:04.4] MN: We were using all the helpers and now we didn’t, this happens.
[0:16:09.0] DA: No, that trails driven pacemaker software.
[0:16:13.9] JD: Yeah, I hope all pace maker software’s written in Rails.
[0:16:20.7] MN: If you do work in one of those shops, please tweet at @radiofreerabbit. I would love to see the shop that has that.
[0:16:26.6] DA: Jacob it was awesome having you here.
[0:16:28.4] JD: It was awesome being here, thank you guys.
[0:16:29.7] WJ: Yeah, thanks for coming on down.
[END OF EPISODE]
[0:16:31.0] MN: Thank you. Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five star review and help developers just like you find their way into The Rabbit Hole and never miss an episode, subscribe now however you listen to your favorite podcast. On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
[END]
Links and Resources:
