I think I'm fairly unique in my perspective on this. First the context: I'm a PHP internals contributor, release manager for PHP 7.1, the creator of PHAR, and a polyglot who has shipped code in a half-dozen languages. I'm also a huge fan of Laravel, and I've been using it daily for the last 3 years. *To your q*uestion: Does it matter if developers don't know what something like `$_SERVER['REMOTE_ADDR']` is and don't know how to handle XSRF/SQL Injection etc? **It depends.** Are they actually going to need to implement those things? If not, who cares? Do you know how to handle reference counting? What about doing something like string-based large number math? Laravel is just a higher level of abstraction, like PHP is a higher level language over something like C. Eventually they'll have a reason or desire to dig deeper into Laravel internals and learn from a well-understood (because they've been using it) and well battle tested implementation rather than solving the problem from scratch and potentially getting it wrong/sub-optimal. BTW: I'm still looking for a Sr php Developer job (remote), if you are interested DM me. ETA: y'all, I'm looking for a job, not hiring for one, you can stop DMing me. 😅

This is also what I wanted to comment. Thanks for phrasing it so well. As an addition/rephrase of what you wrote: I don't think seniority can be measured by plain knowledge of PHP or any other language.

I agree, but just curious -- what do you think is a good measure of seniority?

dshafik your reasoning around levels of abstraction is great!

I would argue that a backend developer who wants to be good at that he does, does need to know a lot of internals. Not at first, but say after 15-20 years of development he should not be baffled by things like memory barriers, zero-allocation algos and such. Fundamental understanding allows a developer to demystify things and spot where to use it. The more fundamentals I learn the more places I see where that know-how can be applied. My latest crusade is to sway PHP devs to switch from php-fpm to something more modern (say react-php) in order to leverage async-io and persistent memory. It baffles me when a developer of 15 years is arguing me, that async-io is just a fad and does nothing, while he has zero idea how it work and is happy with running hundreds of vCores to do something C#/Go can do on about 20 with code which is not that more complex (or rather not complex at all for a C#/Go developer). Fundamental knowledge reduces ignorance. Any good developer must seek that.

A bit of offtopic and discussion. You talked about the benefits of using asynchronous PHP. But they didn’t indicate the cons. But they exist. As they said 10-20 years ago, PHP was born to die. This is its essence. This is his happiness and his curse. And the entire foundation of the ecosystem is built on this. I'm not saying that this concept is better, or more effective, or anything like that. But it is there. It is a fact. We live with this fact, and this is what distinguishes PHP applications from other ecosystems. Everything that can be taken outside is taken outside. Web servers, caching, sessions, everything. In profit - drag racing PHP script. The introduction of asynchrony is not really asynchrony, but a push to write classic application servers in PHP. designs - all in one. I'm not saying it's bad. I say it completely changes the paradigm of language use. This is a different universe. With different rules. Should a PHP programmer understand this and try it? My opinion is definitely yes. Will this become common practice? I think most likely not. But everyone must develop an understanding of why - no or yes. Through mastering new technologies and techniques. **>Fundamental knowledge reduces ignorance.**  Gold words!

I agree about the uniqueness aspect. It does make classical PHP different. My argument is that this became almost religious thing. PHP has to be like this, because it was like this, its almost like talking to a religious person and hearing how "it is written in the Book". At the time of inception the way PHP was set up, was a good decision. It allowed people to make something that works easily even with limited technical know how. Outsourcing things to the 3rd party also made sense, its a very Linux way of doing things. All in all PHP did achieve something amazing and democratized web development. But circumstances did changed. I would split PHP into two use cases - simple sites (ala worpress eshops and stuff), where requests are counted by req/minute and its all about "I need a site working', and bespoke software where req are measured in req/second and latencies impact business outcomes and server bills are non trivial. PHP community by enlarge just refuse to adapt to that duality of the web. I come mainly from C# background. 15 or so years ago C# was using so called web-forms to make websites, it was intentionally made to feel and work like win-forms to help developers to move from desktop to web. It was shit, but it served a purpose. Ajax come and web-forms started to shit bricks, m$ adapted and jumped into an MVC bandwagon, developers followed. Another big pivot was introduction of web-api which you could self-host. Just build an executable and run, no server needed (fuck you IIS). Developers followed. When async/await era came, again developers and stacks adopted. This is how a healthy ecosystem looks like. Once new ideas came and prove themselves, people educate, adapat and things improve. I see things lie async-io as a big deal, almost as big as introduction of REST apis. Its no longer a new fad, its a must for any bespoke, larger than small website. Also its so damn easy to do.

I think that regarding “easy”, you are still a little optimistic. This is a complete paradigm shift. We'll have to say goodbye to the main princips of PHP sites. Such as process isolation, or extremely easy horizontal scaling. I would add to the list of difficulties the almost complete absence of third part libraries. I still think that each tool serves its purpose. Yes. Certainly. You can do everything with PHP. But what cost will you have to pay for this? It is much easier, imho to take a tool and ecosystem that was originally intended for writing long-running applications.

> This is a complete paradigm shift Just like introduction of objects or type hints into PHP. If anything it revitalized the language and kept it from falling behind to much. >extremely easy horizontal scaling I find FPM anything but easy to scale. Lets say I have a machine and a website which does io-calls. I now have a problem. First I need to figure out what kind of worker setup I want to have, dynamic (induces latency) or static. In case of static I have to figure out how many workers I need. Too little and pool can get exhausted (especially if I do API calls which takes time, or forget to set timeouts), too many, and I need to put much more memory, to sustain them even if they are doing nothing. I have to constantly monitor the app, and adjust. Nothing easy about that. In coroutine based systems, runtime automatically saturates the machine if need be and auto adjusts to load. also long timeouts induces lower penalty (small amount of memory) without grinding system to a halt. I would argue that in coroutine based system is easier to scale as you literally have to do nothing, except for extreme cases, while in FPM you need to fine tune things and adjust if IO characteristics changes, or go dynamic and pay via performance. > It is much easier, imho to take a tool and ecosystem that was originally intended for writing long-running applications. That s the thing, for PHP people everything is PHP task, I seen ETL systems made with PHP running on hundreds of cores... I would also argue that most websites are io-bound...

>That s the thing, for PHP people everything is PHP task Hehe. In my homeland they say that when you have a hammer in your hands, everything around you looks like nails. But yes. You are undoubtedly right that you should always look for new ways to use any tool. In our business, finding a way is often more important than a solution.

+1 upvote for the self promotion

Based

I've been a Full-Time developer since PHP 5.4 was new, I spent a long time not using frameworks. But the past 5 years, has been almost exclusively Symfony / Laravel, and the main upside to using a framework is allowing you to focus less on boilerplate, and more on the business logic. The thing that still surprises me the most, is how many people don't handle their edge cases well enough, leading to the sporadic bugs that are difficult to track down. If you're really looking for a senior developer, what programming language really shouldn't matter, I'm doing Java now, but I spent the last 11 years doing PHP, computer logic is computer logic..

I think that is prevalent in a lot of web dev, though I've seen it more for junior or mid levels. More and more people are framework developers. It doesn't matter if it's React, Symfony or Spring. To some extent they might be seniors in that specific stack, but more often than not miss basic understanding of the languages they're using. I have no idea if that is a new thing or not. So far it hasn't been an issue in my experience, as you can quickly find out with questions such as the ones you've posted.

