5 ms·

Sure, let's throw the framework out of the window along with its built-in CSRF protection, sensible security headers, templating language (which escapes input p

by lol768 6y ago

Sure, let's throw the framework out of the window along with its built-in CSRF protection, sensible security headers, templating language (which escapes input properly by default) and well-defined interfaces which enable me to e.g. access Request information. What could go wrong? For 99% of web applications, you probably need these things. I hate working on codebases that have been built without a framework. There's rarely any proper organisation of code. The quality of the code that the developer has rolled themselves is usually poor. At least if folks use something like Symfony or Laravel it's harder for them to shoot their foot off.

deergomoo 6y ago
Authentication too. Do we really want every app rolling its own auth? Sure it's nowhere near as bad as attempting to roll your own crypto, but there's still plenty of room for error. Throw in things like caching, background jobs, notifications, scheduled tasks etc., and a general purpose framework is often a very good choice—especially for a language like PHP which does not handle asynchronous operations nicely. Could I write my own versions of that stuff that only does exactly what I need? Sure, but why would I? It would take valuable time away from actually solving the problem at hand, and I can guarantee what I write wouldn't be as good as the stuff hundreds of people have worked on for several years.
- hombre_fatal 6y ago
  I used to think I agreed with these points, but with experience I'm more likely to assert: - "actually, authentication is so important that it should probably live in your application's git diffs" and - "glue code isn't as bad as I was led to believe -- it's nicer to read a simple application-specific implementation than have to dig into a framework's hyper-abstracted, generalized, one-size-fits-all, complex implementation when things go wrong".
  - deergomoo 6y ago
    I don't disagree in principal, but in practice: - I trust Laravel's auth code more than I would trust my own. Maybe that's naive, and it's probably an indictment of my own abilities, but the framework has hundreds of thousands of users and active support, while I am certainly no security expert. - For a lot of the things I've listed, an application-specific implementation would be far from simple. You can certainly make the case that debugging something like background jobs is harder because Laravel supports multiple different queue drivers and does have to be very generalised (though in practice I find it's a very understandable codebase), but I will happily cede some control to not have to worry about that stuff myself, much in the same way I don't want to be writing my own database adaptor. For what it's worth, I don't work on big systems. We mostly produce bespoke back-of-house systems that small to medium-sized companies use to manage their operations. I am well aware my priorities will not align with those who work on more important things.
    - hombre_fatal 6y ago
      I certainly don't think there are right and wrong answers here, btw. > while I am certainly no security expert While this is the circulated wisdom, I would respond: 1. This idea keeps us from ever learning how authentication works. "It's surely too hard". But by delegating it to complicated framework abstractions, we tend to guarantee that we never know how our app's authentication works. 2. Authentication can be surprisingly simple. Seeing it in the code is a feature. Maybe, "oh, it's just res.cookie('token', securelyRandomNumber())" vs. "hmm, I hope someone writes a blog post about how Ruby on Rails' Devise gem works!" or "I hope the framework's authentication wiki pages answer my exact question!" Frameworks sometimes make simple things complicated. I remember a common Rails/CodeIgniter question was how to redirect the user to the page they were viewing once they log in. That should be trivial. I think Devise eventually got a "redirectAfterLogin = true" config option, but that's kind of my point -- "I hope the framework thinks of my use-case" can be an unpleasant game to play. Of course, there are always trade-offs. I reckon I've simply been burned enough times, perhaps more than you, to prefer erring on the other side for a change. After after 10 years I do prefer it. I can imagine truly horrific bespoke hand-rolled frameworks that you probably have in mind. I won't defend those, haha. This is probably one of those things where your preferences are determined by what just happened to burn you the most so far which is most likely a coin flip.
