61–70 of 158 posts
Earlier quoted context omitted.
And still nobody outside of Meta cares about hack. The niche I think PHP had back in the day has largely been supplanted by Python. Maybe it’s better now, but after moving on from it to basically anything else after a 25 year career, I don’t miss it.
> And still nobody outside of Meta cares about hack. Because everyone is OK with PHP. I'm not even using it directly but most of the web runs on it.
I do this with Perl. One of the reasons I like Perl is because of its high committment to backwards compatibility. I like PHP because it's so easy to set up an installation of my app, but the breaking changes have bit me hard in the past, so I try to minimize its use. Together, it's a great combo.
Earlier quoted context omitted.
> I think you really have to decide based on the complexity you need I don't really agree. I think the goal should be to reduce complexity where possible, but not if you're inevitably painting yourself into a corner. If you want the simplest and most scalable way forward, write static pages and avoid server-side rendering.
How would you be painting yourself into a corner with PHP more than with JS? If you use PHP, you can just serve/use JS later. But if you use JS, you will have a hard time serving HTML from PHP later. Aside from both languages kinda being painting oneself into a corner, I don't see how one would do more so with PHP than with JS, out of all the things.
The cognitive load is null. You’re just having trouble breaking apart your learned behavior. Returning a component of jsx is just the same as writing an include for PHP.
Earlier quoted context omitted.
How would you be painting yourself into a corner with PHP more than with JS? If you use PHP, you can just serve/use JS later. But if you use JS, you will have a hard time serving HTML from PHP later. Aside from both languages kinda being painting oneself into a corner, I don't see how one would do more so with PHP than with JS, out of all the things.
I'm coming from the perspective of real world business concerns, not hobby projects. It's inevitable that you will need to host the pages somewhere else like a CDN to lower latency, integrate with other backends, and the biggest one is allowing the frontend devs to have complete control of the HTML so that stylesheets and javascript don't randomly break for reasons out of their control. They should be able to develop…
Browser -> Client-Side Server Pages -> Business Logic APIs -> Backend Systems.
Earlier quoted context omitted.
And still nobody outside of Meta cares about hack. The niche I think PHP had back in the day has largely been supplanted by Python. Maybe it’s better now, but after moving on from it to basically anything else after a 25 year career, I don’t miss it.
I'm not sure what point you're trying to make by mentioning Hack. At this point it's diverged from PHP to the point that it's basically a different language, is (IIRC) actually slower than PHP 8, and the HHVM doesn't even support PHP any more. As such, it's not a huge surprise that relatively few people outside of Meta give it much attention. I also moved on from PHP several years ago, and don't miss it. That doesn't…
And meta/hack is probably the other huge mainstay of PHP outside of what the person you responded to said. And hack with HHVM was supposed to be the panacea for PHP
Just saying.
What people used to use PHP for tasks, has largely been replaced by Python.
Not only that, but now we have these "frankenstein" solutions with all the interop problems on top of PHP.
Just shows that as a species humans really can't learn.
I'm starting to build a bit of antagonism to all-encompassing frameworks (e.g. Spring, Larvel, Phoenix, etc.), because while they are productive to build new things with, I seem to always have the same issue on legacy projects built with them. It always seems to be a challenge to upgrade dependencies for these projects. Its usually because (in building the thing) one can't fully follow the "prescribed" way of doing t…
Earlier quoted context omitted.
There's a firm foundation in Javascript. The choices aren't choices I'd make but they're choices I understand. Brendan Eich knew what he was doing and it shows, indeed if it was made simply of bailing wire and string it'd have been replaced. For PHP on the other hand - even when I started writing PHP3 - so certainly not the very beginnings, it's clearly just cobbling together whatever works from unrelated half-unders…
Do we need to post that JS' weird things link here? Of the basics of JS, few things are sound. The "firm foundation" idea doesn't really work for JS. It might even work better for PHP, and I am saying that as someone, who doesn't want to do PHP ever again.
The initial equality operator was a mistake, but that was rectified over a decade ago with `===`. Not having a proper int type sucks and holds the language back in a number of ways, but otherwise the language is wonderfully regular.
And anyone who complains about the ecosystem has obviously never tried python, which after a decade of attempts, is now almost on par with JS of a decade ago!
Earlier quoted context omitted.
The only reason PHP still exists is because of shared hosting companies and Wordpress. PHP’s initial appeal was you could do scripting on the server side, “turn off PHP with a ?>” spit out normal html, and “turn back on PHP with a For a beginner programmer, it was simple, easy to understand, and had an include so your designs were’t nested table hairball messes of garbage. (but your CSS was definitely garbage). Today…
PHP might have a bad reputation but I honestly don’t think JavaScript is a better language in real world terms. I do get why JS appeals to people, but switching from PHP to JS feels a little winning an internet argument — you might feel smarter for doing so but in reality all you’ve done is sunk time into something that doesn’t make you any better off.
I'm starting to build a bit of antagonism to all-encompassing frameworks (e.g. Spring, Larvel, Phoenix, etc.), because while they are productive to build new things with, I seem to always have the same issue on legacy projects built with them. It always seems to be a challenge to upgrade dependencies for these projects. Its usually because (in building the thing) one can't fully follow the "prescribed" way of doing t…
Flask prescribes so little that every project is a snow flake. Which of the N available options will you pick to handle auth/templating/cookies/email/whatever. Real decision fatigue when trying to enable core functionality. Extra special is that many of these libraries are single author creations, so maintenance and security are a mixed bag.
Django - every project roughly looks the same. You get so much out of the box that you must have special requirements if you must supplement with libraries. Since so many bits are first party, you have greater confidence that code is being maintained/checked for security problems.