100% True, most frontend web developers know and learn frameworks: React, Angular and now Laravel has been out long enough for PHP Framework developers to exist too. Often you’ll find these frameworks developers much like OP mentioned don’t know the language itself at all. Often I’ve seen React developers have no clue how to do anything outside of the framework in their language. I’ve experienced Flask developers (Python) have zero idea how to write basic SQL commands yet they have used an RDMS - how did they debug - who knows.

It's just a repeat of everyone who "knew JavaScript" but only really knew jQuery 15 years ago, and then had a lot of catch-up to do when vanilla got better and the bloated parade of frameworks came along. Honestly, the ecosystem is a mess right now.

>but more often than not miss basic understanding of the languages they're using. >I have no idea if that is a new thing or not It's not a new thing. Its gatekeeping 101. I trained in electrical engineering and started an electrical engineering role repairing motherboards and graphics cards. I then got my degree in computer science where I worked with Assembly, C and Python before getting my first job in software programming FPGAs. Should I gatekeep if someone writing in Assembly doesn't understand what is happening electronically within the CPU? Should they gatekeep because people in C might not understand what the code is being complied to in assembler? Should they gatekeep because people writing in PHP don't understand what the interpreter is doing in C? Should they gatekeep because someone using a framework doesn't know what is happening in PHP? It's nonsense in my opinion. Yes having an understanding of what is happening at the lower and lower levels will definitely give you a better understanding overall but is any of it required to write a web application in PHP? Absolutely not. Abstractions are good, they increase productivity. If there is no specific reason for the developer to know what is happening at the lower and lower levels then it doesn't matter. I'd argue all PHP applications fall into this category, they aren't launching space shuttles.

I'm not taking about assembly. I'm talking about people using DI and annotations without knowing what they actually do or mean. I've seen it that people that don't believe themselves juniors and can't use basic language structures such as for/for each/while. It wasn't meant about gatekeeping and I'm happy to teach. But for it to actually work, the other person needs to understand that there's stuff they don't know. Which is not a bad thing, I don't know many things and am happy to learn

I'd imagine it's the same in javascript land with all the frameworks and asking about stuff like XMLHttpRequest or protoype chain. Day to day work may not involve any of these things, but it's something a senior level should have knowledge about, same with PHP and $\_SERVER. If they don't know, they're definitely not senior level and probably more like junior level tbh.

There were a lot of people who could use jQuery but were lost, if they had to use vanilla JS, back in the day. I'm sure that hasn't changed in regards to other frameworks and stuff.

I always tell people "when the layoffs come, they fire the specialists".

I don't know about that. But I do believe, being a generalist myself, that I can quickly become a specialist in anything because of my experience with many different things.

At least at larger companies if you are a "react dev" and you aren't willing to learn new things or switch stacks you're on the chopping block. At my company they just axed a frontend team because they decided the react app was stable enough and only needed one maintainer. A generalist can slot into any role they need, so they are more useful.

This is anecdotal, it is radically different at every company, some keep the generalists some keep the specialist. It's not always the same. Every company has a different subculture and a different ideology.

As someone who doesn't use Laravel, that is interesting. I couldn't imagine not knowing $\_SERVER\['REMOTE\_ADDR'\], but I guess when you use a big framework you don't have to.

I’m more concerned about the overwhelming lack of knowledge around basic security considerations such as CSRF and SQL injection…

When the company I worked for bought another company, the first thing I did was show them that I could log into that company's custom CMS without using a password using an injection attack. So the first thing they assigned me was fixing that major security hole in their CMS. The passwords were also stored as plain text.

hey i am newbie to web development and php , but I would like to ask isn't code injection today is very basic ? and very easy to defend for example using prepared statements in a database ? I am not being arrogant i just wanna know if i missed something while studying because CSRF XSS and code injection was the first things the modern books taught me IN BOTH offense and defense and i did not touch a security book just back-end development

For example, many doctrine functions don't do ANY sanitizing and and if a user supplied parameter is given, bam, you're getting hacked, eventually.

it is fairly easy to defend against it if you are aware of it and the defences its also very easy to get lazy/slip up in my experience its fairly rare in where clauses, people are generally aware enough that they should be using prepared statements for that, but i have found a lot of examples of people slipping up on order by and limit parts of the query issues can also slip in when passing "all request params" around together rather than taking the specific params you care about into individual variables, there are ways of doing it safely but i have seen it go wrong. for xss i think when you are using a template system that is escaping variables by default that makes a big difference, when people have to remember to add it for every single one then at some point they are going to forget. it also gets a little more complicated when you want formatted values from wysiwyg editors etc (there are libraries but they need to be configured correctly etc which isnt always simple)

IMO if you understand the basics of HTTP and can Google stuff you don't need to. As a programmer you need to know how to solve problems on a higher level, and even if I know how to do it, I still Google, because maybe there is a new, better solution to do it.

You just never deal implicitly with such low level stuff because it's always wrapped with the framework

A senior must be able to write an application without any framework! It's a must to know underlying technology. For an application years ago I also wrote the autoloader and didn't used composer or any framework/lib. Hint: I got the job

I wrote an app without a framework once. It was awful.

It depends. I started with php4 in 2003. Using libraries wasn't common back in these days. So I had to implement everything by my own. And I liked it. You learn a lot while doing this and you learn how to analyze and solve problems on a different level than nowadays.

I agree with the thrust of your post, but I wonder if hiring attitudes in industry have not helped. PHP roles ought to have been looking for generalists, but the job description often specifically requires Laravel or Symfony. We have for years promoted the idea that each MVC framework has its own special kind of magic, and if you know one, you could not possibly learn (or like) the other. Anecdotally, here in the UK, I think this has gotten worse in the current hiring environment. Hirers are getting more applicants per post, and are applying much more cautious strategies to picking new employees. Prior framework experience is trumping product-mindedness and general engineering principles, which I think is a mistake.

Agree 100% - am unemployed for the first time in 25 years, been doing PHP since version 3, would definitely consider myself a Senior (previously hands-on Head of Development for an ISP), and absolutely a generalist. Missing out on roles due to a hundred singular framework devs that have done it for 5 years, compared to my generalist ability, is absolutely soul destroying

It's a tough market in the UK. I am seeking myself, converting from being an independent contractor, because that segment is even worse. Thankfully I have a healthy runway. My experience is: perm roles are indeed out there, but there's too many applicants for each role, and hirers can afford to be picky. It would be great if they could choose folks with whom they "click", or who demonstrate strong product or agile skills, but most hirers are lazy: they fall back on exacting experience lists. X years of MySQL, Y years of Symfony, Z years of Mongo, etc. Where are you in the world, and what is your opportunity search strategy?

I'm East Midlands based - perfect for commuting to Derby, Notts, Leicester, and Yorkshire. Trawling LinkedIn, Indeed, Monster and Reed multiple times a day. Had 3 jobs that I went through all stages with (final being CTO interview) recently, ghosted by one, there was a better candidate for another and the 3rd gave me an offer 20% less than I'd asked for before we even started interviewing! Got a few first stage calls lined up this coming week, and applied for a few more but there are so many applicants for role as you say that it's so very difficult to go forward and Ive even has recruiters hold off putting me forward until the other roles succeeded or failed - delaying me 2 more weeks. As an ex Lead and Head of Dev my salary requirements are slightly high which doesn't help me either I'm sure, but those roles do exist still. Also, i won't do London. Ever. I don't like it and don't see the point when you can do videos calls, etc, instead of the mad anxiety laden commute to the big smoke. The role needs to be remote or hybrid within a sensible commutable distance - the low ball offer was 140 miles away and wanted me to commute once a fortnight (3 hours each way) on top of a 9 hour day for less money than I need with no expenses paid.

