humble PHP

I'm building a sign up form for Jamaica Plain Porchfest. Technology wise, I decided to choose something that, if I ever parlay this into something other Porchfests might try to use, will be easy to deploy (even for less-techie volunteer groups) and I think PHP is the best bet in that regard. A decade ago Perl was my goto-language (so to speak) for this stuff, but PHP is feeling like right choice; a super gentle learning curve, without a real need for anything beyond the top of that curve. (When I first dabbled with PHP 13 or so years ago, there were parts that weren't ready for primetime, but now it feels reasonably mature and tends to have most needed functionality baked into its core.)

I'm making a semi-automated form builder using the file system and some baked-in JSON processing, and it's going well.

For the form builder, I found it most expedient to put some light html snippets in the code, a choice that seems to give other developers hives. But in grails and angular.js, the alternative is putting lots of logic and page flow control in the html... I don't see that flip as a tremendous improvement. The former gets a bit fiddly with quote marks, the latter gets extremely fiddly with whole new syntaxes to learn to bridge the gap. I only like to learn new concepts that empower me to do new things, not just marginally shinier ways to do the same old things...

(The only drawback is the dramatic unsexiness of PHP, resume-wise. For some reason I was heartened when a few days ago I noticed ".php" in some Facebook URL, though I know they're doing a lot of high powered server-side rendering, so it's more of an apples-to-jet-engines comparison.)
---
Thinking more about this: what are the limits to this style of development? In general, it's not great at setting up tests. But you know, the things that fail are exactly the things that unit tests (in particular) at bad at finding: system setup mistakes (which almost by definition aren't duplicated in the weird mocked-up, stubbed-out world of unit tests), and general flubs of syntax, which should never pass even the most basic developer tests.

So for that, it's probably suboptimal for really large complex engineering projects, but in my heart of heart I think those projects get set up on that scale more often than they should... so much of bespoke programming is very easy and can be kept simple, but there's a consistent Quixotic urge to try to build for the next decades, rather than keep it simple, and build stuff quickly that will last the next few years, and then will be easy to understand and replace when the time comes.

Anyway. Side note: another thing I admire in PHP is the default "lets blurp error messages to the screen". In the past I've been irked by that default, with the idea that things she be kept internal unless explicitly asked to blast to the screen, but for error conditions it's pretty great not having to dig up random logs and what not...plus it utilizes developer's egos, since any screw up will be right in front of the enduser. Failing loudly is critical in getting something up and running.