gocartStatue 6y ago
My rule of thumb is to "mostly never" subclass anything from the framework. No point in wiring all the components manually, I use the base framework installation, but organize all the namespaces to my liking (mostly modules divided into 4 layers). If someone codes big projects like in the Symfony tutorial, he's going to have a bad time.
atarian 6y ago
Are you telling me you don’t like to build your ORM from scratch? Kids these days..
- trey-jones 6y ago
  I think you could replace "PHP Framework" with "ORM" in the "Always use a" section and many of the same arguments could apply. Very often (not always!) an ORM is just a crutch for a new dev that doesn't have time to learn SQL.
  - lol768 6y ago
    > Very often (not always!) an ORM is just a crutch for a new dev that doesn't have time to learn SQL. I can definitely say that's been correct in a few cases. I'll be damned if it doesn't normally make it really easy to switch out the DBMS though (not that this portability is exclusive to an ORM!).
    - trey-jones 6y ago
      I almost wrote some things about that. In 10 years we've never actually used this feature of ORMs, but it's good to know that some people get value from it!
    - kyriakos 6y ago
      In reality its very rare for any large scale application in production to have to switch to a different DBMS and in the cases when that happens, you have to worry about a lot more things than rewriting queries. Even with an ORM there is zero guarantee what you wrote for MySQL will work in Postgres or SQL Server which means. When choosing to use an ORM i think portability should be very low in the list of benefits.
      - pebcakID10T 6y ago
        Absolutely, the main feature any ORM needs before I will consider it, is how easy is it to write raw SQL with the ORM. Because you always have to do this on every large application, and if an ORM gets in your way, it's more hindrance than helpful. Actually love Laravel's ORM Eloquent, because it works for 99% cases, and gets out of your way and lets you populate Laravel models with raw SQL queries when you want to. After using many ORMs in many languages, it's still my favorite.