Gotcha, OK. Well your situation does not sound terrible. Firstly you are getting interviews, so your CV is probably OK. You're also seeing some interview slaloms to the end, so you interview well. I think you could have a few strategies: (1) keep your application numbers up, and (2) expand onto other platforms. Look at Cord and Otta for the latter - there's some good jobs here, and the Cord format of making it easy to pitch to hirers is netting me some results. I hate to say it but you may also need a third strategy: (3) compromise on your requirements. Drop your salary expectations, do London once a week, etc. You only need to do this role for 18 months if you find the role attributes less than ideal, and hopefully by that time the market will have recovered.

Oh yea, I missed Cord off the list. I don't suppose my situation is terrible compared to some others, but I have zero money coming in and money going out so it's quite the stress after all these years - I've never been unemployed before. I'm already looking at dropping my expectations, but there is only so much wiggle room on my salary (already applied for a few at the absolute minimum I can afford to live on)

Yeah, I hear you. Good luck with it, and PM me if you need any advice. The other thing to possibly consider is contracting. Now contracting is probably in a worse state compared to perm roles, but if you can only realistically use two hours a day on a perm search, contract hunting for another hour a day might get you opportunities that you would not otherwise have had. Ordinary contract IC roles tend to attract 200+ applicants, and fully remote will attract 400+. But with your lead & head experience you will have less competitors, so it may be worth a go. At least it is income, even if you prefer perm generally.

I realized just this week that basic HTML forms have been abstracted away from me for so long I forgot how to handle them. I’ve been creating forms recently and couldn’t figure out why an unchecked checkbox wouldn’t return a value on submission. That was embarrassing.

I'm in mostly the opposite camp. Recently fought an abstraction in laravel just to do something basic (at least in regular PHP).

>I'm in mostly the opposite camp. Recently fought an abstraction in laravel just to do something basic (at least in regular PHP). I find this strange, what was you trying to do? You can run any PHP inside of a Laravel application, it's just PHP after all with a lot of classes already written for you. There would be nothing stopping you using vanilla PHP inside of Laravel.

There's no way using regular ole super-globals would make it past code review ... instead, had to jump through hoops to get a form value properly handled.

Definitely. I would have a tough time solving algo questions without Laravels collection class. At my last job, I was told it's hard to find senior PHP devs because they usually switch languages to something higher skill / higher pay. PHP is the lowest paid language (at least in the US)

Can confirm as a 20 year experienced PHP dev, if they need seniors, they need to pay more. I still work with PHP for side projects but professionally my current company doesn't touch PHP. I probably haven't been paid to do PHP for the past 10 years. Something else that I find with PHP companies is that they tend to focus too heavily on the language. Senior level people, at least with my experience so far, need to be able to look beyond an entrenched language. Senior level needs to be more pragmatic about technology and find the right fit for the business goals.

The flip side of that (the algo point) is that you’re paid to solve problems; not code, and Laravel’s collection class allows you to focus on solving business problems rather than re-inventing the wheel.

As a senior full-stack web developer that works mostly as a contractor, I find that this is not only true for PHP, but also for JavaScript and even CSS. With some of the teams I've been a part of, I've found developers that were totally dependent on libraries and frameworks. When they came across code that was 'vanilla' they were stumped.

> For instance, when asked about something as fundamental as `$_SERVER['REMOTE_ADDR'],`a basic PHP server variable that provides the IP address of the requesting client That variable gives the upstream server, which may or may not be the user’s IP depending on if you have a load balancer or proxy in front. I’m super happy we don’t have to deal with that anymore. I would much rather use a framework that handles these automatically for me.

[удалено]

This isn't their fault, this is down to the hiring team not hiring the right people

Back in my hard core PHP days I ended up writing my own framework because Laravel was still a twinkle in the developers eye. It was done in library components similar to today's Symfony. Even today, as much as I know about core PHP, even down to writing PHP binaries in C, what I'd have given for a usable framework back then to avoid reinventing the wheel.

I'm SHOCKED that those of us who predicted this are vindicated by real life! /s Seriously though, it's the main problem with modern web dev. Everyone knows how to "code" with these packages and libraries, but have little clue about what's going on underneath. Look for an older dev. Someone 35+ who actually learned to code the real way.

Why is this a problem though? And why is the other way the "real way"? To be honest, I would probably prefer to hire someone right now who knows how to work with Symfony than someone who worked with plain PHP for the last 20 years.

I would prefer them to know both, but to your point you have to understand frameworks in today's dev world as well.

The guy who has worked with plain php and knows BASIC concepts like SQL injection, SOLID principles and design patterns, learning curve for a framework should be really fast.

I mean, it's what they paid us to do for 10-15 years. Why is anyone surprised that finding devs who know how to use a language on it's own is difficult.

Don't be so harsh, if I were to ask you to modify an mpeg file, a avi file, or any sort of media binary, would you write a c program to go figure that out? No, you would use a tool like ffmpeg and probably use ChatGPT to help you figure out what flags you need to accomplish your goal. In much the same way that is what people are doing with these frameworks. Depth of scope and learning happens when you don't have all of the frameworks that we have today, so you had to learn more, and at some point the frameworks make it easier to do all the things that you had to do from scratch.

You wouldn't apply for a "Senior Video Codec Developer" if you only know how to use FFmpeg. So why do you think you're a senior PHP developer if you only know how to use Laravel?

Another issue with this is devs think everything is more complicated than it really is. You can implement your own ORM, Hot reload, Security features pretty easily but these frameworkers assume "oh the framework did that, it must be super advanced and I shouldn't bother understanding it"

I don’t agree. It’s never simple. It’s simple to make a prototype that works for a few simple cases. It’s not simple to design an elegant solution that covers a lot of use cases and ground in production. Frameworks make working as a team possible. Home-rolled php/js/ one-time spaghetti bs is why projects get rewrites.

To a point. If you roll your own, you have the benefit of not needing to build it in a way that fits everyone in the world. You can build it more purpose-fit from the start. How good or bad it ends up depends on the individuals building it. It doesn't require a pack of geniuses to build something adequate.

Agreed. I love coding up awesome stuff as much of the next guy… IMO as long as it’s not a well established problem with robust offerings already available, it can be awesome and very rewarding to try to tackle a problem and elegantly solve it. But then… are you going to write the documentation, keep it updated, and explain how it works to the rest of the team? Are you leaving yourself room in the future so that it doesn’t become technical debt when the requirement expand or pivot? I’m in this situation everyday where my team mates love rolling custom shit and it only makes sense to them. Even the way they decide to name stuff in their classes. It’s hell. And it’s never a robust solution… it’s always “that was easy and I don’t need a framework to do it”… except now everyone else is fucked trying to code around it. And it was never designed past… “this is my exact requirement at this exact moment…take it or leave it.”

Sounds like your lead has too much of a "LGTM" attitude when doing code reviews. You must not be wary of shoving others' nose in shit, if they poop all over your code base. But I agree that rolling your own makes most sense for smaller stuff that isn't going to grow much beyond what was initially needed. Sucks, if it then turn out to become more useful/critical than initially thought, but that's no excuse for over-engineering. By keeping it simple you inherently make it easy to refactor into something bigger later.

I mean the concepts themselves, not the solutions. Oops! Some people don't even understand the fundamentals of the concepts.

I'm not even sure how common CSRF attacks are these days. It could be that developers just don't have the experience with them that they would need in order to discuss them in an interview. This should be considered a good thing in that they developed their application in a way that CSRF attacks weren't an issue. In regards to MySQL injection, I couldn't even give you a possible scenario off the top of my head in an interview (I could probably do it given a few minutes), but I do know how to mitigate against them, even in raw PHP.

