Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learn PHP the Right Way

github.com

Post reply on HN
Print view View original

61–70 of 73 posts

Re: Learn PHP the Right Way

#61

Post by archerx »

bearjaws wrote: post #51
archerx wrote: post #35

Earlier quoted context omitted.

1. I am already very good with JavaScript, I like having the language separation between frontend and backend. 2. I much prefer using PHP arrays than JS arrays. All the other stuff you mentioned have never been a issue for me in the past 10 years. I don’t care about types (I don’t even remember when I had a real type bug). 3. The modern web is an over engineered mess, all the modern js frameworks have made the user e…

1) Okay, but in terms of getting shit done how is it helpful to people to learn two languages? 2) They aren't even arrays? How can you say that lol. If you haven't tripped over what I have listed I just cannot imagine how you have been using PHP. I ran into a multibyte encoding issue with Mongodb and Laravel last week for example. Just a few weeks ago the lovely json_encode a map was sometimes an array vs an object.…

1) learning two languages is not hard or a problem. The fundamentals are the same.

2) I have no idea what you are doing but I have never had those issues. I don’t use Laravel or Mongodb though so maybe it’s that? json_encode should give you a string not an array or object?

3) stating a fact is not a strawman and calling it a strawman is not an argument. PHP is as good or as bad as you want it to be. It boils down to the skill of the developer. Bad developers will have a bad time, but that applies to most languages.

I’m not serving an entire JS “stack” either, I write fast, efficient tailored JS without dependencies or frameworks.

Sending html and having JS just for interactivity is surprisingly fast.

Re: Learn PHP the Right Way

#62

Post by forgetfreeman »

bearjaws wrote: post #53
forgetfreeman wrote: post #44

Earlier quoted context omitted.

If it wasn't that good for a backend it wouldn't have maintained complete domination of that market for decades, which it has. Incidentally the number of web development projects that have any objective use of async programming or fussy types is a rounding error. Perhaps your interests are pointing in another direction?

JavaScript is a terrible language and it still dominates front end :)

There are two types of developers that consistently bitch about languages: junior developers with delusions of grandeur and senior development that drank the coolaid and are yoked to a project using the wrong stack.

Re: Learn PHP the Right Way

#63

Post by throwitaway1123 »

mats852 wrote: post #60
replwoacause wrote: post #59

I like PHP, and guess what? I also like PowerShell for web apps. I don't really care what anybody says—I can build fast in PowerShell. My clients are happy, it's simple to debug, and I can tap into .NET classes when necessary. PowerShell + HTML + Alpine = productivity. I'm not building the next Netflix or Amazon and the end-user isn't going to notice or care that I haven't selected Node and React. I just can't get be…

I really learned to appreciate what Powershell is after listening to @adamgordonbell CoRecursive episode with Jeffrey Snover ( https://corecursive.com/building-powershell-with-jeffrey-sno... ). I really loved PHP, but now with go+templ ( https://templ.guide ) I personally don't have a use-case for PHP anymore, but that doesn't mean it's irrelevant for the world.

> I really loved PHP, but now with go+templ (https://templ.guide) I personally don't have a use-case for PHP anymore, but that doesn't mean it's irrelevant for the world.

This is the first time I've heard of Templ. It looks cool and it was really easy to set up. Apparently there are IDE extensions to enable syntax highlighting and HTML auto-completion, but is there a way to type check the templates? One of the things I love about JSX as a templating language is that errors in your markup get reported as type errors [1]. If I write `` instead of `` and run `tsc --noEmit --watch`, TypeScript will complain until I fix the issue. You can even extend the types to support your own HTML custom elements. JSX is a first class citizen in TS (and by extension any editor or IDE with support for TS).

[1] https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast...

Re: Learn PHP the Right Way

#64

Post by throwitaway1123 »

ecjhdnc2025 wrote: post #54
bearjaws wrote: post #51

Earlier quoted context omitted.

1) Okay, but in terms of getting shit done how is it helpful to people to learn two languages? 2) They aren't even arrays? How can you say that lol. If you haven't tripped over what I have listed I just cannot imagine how you have been using PHP. I ran into a multibyte encoding issue with Mongodb and Laravel last week for example. Just a few weeks ago the lovely json_encode a map was sometimes an array vs an object.…