deleted 6y ago
[deleted]
tzs 6y ago
> At least if folks use something like Symfony or Laravel it's harder for them to shoot their foot off I'd like to consider giving Symfony or Laravel a try, but at work we run Debian and stay with a given release until it is near the end of extended long term support. Laravel's oldest release that is still supported is 5.5 LTS, which requires PHP >= 7.0.0. The next oldest still supported is 6 LTS, requiring at least 7.2.0. We're on Debian 8, Jessie, which is on extended long term support until 2022. It has PHP 5.6.29, so no Laravel for us. Even if we were on 9, Stretch, which has PHP 7.0 and so could use Laravel 5.5 now, Stretch is on long term support until 2022 and will be on extended LTS for probably a couple years after that, we'd run past Laravel's LTS. Heck, even if we were on the current Debian, which is 10, Buster, which has PHP 7.3, it is not clear we could use Laravel. Laravel only does security fixes for 3 years on LTS releases. Buster has Debian support until 2024, LTS for a couple years after that, and then extended LTS for a couple year, so it will be past the end of security patches for the current Laravel before it even reaches LTS. So unless I can be sure that the next LTS release of Laravel does not raise the PHP requirement past 7.3, Laravel is out of the running. (But wait...what about https://packages.sury.org/php/ https://packages.sury.org/php/ which is a package repository maintained by one of the main Debian PHP packagers where he packages newer PHP for older Debian? That's close enough to the official packages that I could probably convince the IT folk to add it. Alas, he only packages for older Debian until they go out of LTS. If you stick with it through extended LTS, you are out of luck). With Symfony, 3.4 is the oldest supported release. That requires at least PHP 5.5.9, so will work on Jessie or later. However, 3.4 support ends in a couple months. That will leave all supported Symfony requiring at least 7.1.3 which means you have to be on Buster. It looks like they have a similarly short LTS support life as Laravel, so even if you are on Buster today, there doesn't seem to be any good reason to believe that there will still be a supported Symfony that works there at the end of its regular support lifetime, let alone that one that can take you into Buster's LTS or extended LTS. Debian is the only Linux distribution for which I've looked at this in detail, but a brief look at others suggests that the situation is similar for Red Hat, and maybe Ubuntu.
- conradfr 6y ago
  That's more a problem with the way you workplace operates, as even the php organization doesn't support versions < 7.2 (and more realistically < 7.3). You're kind of in a no-win situation.
Kalium 6y ago
I think it's one of the key virtues of the programmer: arrogance. I've worked with engineers who hated frameworks. They saw them as overhead imposed by force on everything they did that didn't know or care what they actually needed. Surely it was better and simpler to compose libraries to do what they needed, as they found they needed it. Ultimately, they failed to understand that they needed CSRF protection, security headers, input validation, any kind of meaningful authentication or authorization framework, and so on. In their arrogance, they assumed their insight into their needs complete and total.
- Supermancho 6y ago
  Programmers are motivated by Laziness and Hubris to various degrees. Arrogance is a side effect of success (within a limited domain).
pebcakID10T 6y ago
Back when I did PHP, our company started using Laravel and it was amazing. The team was so much more productive with that framework and our platform was very easy to maintain. This article is bonkers. What a bizarre opinion, hopefully nobody listens to it.

by lol768 6y ago

deergomoo 6y ago

Authentication too. Do we really want every app rolling its own auth? Sure it's nowhere near as bad as attempting to roll your own crypto, but there's still plenty of room for error. Throw in things like caching, background jobs, notifications, scheduled tasks etc., and a general purpose framework is often a very good choice—especially for a language like PHP which does not handle asynchronous operations nicely. Could I write my own versions of that stuff that only does exactly what I need? Sure, but why would I? It would take valuable time away from actually solving the problem at hand, and I can guarantee what I write wouldn't be as good as the stuff hundreds of people have worked on for several years.

hombre_fatal 6y ago
I used to think I agreed with these points, but with experience I'm more likely to assert: - "actually, authentication is so important that it should probably live in your application's git diffs" and - "glue code isn't as bad as I was led to believe -- it's nicer to read a simple application-specific implementation than have to dig into a framework's hyper-abstracted, generalized, one-size-fits-all, complex implementation when things go wrong".
- deergomoo 6y ago
  I don't disagree in principal, but in practice: - I trust Laravel's auth code more than I would trust my own. Maybe that's naive, and it's probably an indictment of my own abilities, but the framework has hundreds of thousands of users and active support, while I am certainly no security expert. - For a lot of the things I've listed, an application-specific implementation would be far from simple. You can certainly make the case that debugging something like background jobs is harder because Laravel supports multiple different queue drivers and does have to be very generalised (though in practice I find it's a very understandable codebase), but I will happily cede some control to not have to worry about that stuff myself, much in the same way I don't want to be writing my own database adaptor. For what it's worth, I don't work on big systems. We mostly produce bespoke back-of-house systems that small to medium-sized companies use to manage their operations. I am well aware my priorities will not align with those who work on more important things.
  - hombre_fatal 6y ago
    I certainly don't think there are right and wrong answers here, btw. > while I am certainly no security expert While this is the circulated wisdom, I would respond: 1. This idea keeps us from ever learning how authentication works. "It's surely too hard". But by delegating it to complicated framework abstractions, we tend to guarantee that we never know how our app's authentication works. 2. Authentication can be surprisingly simple. Seeing it in the code is a feature. Maybe, "oh, it's just res.cookie('token', securelyRandomNumber())" vs. "hmm, I hope someone writes a blog post about how Ruby on Rails' Devise gem works!" or "I hope the framework's authentication wiki pages answer my exact question!" Frameworks sometimes make simple things complicated. I remember a common Rails/CodeIgniter question was how to redirect the user to the page they were viewing once they log in. That should be trivial. I think Devise eventually got a "redirectAfterLogin = true" config option, but that's kind of my point -- "I hope the framework thinks of my use-case" can be an unpleasant game to play. Of course, there are always trade-offs. I reckon I've simply been burned enough times, perhaps more than you, to prefer erring on the other side for a change. After after 10 years I do prefer it. I can imagine truly horrific bespoke hand-rolled frameworks that you probably have in mind. I won't defend those, haha. This is probably one of those things where your preferences are determined by what just happened to burn you the most so far which is most likely a coin flip.

gocartStatue 6y ago

My rule of thumb is to "mostly never" subclass anything from the framework. No point in wiring all the components manually, I use the base framework installation, but organize all the namespaces to my liking (mostly modules divided into 4 layers). If someone codes big projects like in the Symfony tutorial, he's going to have a bad time.

atarian 6y ago

Are you telling me you don’t like to build your ORM from scratch? Kids these days..

