A decently structured PHP application is often maintained by nontechnical people with a limited understanding of programming but they can get by with just a text editor and a codebase. I have not come across any nontechnical person who could easily get a react/modern js framework pipeline going to do a small change, not to mention dealing with npm changes. I would almost feel like it would be a jerk move to leave someone without a technical department a pile of react/npm soup right now.
There's nothing in his post suggesting that the way he developed is harder for someone else to pick it up. MVC Frameworks aren't necessarily easier to use than vanilla PHP. Your answer reminds me of people who don't know how to use vanilla JavaScript and have to add jQuery to the project for things that could be one-liners in vanilla JS.
The whole "what if the customer needs something in the future" is just a piss-poor excuse that bad developers make to prematurely optimize. There's nothing in an MVC framework that makes it easier to add new features.
There is nothing preventing him from using official libraries for Stripe or Google Maps if needed.
There is nothing preventing him from using libraries that can be updated, probably with a single CLI command.
There is nothing suggesting his system is unsafe. Quite the contrary.
He didn't outsmart the entire industry. He just built something that works without relying on your favorite tool. Maybe you should try someday, you might actually learn something.
A simple php endpoint is something any web developer can understand. The more frameworks/libraries/patterns/abstractions you throw in the less likely it is they will understand it. Especially years later when the framework is inevitably out of date, good luck convincing why they need to spend money upgrading a framework every year.
> hey can we put Google maps in here?
Has this changed recently? Last I checked you would just drop a script tag into the page, who needs a library for that? Edit - I checked (https://developers.google.com/maps/documentation/embed/guide), how does a framework make a copy/paste job any simpler?
> "we need to integrate with stripe payments"
I'm not familiar with stripe, but don't you just give it a return url? I don't see how a framework would help at all here.
> you'll need to stay 100% up to date on all security issues/approaches/classes of vulnerability to make sure your custom system is secure.
This is harder with a framework, it's one more thing to keep updated. The less libraries the less vulnerabilities.
Having worked with both kinds of application, I personally find it much easier to learn my way around and understand a self-contained application than one which is a giant web of moving-target third party dependencies and frameworks, themselves largely undocumented and subject to the framework-hipster "move fast and break your users' things" mentality.
However I would be concerned about a couple of things if this were me and I was doing anything beyond the absolute most basic web app:
- long term maintenance. Doing something only you understand and only you can maintain (that job security you mention) is a bit of an unprofessional dick move IMO.
- if you need to get other people in to help, you now have to spend more time training then up on your custom system that they don't understand and keep an eye on them to make sure they are doing it right and not introducing security issues
- When your client wants to integrate with some common third party thing ("hey can we put Google maps in here?"/"we need to integrate with stripe payments") you'll need to reinvent the wheel from scratch to do it using your custom system rather than just use a well-supported off the shelf library.
- you'll need to stay 100% up to date on all security issues/approaches/classes of vulnerability to make sure your custom system is secure. Your audit was ok this time, but everytime you make a change to your custom library (e.g. to support Google maps or stripe) you're now going to need to go through the audits again to be sure you've not opened up any new security holes (and perhaps new ones you've not ever heard of because you are only working in this weird little custom system/thiefdom for the past 2 years)
- how to support the INEVITABLE requests for extra features that require something client-side that cannot be easily done with only PHP and static pages. It is not the 90s any more - the cat is out of the bag regarding interactivity ... the requests for client-side nicities that users are used to in other things WILL COME! Clients always want more! :-)
Still anyway I guess you don't need my good luck wishes as I am sure you are correct and that you really have out-thought and out-coded all of the well-supported and well-funded frameworks that have been built by many thousands of people and have been battle-tested in the field for years (e.g. Laravel, .net MVC, struts etc). Because otherwise if you hadn't totally out-smarted the entire industry, I'd be shitting myself and checking my professional liability insurance about now.