4 ms·

> I'm not convinced that smaller PHP projects, at least, might not be better off without frameworks at all Uh having experienced the old pre-codeigniter php, I

> I'm not convinced that smaller PHP projects, at least, might not be better off without frameworks at all Uh having experienced the old pre-codeigniter php, I don't really recommended it. Without proper controller separation (using twig as rendering engine for example) it poses the risk for the business logic to be tangled with view. Not to mention that it's hard to do routing with native php, except the simple [folder-path]/[php-filename].php and remove the extension requirement with .htaccess. At that point I recommend to just use a framework instead, though arguably Laravel may be too big for some. I don't know if PHP has similar framework like expressJs though that just handle the minimum requirements.

chipotle_coyote 5y ago
> Without proper controller separation (using twig as rendering engine for example) it poses the risk for the business logic to be tangled with view. Well, you should also quote the part in my comment about "use Composer to pull in specific packages that you really need." :) I'm not suggesting "roll everything on your own," necessarily: if you want to use Twig, or another templating engine, add that as a Composer package. (Personally, I'd just write a small pure PHP template class to handle this and trust myself not to be a dingus, but if I were on a team that might change the calculus here.) > Not to mention that it's hard to do routing with native PHP... Again, you don't have to roll your own here; you can include something like FastRoute or even Symfony's router as a routing engine. I'm not saying you should avoid absolutely all libraries. Laravel is built on top of a lot of Symfony libraries, after all! For a project I've been noodling with slowly, I'm using my own "pure PHP" template engine, but I'm using FastRoute for routing, Doctrine DBAL (although not the ORM) for database access, Monolog for logging, PHP Debug Bar to get a lot of debugging info in development, etc.
- fendy3002 5y ago
  Okay that's a fair approach, though it's still not recommended for everyone especially those who isn't much familiar with those packages setup.

chipotle_coyote 5y ago

> Without proper controller separation (using twig as rendering engine for example) it poses the risk for the business logic to be tangled with view. Well, you should also quote the part in my comment about "use Composer to pull in specific packages that you really need." :) I'm not suggesting "roll everything on your own," necessarily: if you want to use Twig, or another templating engine, add that as a Composer package. (Personally, I'd just write a small pure PHP template class to handle this and trust myself not to be a dingus, but if I were on a team that might change the calculus here.) > Not to mention that it's hard to do routing with native PHP... Again, you don't have to roll your own here; you can include something like FastRoute or even Symfony's router as a routing engine. I'm not saying you should avoid absolutely all libraries. Laravel is built on top of a lot of Symfony libraries, after all! For a project I've been noodling with slowly, I'm using my own "pure PHP" template engine, but I'm using FastRoute for routing, Doctrine DBAL (although not the ORM) for database access, Monolog for logging, PHP Debug Bar to get a lot of debugging info in development, etc.

fendy3002 5y ago
Okay that's a fair approach, though it's still not recommended for everyone especially those who isn't much familiar with those packages setup.