If you "simply create functions with granularity similar to PHP's features" you're basically re-implementing PHP from first principles. The advantage of PHP over C is that you don't have to do that. A lot of PHP is just wrappers around C anyway.
And yes the fact that it's easy to serve a website from PHP is a big part of its value, all else aside.
PHP is basically the Ur-implementation of Server-Side rendering and processing. JSP's and a bunch of other technologies are basically "PHP, except in-house" relative to other programming languages. As one of the earliest impl's of that that I'm aware of, it's also got the beefiest stdlib, and most eyes-on time. It was basically the JS of it's era. The value-add was that you once you implement the templates & widget toolkits, your designer could mix and match those elements for an arbitrary set of UI impl's without having to worry about leaving the php ecosystem. (I.e. abstraction + 1), and you get that "dynamic web page" experience where pre-PHP, you didn't have it short of writing a task specific, full featured native client, which was a different impl for each OS, and often meant implementing Yet Another Bespoke RMI implementation to get to your data sources anyway. PHP allowed abandoning the windowing toolkits and finicky clients, and just using a web browser + http. The drawback being all the dynamicity was entirely dependent on the server-side, meaning scaling your user population required beefier and beefier servers since the server was doing all the work. Eventually, the blight of JS happened, and the architect's realized they could dump the rendering work on caller's machines. It's all about tradeoffs. In a world with clients which were much less powerful than server hardware, and sketchier network speeds, PHP made the most sense. With hardware capable of running at clock speeds on par with server hardware, and broadband speeds broadly available, there's a case to be made for making the caller's hardware do more of the work. Personally, I think the server pages ultimately kept the incentives aligned better, but no one really asked me, and apparently the bean counters like externalizing costs wherever they can.
If you "simply create functions with granularity similar to PHP's features" you're basically re-implementing PHP from first principles. The advantage of PHP over C is that you don't have to do that. A lot of PHP is just wrappers around C anyway.
And yes the fact that it's easy to serve a website from PHP is a big part of its value, all else aside.
PHP is basically the Ur-implementation of Server-Side rendering and processing. JSP's and a bunch of other technologies are basically "PHP, except in-house" relative to other programming languages. As one of the earliest impl's of that that I'm aware of, it's also got the beefiest stdlib, and most eyes-on time. It was basically the JS of it's era. The value-add was that you once you implement the templates & widget toolkits, your designer could mix and match those elements for an arbitrary set of UI impl's without having to worry about leaving the php ecosystem. (I.e. abstraction + 1), and you get that "dynamic web page" experience where pre-PHP, you didn't have it short of writing a task specific, full featured native client, which was a different impl for each OS, and often meant implementing Yet Another Bespoke RMI implementation to get to your data sources anyway. PHP allowed abandoning the windowing toolkits and finicky clients, and just using a web browser + http. The drawback being all the dynamicity was entirely dependent on the server-side, meaning scaling your user population required beefier and beefier servers since the server was doing all the work. Eventually, the blight of JS happened, and the architect's realized they could dump the rendering work on caller's machines. It's all about tradeoffs. In a world with clients which were much less powerful than server hardware, and sketchier network speeds, PHP made the most sense. With hardware capable of running at clock speeds on par with server hardware, and broadband speeds broadly available, there's a case to be made for making the caller's hardware do more of the work. Personally, I think the server pages ultimately kept the incentives aligned better, but no one really asked me, and apparently the bean counters like externalizing costs wherever they can.
[flagged]