> 1) Okay, but in terms of getting shit done (one of your points) how is it helpful to people to learn two languages? It's actually pretty clarifying. Two different perspectives on one single problem domain is almost always good for your brain. Like being bilingual. Also I would dispute that there are not, fundamentally, two different environments in the browser and Node backend even now. One of those environments is…

> One of those environments is a GUI which is naturally a good application for async. The other is not. Backend web development is still largely input -> process -> output. Node is just shoehorning JS in, and pretending that JavaScript's weaknesses are strengths.

Until you need to perform two or more IO operations at the same time (e.g. more than one of: database query, Redis query, HTTP request, file operation, etc). Then it becomes:

input -> Promise.all (or Promise.race, or Promise.allSettled, or Promise.any) -> output.

If you watch Ryan Dahl's original presentation introducing Node, you'll see that JS was explicitly chosen because of its asynchronous nature — it wasn't shoehorned in: https://youtu.be/EeYvFl7li9E?t=795&si=FG0yxaGoCgz1rqOX

> Not sure what you mean. There are a bunch of ways to run PHP

Node doesn't require an upstream CGI server at all. There's a server built-in to the Node binary: https://nodejs.org/docs/latest-v22.x/api/http.html#class-htt...

Re: Learn PHP the Right Way

#65

Post by throwaway03254 »

LoganDark wrote: post #32
throwaway03254 wrote: post #21

Earlier quoted context omitted.

12 years ago (2012), the latest PHP version was 5.4. The current version is 8.4. The language has made major changes to both syntax and functionality.

Eh. On its own that means nothing, the other commenters make better points.

I'm not going to bother explaining something that can be found easily on Google.

Re: Learn PHP the Right Way

#66

Post by citrin_ru »

cletus wrote: post #37

It's disappointing that PHP still gets hate in 2024. PHP of 2024 isn't the PHP of 2004. As someone with a bunch of experience in Java, C, C++, Python, PHP, Hack, Javascript and a handful of others, PHP is (IMHO) almost a perfect language for serving HTTP requests because of these characteristics: 1. Essentially an HTML document is a valid PHP program. This is an excellent starting point for beginners; 2. PHP has a st…

IMHO most of hate is just because it is fashionable to hate some languages including PHP and Perl. But there is some criticism which looks valid to me e. g. [1]

Regarding embedded into HTML PHP code - it's a easy for beginners but in a large application it leads to hard to maintain mix of app logic and presentation - AFAIK this feature is rarely used outside toy project for many years.

[1] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ (very old and some issues may be were addressed but it's hard to fix all of this without creating an incompatible language)

Re: Learn PHP the Right Way

#67

Post by ecjhdnc2025 »

throwitaway1123 wrote: post #64
ecjhdnc2025 wrote: post #54

Earlier quoted context omitted.

> 1) Okay, but in terms of getting shit done (one of your points) how is it helpful to people to learn two languages? It's actually pretty clarifying. Two different perspectives on one single problem domain is almost always good for your brain. Like being bilingual. Also I would dispute that there are not, fundamentally, two different environments in the browser and Node backend even now. One of those environments is…

> One of those environments is a GUI which is naturally a good application for async. The other is not. Backend web development is still largely input -> process -> output. Node is just shoehorning JS in, and pretending that JavaScript's weaknesses are strengths. Until you need to perform two or more IO operations at the same time (e.g. more than one of: database query, Redis query, HTTP request, file operation, etc)…

> Node doesn't require an upstream CGI server at all. There's a server built-in to the Node binary

Though you'll still want a process manager for this to make sure it stays up. Which it won't, over the long term.

PHP also has a built-in webserver, which you shouldn't use.

FrankenPHP is the better way to do this with PHP: you get a full Caddy build, with all that offers, with a built-in PHP engine.

Re: Learn PHP the Right Way

#68

Post by throwitaway1123 »

ecjhdnc2025 wrote: post #67
throwitaway1123 wrote: post #64

Earlier quoted context omitted.

> One of those environments is a GUI which is naturally a good application for async. The other is not. Backend web development is still largely input -> process -> output. Node is just shoehorning JS in, and pretending that JavaScript's weaknesses are strengths. Until you need to perform two or more IO operations at the same time (e.g. more than one of: database query, Redis query, HTTP request, file operation, etc)…

> Node doesn't require an upstream CGI server at all. There's a server built-in to the Node binary Though you'll still want a process manager for this to make sure it stays up. Which it won't, over the long term. PHP also has a built-in webserver, which you shouldn't use. FrankenPHP is the better way to do this with PHP: you get a full Caddy build, with all that offers, with a built-in PHP engine.

