Hacker News Reader

Comment by lol768 | Hacker News Reader

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.

View on HN

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.

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".

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.

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.

If there's one thing I hate it's reading modern framework code. Everything seems like it's been abstracted and genericized to the point of every component being spread over 10 files.

Ah sure—my point was less that I don't understand it (I'm very familiar with Laravel's auth system) and more that there are a lot of extra security considerations beyond the basic logging in, that I don't consider myself in a good position to keep on top of.

I don't disagree though; having tons of stuff available in the framework does give less incentive to learn how it all actually works, and I do worry that my base programming skills may atrophy (though for me this is more because a large portion of my workload is fairly uninteresting CRUD stuff).

> 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.

Agreed completely. My personal experience with PHP development has been 50% an awful undocumented "framework" written by a guy who no longer works at the company, and 50% Laravel on PHP >= 7. So yeah, I suppose it should be no surprise that I like Laravel!

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.

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

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

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.

> 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!).

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!

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.

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.

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.

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.

> 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/ 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.

Are you not allowed to install a new version of PHP? Because isn't it more worrying that you are using versions of PHP that are EOL?

They are EOL upstream. LTS Linux distributions backport security fixes and some bug fixes from current upstream versions to whatever versions are in their distribution.

That's actually one of the main points of an LTS distribution. They run the same version of languages, databases, web servers, firewalls, and everything else at the end that they did at the start, so that you get a stable platform throughout their lifetime.

If you go down the road of updating individual components to something significantly newer than what your distribution supports you can easily end up breaking other things--so then those need to be updated too, which might break more.

Even if that doesn't break anything else (and PHP would probably not...offhand I can't think of anything that I need in Debian that depends on PHP so switching to a later PHP would probably be safe on that front), it leaves you with software that isn't covered by your distribution's regular updates. For each such thing you install, you've got to put in place some way to find when the upstream has a bug fix or security fix you need, and some way to get and apply that.

I didn't realise they backported security fixes for PHP(as the example) independent of the vendor thanks for that you massively upgraded my knowledge.

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.

Debian LTS for a given Debian release provides support for whatever packages came with that release even if the upstream does not. They are still patching PHP 5.6 on Jessie and 7.0 on Stretch. There was a 5.6 update on Jessie last month.

See https://security-tracker.debian.org/tracker/source-package/p... for a list of all Debian's PHP 5 patches. The latest dozen or so are all less than a year old.

That's great for legacy projects but not realist for new or active projects running on modern frameworks.

I think you just said what OP said, but backwards. They have a long-running stable system that works great, but because the frameworks require versions that are more bleeding edge they aren't going to get them. I think frameworks that always target newer versions of their base language are limiting who will use them.

Mmm. Worth noting that PHP as a language has been moving pretty fast lately. The 7.x series is something like 2-3 times faster than 5.6 in most benchmarks, plus a lot of developer friendly features have landed, and some useful security features, which has led to a lot of people cutting support for older versions.

I understand the logic behind running Debian until the end of extended LTS, but it's going to have a number of drawbacks. Not being able to use a supported version of Laravel is probably not the biggest one either.

It's not a tradeoff that would be viable for my team, at any rate.

You could tell the same about (many) other languages or plattforms (e.g. .Net Core, maybe Java)

Maybe only python2 will match your expectations.

Can't you just upgrade to the latest debian, or switch to ubuntu? Seriously, migrating a php codebase is the easiest thing you could do. Of course you'd need to upgrade your code to php7 that isn't or may have breaking changes but the performance benefits alone are worth it.

Maybe you should suggest to management that instead of staying till end of life you stay till one-half end of life, that way you still keep somewhat modern stacks.

Reply on news.ycombinator.com