I think you may be missing a huge factor as well. A huge reason to even use a framework to begin with is standards. Everyone knows how to interact with the code and bringing on new employees is as simple as advertising the framework. They will be able to integrate nicely with it very quickly if they are familiar with it. If they are not familiar with but know the language it might take 3 months or so on a large codebase, in my experience.
If you are building your own applications from scratch and you expect your employer to higher people to come in and learn an entirely new application that was built from scratch with no prior knowledge or being able to work with it then you are going to cost your employers thousands if not tens of thousands of dollars when you leave.
You might not see it now because everyone knows the codebase but try to get some new people into it who may have never coded an application before. You're going to make their life hell and they are going to ask 1000 questions they don't need to which also takes away time, money and resources from other parts of the company. Again, talking from experience here. My first company I worked for did this and it was hell but she (the lead dev) thought nothing of it because she was the one who built it.
Bad Premise
Your entire argument is based off of the premise that a framework calling your code is inherently bad. You say your code calling the library is good but the framework calling your code is bad but you have no supporting argument to back that up? Why is a framework calling your code bad?
If you say it's because it makes you too restricted to how the framework does things then why is that bad? If you say it's because of the structure of the code or the methods you use is forced on you then why is that bad?
New Features
Also when you use a framework you have the benefit of tens or hundreds (sometimes thousands) of contributors working around the clock just for you and your software. New features? Sure! just check the roadmap and when new features will be added to your application.
Documentation
When coming to a new framework you have the advantage of having 100's of pages of documentation to come through. Masonite has ~550 pages. This allows new developers to reference the docs instead of ask all those questions. Noone needs to fire off a slack message "how do you set a session again? I can't figure it out".
They can:
* Read the docs
* Check stack overflow questions
* Read community articles about how others did it.
* join official lines of community like framework discords, slacks, email lists etc.
There is much more to using a framework than being forced to code a certain way.
Hey Joseph - thanks for your detailed response, and for sharing your experiences. This is great. My experiences obviously differ to yours, but that's being human I guess.
Bad Premise
Why is having my code called by the framework 'bad'? Fair question, and I don't really address it. In a sense, isn't all code being 'called' from something else? Called by a compiler, called by an interpreter... called by the operating system. Something else is providing the environment for what I'm writing.
I guess my objection to the inversion of control I experience with a framework usually comes down to two things: it's hard to debug when it goes wrong, and it's hard to redesign it to fit your needs. It's harder to understand what happens when your code gets called as it's obeying rules that you're not aware of or in control of.
New Features
But do I need any of them? What are the benefits to me? I've seen developers add these features to projects when they're not needed... or worse, when they almost fit a requirement. They will use them, depend on them, develop around them until the codebase is distorted in their favour. And then, ultimately, be let down with them as the final feature never gets implemented.
Documentation
I'm not sure this is an argument in favour of frameworks, or of documentation. Good libraries have good documentation too.
I'm not sure this is an argument in favour of frameworks, or of documentation. Good libraries have good documentation too.
it's not the library documentation I am talking about but how your application interacts with them. There is no documentation on "how to create sessions with David Wickes application that communicates with the B2C part" or "how to send a quick email with David Wickes application that communicates with the warehouse."
But do I need any of them? What are the benefits to me? I've seen developers add these features to projects when they're not needed...
out of curiosity, how long have you been in industry? Not being rude but curious. Your experiences are your own and you are entitled to them and I respect them. I am not saying my experience overtrumps your experiences but as someone who has been in industry and have ran some big projects with $60M+ on the line for quite a while I can tell you that requirements always change and if you don't need that ability to send an email that was just added to the new release of XX framework a few months ago, when your boss come back and you and says:
"oh remember that wharehouse app you made to manage all those products? i need you to add a completely unexpected requirement of sending that email directly to shipping with all item details and who the shipment is going to"
Framework to the rescue because a developer coded that for you and you can easily send an email and package it up in a nice "mailable" class you can pass around all parts of your code.
it's hard to debug when it goes wrong,
But isn't that why you have framework documentation, Stack Overflow answers, Slack channels, community articles, online videos you can reference to help you debug that is not available to you if you build something from scratch?
and it's hard to redesign it to fit your needs.
I'll give this one to you. Frameworks generally can be manipulated in the sense of file structure but typically has only 1-3 way to do things like:
This is how you send email
this is how you interact with form inputs
This how you do x, y, z
So yes frameworks make you do certain tasks a certain way but that's not a strong argument of why it is bad imo.
Maybe it is to you but having freedom to code the way you want to code isn't a perfect solution, it has significant drawbacks and maybe that's the point I am making is that this sounds good but it has a lot of drawbacks when you find the can you kicked down the road. I am genuinly curious on your opinion this time next year or 2 years from now or even when you switch employers.
Thoughts
I think you may be missing a huge factor as well. A huge reason to even use a framework to begin with is standards. Everyone knows how to interact with the code and bringing on new employees is as simple as advertising the framework. They will be able to integrate nicely with it very quickly if they are familiar with it. If they are not familiar with but know the language it might take 3 months or so on a large codebase, in my experience.
If you are building your own applications from scratch and you expect your employer to higher people to come in and learn an entirely new application that was built from scratch with no prior knowledge or being able to work with it then you are going to cost your employers thousands if not tens of thousands of dollars when you leave.
You might not see it now because everyone knows the codebase but try to get some new people into it who may have never coded an application before. You're going to make their life hell and they are going to ask 1000 questions they don't need to which also takes away time, money and resources from other parts of the company. Again, talking from experience here. My first company I worked for did this and it was hell but she (the lead dev) thought nothing of it because she was the one who built it.
Bad Premise
Your entire argument is based off of the premise that a framework calling your code is inherently bad. You say your code calling the library is good but the framework calling your code is bad but you have no supporting argument to back that up? Why is a framework calling your code bad?
If you say it's because it makes you too restricted to how the framework does things then why is that bad? If you say it's because of the structure of the code or the methods you use is forced on you then why is that bad?
New Features
Also when you use a framework you have the benefit of tens or hundreds (sometimes thousands) of contributors working around the clock just for you and your software. New features? Sure! just check the roadmap and when new features will be added to your application.
Documentation
When coming to a new framework you have the advantage of having 100's of pages of documentation to come through. Masonite has ~550 pages. This allows new developers to reference the docs instead of ask all those questions. Noone needs to fire off a slack message "how do you set a session again? I can't figure it out".
They can:
There is much more to using a framework than being forced to code a certain way.
Hey Joseph - thanks for your detailed response, and for sharing your experiences. This is great. My experiences obviously differ to yours, but that's being human I guess.
Bad Premise
Why is having my code called by the framework 'bad'? Fair question, and I don't really address it. In a sense, isn't all code being 'called' from something else? Called by a compiler, called by an interpreter... called by the operating system. Something else is providing the environment for what I'm writing.
I guess my objection to the inversion of control I experience with a framework usually comes down to two things: it's hard to debug when it goes wrong, and it's hard to redesign it to fit your needs. It's harder to understand what happens when your code gets called as it's obeying rules that you're not aware of or in control of.
New Features
But do I need any of them? What are the benefits to me? I've seen developers add these features to projects when they're not needed... or worse, when they almost fit a requirement. They will use them, depend on them, develop around them until the codebase is distorted in their favour. And then, ultimately, be let down with them as the final feature never gets implemented.
Documentation
I'm not sure this is an argument in favour of frameworks, or of documentation. Good libraries have good documentation too.
it's not the library documentation I am talking about but how your application interacts with them. There is no documentation on "how to create sessions with David Wickes application that communicates with the B2C part" or "how to send a quick email with David Wickes application that communicates with the warehouse."
out of curiosity, how long have you been in industry? Not being rude but curious. Your experiences are your own and you are entitled to them and I respect them. I am not saying my experience overtrumps your experiences but as someone who has been in industry and have ran some big projects with $60M+ on the line for quite a while I can tell you that requirements always change and if you don't need that ability to send an email that was just added to the new release of XX framework a few months ago, when your boss come back and you and says:
"oh remember that wharehouse app you made to manage all those products? i need you to add a completely unexpected requirement of sending that email directly to shipping with all item details and who the shipment is going to"
Framework to the rescue because a developer coded that for you and you can easily send an email and package it up in a nice "mailable" class you can pass around all parts of your code.
But isn't that why you have framework documentation, Stack Overflow answers, Slack channels, community articles, online videos you can reference to help you debug that is not available to you if you build something from scratch?
I'll give this one to you. Frameworks generally can be manipulated in the sense of file structure but typically has only 1-3 way to do things like:
So yes frameworks make you do certain tasks a certain way but that's not a strong argument of why it is bad imo.
Maybe it is to you but having freedom to code the way you want to code isn't a perfect solution, it has significant drawbacks and maybe that's the point I am making is that this sounds good but it has a lot of drawbacks when you find the can you kicked down the road. I am genuinly curious on your opinion this time next year or 2 years from now or even when you switch employers.
I will be following up with you then 😈
Dito!