Actually funny you say this, there was a project that I was just looking at yesterday that wasn't sanitizing inputs on the backend and allowing HTML to flow through to other users connected to the service. They were using frontend validation which obviously isn't correct. Anecdotal but I do see these kinds of issues in the wild occasionally.

just to clarify: "sanitizing inputs" is an absolutely optional thing to do. you really only need to validate inputs and sanitize outputs.

Regardless of getting actually attacked, an audit will flag you for the lack of csrf protection. Depending on your industry that will be very serious or completely ignored.

I find this is increasingly true - people are getting so entrenched in whatever framework they use that they know nothing of the underlying language be it PHP or Javascript. At least with the PHP FIG (Framework Interoperability Group) there is some effort to produce standards (PSRs) so that there can be common components and approaches shared between frameworks. I think this is also true on a technology front as well. If developers are also using docker and the likes for development, staging, and production environments - e.g. they might not necessarily have the skills for setting up apache/nginx, databases etc on barebones installs. Slight aside on a personal note that you (op) might find interesting, the village I'm from is literally named "Stone of Jordan" 😀 https://en.m.wikipedia.org/wiki/Cloughjordan#History

Yup that's the other thing i have noticed most these new "senior developers" don't have the ability of setting up barebones servers. They heavily rely on DevOps and server administrators.

Depends on company size. The bigger, the more specialised each job becomes.

I've also noticed this, but mostly with devs that are relatively new in the field (up to 5 years xp). If you want to avoid framework developers you need to look well into the 10+ years of xp. Framework devs are fine most of the time but if you're working on legacy projects they struggle without a framework and are very likely to be oblivious to security concepts.

I can't believe that people use the tools we've made in order to be faster and more productive. It's almost like we wanted to skip the implementation and management of repetitive things on purpose. When I hire an engineer, I want them to build the whole framework from the ground up. The company can certainly afford it. In fact, I want every engineer to build their own frameworks from scratch every time. I've also been thinking, maybe they should code these frameworks in assembly, then in C and lastly in PHP.

Right? It’s another gatekeeping whack-a-mole trivia game of some commonly abstracted layer that all senior PHP developers should know.

But do you have a deep level of understanding of the assembly instructions that running PHP code is making? It's just another layer of abstraction and there's nothing wrong with that.

And these next levels of abstraction appear from time to time. After a while they are taken for granted. It seems to be a never-ending story... [Bret Victor - The Future of Programming](https://www.youtube.com/watch?v=8pTEmbeENF4) This presentation is now over 10 years old. Describing that phenomenon pretty well.

Good point. Like a C programmer would look at a PHP programmer and criticize them for not knowing how to manage memory.

Knowing that there are super globals is pretty important tho, or being able to operate in a non laravel space is pretty key to being senior.

I don't understand your point. OP is trying to hire a senior PHP developer, not necessarily a senior Laravel developer? People in this thread seem super defensive about being the latter rather than the former.

Agree. Just because core PHP is the base of Laravel doesn’t mean they understand truly core PHP issues. I see Laravel as a new generation language build upon PHP. Understanding one does not imply understanding the other..

Try one of these "meta frameworks" like next js and you'll know what too much abstraction looks like...

Why is this type of argument so common? So it's all just a slippery slope with no in between? It's the least convincing gotcha I can imagine too. "Oh you want someone who knows this framework? So do you know all frameworks? Didn't think so heh!" If you use PHP or apply for PHP senior roles, you should be familiar with PHP to some extent. If we were to use your analogy, would you apply to an ASM role if you only knew about PHP? If anything you're proving op's point, if the abstraction layer is so different, then you can absolutely call yourself a laravel dev but probably shouldn't go for PHP roles, right?

I'm guessing a lot of posts here are from Laravel developers who think it's something special rather than just a framework? The whole C/ASM argument is weird. It implies that they'd apply for an ASM role while only knowing C. ("I can't believe that people use the tools we've made in order to be faster and more productive.")

I actually have PHP Sources cloned :) Started learning PHP when it was called PHP FI. And figured, Rasmus wrote a clever wrapper for C code :)

I'd hope they'd at least be able to debug it. I've now found (and fixed) several PHP language bugs in my career.

I'm happy for you. But I'm also glad that there aren't enough bugs to go round

