5 ms·

PHP. Use PHP, it’s so crazy easy for web development. - No compiling, - no middleware, - no state (which also means no memory leaks), - just drop a file on

PHP. Use PHP, it’s so crazy easy for web development. - No compiling, - no middleware, - no state (which also means no memory leaks), - just drop a file on web server and it works (no crazy CI pipeline), - the documentation is fantastic, - it’s extremely fast, and - no surprises because it’s tried and true. PHP is so under appreciated.

icedchai 4y ago
For my freelance work, I did a ton of "old school" PHP (no frameworks.) A few years back, I tried Laravel and it was incredibly productive.
yrgulation 4y ago
The issue with php is the type of developers that use it and bloated frameworks. Nearly all developers still debate wether to use setters and getters and have no clue how to use the language itself, as a result using over engineered frameworks. The language itself is nice but is swamped by amateurs.
- tobinfekkes 4y ago
  The "PHP is full of amateurs" trope is so tired. You know why there are amateurs? Because it's simple, understandable, maintainable, low barrier of entry. You know what amateurs do with simple things and time? Become professionals. Then they solve other people's problems, rather than solve never-ending developer problems we create ourselves. Having done PHP development for +12 years, I have never once had a debate about getters and setters. Nor did I know that was something to even debate about.
  - yrgulation 4y ago
    You are right about the reasons there are so many amateurs in the php world. But i disagree with the statement that they become professionals over time. If you keep doing the same wrong thing over and over you just become better at doing the same wrong thing over and over, many being just old junior developers. Add the fresh supply of amateurs entering the php job market each year and you are stuck. There are elites among php, you may be one of them, but having interviewed hundreds believe me the quality is very very low.
    - trog 4y ago
      You are living in a fantasy world if you think this is limited to one language
jchook 4y ago
Also good about PHP: - mostly backwards compatible with easy upgrades, even between major versions - many new features all the time for better static analysis, type safety, speed, succinct code, etc - designed for use with Web - PHP itself is a (good) templating langue, so no need to reinvent the wheel there - FFI interface for integrating native code - easy to learn Some downsides though: - Single threaded with typically blocking I/O and no built-in async paradigm means it’s like 1/1000 as fast as something like node for I/O heavy applications, even when using something like ReactPHP - Need something like FPM to fire up one whole process per visitor - Many core language features like OOP, type hints, lambdas, etc are a bolted-on afterthought and still only 60-90% there - Still no typed resource handles until PHP 9+ - Syntax is cumbersome in many ways, though improving
bottlepalm 4y ago
I tried out PHP recently for a project because I have fond memories of it, but didn't end up going with it. I want server side rendering for the SEO benefits, but I also want some good 'app like' interactivity on the page. Doing the app like stuff with PHP is possible, but you kind of have to have mirror routines, one to load the data, and other api calls to update the data using whatever binding library you choose. The good client side rendered js frameworks, react/svelte/vue have SSR solutions, but they also have their own servers for enabling SSR - next.js and sveltekit. So if you need SSR, SEO, good client side interactivity - you might as well as used those pre-packaged servers. You also have the added benefit of working in a single language across the stack. Laravel's front end recommendations aren't great - https://laravel.com/docs/9.x/frontend https://laravel.com/docs/9.x/frontend I do like how react packages html/css/js as components and that you get static typing across the typescript to html bindings which makes the code more maintainable. Also react has a pretty good front end component library with MUI. You kind of have to 'kitchen sink' the front end libraries with PHP as there's no compiler to weed out the ones you're not using - plus you need to use a CSS library, and 'bring your own javascript' to utilize them with where MUI includes everything wrapped as components already. Interested in others thoughts on this.
- 0xblinq 4y ago
  You can add any interactivity you want to PHP (or any other server rendered html) using Alpine.js, Unpoly, HTMX, or any other kind of modern approach to frontend JavaScript. It is not anymore a dichotomy between ugly jQuery spaghetti or full SPA Next.js thing.
  - bottlepalm 4y ago
    I did consider Alpine, the pro is that it is very light. The con is that the components don’t seem as complete as MUI and not free either. Also the repo activity of next/react/MUI is much higher than PHP/alpine. One thing you want to do is try to choose a stack with the best chance of not leaving you stranded in few years. Also a good set of components so I’m not stitching together random packages that may or may not be under active development. I like next because I don’t want to build a SPA, I want multiple pages that are rendered server side - for the SEO benefits.
