←back to thread

133 points avan1 | 2 comments | | HN request time: 0.001s | source
Show context
hu3 ◴[] No.45077689[source]
> In short, the modern PHP ecosystem gives us the best of both worlds: the ability to build quickly and confidently in PHP, while still having powerful options (C, Rust, Go) for performance-critical parts. This hybrid approach lets us stay productive without sacrificing speed where it matters most.

I understand this for a large codebase where rewriting is not feasible.

But if that wasn't the case, a C# APIs achieves both speed of development and execution in my experience. You'll rarely need to reach for C++ or Rust.

PHP is great but the language still doesn't allow things like typed arrays. It will happily accept string in a array of dates, for example.

replies(5): >>45077729 #>>45077935 #>>45078609 #>>45079138 #>>45081157 #
ThinkBeat ◴[] No.45077935[source]
Having been in the C# world for a long time, and the various web/api frameworks.

PHP is really nice if you dig into it, it includes so many great functions and functionality built in for creating web stuff.

It also has a number of issues,. but to quikly put something together PHP take the win in my limited opnion.

replies(3): >>45078266 #>>45079032 #>>45081636 #
reactordev ◴[] No.45078266[source]
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 <?php”.

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, it’s so easy to run JavaScript, I can build a basic jsx site in under an hour, just like I can with PHP and includes. With Bun, I can quickly write a data access layer as well and wire up crud APIs w/ JWT auth. A weekend project in both.

replies(4): >>45078380 #>>45078415 #>>45078417 #>>45085822 #
freedomben ◴[] No.45078415[source]
I'm not a huge fan of PHP, but for simple sites I think you way underestimate the power and simplicity. It feels old compared to jsx approach, but old doesn't always mean bad. I've increasingly returned to the template rendering model pioneered by PHP and for sites that aren't full blown apps, it is a lot simpler which means faster iteration and reduced cognitive load. I think you really have to decide based on the complexity you need
replies(1): >>45079044 #
sublinear ◴[] No.45079044[source]
> 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.

replies(1): >>45079127 #
zelphirkalt ◴[] No.45079127{3}[source]
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.
replies(2): >>45079257 #>>45079496 #
1. reactordev ◴[] No.45079496{4}[source]
The issue is, if I’m using JS, why on earth would I ever use PHP? I can just await file('index.html') or return <IndexPage>

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.

replies(1): >>45097428 #
2. zelphirkalt ◴[] No.45097428[source]
So if returning a component is the same, how would one (PHP) be more painting oneself into the corner than the other (JS)?