The FrankenPHP binary also needs a daemon to manage it, which is why the docs recommend using Docker. So you end up with Docker (or SystemD or whatever you prefer), managing Caddy, which is in turn managing PHP. This is because the server which ships with PHP is documented with a big red warning that says something to the effect of "don't actually use this in production, this is just a dev server" [1]. Node's built-in web server is production ready, so you can safely cut out the reverse proxy middleman. I don't actually have any major qualms about the FrankenPHP stack, I was just trying to intuit what the original commenter meant when they said "standalone server".

[1] https://www.php.net/manual/en/features.commandline.webserver...

Re: Learn PHP the Right Way

#69

Post by ecjhdnc2025 »

throwitaway1123 wrote: post #68
ecjhdnc2025 wrote: post #67

Earlier quoted context omitted.

> Node doesn't require an upstream CGI server at all. There's a server built-in to the Node binary Though you'll still want a process manager for this to make sure it stays up. Which it won't, over the long term. PHP also has a built-in webserver, which you shouldn't use. FrankenPHP is the better way to do this with PHP: you get a full Caddy build, with all that offers, with a built-in PHP engine.

The FrankenPHP binary also needs a daemon to manage it, which is why the docs recommend using Docker. So you end up with Docker (or SystemD or whatever you prefer), managing Caddy, which is in turn managing PHP. This is because the server which ships with PHP is documented with a big red warning that says something to the effect of "don't actually use this in production, this is just a dev server" [1]. Node's built-i…

FrankenPHP doesn't proxy to the PHP dev server. It is a PHP SAPI process manager itself.

You should be able to run FrankenPHP as the front end server just fine -- Caddy is excellent and it's my production front-end almost everywhere anyway (the Let's Encrypt support alone is worth it).

Though depending on the deployment I sometimes use Apache and mod_php still for the backend; this is still modestly less painful if you want to use WordPress in the same environment.

There is absolutely no way I would put node at the front of any server; I'd reverse proxy to it as a matter of principle, with very locked-down routing. The security situation with node package dependencies is hilariously bad, and some other server should be managing HTTPS.

Personally I consider the NPM ecosystem to be a horrific side-road in web development, and I think by contrast PHP is at least honest about what it is and what it is not. The amount of cargo-culting advice around package management in NPM is frightening.

Re: Learn PHP the Right Way

#70

Post by throwitaway1123 »

ecjhdnc2025 wrote: post #69
throwitaway1123 wrote: post #68

Earlier quoted context omitted.

The FrankenPHP binary also needs a daemon to manage it, which is why the docs recommend using Docker. So you end up with Docker (or SystemD or whatever you prefer), managing Caddy, which is in turn managing PHP. This is because the server which ships with PHP is documented with a big red warning that says something to the effect of "don't actually use this in production, this is just a dev server" [1]. Node's built-i…

FrankenPHP doesn't proxy to the PHP dev server. It is a PHP SAPI process manager itself. You should be able to run FrankenPHP as the front end server just fine -- Caddy is excellent and it's my production front-end almost everywhere anyway (the Let's Encrypt support alone is worth it). Though depending on the deployment I sometimes use Apache and mod_php still for the backend; this is still modestly less painful if y…

> FrankenPHP doesn't proxy to the PHP dev server.

I didn't say FrankenPHP proxies to the PHP dev server. I'm saying FrankenPHP is a Frankenstein amalgamation of the Caddy reverse proxy server and PHP, which is necessitated by the lack of a production server built in to PHP. Some languages/runtimes like Go (which Caddy is written in) and Node have production ready servers built in to their standard libraries.

> I'd reverse proxy to it as a matter of principle [...] some other server should be managing HTTPS.

I've used Caddy and it's great, but if I have Cloudflare or some other service terminating SSL and serving static assets, then I don't necessarily need Apache, Nginx, or Caddy acting as a middleman.

> The security situation with node package dependencies is hilariously bad

Most of the security issues involving NPM are related to client side JS, not server side JS. PHP doesn't run client side at all, so it's a bit of an apples to oranges comparison. If you're just doing traditional server side templating then there are plenty of rock solid frameworks. Hapi has zero third party dependencies and was designed by one of the authors of the OAuth spec for example.

Post reply on HN