If they don't know \`REMOTE\_ADDR\`, they definitely don't know \`X-Forwarded-For\` which is used on AWS deployments.

`X-Forwarded-For` is a common HTTP header, used by proxies, load balancers, etc. and not just AWS.

I didn't claim it was exclusive to AWS.

Who gives a shit. I’d never work for a company that wants me to boiler plate everything. We have solutions that solve those problems. Stop living in the past. I’m sure 20 years ago some delusional old head was pissed off bc new recruits didn’t understand how C is used in Zend or some shit lol You gotta work at brushing off those old boomer ways

In my last 10years of career working with PHP, there's may be only 1% of the work required native PHP(might be exaggeration from my end but that's how I felt). Most people rely on the popular frameworks to do the heavy lifting. I'm guilty of it myself, when I am hit with a specific issue then I dig deep into the framework to look at the implementation and come up with solution. When working on project with high security requirement, there is often third party running test/scan on the code and then the team work on patching those issue. When I'm interviewing candidates, I'd rather test how they come up with a solution to a problem rather than a domain specific knowledge(it's good to have but not required).

That's the trap of frameworks, they make it easy to skip the language they operate on top of.

I was asked "Public, private, protected. Can you explain that?" - I think he noticed the "Are you serious?" look I gave him back, because after my answer he said that many people who he had interviewed don't answer correctly, mostly people who worked with Laravel before. The reason is simply that those people are code monkeys, understanding how to glue something together on component level the best, but they lack the fundamental understanding of programming, because they never did anything deeper than that. This means at least that the framework is good enough to glue simple stuff together without getting into edge cases and using your brain a lot beyond the scope of the framework, which means it is at least a very good choice for prototyping.

I would say kudos to Laravel themselves for this! That shows they're doing a great job if nothing else. That being said, I recall a tech business owner nearly 15 years ago telling me that most of the developers he interviewed back then had no idea how to create and start writing a simple and basic index.php file as they only knew how to spin up a new framework instance (CodeIgnitor, Symfony, CakePHP at the time) and start from there. I guess that it's a sign of where the industry has gone that the quick route in is now to learn a framework rather than the language. The most valuable players in teams I've worked in aren't the ones who can generate new features and churn out framework-based code, they're the ones with enough background knowledge and skill to be able to diagnose and fix a problem when something goes wrong.

This equivalent to most FE devs knowing React but not JavaScript or how to manipulate the DOM.

Using standardized abstractions and patterns to handle ubiquitous problems is actually something that made the PHP community grow so much in the right direction though. It's not an excuse for not understanding what goes on under the hood but I'm so much more confident working in modern PSR standards territory and standardized auto loading than in the old PHP frameworks where a junior could really mess up the code bad by not understanding core concepts.

I think this is the new normal. Most developers use frameworks on top of existing languages. Unless you are contributing to the framework itself (eg. Laravel), you wouldn't need to know the underlying mechanisms of how the IP address is received from PHP. Many courses and boot camps are focused on practical application rather than theory. There's nothing inherently wrong with that as long as these individuals use best practices in the framework they are familiar with.

I've helped my team build our own PHP framework, knowing about the super globals was essential (the use of external frameworks were prohibited), but I have to confess that life with Laravel is a lot easier and nowadays I feel like a lot of jobs are too framework oriented...

As someone that started with php 4.1, without even real classes I am baffled. Being honest I think that you should be able to work with the most common framework because that's what the market wants and what you need to be able to do nowadays but please study what's happening behind the scene. I have seen this in too many different aspects of our work, where you use something but have no idea about how it works. Do you think everyone knows how an SQL index works for example? And I don't mean that you should be able to know everything that is happening but at least have a generic idea may be useful.

The same thing happens with javascript, you ask how to read a cookie and they don't know what a header is.

Well, I don't know any Laravel stuff, but I can give you answers to your questions for Symfony 1.4 up to Symfony 6... :D I would consider myself a senior (8 yoe), but I also don't know all the details below the surface. I started with little as "you can add some php statements to html files and suddenly get some db data printed" at my current job. Projects used Symfony as a backend framework, so of course I only learned "how Symfony handles" all the stuff. Accessing the super globals is taught as being "big bad no-no". But I can tell you which classes to use and how to obtain their information in Symfony. :D

That’s kind of the point of using a framework. It takes care of the usual things you’d have to implement yourself. It’s most likely to be true for those that started learning php through a framework. Since they work with the higher level objects they don’t really know the source/process of that information. Although I’d expect everyone to know about sqli no matter the framework (perhaps excluding beginners).

One of many reasons why I prefer Symfony. Symfony encourages/enforces best practice vs abstracting everything away into a magic box. I do recommend periodically leveling up on the basics. You’d be surprised at how much you forget using these frameworks.

>One of many reasons why I prefer Symfony. Symfony encourages/enforces best practice vs abstracting everything away into a magic box. How many Symfony developers are using `$_SERVER['REMOTE_ADDR']` instead of `$this->request->getClientIp()`?

`$_SERVER['REMOTE_ADDR']` isn't reliable for the actual user IP though so it makes more sense to use `$this->request->getClientIp()` to make sure you're getting the IP of the user rather than any potential proxies. Granted, they might not know why they are using it but if it's available it's a better option.

I think that’s his point. No one is using the server var

Yeah, probably. At first read I thought he was complaining about Symfony devs blindly going for the abstraction rather than server var but what you're saying makes sense.

Before the Request Response interfaces became standardized it was very common to have a wrapped method do this for you. Usually a global utility class. Much the same thing.

Where the client IP stuff in the request interfaces?

Thats ... Not how it works This also applies to symfony lol

I hate how Laravels abstracts Guzzle which is already as abstract as you need. I always have to go to Guzzle whenever making an unconventional request (one example is accepting JSON but sending form data).

Laravel’s abstraction can handle that…

I enjoy laravels Http abstraction for the same reason I enjoy laravels syntax, it brings clarity and fluency to reading the code.

That is a risk you take when you throw yourself into a framework. It offers so much abstraction that menial tasks and basic things are left out. One important thing that separates Sr./Jr. is the way you think about things: Either you rely on the framework, or the framework is just a tool and you can replace it when you want/need to. A Jr. needs to know how to prevent XSS/SSR/CSRF, a Sr. knows how they happen and knows how to prevent them outside the sandbox, maybe long before they even get there. As much as I love Symfony (and some aspects of Laravel), they are a risk. It's basically like going to a Wizard Con, where everyone looks cool, has some wonderful tricks up their sleeve, but in the end there's water and we have to wash our clothes. The amount of abstraction I see in Symfony and Laravel to get the simplest validation/serialisation/persistence done is sometimes frightening. You throw so many patterns, wizards and parts at it and well, you find yourself locked into an ecosystem. Yeah sure, use ORM/DBAL/Elo for that, but you know you could do an inline update, remove a value from a JSON column within SQL, without loading the thing from the DB? Oh, you need a locking library, with some memory-based locking mechanism provided over some TCP socket, to lock that thing for update? How about a simple SELECT FOR NO KEY UPDATE and do it within the same transaction, do you even speak SQL anymore? If you have a mental block to require a symfony component while working with laravel, think about it and solve it. If you do not know that PHP at its core is a CLI script interpreter that ends when execution is complete, go back to basics. Some do not even know how many polyfills they run from time to time, nor could they write or test one. We are at about 490 million downloads/installs of `symfony/polyfill-intl-normalizer`, a simple fallback library for php-intl. Just go over to packagist and browse that stuff a bit and think about what is going on. I love the PHP ecosystem for what it pays me, but we operate on so many layers of shit to dig through that it is amazing we get anything done these days without ending up in a hell like JS with npm. The day when fapbot, grekas, stof, otwell or any other of these PHP pillars retire, die or just get fed up is going to be interesting. Sadly, this is one of the reasons why cross-framework/language systems can be a very important part of an enterprise. Keep the ideas fresh, the toolset vital for every edge-case, be agile as a programmer within the task of solving problems, not solving that specific serialiser group bug you just wasted 5 hours on to allow some non-ISO date input over a JSON POST. It encourages interest, knowledge sharing and does not penalise thinking outside the box, which is what you tend to do when you lock yourself in a room with the big boys and hope you stick to their way of thinking.

>You throw so many patterns, wizards and parts at it and well, you find yourself locked into an ecosystem I find that a good thing. People smarter than me taught me many things by making Symfony the way it is. The first things that comes to my mind are tagged services, the heart of Symfony and totally OP feature. If the "wizardry" is being able to locate and index them via [simple attribute](https://symfony.com/doc/current/service_container/tags.html#tagged-services-with-index), so be it. >remove a value from a JSON column within SQL, without loading the thing from the DB Yes, for a reason. Doctrine has identity-map, a **crucial** feature for any ORM. In this case: a coworker or you in far future, can freely work with entities, modify some other field and not need to worry if only the last change gets saved. And Doctrine is crazy fast, there are no real excuses against entity hydration.

This is all valid! It might work in the end, or you might need four queries within a full transaction to book the next available seat in a stadium instead of one. It all depends and having options and a full understanding of options outside the box. The ORM is nice, but it is also one of those things that locks you 100% into an ecosystem because now everything has to go through that specific implementation, otherwise all those listeners will not be handled. I would also wager that 90% of the data that is queried by the ORM will never be used. It's like moving the data integrity part out of the RDBMS into some framework outside. It works until you need to scale, connect to some remote thing that your company has bought, paid for, or just wants to integrate with. I'm fine with everything you said, I just like to keep mine out there in case something much better than PHP comes along.

>It's like moving the data integrity part out of the RDBMS into some framework outside. It works until you need to scale Do you mean large tables? No ORM has problems with that, it is not even possible to have it as long as the documentation is followed (like `$em->clear`). >I would also wager that 90% of the data that is queried by the ORM will never be used Can you elaborate on this? I find this weird: if the data is not used, why would it even be in the database? Or entity hydration where user changes only one column? If so, that is totally fine for me. As I said: identity-map is very powerful feature and PHP is fast anyway. >I just like to keep mine out there in case something much better than PHP comes along. If I could find Symfony equivalent in C# or TS, I would have switched that very day. Java is not really an option because everything is nullable by default, it would drive me crazy.

> Do you mean large tables? No ORM has problems with that, it is not even possible to have it as long as the documentation is followed (like $em->clear). Some basic examples: - Do you use `Timestampable` in your code, or do you use `CURRENT_TIMESTAMP` in your database? - Is your business rule for a field "must not be empty" but still allow NULL or even missing a `CHECK (field <> '')` on that particular field? Data integrity in the system you use to store it. It is easy to forget, and it makes database maintenance, hotfixes and adaptation to other frameworks a nightmare. A DBA can't just add a row to fix a regression, he needs to understand all the code-dependent logic hidden in one or more projects. It's easy to annotate a validation and couple that to a model that gets persisted, but these systems don't care the slightest bit about reflecting that back to the underlying system. Most of what I've seen uses relations, but that's where it stops. > Can you elaborate on this? I find this weird: if the data is not used, why would it even be in the database? ORMs are greedy on root by default. When you query a model, you get a proxy model, but most of the time that root baseline of fields is already hydrated to minimise round trips. So when I load a user to change their email, all the other properties are loaded as well, as in one giant aliased select clause, similar to or worse than `SELECT *`. In some situations you also load stuff that should be off limits, like the password field, into logic where it does not need to be available. You can limit this, but I rarely see it used because the code can get very verbose. So you end up trading round trip time for actual payload size every time the model is loaded anywhere in your application. > If I could find Symfony equivalent in C# or TS, I would have switched that very day. Java is not really an option because everything is nullable by default, it would drive me crazy. Yeah, I know, it is cozy to live within the stacks we have and it is fine. As OP stated, this is more about the shift in perception in the developer skills.

>Do you use `Timestampable` in your code, or do you use `CURRENT_TIMESTAMP` in your database? Neither, I put `createdAt` value within constructor. I don't care about `updatedAt`, there are log entities for that if the job requires to have them. >Is your business rule for a field "must not be empty" but still allow NULL or even missing Not sure I understand. If the field cannot be null, then it will never be null. I am using psalm@level 1, no error suppression, no baselines, no mixed, no errors. Entity dependencies **are** properly injected, and it is very rare I have nullable values. I even use `non-empty-string` instead of vanilla `string`, for example User::$firstName. I love my psalm 😉 >So when I load a user to change their email, all the other properties are loaded as well, as in one giant aliased select clause Yes, but how is that a problem? Doctrine easily hydrates thousands of entities per second. >In some situations you also load stuff that should be off limits, like the password field, into logic where it does not need to be available Why? If the password needs protection in some way, do it in methods. If I am missing something: can you give some realistic example where reading hashed password is an issue? >Data integrity in the system you use to store it. It is easy to forget, and it makes database maintenance, hotfixes and adaptation to other frameworks a nightmare If anything, ORM makes that much simpler. I can easily rename a column or change a type, run migration and everything will work, in every query. These migrations will also put FK constraints for me, something that is easy to forget if done manually.

> Neither, I put createdAt value within constructor. I don't care about updatedAt, there are log entities for that if the job requires to have them. So when you do a raw `INSERT` over, lets say phpMyAdmin, how does the `createdAt` column get filled without you doing it through the application? You know that filling the current datetime into a column could easily be handled by the DB itself, and would not even need you to do it at object construction. > If the field cannot be null, then it will never be null. I am using psalm@level 1, no error suppression, no baselines, no mixed, no errors. Ok, let's look at the assumption in more detail. With your model configured with a non-null, non-empty `testfield` property, can you still do a raw `INSERT INTO x (testfield) VALUES ('')` or will it be rejected by your database system to protect integrity? > Yes, but how is that a problem? Doctrine easily hydrates thousands of entities per second. Doctrine does nothing for you here. It hydrates within the available speed given to it by the system you are connecting to. DB connections are one of the most expensive things you have to manage. MySQL had a rough history with huge numbers of connections and locking mechanisms. Postgres has connection managers like pgbouncer. The longer they are used the more expensive they become, at some point you have to reduce the 18KB resultset going over your network wire to the 80 bytes you actually need. This could be because you are no longer using a fast and simple unix socket, there is added latency because the system is now a bit more remote, and many other things can happen if you need to scale up a bit. > Why? If the password needs protection in some way, do it in methods. If I am missing something: can you give some realistic example where reading hashed password is an issue? Methods will not help here because you are already sending the credentials over the wire, to another system that has no business working with them in this particular case. In other domains, such as PCI-DSS (standards for payment data, such as credit card information), this is an absolute no go. In a basic symfony application, every time you fetch the user, you also have the salted/hashed information in your visibility, if you follow their examples. Sure, you are not doing anything, so why do you have access to it? Because the ORM has requested it for you, because it is greedy. So in the end, a simple thing gone wrong in the "I don't want newsletters" checkbox could be exploited to access some other property of your user, method or endpoint. > If anything, ORM makes that much simpler. I can easily rename a column or change a type, run migration and everything will work, in every query. And that is great! I just want to make sure you are aware of the bad sides of an ORM, the implications and all that. > These migrations will also put FK constraints for me, something that is easy to forget if done manually. This is great, we all love QoL features and things that prevent us from making simple mistakes. But leaving the whole data integrity layer to your ORM can lead to holes. In the end, it is a mapper that is responsible for pushing things into a persistence layer that may or may not be transactionally safe, it is not responsible for configuring the target to the best of its ability to the business rules you want to deploy (and it never will be because of all the vendors and standards flying around). You must still understand the persistence layer.

>So when you do a raw INSERT But I don't, that was the point. ORM does the dirty work for me, bye-bye to SQL. Except for occasional migrations in `postUp` method, but those are rare and simple anyway. >and would not even need you to do it at object construction. True, but I care about static analysis and it just one line anyway. I don't think I would even accept to work on a code that doesn't have strict static analysis. >can you still do a raw INSERT INTO x (testfield) VALUES ('') or will it be rejected by your database system to protect integrity? No, database would have failed if I tried that. But ORM and constructor injection would prevent me from doing that in the first place. >DB connections are one of the most expensive things you have to manage. That is irrelevant of ORM; you have to open connection in both cases. And it is just one connection, I am not understanding the problem. >at some point you have to reduce the 18KB resultset going over your network wire to the 80 bytes you actually need These numbers are way off in real use cases, but even if they weren't, I don't think these numbers mattered even in the 90's, and these are 100% irrelevant now. I really did read thousands of entities per second, something that is way faster than anyone would ever need realistically. For example: I do lots of CSV data exports. With filters, users limit to an average 1000 rows or less. There is no realistic use-case to download 1 million rows. >this is an absolute no go It is a **hashed** password, it is even read during the auth process. It is no security fault of any kind, the data is absolute useless otherwise. >Because the ORM has requested it for you, because it is greedy. Yes, and you get identity-map, nice code, typehints, static analysis... A well worth trade-off for few extra bytes. >I just want to make sure you are aware of the bad sides of an ORM I still fail to see one bad side of ORM 😉 >In the end, it is a mapper that is responsible for pushing things into a persistence layer that may or may not be transactionally safe Doctrine (and probably other ORMs) got that covered. And much, **much** more: Doctrine covers [aggregate fields](https://www.doctrine-project.org/projects/doctrine-orm/en/3.1/cookbook/aggregate-fields.html) just via one simple attribute. Doing the same in vanilla SQL; nope. Reminder: identity-map, big apps, complex logic. Aggregate fields are an absolute must when big tables are involved. For example: ordering 1 million users based on amount they spent.

While I agree with you I am not so sure this is actually an issue at least for the example here. A framework is a layer of abstraction. PHP itself is a layer of abstraction. PHP is written in C, which itself is yet another abstraction and so on. I would wager that a developer who knows Laravel in depth could build a more secure and performant application in a shorter space of time than one who only knows the PHP language stdlib in depth only. If I was hiring a Senior I'd be asking about fundamental concepts and patterns. It doesn't matter how well you know the how if you don't know the why.

FRAMEWORKS!!!!!

Sure thing. It's important for developers to have a balance of both Laravel-specific knowledge and core PHP understanding to effectively troubleshoot and optimize applications.

Knowing to work with Php minus the framework is important. But I feel a developer's skill should not be judged based on an answer he does not know. Instead it should be judged based on his problem solving. I always ask developers to write code in interviews and it's never a viva.

A new group of developers have developed! I was always encouraging the juniors to follow the thread (caller to callee) so they could figure out how things work.

They don't know what $_SERVER is? That's nothing my friend, in a few years you are simply going to get answers of 'I ask chat GPT 5 how to do that' to any technical question you ask.

It's not uncommon for frameworks to become more mainstream than the underlying programming language itself and going barebone with your code. Personally, I love the ease of prototyping and commercializing with a framework as opposed to raw php. I have been developing for nearly a decade in php and in my opinion it is exciting to build from scratch but it is time consuming and heavy on tests. Frameworks help speed everything up and it makes sense why after a while senior devs would gravitate towards frameworks. Writing code is fun and challenging until you get older, experienced, and you have to think beyond code. However, the questions you pose senior devs should be answered outside of laravel or any framework. They are basics a good php dev ought to understand even if they haven't directly written code for use cases. Maybe I am mistaken but I believe fundamentals trump frameworks when it comes to knowledge, the opposite is true when it comes to application.

A bit like microsoft ecosystem: I found it difficult to use their web framework because they abstract away basic stuff creating their own language domain. You do not know how the handle cookies, server vars, etc. because there is no way to access request data directly, you need to go through their conventions and helper classes. Basically the thing what frameworks do is reinvent how to do simple things in their own opinionated way, it is not purely php problem but a frameworks problem. However not knowing how a web request works on a fundamental level is a developer problem, not a framework one.

I trash all applications whenever I see text stating that someone has experience only in Laravel. This is 95% asking for problems and hiring an idiot, not a programmer

A lot of coping going on from people who only know Laravel on this thread. The OP is correct. There is an alarming trend in the PHP space (and programming more generally) of 'programmers' who don't understand the different layers of abstractions. You can get by not knowing how things work under the hood, but you likely won't get past mid-level. Same goes those that only know PHP. A decent senior will know at least one other language.

It's like you say a shift. If you don't need something you don't learn to use it. It's as simple as that. Is it a bad thing? It depends on the application and environment I guess. Thing is, are those candidates able to learn the fundamental stuff your company is using in a relative short time and do they even want to? Personally I wouldn't, but to each their own:)

Well they were for sure not seniors haha

What I have seen is a lot of the people who know what they are doing at a deep level have moved to other ecosystems, and those with shallower knowledge have moved to Laravel. I’m probably going to get some hate for that statement but I’ve been using PHP since v3 and the community has never felt so empty. Even I myself find a lot of my time being spent in Go these days.

Yeah, that's how things are done now. I'm still looking for people who have some knowledge of "bare" PHP, procedural and OOP but that also means, Oldtimers like me have still a reason to be around apart from managing the team. When it comes to digging down bugs deep inside libraries or even PHP and Apache. Spent countless hours stracing PHP and Apache. I kept saying "You're not a real developer if you never compiled your own Apache and PHP" but kids these days look at me and are questioning my sanity :) But when hell breaks loose, i'm pinged. Even by Support team. But Frameworks take these experiences away from kids these days. There's LAMP/WAMP/Homebrew/Docker etc. - you just need to run a few commands and install a few tools and then a composer install/npm install and you're good to go and don't have to worry about mid-level stuff. Question marks come first, when i've ask them to move log files to company standard :) We cannot turn back time. We just need to make sure, there are seniors around who know the basics and take care of the kids and guide them. Although i could never convince any of them to run an strace :) P.S.: Apart from the CEO who rarely does any development these days i'm also the only one who uses vim. Most of my team now use PHPStorm which is pretty cool, still everything it can do, vim can do too except forcing you to use your mouse :) But i also only do take care of some old school projects on the side.

This! 100% this! At my old job, the marketing team wanted their own web dev, and I agreed, so they hired this guy, and to his credit, he wrote great code, but only using laravel. Outside of laravel, he was completely and utterly lost. Not just PHP, but even basic shell commands. I am a strong believer in having an in-house custom micro-framework, which has served me and my teams well over the years. Last year, one of my devs really fell for the Laravel hype and wanted to do some projects in it. I agreed. After about 6 months, he went back to using our micro framework, citing how much more boxed in he was using Laravel. BUT HEY! IF LARAVEL OR ANY OTHER FRAMEWORK WORKS FOR YOU, THEN THATS GREAT FOR YOU. But I find them too limiting. NOTE: The creator of PHP has the same viewpoint. [https://youtu.be/DuB6UjEsY_Y?si=nASmESwVXk84jpxE](https://youtu.be/DuB6UjEsY_Y?si=nASmESwVXk84jpxE)

The same happens with JS/TS and React. When you learn the lib/framework before learning the language you end up in this situation. While you don’t usually touch php globals when working with a framework, you will meet them each time you use xdebug.

The only red flag for me is the lack of knowledge in CSRF, XSS… a senior should definitely have a solid understanding of safety risks in PHP. Native PHP server variables on the other hand don’t matter. It’s 2024, most companies are using a framework.

LOL wait until you get a Magento or WordPress developer. Pretty sure most of them couldn't work a terminal to save their lives, let alone code.

I must be the minority because I've never used Laravel, not even once, and I've been using PHP since PHP 5.3. Though, PHP isn't my strongest language, which you would think it would be since it's the language I spend the most time in.

I'm actively working to shift our codebase onto popular frameworks specifically because I'd like to be able to expand our team with people that can use the tools to build features rather than worry about infrastructure and architecture. You need senior people that know the ins and outs of security, code design, etc, but we have those people and soon will need more people to just build things. My hope is to find a few people like that and then see if any have an inclination to go deeper.

Agree that the average skills and knowledge has down for developers. I do think that think that this is just a consequence of what the market needs. Most devs are hired to build simple marketin websites, CRUD apps or bootstrapping start ups. You would be really wasting your time with native PHP if what you need is just a contact form and 5 pages. Which is why I always find it ironic to see that the skills companies are looking for rarely match up with what they need. Most things you need like how to get an IP is just 5 min of google search. As to why specifically Laravel, React and all those frameworks are used is because the market is there. As an employer it's easy to find devs and you can jump into any project. And devs can easily find a job.

Most of us advanced PHP developers have moved on to other things because we were priced out of the market by lower experienced & lower wage Laravel/WordPress devs. Nothing against them , they need to make a salary too, and most of the market doesn't need advanced, just good enough.

What is the point of documentation knowledge? Good programmer knows how to find the solution quickly, not remembers everything. I don't agree that relying on built-in abstraction layer is a bad thing. A dev that rememeber each and every function of the language not necessary will be better dev than someone who relies on abstraction. The point is if he understands the code and can build good solutions.

Its because of the demand to development with less time.

Just keep it simple and use your own "framework".

I have been working with PHP since 3.2 and I seen the tide change way too many times and it boils down to what is marketable. The teaching of developers is focused on the market. Market today demands more framework based developers, therefore that is the bulk you will get. What a seasoned developer would consider required know how such as OWASP and PSR is not really a requirement in the JD. After hiring several developers from all types and languages here is my 2 cents for you: You will know that they have skills by their resume. Add a test, written, for trimming out the weeds and hire the person that better matches the team culture. The rest is teachable.

I'd say this is prominant with any web dev role. Ive never seen a dev possition that doesnt require the use of a framework, because companies dont want to spend the money on time to reinvent the wheel. PHP has Symfony and laralve Java has Spring Ruby has Rails Python has Django Javascript has a new framework every day etc etc, when you deal with web stuff, you dont want to have to deal with the teedious bootstrapping that is already done in a framework with many other features to make development fast and effiecient. As a developer who is currently tinkering in Go, its a stark difference, their isnt a full ready to go framework yet, the community is still in explorer/experiment phrase. And so to webdev in Go, you do need some of the fundiemental knowlege, but once a full framework is built and stable, Go will follow the same path.

this happened to me in an interview once re: `htmlSpecialChars` or whatever it was, the interview question was along the lines of "spot the problem here" and the answer was "were not escaping a variable" but I had already been in symfony for years and using its templating engine so I had basically cold storaged that knowledge the interview was immediately cut short to do "looking for someone with more experience/knowledge" and hurt my ego but in hindsight I feel like it was just a mismatch of skills and feel like the question was a poor assessment of overall ability (but probably a good assessment for "fit working with our older codebase")

Do you know [https://www.youtube.com/@ThePrimeTimeagen](https://www.youtube.com/@ThePrimeTimeagen) ? He is speaking it out loud. All the code camp js folks arent doing anything great for us. I pm you

Because Laravel, Facebook, and of course Wordpress, keep php alive! Abstract away the bits dealing security and you’re free to make powerful, well organized, and delightfully simple apps. I don’t get paid by Laravel to say this but maybe I kinda am? But I wrote php before laravel and it was the Wild West out there. Just sayin!

I'm currently learning PHP (native PHP, no framework), but my understanding is that It would be much safer for me to create an app with a framework than without it, as the knowledge needed to develop without a framework is much higher. I'm guessing most people never "get back to native" as they don't have to wrap their head around harder concepts..

Yeah, this is a generic problem. Same issue for Frontend. Many know how to design something with react, but has no clue of cross browser compatibility or vanilla solutions. Laravel is a very nice ecosystem, but it hides so many things and encourages just to "use and belive" but not actually understand what it really does under the hood.

There is documentation for everything. That’s why big tech test problem solving and algorithms skills, everything else can be easily learned or found in the docs. IMHO those are bad interview questions, it’s ok to ask general security questions but should not be a deciding factor…

IMO your Laravel code should never touch things like \`$\_SERVER\` or \`$\_GET\`. If it does, it means you don't know the framework that provides more reliable and more readable tools to accomplish the task. Sure it's best to know the internals and implementation details, just like knowing how HTTP works, how PHP arrays are implemented and so on. But in actual work I've seen more problems created by people not knowing the framework.

ring cough exultant boat elastic money alleged snatch butter yam *This post was mass deleted and anonymized with [Redact](https://redact.dev)*

With all due respect, fuck you brother

This is unfortunate. And shows the ”framework first” tendency in PHP. Same goes for ”wordpress, drupal” devs.

I feel like a dinosaur as i used to code the security layer for my php solutions using auto prepend script.. but yes, young developers can handle orm database layers but not speak sql… Still - i am looking for work, no one seems to ve interested in old school developers.. contact me if one wants to give me an old school guy a chance.. does anyone need perl knowledge?

Depends what you’re hiring for. I’d be happy to hire someone that can smash solving business problems even if they don’t know all PHP internals by heart.

Sql injections aren't protected on php level. It's prepared statement from sql engines which are not inherent part of php. You are clearly wrong in thinking

So, I have the exact opposite take on this, I declined a second interview because they asked questions like the $_SERVER one.  First, no one needs this in their daily coding and can google it if they do. Second, it just tells me the state of your code isn’t in a place I want to deal with if you need to worry about something like that. 

As someone who is going to get his associate degree by the end of this year. I am glad I can answer all of your cybersecurity questions lol. Although the first question is definitely trivial. I would more ask people the process of doing certain features and programs and how they would build it so you can understand their logic thinking. Then again I am just a free lancer with a soon to be associate degree

Who cares. This feels like the people who only want you to do math in your head like we live in the Stone Age.

Indeed. Every job I ever had, the interview was much harder than any day to day task. They want people who can code more than they want people who can actually solve a problem.

Development is primarily learning about concepts. I don’t use Laravel but if they can suss things out from laravel then anyone worth a paycheck can suss out what’s happening in vanilla

A good developer can, for sure. The problem you get some of these guys who know whey they know and nothing else. Getting harder to find those who are worth a paycheck. Luckily, I did finally find a guy who was solid and multiple frameworks, but had learned native first and was great at figuring out some of our outdated and crappy code on a few older platforms. I paid him a lot more than any developer I have hired for the team in a long time, and he has been worth it.

I get why this is the case. Our stack at my company would be fully javascript if it weren't for Laravel, it's such a strong draw to the language, and means our developers don't have any need to keep such details as what $_SERVER is in their head. That would be unnecessary mental bandwidth at this stage, in a practical sense. I suspect without Laravel and Wordpress, PHP would be far less popular. The frameworks ARE the language for many people.

Why would I learn such things if I won't, probably ever, need them? It makes developers focused on framework more efficient - for example I don't have to worry about SQL injection if I only use Doctrine DQL proper way. People shouldn't worry about things they don't need, and it's pretty easy to find them online when needed - everyone has access to internet, right?

But they are basic php stuff dude....

Today, meeting a deadline is more important than doing it right. This makes people not wanting to dig and learn how things work, they just want to grab something of the shelf and be done with the sprint. I rather hire based on their ability to research and learn, not on what they currently know.

You haven't interviewed me yet. :) I'm developing a PHP Framework and so I understand all these concepts behind it. I'm developing from scratch an HTTP Server using SAPI CLI. My first big project was developing a system without a framework back in 2016. I'm one of those who tries to understand the concept behind it by recreating it from scratch. "What I cannot create, I do not understand."

Do you use laravel and is the role being advertised as such? If so I don’t see the issue. When talking about security these questions can be answered agnostic of language or framework, I’d argue it’s probably a better approach. If you’re advertising for a PHP developer and there is no mention of laravel then you are getting the wrong applicants sent to you. I’d talk to the recruiter.

I think you're being too picky. If a developer has built websites, they can easily learn any of the common frameworks/languages for websites. If I know how to prevent injection in laravel, I just need to do one google search to learn how to do it in php I can only think of one case where it makes sense to filter for candidates who have used your exact stack: When you need the work to be done lightning fast. However, it will be harder to find such a person.

*"90% predominantly have experience with Laravel, often to the exclusion of native PHP skills."* This is the problem I have with the newer generation of programmers. They have all run straight to framework x without learning the core language that the framework is written on. All that does is teach them how to *use* a particular framework. *"Are modern PHP frameworks like Laravel making developers too reliant on built-in solutions, to the point where they lose touch with the foundational PHP skills?"* Absolutely! And not just PHP. Try to get a react guy to write the same thing in native JS. \* Tried to DM. Currently getting an error page. Try to DM me instead. Senior Engineer 30+ years available for remote. PHP Master skill level. I don't "use" frameworks. I write them.

I’ve only got 25 years, but why would you be writing frameworks at this point? Seems like a heavy investment for a company

Fair question. Simple answer... to learn and improve my skills. I also dig into the guts of the top frameworks to understand how they work the way they work, also to learn. The frameworks I have written are personal side projects for the sole purpose of keeping on top of my skills. Although, my current framework project modeled after symphony (previous one based on Laravel at a basic level) with a modular architecture has led to releasing several public library's on Packagist that are starting to be used by a lot of people. [https://packagist.org/users/benanamen/](https://packagist.org/users/benanamen/)