super256 4y ago
> - no state (which also means no memory leaks), Ehh, what? Sessions are state. > - just drop a file on web server and it works (no crazy CI pipeline) Except when I have to set-up php-fpm, opcache and configure countless parameters in php.ini. > - the documentation is fantastic, Yes, but I still have to check it for useless constructs like "mysql_real_escape_string" vs "mysql_escape_string" which should have never existed in the first place. PHP didn't earn its reputation without a reason. But I'm glad to hear that certain things are improving.
- phendrenad2 4y ago
  > Sessions are state Is database state? > php-fpm, opcache Nope > countless parameters Certainly not > "mysql_real_escape_string" vs "mysql_escape_string" There are only a handful of these, and you can learn about them with a simple google search.
  - super256 4y ago
    > Is database state? Duh. I'm talking specifically about session_*. This data isn't magically stored in the air and if you use more than a single machine, you need to implement the SessionHandlerInterface with a solution like redis or memcached in a clustered setup. That's literally the same as using any other language, plus such map-reduce kv stores. Since you mention that I wouldn't need php-fpm and opcache, I assume that you haven't worked at scale with php. php might be a good fit as long as you don't have any users, but this isn't true for everyone.
    - phendrenad2 4y ago
      > This data isn't magically stored in the air and if you use more than a single machine I'm curious, what do you think the OP meant when they said "stateless"? > I assume that you haven't worked at scale with php Oh I have actually! But I'm curious, how many sites do you think have a high enough scale to need php-fpm and opcache?
      - 4y ago
