4 ms·

> instead of playing to the language's advantages and using light-weight tools and libraries that would allow them to move faster. Depending on what you mean b

by aarondf 11y ago

> instead of playing to the language's advantages and using light-weight tools and libraries that would allow them to move faster. Depending on what you mean by "move faster", I may have to disagree. Besides a one-off script, I can't envision a scenario where using "tools and libraries" would allow you to move faster than using Laravel. Laravel comes with an unbelievable amount of stuff done for you, right out of the box. Routing, Auth, Database, Queueing, Caching, Asset Pipeline, Templating, etc, etc. If your goal is to rapidly develop an application, there really is no better framework than Laravel to get that going. There's even a vagrant box that's all tooled for Laravel. TBF, I may have misunderstood what you meant by "move faster".

Zelphyr 11y ago
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/ https://aerotwist.com/blog/the-cost-of-frameworks/
- 27182818284 11y ago
  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
- eropple 11y ago
  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.
- acomjean 11y ago
  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.
- lostsock 11y ago
  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?
  - treeface 11y ago
    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.
brightball 11y ago
Laravel is an excellent Rails clone, but the entire problem with Laravel is that it's a PHP framework. I've been a PHP dev for 15 years and the biggest issue with frameworks in PHP is PHP itself. A request comes in, the PHP process loads up everything, executes the request and tears down...on every single request. In just about every other language, the application boots up, loads everything into RAM and each individual request doesn't have to reload things. There are definitely trade offs here. You can have a 1 TB hard drive filled up with PHP code on a 256mb of RAM server and everything is still going to run fine. There's a lot of value in that and most people who are PHP averse seem to be turning to Lamba from AWS to fill that gap. PHP scales down better than just about anything else out there. When the other commenter mentioned doing lightweight scripts with PDO that's essentially what he meant though. Lightweight avoids reloading libraries and PHP is lightning fast when you do that. A lot of progress has been made over the years to help PHP handle frameworks better, but there's a big reason why PHP grinds to a halt with heavy frameworks and that's it. Check out the techempower framework benchmarks. Using PHP like Go, however, and just pulling in what you need can be extremely powerful. Here's an entire presentation on it that I gave to a local PHP group. http://www.slideshare.net/barrywjones3/whats-the-right-php http://www.slideshare.net/barrywjones3/whats-the-right-php FWIW, I do really like Laravel and even recommend it if you HAVE to use a big framework.
- adrianmacneil 11y ago
  Pretty sure newer versions of php have an opcode cache built in, so they don't need to load everything on every request now?
  - brightball 11y ago
    Unless something has changed, that's the equivalent of keeping the files in RAM but it doesn't maintain state and routes, etc so it still has to reprocess.
    - acveilleux 11y ago
      That depends on implementation. The cache could be maintained in shared memory, an external process or disk files and in all cases can provide a significant speed up over reading in and compiling hundreds of files without burdening all workers with all compiled opcodes. The current implementation uses shared memory. In addition, that does not mean retaining all the variables and data, only the compiled opcodes and that's the bulk of the startup time.

by aarondf 11y ago

Zelphyr 11y ago

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/ https://aerotwist.com/blog/the-cost-of-frameworks/

27182818284 11y ago
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
eropple 11y ago
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.
acomjean 11y ago
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.
lostsock 11y ago
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?
- treeface 11y ago
  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.

brightball 11y ago

Laravel is an excellent Rails clone, but the entire problem with Laravel is that it's a PHP framework. I've been a PHP dev for 15 years and the biggest issue with frameworks in PHP is PHP itself. A request comes in, the PHP process loads up everything, executes the request and tears down...on every single request. In just about every other language, the application boots up, loads everything into RAM and each individual request doesn't have to reload things. There are definitely trade offs here. You can have a 1 TB hard drive filled up with PHP code on a 256mb of RAM server and everything is still going to run fine. There's a lot of value in that and most people who are PHP averse seem to be turning to Lamba from AWS to fill that gap. PHP scales down better than just about anything else out there. When the other commenter mentioned doing lightweight scripts with PDO that's essentially what he meant though. Lightweight avoids reloading libraries and PHP is lightning fast when you do that. A lot of progress has been made over the years to help PHP handle frameworks better, but there's a big reason why PHP grinds to a halt with heavy frameworks and that's it. Check out the techempower framework benchmarks. Using PHP like Go, however, and just pulling in what you need can be extremely powerful. Here's an entire presentation on it that I gave to a local PHP group. http://www.slideshare.net/barrywjones3/whats-the-right-php http://www.slideshare.net/barrywjones3/whats-the-right-php FWIW, I do really like Laravel and even recommend it if you HAVE to use a big framework.

adrianmacneil 11y ago
Pretty sure newer versions of php have an opcode cache built in, so they don't need to load everything on every request now?
- brightball 11y ago
  Unless something has changed, that's the equivalent of keeping the files in RAM but it doesn't maintain state and routes, etc so it still has to reprocess.
  - acveilleux 11y ago
    That depends on implementation. The cache could be maintained in shared memory, an external process or disk files and in all cases can provide a significant speed up over reading in and compiling hundreds of files without burdening all workers with all compiled opcodes. The current implementation uses shared memory. In addition, that does not mean retaining all the variables and data, only the compiled opcodes and that's the bulk of the startup time.