trey-jones 6y ago
I think you could replace "PHP Framework" with "ORM" in the "Always use a" section and many of the same arguments could apply. Very often (not always!) an ORM is just a crutch for a new dev that doesn't have time to learn SQL.
- lol768 6y ago
  > Very often (not always!) an ORM is just a crutch for a new dev that doesn't have time to learn SQL. I can definitely say that's been correct in a few cases. I'll be damned if it doesn't normally make it really easy to switch out the DBMS though (not that this portability is exclusive to an ORM!).
  - trey-jones 6y ago
    I almost wrote some things about that. In 10 years we've never actually used this feature of ORMs, but it's good to know that some people get value from it!
  - kyriakos 6y ago
    In reality its very rare for any large scale application in production to have to switch to a different DBMS and in the cases when that happens, you have to worry about a lot more things than rewriting queries. Even with an ORM there is zero guarantee what you wrote for MySQL will work in Postgres or SQL Server which means. When choosing to use an ORM i think portability should be very low in the list of benefits.
    - pebcakID10T 6y ago
      Absolutely, the main feature any ORM needs before I will consider it, is how easy is it to write raw SQL with the ORM. Because you always have to do this on every large application, and if an ORM gets in your way, it's more hindrance than helpful. Actually love Laravel's ORM Eloquent, because it works for 99% cases, and gets out of your way and lets you populate Laravel models with raw SQL queries when you want to. After using many ORMs in many languages, it's still my favorite.

deleted 6y ago

[deleted]

tzs 6y ago

> At least if folks use something like Symfony or Laravel it's harder for them to shoot their foot off I'd like to consider giving Symfony or Laravel a try, but at work we run Debian and stay with a given release until it is near the end of extended long term support. Laravel's oldest release that is still supported is 5.5 LTS, which requires PHP >= 7.0.0. The next oldest still supported is 6 LTS, requiring at least 7.2.0. We're on Debian 8, Jessie, which is on extended long term support until 2022. It has PHP 5.6.29, so no Laravel for us. Even if we were on 9, Stretch, which has PHP 7.0 and so could use Laravel 5.5 now, Stretch is on long term support until 2022 and will be on extended LTS for probably a couple years after that, we'd run past Laravel's LTS. Heck, even if we were on the current Debian, which is 10, Buster, which has PHP 7.3, it is not clear we could use Laravel. Laravel only does security fixes for 3 years on LTS releases. Buster has Debian support until 2024, LTS for a couple years after that, and then extended LTS for a couple year, so it will be past the end of security patches for the current Laravel before it even reaches LTS. So unless I can be sure that the next LTS release of Laravel does not raise the PHP requirement past 7.3, Laravel is out of the running. (But wait...what about https://packages.sury.org/php/ https://packages.sury.org/php/ which is a package repository maintained by one of the main Debian PHP packagers where he packages newer PHP for older Debian? That's close enough to the official packages that I could probably convince the IT folk to add it. Alas, he only packages for older Debian until they go out of LTS. If you stick with it through extended LTS, you are out of luck). With Symfony, 3.4 is the oldest supported release. That requires at least PHP 5.5.9, so will work on Jessie or later. However, 3.4 support ends in a couple months. That will leave all supported Symfony requiring at least 7.1.3 which means you have to be on Buster. It looks like they have a similarly short LTS support life as Laravel, so even if you are on Buster today, there doesn't seem to be any good reason to believe that there will still be a supported Symfony that works there at the end of its regular support lifetime, let alone that one that can take you into Buster's LTS or extended LTS. Debian is the only Linux distribution for which I've looked at this in detail, but a brief look at others suggests that the situation is similar for Red Hat, and maybe Ubuntu.

conradfr 6y ago
That's more a problem with the way you workplace operates, as even the php organization doesn't support versions < 7.2 (and more realistically < 7.3). You're kind of in a no-win situation.

Kalium 6y ago

I think it's one of the key virtues of the programmer: arrogance. I've worked with engineers who hated frameworks. They saw them as overhead imposed by force on everything they did that didn't know or care what they actually needed. Surely it was better and simpler to compose libraries to do what they needed, as they found they needed it. Ultimately, they failed to understand that they needed CSRF protection, security headers, input validation, any kind of meaningful authentication or authorization framework, and so on. In their arrogance, they assumed their insight into their needs complete and total.

Supermancho 6y ago
Programmers are motivated by Laziness and Hubris to various degrees. Arrogance is a side effect of success (within a limited domain).

pebcakID10T 6y ago

Back when I did PHP, our company started using Laravel and it was amazing. The team was so much more productive with that framework and our platform was very easy to maintain. This article is bonkers. What a bizarre opinion, hopefully nobody listens to it.