phendrenad2 4y ago
Shhhh stop talking about PHP, the ruby devs will start contributing code and ruin it! (I'm already angry that they moved the YAML parser out of the PHP standard library...)

icedchai 4y ago

For my freelance work, I did a ton of "old school" PHP (no frameworks.) A few years back, I tried Laravel and it was incredibly productive.

yrgulation 4y ago

The issue with php is the type of developers that use it and bloated frameworks. Nearly all developers still debate wether to use setters and getters and have no clue how to use the language itself, as a result using over engineered frameworks. The language itself is nice but is swamped by amateurs.

tobinfekkes 4y ago
The "PHP is full of amateurs" trope is so tired. You know why there are amateurs? Because it's simple, understandable, maintainable, low barrier of entry. You know what amateurs do with simple things and time? Become professionals. Then they solve other people's problems, rather than solve never-ending developer problems we create ourselves. Having done PHP development for +12 years, I have never once had a debate about getters and setters. Nor did I know that was something to even debate about.
- yrgulation 4y ago
  You are right about the reasons there are so many amateurs in the php world. But i disagree with the statement that they become professionals over time. If you keep doing the same wrong thing over and over you just become better at doing the same wrong thing over and over, many being just old junior developers. Add the fresh supply of amateurs entering the php job market each year and you are stuck. There are elites among php, you may be one of them, but having interviewed hundreds believe me the quality is very very low.
  - trog 4y ago
    You are living in a fantasy world if you think this is limited to one language

jchook 4y ago

Also good about PHP: - mostly backwards compatible with easy upgrades, even between major versions - many new features all the time for better static analysis, type safety, speed, succinct code, etc - designed for use with Web - PHP itself is a (good) templating langue, so no need to reinvent the wheel there - FFI interface for integrating native code - easy to learn Some downsides though: - Single threaded with typically blocking I/O and no built-in async paradigm means it’s like 1/1000 as fast as something like node for I/O heavy applications, even when using something like ReactPHP - Need something like FPM to fire up one whole process per visitor - Many core language features like OOP, type hints, lambdas, etc are a bolted-on afterthought and still only 60-90% there - Still no typed resource handles until PHP 9+ - Syntax is cumbersome in many ways, though improving

bottlepalm 4y ago

I tried out PHP recently for a project because I have fond memories of it, but didn't end up going with it. I want server side rendering for the SEO benefits, but I also want some good 'app like' interactivity on the page. Doing the app like stuff with PHP is possible, but you kind of have to have mirror routines, one to load the data, and other api calls to update the data using whatever binding library you choose. The good client side rendered js frameworks, react/svelte/vue have SSR solutions, but they also have their own servers for enabling SSR - next.js and sveltekit. So if you need SSR, SEO, good client side interactivity - you might as well as used those pre-packaged servers. You also have the added benefit of working in a single language across the stack. Laravel's front end recommendations aren't great - https://laravel.com/docs/9.x/frontend https://laravel.com/docs/9.x/frontend I do like how react packages html/css/js as components and that you get static typing across the typescript to html bindings which makes the code more maintainable. Also react has a pretty good front end component library with MUI. You kind of have to 'kitchen sink' the front end libraries with PHP as there's no compiler to weed out the ones you're not using - plus you need to use a CSS library, and 'bring your own javascript' to utilize them with where MUI includes everything wrapped as components already. Interested in others thoughts on this.

0xblinq 4y ago
You can add any interactivity you want to PHP (or any other server rendered html) using Alpine.js, Unpoly, HTMX, or any other kind of modern approach to frontend JavaScript. It is not anymore a dichotomy between ugly jQuery spaghetti or full SPA Next.js thing.
- bottlepalm 4y ago
  I did consider Alpine, the pro is that it is very light. The con is that the components don’t seem as complete as MUI and not free either. Also the repo activity of next/react/MUI is much higher than PHP/alpine. One thing you want to do is try to choose a stack with the best chance of not leaving you stranded in few years. Also a good set of components so I’m not stitching together random packages that may or may not be under active development. I like next because I don’t want to build a SPA, I want multiple pages that are rendered server side - for the SEO benefits.

super256 4y ago

> - no state (which also means no memory leaks), Ehh, what? Sessions are state. > - just drop a file on web server and it works (no crazy CI pipeline) Except when I have to set-up php-fpm, opcache and configure countless parameters in php.ini. > - the documentation is fantastic, Yes, but I still have to check it for useless constructs like "mysql_real_escape_string" vs "mysql_escape_string" which should have never existed in the first place. PHP didn't earn its reputation without a reason. But I'm glad to hear that certain things are improving.

phendrenad2 4y ago
> Sessions are state Is database state? > php-fpm, opcache Nope > countless parameters Certainly not > "mysql_real_escape_string" vs "mysql_escape_string" There are only a handful of these, and you can learn about them with a simple google search.
- super256 4y ago
  > Is database state? Duh. I'm talking specifically about session_*. This data isn't magically stored in the air and if you use more than a single machine, you need to implement the SessionHandlerInterface with a solution like redis or memcached in a clustered setup. That's literally the same as using any other language, plus such map-reduce kv stores. Since you mention that I wouldn't need php-fpm and opcache, I assume that you haven't worked at scale with php. php might be a good fit as long as you don't have any users, but this isn't true for everyone.
  - phendrenad2 4y ago
    > This data isn't magically stored in the air and if you use more than a single machine I'm curious, what do you think the OP meant when they said "stateless"? > I assume that you haven't worked at scale with php Oh I have actually! But I'm curious, how many sites do you think have a high enough scale to need php-fpm and opcache?
    - 4y ago

phendrenad2 4y ago

Shhhh stop talking about PHP, the ruby devs will start contributing code and ruin it! (I'm already angry that they moved the YAML parser out of the PHP standard library...)