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.
vim projects/example.cs
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
app.MapGet("/", () => "Hello World!");
app.Run();
Not the same as PHP I know, but it's close enough for me.
PHP:
- vim projects/webhook.php
- vim projects/webhook.cs
- Assign a port number
- Reconfigure Nginx/Caddy to serve that port number
- Reconfigure systemd to dotnet run projects/webhook.cs on startupPHP’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.
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.
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-understood parts and so there's no coherent centre to it, when I last worked on some PHP earlier this year it still felt like bailing wire and string.
Equally, PHP3 is worlds apart from modern PHP.
Your point is a little like saying “motorbikes are easy to maintain because they’re based on the penny-farthing”. Times have changed and your references are literally decades out-of-date.
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!
Saying “at least x isn’t as bad as y” doesn’t further a discussion, it only acknowledges denial about just how bad the problems are with x.
This is particularly true when we weren’t even discussing y (in our case, Python) in the first place.
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.
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 everything locally with mocks instead of your server and use whatever build tools and frameworks they want. There are also SEO and accessibility concerns with the page structure. The backend devs should not be making decisions about any of that. Sometimes the client may want quick turnaround on simple but very specific changes to the pages. None of that process should depend on backend teams who don't care and will drag ass about it because they will have to refactor their junky code that hasn't been touched in years.
Getting rid of dependencies and having good boundaries in the code that align with the way dev teams are organized is always a good thing. I'm not sure why anyone would go for SSR unless they haven't done web dev in a while or are working on a legacy project. Even if this starts out as a hobby project, you need to keep things clean for future maintainers.
Browser -> Client-Side Server Pages -> Business Logic APIs -> Backend Systems.
To me it rather sounds like what you describe are code monkeys that give zero pushback on back engineering decisions, and will jump at anything that marketing throws in front of them. We have way too many of that kind already, making the web a dystopian version of what it should be.
And let me tell you, I am mostly doing backend things, as all the hype in the frontend world is offputting, but when I do frontend things, I don't do half-assed things. I make websites more responsive than 95% of "responsive" websites that we find these days as passing for that, most of which are developed by frontend developers, unsurprisingly. This is because I don't subscribe to the hype and solve responsiveness issues using web standards and CSS.
Just the other day I enhanced a couple of pages in a platform I am building, so that they can be used entirely without JS, while they are polling the backend API. Nothing too complicated, simply taking precautions on the backend side for enabling those pages to be reloaded and rendering updated state, and avoiding reloading them triggering new unwanted duplicate actions in the backend. How rare it is, that I see frontends going to that length of putting in some minimal effort, to make their websites more accessible and privacy friendly. Where are all those great web developers?
As I see it, a good developer with good knowledge about the basics of web development, most importantly HTML and CSS, only secondarily JS, can build better sites than most of what we see on the web today. The current mainstream is clearly not working all that well.
Why one would go for SSR? Because it doesn't require ones users to run untrusted JS. Because it doesn't require every single client to rerender the same things over and over again. Because it is lighter on the client. Because often it needs less data transferred, because there is no frontend framework whose code needs to be sent. Because it does not require repairing browser functionality after breaking it. There are many reasons to choose SSR. Also I will note, that you can do SSR and separate the logic for rendering your pages from your other code, so that the SSR accesses only API routes. Then others can build alternative frontends for that API.
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.
Unfortunately I can't think of anything constructive to say about this nonsense.
> 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.
You assume people agree that it's preferable to work in JavaScript.
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.
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 mean I don't recognise that there are still perfectly legitimate reasons to choose it.
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.
Because everyone is OK with PHP. I'm not even using it directly but most of the web runs on it.
Typescript exists, but if I'm compiling something I'm using a real language or framework like dotnet. There's no reason for me to use typescript and node and install 100 packages when I can just install dotnet.
While strongly typed languages are great. I like to be able to get things done. This is why I don’t C++ anymore. This is also why I don’t dotnet anymore. Too much BS with the type system and correctness and the Microsoft way or lack of support or rug pull. They lost me when they killed XNA.
Typescript is actually good, except for the fact that it’s a transpiler to JavaScript. That part sucks.
I want a C++, with Types, with memory safety, with garbage collection, with pointers, with a dev experience like dotnet, but we don’t have those things.
> I want a C++, with Types, with memory safety, with garbage collection, with pointers, with a dev experience like dotnet, but we don’t have those things.
Dotnet, you want dotnet. Dotnet has all of those. Yes it has pointers.