My experience with these Frameworks is that one has to invest just as much time into learning the framework as writing your application in the first place. Then, the framework authors make breaking changes to the API. But your application is in production and the PTB won't let you re-architect it. So now you have a technical debt problem, back-porting features and bug fixes. So now you're developing the application AND the framework that it runs on. Also, 80% of the features of the framework will go unused because who has the time to learn all of it? You only learn what you need to get the job done and you move on. So there's all this baggage lying around and you don't know what it does. If you had just written the whole thing yourself you would understand every line of code, there would be no crud/baggage and no technical debt. PHP *is* the framework. Just write your own code.
@@victortodoran1828 I agree. I can build a framework but I will need too much time to do it. Anyone using a framework where the author can easily break the code is using the wrong framework. That's why semantic versioning exists. Although I do understand where the original author is coming from. I find that some frameworks do way too much. I personally prefer frameworks that work as a glue for libs and allows the dev to still build the code they way they want instead of enforcing a way to programme that often goes against clean standards. The leaner the better.
No, if you use a serious framework, you won't experience unexpected breaking of the API. Probably more than 80% of the language features themselves go unnoticed by the average programmer. The framework has to cover a broad range of use cases. It doesn't mean you have to learn all of them. If you write the whole application yourself, you'll need few years, nobody else, probably not even you, will understand the code by the end. Serious and professional software development can be done only using frameworks, or at least third-party libraries. No way you can finish a commercial product in time writing everything by yourself. And no employer or client will pay you so much money to write everything yourself. I have the impression most of the critics against frameworks come from beginners who haven't delved deep enough into the topic of frameworks.
I like that "Instrumentation" pattern in your repository implementation. I haven't seen it before - usually people just throw exceptions. Is there a reason you're using the instrumentation? To prevent call stack destruction?
TRONGATE framework has quickly filled its placed and will change people's attitudes to frameworks....Trongate is going to leave all the existing frameworks in the dust, if you liked CI3 you will love Trongate because its in part inspired by it, and 20 years of best practices rolled into one, the focus is on speed, stability and NO REWRITES .... there is a newer version of Laravel since this talk and a lot of what you did in last version is now different. Trongate is V1 forever!!!!
what i like are micro frameworks like f3, which are being around for quite some time. technically imposing orm models, page controllers and templated views. the problem first aproach though goes before the coding. the apps i'm working on have not a complexity that would require interfacing a framework though 🤷♂️
Yeah! micro-frameworks are better since those help you to have your domain code more decoupled, but still, it is important that you design your code using micro-frameworks and not on top of that :D
If you are starting out and if you are not working I'm a team then I agree however as someone who has many years under his belt I can assure you I no longer have interest to build everything myself. I typically use popular libs to handle code that i really don't need to build anymore. It also has the advantage of having more support and allowing other devs to work with the code if they have used said lib elsewhere.
My rule of thumb: Use it for fast prototyping and if time pressure is a deal. Don't use it for enterprise applications which you want to (be able to) maintain also in 2+ years.
My experience with these Frameworks is that one has to invest just as much time into learning the framework as writing your application in the first place. Then, the framework authors make breaking changes to the API. But your application is in production and the PTB won't let you re-architect it. So now you have a technical debt problem, back-porting features and bug fixes. So now you're developing the application AND the framework that it runs on. Also, 80% of the features of the framework will go unused because who has the time to learn all of it? You only learn what you need to get the job done and you move on. So there's all this baggage lying around and you don't know what it does.
If you had just written the whole thing yourself you would understand every line of code, there would be no crud/baggage and no technical debt.
PHP *is* the framework.
Just write your own code.
Dude.
Let's be serious, if you wrote the whole thing yourself you would never finish and 100% you won't understand every line of code.
@@victortodoran1828 I agree. I can build a framework but I will need too much time to do it. Anyone using a framework where the author can easily break the code is using the wrong framework. That's why semantic versioning exists.
Although I do understand where the original author is coming from. I find that some frameworks do way too much. I personally prefer frameworks that work as a glue for libs and allows the dev to still build the code they way they want instead of enforcing a way to programme that often goes against clean standards. The leaner the better.
No, if you use a serious framework, you won't experience unexpected breaking of the API.
Probably more than 80% of the language features themselves go unnoticed by the average programmer. The framework has to cover a broad range of use cases. It doesn't mean you have to learn all of them.
If you write the whole application yourself, you'll need few years, nobody else, probably not even you, will understand the code by the end.
Serious and professional software development can be done only using frameworks, or at least third-party libraries.
No way you can finish a commercial product in time writing everything by yourself. And no employer or client will pay you so much money to write everything yourself.
I have the impression most of the critics against frameworks come from beginners who haven't delved deep enough into the topic of frameworks.
PHP *is* the framework.
I like that "Instrumentation" pattern in your repository implementation. I haven't seen it before - usually people just throw exceptions. Is there a reason you're using the instrumentation? To prevent call stack destruction?
It's interesting how quickly code igniter has left center stage
TRONGATE framework has quickly filled its placed and will change people's attitudes to frameworks....Trongate is going to leave all the existing frameworks in the dust, if you liked CI3 you will love Trongate because its in part inspired by it, and 20 years of best practices rolled into one, the focus is on speed, stability and NO REWRITES .... there is a newer version of Laravel since this talk and a lot of what you did in last version is now different. Trongate is V1 forever!!!!
it's never been on the center stage
If you don't use a framework you will end up creating one!
If you use a framework long enough you will end up rewriting it.
atleast its your framework and you only add what you need...
what i like are micro frameworks like f3, which are being around for quite some time. technically imposing orm models, page controllers and templated views. the problem first aproach though goes before the coding. the apps i'm working on have not a complexity that would require interfacing a framework though 🤷♂️
Yeah! micro-frameworks are better since those help you to have your domain code more decoupled, but still, it is important that you design your code using micro-frameworks and not on top of that :D
I don’t like frameworks in PHP. Better to sharpen your blade closer to the language.
If you are starting out and if you are not working I'm a team then I agree however as someone who has many years under his belt I can assure you I no longer have interest to build everything myself. I typically use popular libs to handle code that i really don't need to build anymore. It also has the advantage of having more support and allowing other devs to work with the code if they have used said lib elsewhere.
The title of the video is click-bait and totally false.
So what about the laravel way *Controller::__invoke(Article $article)?
What do you mean?
If is it ""ok"" to have it?
My rule of thumb: Use it for fast prototyping and if time pressure is a deal. Don't use it for enterprise applications which you want to (be able to) maintain also in 2+ years.
I like Slim PHP Framework :)
This is a really bad speech. He's mixing DDD with Hexagonal Architecture.