Haha me too. I think PHP was a great rite-of-passage as a developer back then: inconsistent standard API, all the session and cookie access built in, with all the security gotchyas, evolution from major versions 4 to 5, obsession with Frameworks, growth and development of ZF and Symfony etc. Great experience.

As I left the ecosystem, I realised I approached writing code in a very defensive, overly structured way and have written less than half as many libraries ever since. The jury is out on whether that's a good thing or not.

As a sometimes-front-end dev, part of me quietly yearns to go back to the days of serving full html pages, especially since data transfer speeds are higher than they've ever been.

Edit: that's not a rejection of React et al. more an acknowledgement that everyone wants to do server-side rendering "because performance" which was... what we used to do. If we serverside render most of the page, we only need to enhance _some_ of the UI clientside? Yup. Exactly what we used to do.

Regarding PHP, if you want it as a rite of passage it should come after writing software in better languages with better tools. PHP-first means bad-habits-first.

C imposes similarly rigorous proving grounds for developers, but without pushing new developers into bad habits that would come back to bite them later. If you want people to start with more requirements for hard thinking about how to not build a deathtrap, choose C instead.

As for the benefits of rendering server-side, they are legion, and most important among them is the fact that pushing everything to the client-side part of the system means not really knowing what your code will do in the wild, imposing whole new classes of frustration on users, and piles of other horrors. Yes, we could benefit from falling back on far more default-server-side technologies and using JavaScript only where it's needed, I think, for the sake of the users first and foremost.

JavaScript is great for some things. It's terrible for others, and all too often trying to use JavaScript for everything means coupling the wrong tools for many jobs together with the wrong place to run code, too. Even when I enjoy JavaScript work, the simple act of checking online documentation for the JavaScript tools I'm using ruins the whole experience for me as I realize how we're punishing our users when we don't think about how we're using JavaScript from a user's perspective.

My first language was Pascal. I'd like to think I learned good habits up front. But I'll fully admit, when I first started writing PHP, I definitely treated it as a "script". My code barely used functions at first. It was a big top-down autoexec.bat style recipe. It took quite awhile for me to come around to treating PHP like a real programming language. I think a lot of it came from the fact that I'd edit, and refresh the browser page. Whereas with Turbo Pascal, I'd save my work, and compile. Once I did come around to writing more application-style with PHP, I was more interested in other things (Java and Ruby at the time)

autoexec.bat, those were some good times, loved hacking the config.sys file

ahh... the good ol' days of magic_quotes enabled by default... because, yeah, why would anyone want to use data for anything else than putting it in a mysql db ? mm ? :-)