Hacker News Reader

Comment by Zelphyr | Hacker News Reader

Until you hit something the framework wasn't design to do (which happens 100% of the time in my experience). Now you're working for the framework instead of it working for you.

This guy said it better: “Frameworks invert control. They control the lifecycle of the app, and give you entry points where your code runs. You’re still responsible for the final code, but you’re not in control.” https://aerotwist.com/blog/the-cost-of-frameworks/

View on HN

I find this very true from my personal experience, but I also fine the repetition in my work to happen often enough that if you don't use a framework, you end up making your own framework

Depends on the framework. Dropwizard, for example, is built upon Jersey, which is designed to be modular and to allow components, even in core, to be extended or replaced (because they're nothing-special Java objects, all the way down). You have to understand the framework, but it's generally safe to assume that the intentions of the framework are good and that by adhering to the contracts between objects you'll get the result you want.

I'm not a big fan or frameworks for that reason. I do like some of the framework functionality and my apps are relatively small so I ended up going the micro framework route (Silex), using what I want (routing, forms, twig) and basically building the rest of the application in my own way.

Can you give an example of something you would like to do that a framework like Laravel won't let you do or you feel like you have to fight against?

Yeah, I hear that argument a lot from people who don't understand how the service container works. Laravel is really quite easy to understand if you have a decent knowledge of PHP. You can replace entire chunks of the framework for basically no cost if you want something to work differently.

Reply on news.ycombinator.com