Hacker News new | comments | ask | show | jobs | submit login
My PHP Development Setup (johnmackenzie.co.uk)
340 points by prostoalex 34 days ago | hide | past | web | favorite | 163 comments



Glad to see modern PHP getting more coverage on HN. For anyone interested in how the latest version performance compares to similar languages checkout vs Python [1] and the vs Ruby [2] pages from the benchmarks game team.

[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

[2] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...


The sequence of Hack/HHVM trouncing PHP performance, then the PHP team responding with a release that took the air out of Hack/HHVM for most people other than FB was interesting to watch.


Aside from doing well on synthetic benchmarks, what case would you make for starting a new project in PHP in 2019? What are its strengths?


I think that you can count Laravel as one if PHPs strengths. It is a modern, beautiful framework that took a lot of the best stuff from Ruby on Rails and ran with it. Seriously good stuff.

If I need to build an API, or want an app with backend/frontend separation, it is my go to.


Some weeks ago I had to choose a PHP framework and ended up with Laravel vs Symfony.

I started the project twice in both frameworks.

And while Laravel might be the most popular one I would say you should go with Symfony 4.

Laravel just has too much magic. When your IDE doesn't know what is going on, how will you?

But whatever the choice, skip 'annotations'! It's a bad trick that will mess up your project at one point (for example if your IDE cleans up unused usages).


Laravel does have a lot of magic, however you can be aware of what's going on. https://github.com/barryvdh/laravel-ide-helper

Framework continues to evolve, for the better of course. With the introduction of PHP 7, I believe Laravel will get rid of magic eventually. Meanwhile, we've got tools to help ourselves.


PHP recently received an extension that exposes an asynchronous programming framework, called swoole. It's extremely promising (but not perfect). Here's the link https://www.swoole.co.uk/ and it produces some very, very, very interesting results - both in synthetic benchmarks AND real world. Link: https://www.techempower.com/benchmarks/#section=data-r17

In certain use cases, it literally annihilates Golang for example and leaves node.js way, way, way behind.

Now, ignoring the numbers, there are many things you can do using PHP:

- web applications

- background services

- queue systems

Imagination is the limit (but that applies to any language these days)

There's plenty options to choose from, from web-related frameworks to community provided libraries, even the command line interface received a ton of cool libraries to play with. I can't state that you can do X in PHP but can't do the same in Y, Y being another language. However, frameworks such as Laravel make it trivial to bootstrap a project, create an API, create a nice UI using Vue (Laravel comes with excellent Vue tooling) and deploy the whole thing in a few easy steps to popular hosting providers.

Granted, it's not language specific, there was a huge community effort behind everything PHP related: from standards, to package manager, to tooling, utilities and so on so the ecosystem is quite healthy and progressing.

The nice thing about it, ultimately, is that it's really fast enough and keeps getting faster, with new (useful) language features.

If you're after a tldr version and don't care about the wall of text above:

Strenghts:

- excellent ecosystem http://www.packagist.org, http://www.getcomposer.org

- excellent *nix support, easy installation: https://launchpad.net/~ondrej/+archive/ubuntu/php

- great object oriented model that supports strong typing: http://php.net/oop

- excellent choice of web-app frameworks: https://laravel.com/, https://lumen.laravel.com/, https://symfony.com/

- big choice of extensions that expose additional functionality, such as swoole: https://www.swoole.co.uk/ or zeromq: https://github.com/mkoppanen/php-zmq

- great performance for an interpreted language

- easy scaling due to php-fpm http://php.net/manual/en/install.fpm.php (this has been available for a decade)


Async programming was there for a long time in the form of ReactPHP. With the caveat, of course, that comparatively few people know of it because of peculiarities of PHP's target audience. It's hard for something non-standard to gain traction in PHP.


Swoole looks exactly like some node.js code. The problem is that node has promises and async await while swoole/php has only callbacks right? No other mechanism..

That makes node a lot nicer to do async.


I love how they embrace toy apps for benchmarking. [1] I've found that I learn a lot about writing fast code by writing a toy app, measuring how long it takes to run N times, making a small change and benchmarking the change.

I was recently playing with generating v4 UUIDs in Elixir, and it was fun to try writing code that was nominally faster than the most popular UUID library out there. It was also interesting to see how the code gets less maintainable, more repetitive, are harder to read when I started trying to shave nanoseconds off the average run time. It's also fun to start realizing that the program can't get much faster because your approaching the physical limits of the hardware.

[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...


Interesting they decide to run with Ruby JIT. Which may not be the fastest way run Ruby Script (yet). And measurement includes Startup time, which means JIT and TruffleRuby aren't really real world measurements.

But Seriously PHP has come a long way. May be there should be something that compiles to PHP? Coz Php still looks very ugly.


PHP community did an exceptionally excellent job to improve standards in the past few years. A lot of features has been added to the language itself as well as huge performance improvement.

Many complain about PHP is from the past. Still a lot of developers just hacking around but it is not hard to find decent PHP developers anymore.


Agreed. Modern PHP development is very similar to Java development (although there are still quirks). I've programmed in PHP professionally for the last 8 years and can confirm that the language is improved by leaps and bounds. Composer by itself is a joy to use (especially compared to npm). We introduced PHPStan recently and it's basically a magic bug finder, it's fantastic.


While I do think Composer is an awesome improvement for the PHP ecosystem in general, I still find it insane that you cannot run `composer update` on a machine that has less than 1.5G memory allocated to PHP. It is an absolute resource hog, which is problematic for a lot of reasons.


I really enjoy using Composer as well but my exposure is limited. Does composer do anything for security that npm fails at? The most I've seen is that packages in composer tend to have way less dependencies than npm packages but that's not really a great reason to call it more secure (better, yes, but not ideal). Just wondering if Composer has some security features that I'm not aware of.


I'm not aware of any security advantages compared to npm. But one thing that comes to mind is that a while ago npm, by default, did not generate lock files, which is very much a risk concerning deployment and dependency-management in general. It's not an issue any longer, though, both yarn (yarn.lock) and npm (package-lock.json?) generate lock files by default.


Any sources for modern PHP? I kinda started programming in PHP (completely self taught from internet as a kid in grade school) and my first internship was in PHP. When I started learning other languages, and technologies I basically realized PHP is nothing but an eternal hell. This was 10 years ago. To be very honest, PHP was so bad back then I hardly believe it's passable now. But I'd like to explore it a little, to see that I'm wrong and they somehow saved PHP. Is there a source that can give me what modern PHP has to offer and how it diverged from its (famously) "fractal of bad design' nature?


PHP: The Right Way (https://phptherightway.com/) is a maintained resource which I frequently recommend.

Additionally, JetBrains has good resources. The PHPStorm IDE is worth your time, as well as the blog PHP Annotated Monthly: https://blog.jetbrains.com/phpstorm/category/php-annotated-m...


PHP: The Right Way has helped me immensely. It is the best of "The Right Way" sites because it's maintained by people who know what they're talking about, it gives you the most important resources and documentation you should read, refer to, and understand.


Laracasts.com is a great way to get started.

phptherightway.com is by far one of the best "one stop shop" for modern php development.


The Symfony docs are great. Also, see https://symfonycasts.com/.


To be honest, plenty of languages that allow bad behaviour could be classed as hell including C and C++ but done well, all of the main framework languages can also be nice.

PHP has its origins in scripting rather than what traditional developers might consider a "real" language but as a C# developer, I often turn to PHP for my web "sites" as it is plays much nicer with front-end frameworks and using a framework like Yii2 does most of my heavy lifting.


Agreed. We use it extensively and it lets us move very fast. Devs coming from Java and similar environments usually say something like "I thought I hated PHP but it's very nice now and I feel very productive in it".


I used to be a .net dev, then I switched to Ruby then to a polyglot role using python/php/javascript/.net. Today Laravel is my goto for new web development. For me, it is equal in strength to RoR, or ASP.NET CORE MVC. All languages have sufficient library strength, and similar feature sets. But PHP offers superior "dev-ops". Deploying updates is so painless in PHP, that I feel like I can really move a lot faster.


I recently started taking some of my old PHP code and updating it to PHP 7.x. There's a lot of weird hackery they've removed, and bugs I didn't know I had were revealed in that a lot more broken behavior leads to errors now, instead of silent failure that PHP was known for.


> […] not hard to find decent PHP developers anymore.

In Oslo, I found PHP developers hard to come by. Though, I think the situation is better in continental Europe.


> Most developers use Makefiles

I disagree. I'll argue that most of the new crop of developers are self-taught/bootcamp-trained/career-switching and they straight to the web. For RoR, Node.js, Python, Go, etc. it's not a common setup and those are the languages being learned today.

Now if we are talking about the public who has a "I remember when I started with PHP" nostalgic feeling while reading this article I might agree, but that is not "most developers" :)


Most of the new crop of self-taught/bootcamp-trained come straight to the web.

There's also the niche OS called Windows that is quite popular in some circles and they don't use Makefiles either as rule.


Plus the niche platforms known as .NET and Java :)


Don't forget PHP on Windows IIS (like I must live with at my job, because we have lots of enterprisey COTS, and the sysadmins don't want to have to administrate two OSs, and I don't want to sysadmin, because I don't want to get the 2 AM phone calls).


I agree with you. I am not sure "convenience Makefiles" like these really accomplish much, other than letting you put 6 shell scripts in one file. The cost, of course, is that you can't run anything on Windows. If you have a native Make-like, I would just use that instead (npm lets you define them in packages.json, for example.)

These convenience Makefiles ultimately don't get to the root of the problem of building a dependency graph for your project, and result in much overbuilding. For example, I have a Go backend + Vue/Typescript frontend. "make all" will re-webpack the frontend when you modify the backend because make was not taught the dependency graph. It doesn't understand the dependencies between input and output because it was not told that. Telling it that involves reverse-engineering your language's internal dependency management (go already knows what it has cached, for example), so nobody does it. If you _do_ decide to rewrite your language's dependency management to make make do incremental builds correctly, you will get it wrong and then _underbuild_, which is why "just run make clean!" is such a common remark. To me, underbuilding is worse than overbuilding, but both are bad. If you can't solve that problem (by using something like Bazel), I would not bother with make. (We all dream of the days when .c became .o and your binary was just all the *.o files linked with some libraries. But that is not how newer programming languages work at all.)

For the case where the author is just using docker-compose, I would say... you have two docker-compose files, one for local development, one for production. You build your development docker-compose approximately once, have it running, and tell your web framework thingie to rebuild when the code changes (mounted in the container with a volume). Meanwhile, your CI system builds a container without any of that dynamic recompilation stuff for production. Not great, but not horrible either. You will need some glue to run your unit tests inside the container. Probably a shell script that the Windows users on your team will port to Powershell for their own use. All in all, not ideal, but not super bad either. (I personally think I will move in the direction of ksync/telepresence and minikube, so the shell scripts to do things like run the tests or wipe the database are run inside the dev container, and nobody has to pretend their local machine matters for anything but "minikube start". But it is more work than docker-compose, for sure.)


> other than letting you put 6 shell scripts in one file

They make working in the repository as a newcomer abundantly better.


Installing Make on Windows is easy. Works like a charm.

  choco install make


You don't really need Makefiles until you don't have dependency management. If you just need 'shortcuts', you can just use python/shell/whatever scripts


This is what I do. Batch/Bash scripts depending on the environment. OR (downvote me) I just scp the app to the server, then systemctl restart it!


I have done this in test environments with springboot + systemd. Man it’s a great platform.


Uhm... I didn't know that makefiles are that easy. Last one I looked at one it looked like it could run a spaceshuttle. Lot's of crazy stuff. Thought it would be super complicated, but now.. well.. will try this out.


The makefile in that article is not really a makefile though. It is just a convenient way to bundle some shell commands.

The real intention of a makefile is to specify dependencies, and how to (re)build targets if they are out of date compared to their dependencies. That is traditionally used to build e.g. C or C++ projects, and can indeed quickly become very cumbersome. Almost nobody writes them by hand for larger projects. These days almost everybody uses either some makefile generator or a more modern alternative to make.


I find makefiles are an excellent universal interface for other build tools. If I am downloading some sourcecode off the internet I'd much prefer to be able to just type make or make build and be done with it rather than sifting through pages of instructions for how to set up and configure their build server of choice, etc.


I'll take make anytime over grunt / gulp / whatever flavor of the day JS build chain nightmare is popular today.


I was just having that discussion this morning.

Early in my re-entry to web I was using grunt to manage the build processes, but that fell away fast—

I'll either write a Makefile or a shell script to manage those builds and processes now—and I'm far more productive for it. No need for a number of plugins and yet more dependencies to manage.

Though, I have to say I've seen less and less of Grunt and Gulp (etc) in modern JavaScript (especially TypeScript)


I constantly say to my colleagues that modern C++ is far easier to use than modern JavaScript.

What you mention is the main reason for that claim.


I think build systems are prone to this in general — I don't think I've seen a non-trivial Gulp, Webpack, etc. setup which wasn't approaching similar levels of complexity. You get to use JavaScript instead of terse symbols but at the cost of having to wrangle thousands of dependencies which will regularly conflict, require replacement, or block upgrades for awhile.

The main less I take from this is that a) it still pays to keep it simple and b) as an industry we should continue focusing on reducing maintenance costs as much as we chase after the cool new project of the week.


I really enjoy articles like this. In fact if anyone know some high quality resources of modern PHP, please give me some pointers. I am somewhat proficient in programming, and a recent project requires me to work in PHP. I know people in the industry likes to make fun of php's design flaws and quirks, but a few weeks in, I feel it is alright. The community around it are making solid improvements. The only frustrator is that once too often when I search something the top results are all W3C school tutorials from 2004.


I work a lot with Laravel, it is a hell of a framework, documentation is amazing, it's clean, very well done, super extensible, there are a lot of extensions (just have a look at the Spatie library) and allows me to build up a website/webapp backend with a good API, basic authentication and other basic features in minutes.

Also, and this is a really strong point, can manage assets super easily, React and Vue stacks are supported out of the box with laravel-mix.

And if you need something lighter (for building just an API for instance) Lumen is the light version of it.

I have a lot of experience with PHP and Python frameworks, Laravel comes as absolute top for me.

https://laravel.com/

https://spatie.be/open-source

https://lumen.laravel.com/


As someone who recently took on the Laravel learning curve, be aware that Laravel moves atypically fast. That is, something in say version X.Y might be different in X.Y+1 or Y+2. That ends up manifesting itself as a lot of noise when you're asking The Google for help.

It can be frustrating. When you're on a deadline it can be unnerving and then some.


Ha ha. Joke's on me. I just inherited at 3.x site. Getting it upgraded to 5.5 looks like it will be a half-total rewrite.


If you can get it to 4.2, you may find this helpful: https://laravelshift.com/


That's true for additional features, but rarely does documented behavior change in a point release. That usually only happens when there is a security bug.


That’s not true. It happens quite often. Variables, classnames, php targets are changed on a whim.


More than twice The Google found me solutions that were out of date by Y+1 or Y+2.

I finally got into the habit of making sure what I found was current. But that doesn't prevent so much noise in the Laraval + The Google signal.


Yes. That's probably the main reason why I keep developing in php. The fact that Laravel and Lumen are so well thought out.


Thanks man. I have heard a lot of good words of laravel. Will definitely have some experiment with it.


Gold standard is https://phptherightway.com/

Also the symfony documentation and particularly the source code is an excellent example of modern high quality PHP.


Thanks, man. That are some good reads.


Also see the pragmatic counterpoint: http://www.phpthewrongway.com

They make for a good read together.


Most complainers haven't looked at PHP the last 20 years or so. A lot has happened since v4 but it's fun to make fun of people I guess.


Why take it personally? We complain about the language and to some extent the original creators of the language -- not its users. Complaining (at its best) makes things happen.

I worked with PHP in '98 (ported a perl thing into this cool new web language) and then much later in 2014-2017. I found much to complain on the second time :) PHP7 is a good update, nevertheless.


Has PHP removed features?

A language is just as much about what features it excludes as to what it includes.


Yep. In addition to the removal of register_globals sometime back, several deprecated extensions (like mysql_* and ereg_*) and magic quotes have also been removed.

Some other deprecations: http://php.net/manual/en/migration70.incompatible.php


Honest question: after all this PHP evolution is it any better than Java, today?

My impression was that PHP post-PHP 4 was basically cloning Java. On top of that, unlike Java, PHP started from the bad base provided by old PHP versions.

If your project is already in PHP or you are super proficient with PHP, ok, but otherwise I would just start directly with Java.


The PHP world clearly had some Java envy rolling into the 4 to 5 era. The problem with that was less that PHP was trailing Java (although that was true in some real respects) and more that people seemed to be assuming the problem with PHP was that it wasn't using enough high ceremony and design patterns that existed to solve problems for static/manifestly typed languages (and PHP, like other dynamic/scripty languages, had different solution idioms for). Writing Java in PHP really was/is suboptimal.

The popularity of Ruby/Rails and to some extent Python and node did a lot to shine a light on the productivity possibilities of embracing the dynamic/scripty side -- at its furthest edge, you can see this in how Java has changed and brought in some of the strengths from the dynamic/scripty world. But also I think it started a good part of the PHP world down the road of thinking about what the actual problems with working in PHP were and working on those.

I'm not going to enumerate PHP's strengths because I'm (a) weary of doing so and (b) have decided for the moment it's possible there's more value in keeping the various possible competitive advantages quiet. But suffice it to say that PHP has always had strengths (along with its real weaknesses) that a lot of the dev world seems astonishingly blind to, so it's a misunderstanding to think of past versions as nothing worth building on. Filing off some of the warts, adding helpful and convenient features, and bringing performance back towards first in class rather than buying into enterprise cargo culting has really given it a boost and even made it more fun.

It's definitely not the right tool for every problem/project, there are still things missing from the language that I sometimes wish I had when using it, but it's great for a certain class of web applications.


"Why isn't Java used for modern web application development?" https://softwareengineering.stackexchange.com/questions/1020...


That's ridiculous. Startups tech is more about fashion than anything. Half decent developers using modern Java tools can deliver things maybe 5% slower than any developer using a dynamic language and you get way better speed and stability using Java/the JVM.


> The only frustrator is that once too often when I search something the top results are all W3C school tutorials from 2004.

There is no such thing as "W3C School".

There is the W3C, which is a standards body that publishes various web technology specifications such as HTML, CSS, and DOM specifications.

Then there is W3 Schools, who are entirely unrelated to the W3C. They publish low quality tutorials and sell worthless certificates. They chose a name which confuses people into thinking that they are somehow "official"; this couldn't be further from the truth.


Check out the Symfony docs and https://symfonycasts.com/.


Mostly look at Symfony, the framework or the individual components. It's a bit too "enterprise Java" sometimes but otherwise it's very solid (and a very well run project).

Laravel seems more popular in the US but it stills uses many Symfony components.


Although Laravel promotes ways of coding that keeps the code readable and more fun that the traditional Symfony/Java way (Like really long class namespaces and names that have redundant strings in them etc).

Laravel uses Symfony components but the APIs are a lot more fluent and more natural to use.


I don't know why people get so bent about Makefiles. Its a way to preserve muscle memory using a universally (well most *nix systems, anyway) available software.

It allows you to have package your often used shell commands into one well known (even a 30 year manual will teach you how to read/use a makefile) file.


I'm doing it in a really weird way, and I'm probably alone in this setup:

1. Various IDEs on my Windows machine writing PHP & HTML/CSS.

2. Saving all files over Samba to a Debian Web Server running Apache.

3. Once the code is complete and signed off, it's migrated to a production server.

4. Have a global error hook via 'set_error_handler' in each PHP file that 'echos' out the problem into the Browser. This doesn't help me with syntax errors though.

I'm fairly new to PHP development (Previously .NET dev), so I'm probably doing many things wrong here, and I'm totally open to suggestions, however I DO have to stick with Windows as my dev machine.


Well, generally the modern day approach would be to:

1. Use source control. A good idea in general.

2. Have an automated deployment system that does the "saving files over Samba" for you.

3. Use a proper logging system and access the log files to see the errors.


Agree with 1. and 3.

For 2. I don't really agree he should necessarily change that. SAMBA is nice and fast and painless. It really depends on whether that target machine will ever be used by anyone else to write code on.


Already do #1 (kinda), do you have any suggestions for #2 and #3?


1. Do it propery :) Here's a good guide: https://nvie.com/posts/a-successful-git-branching-model/

2. Gitlab has solutions, Atlassian Bamboo, Buddy, FTPloy, Jenkins, etc.

3. Monolog https://github.com/Seldaek/monolog


Not doing php anymore, but I used to have a similar setup as yours, with the only difference that I had a FreeBSD server instead (that acted as my nfs, dev server and at the beginning as my router too, quite fond of that server, brought it from FreeBSD 4 to 8, with no reinstall, just hardware changes and software upgrades).

At the job I had back then, we used to run a virtual machine on your dev computer and the ide we were using (netbeans afaik) could function properly over ftp. Since there was no real network between netbeans and the virtual machine, things were fairly fast.

These days, albeit not doing php, but python, I use a docker image with my software installed and I'm mounting a local directory (where my sources are) to the container. Needs a bit of fine tuning, but works.


Makefile for essentially a bundle of shell aliases? Weird flex for PHP but ok.


I am guessing the Makefile helps with "portability" aspect. Where as aliases would need to be "installed" on end user's machine outside of cloning a repo.


That kind of anaemic Makefile in the article can be expressed as a single case statement in a plain POSIX shell script:

    #!/bin/sh
    set -e

    case "$1" in
        up)
            docker-compose up -d
            ;;

        build)
            docker-compose rm -vsf
            docker-compose down -v --remove-orphans
            docker-compose build
            docker-compose up -d
            ;;
        *)
            echo "unknown verb: $1"
            ;;
    esac
I honestly think there's a phenomenon where, since the bash man page is too bloated, looking up shell syntax has become a no-no. So if people don't already know the syntax for what they want to do, they treat shell scripting as a lost cause.


The idea of your shell script and Makefile are the same. For me it doesn't matter which one is used but source code should have some kind of easily usable list of common development tasks. Otherwise developers are doing this and that and the easier ways of doing repeatable stuff are not getting propagated to everybody.


Yes indeed. My comment was only tangential to that aspect.


Modern PHP is much better than the old one. One feature I miss from Kotlin are Infix-Functions: https://kotlinlang.org/docs/reference/functions.html#infix-n...

Even the newest PHP feels somewhat dated, Infix-Functions could reduce a lot of typing by making library and custom wrapper code – which almost always exists – resemble more.

  function foo(String $s) {...}
  // current function call syntax 
  foo('hiho');

  // just syntactic sugar - below code is the same as above
  function String.foo(String $s) {...}
  'hiho'->foo();


Why is this a useful syntactic sugar?

EDIT: I'm dumb. The syntactic sugar is just operator overloading. The better question is why would you ever give that to a PHP developer? I've been digging through some of it, and it's just annoying to untangle some of the code people write, as compared to other languages.


For example you can't just write [1, 2, 3]->map(...) in PHP.

Right now the best is to use something like Laravel's collect, e.g. collect([1, 2, 3])->map(...). Oftentimes all you want is to add one method to an object. Right now you would have to sub-class it or write an ugly wrapper function.

Infix-Functions are one way to "extend" functionality without messing with inheritance – with other words, you can easier express what you mean with less code in an consistent way. In Android dev, Kotlin and Infix-Functions are quite popular. Too often in PHP you have to write some_function($object). The other thing is that PHP has a lot of strange function names and Infix-Functions could help to give the language designers a second chance to come up with better names, even if the Infix-Functions just call the existing code.


I would be fan of adding some kind of in-place map as a method on an array to php, but other that that I don't see much benefit to it.


Mine is a a lot simpeler, install Xampp with desired php/mysql version and im ready to go.


I've struggled for years for a decent PHP IDE, I've used everything from nano, to vi to Eclipse, I even developed my own in PHP using wxwidgets (wxphp) which fell to the wayside when PHP7 came along and the support for wxwidgets was dropped. I used PHPStorm a couple of times but had various issues and finally I have settled on Atom[1] which in the almost 20years I've been developing in PHP must say is hands down the best IDE for PHP yet... and it's free.

[1] https://atom.io


I swear by PHPStorm, it has everything I need in one spot, and a built in terminal window for everything else. Saves so much cognitive load on context switching. Instead of flicking through four different windows and losing my train of thought constantly, it's just the browser on one screen and an all in one tool in the other.

PHPStorm's XDebug integration is second to none, it has full MySQL integration, and it's autocomplete and click-through intelligence is incredibly smart.

I have tried atom, but I miss too many of PHPStorm's features. There is so much it can do, and so much intelligent functionality, but it all stays out of the way until you call upon it.


I second this.

Without going into what I've tried and yadda yadda yadda, white noise, my credentials and so on - PHPStorm id the IDE. No Atom / VSCode or whatever can't compare. You get ctrl+click go to definition, you get ssh terminal, you get XDebug integration, it plays with Vue/ES6/React, you get MySQL integration, Vagrant integration, extensions to get VIM bindings and so on. Next to proper keyboard, monitor and mouse - buying PHPStorm is hands down one best money spent when it comes to what I work with every day.

I'm NOT saying "you can't get X with Y editor which is free" - sure, I believe you can, but this thing completely satisfies my every requirement and I don't have to spend time looking for integration extension or whatever. It saved me a ton of time so far, it will do so in future - I approve it, however I don't think anyone's editor "sucks and you should go with PHPStorm". Everyone should go for what they think brings them the best experience / value.


Third it.

I'm not even an IDE -- I'm a strict Vim user, but when I had to work in PHP I found the experience to be very nice. Especially integrating with the debugger.

JetBrains' stuff is top notch and I will buy their IDE for any language I work in, even if I don't use it very often.


Yeah, PHPStorm is a mediocre to terrible text editor but an amazing IDE. I used Sublime Text for many years prior and PHPStorm can't even come close in terms of ease of keyboard navigation, responsiveness, multi-file organization, etc BUT after 3 years of PHPStorm I won't use anything else.


> a built-in terminal window

I remember that time when I couldn't get it why there isn't built-in terminal in the SublimeText and then I found windows managers like `sway` or `awesome` and I started do not care about it.

> PHPStorm's XDebug integration is second to none, it has full MySQL integration, and it's autocomplete and click-through intelligence is incredibly smart.

Support for XDebug exists in all modern editors - Atom, Sublime, NetBeans, etc. etc. If you "waste" some time on customizing your editor auto-completion feature you might will get a really decent one (in aforementioned editors).

I must say PHPStorm had a superior look-for-file (think: Ctrl+P) feature which really gets annoying in other editors if you get used to it.

About the MySQL integration: I was really positively surprised having it in the IDE but I've stopped using it as soon as my colleague told me about the HeidiSQL [0]. For person who was using SQL Management Studio at university, HeidiSQL offered the same feel - fast, lean and simple to use but also it is free and installation in Linux (wine) or macOS does not take much time. It is probably the best application written in Pascal that I know about.

[0]: https://www.heidisql.com/


> Support for XDebug exists in all modern editors - Atom, Sublime, NetBeans, etc. etc.

It does, but PHPStorm's is particularly competent. From rewinding the stack, having an in-context command line prompt to run code in, conditional debug points, current context auto-complete for the command line, it can even read cachegrind outputs. It's the level of competence they implement in all their features that take it from a "text editor preference" to a professional level tool.

> I must say PHPStorm had a superior look-for-file (think: Ctrl+P) feature

You can also "look everywhere" which looks at literally everything from the same text-box, so if I type "show line numbers" it searches through the settings panes and finds the "show line numbers" setting, and because it's a toggle, I can just hit enter on the search result and it toggles the setting. Also class definitions (PHP, Javscript and CSS definitions) are all fuzzy searchable. "SoClNa" will find the SomeClassName definition and also the "Some/Class/Name" folder and so on.

I know I'm gushing about it but I really could talk for ages about all the little things it does.


Honestly, PHPStorm and the Symfony plugin. I practically feel like I'm cheating my clients with how easy it's now.


I used PHPStorem for a while, but lately VSCode has been giving it decent competition.


I also use VS Code. What would you say are the primary differences between VS Code and PHPStorm?


I haven't used PHP for quite a while but personally I was more satisfied with the SublimeText than Atom but the difference between those two was minimal and I even could say it was "matter of taste". I switched back to SublimeText, because I had been more satisfied with the auto-completion and snippets features in my setup and I couldn't find any plugins to Atom which will give me comparable feel. Today, I guess many add-ons for Sublime are outdated and/or not possible to work with, so Atom might a better choice.

Except PHPStorm I know many developers who got used to NetBeans IDE.


PHPStorm makes everything so easy.


While I fully agree that PHPStorm is a great IDE (most of the people in my team use it), I prefer Visual Studio Code for my work: first because it is free for commercial use, second because I also do a bit of C# from time to time and having a single environment is easier. Initial versions of VSCode were terrible, but now it is more than decent.


What are the problems of PhpStorm?

It won't make you dig around a dozen plugin to make it work in a decent way and even better than atom + plugins and what about $8/month?


As occasional PHP developer, Netbeans and Eclipse have been pretty ok for my little Websites.

What were your issues with them?


Is Php becoming popular again?


It's still extremely prolific, it's just not "cool". There are some very talented programmers working in PHP land.


It's always been popular and many of the big successful products are written in PHP. We see more and more startups doing PHP as well. I think a lot of devs have discovered that the new PHP versions let you have a very fast work flow.


No but if your job requires you use it it's nice that there are people out there trying to make the experience more tolerable.


Aren't the new versions of PHP quite good?


They are, quite good and the performance keeps improving with every new version. We're expecting another huge performance boost with version 7.4


Just curious: in what scenarios did you see performance problems with PHP? In all my projects performance was more than adequate, even with 5.6 that was a few times slower than 7.x. All my current projects are 7.2, at some point I will get on 7.4 but not because I need more performance, just for bug fixes and security updates in the supported period.


They are but if you're coming from Python/Ruby or even newer Java releases you will still go through a period of depression.


Can you go more in detail about what is depressing in PHP compared to Python/Ruby or even Java?

There are differences between the languages as such, e.g. PHP has traits, Python has Operator overloading, etc. From a tooling perspective I cannot tell that there is any big differences.


I'm used to Python. PHP has a ton of weird flaws that seem like outright mistakes rather than unfortunate trade-offs. It really grates.

spl_object_hash returns a unique id, rather than a hash. So why the name? Probably because it's formatted as a masked hex value. I had already started writing code to deal with hash collisions when I found out.

The `self` and `static` keywords for accessing the current class do roughly the same thing, except `self` is static and `static` is dynamic. That's not very nice.

You can't define consts on traits. If you google it, you find a reddit thread where multiple people offer creative theories of why consts on traits would violate OOP principles, and a bug report where you find out that it's because the implementation is too naive to deal with collisions.

Sequential and associative arrays are the same data type, even though in practice you always use them either one way or the other. That interacts really badly with JSON (is an empty array supposed to become [] or {}?) and makes code harder to understand.

Anonymous functions are called closures, but they aren't closures, unless you manually declare which variables from the surrounding scope you want to access and that you want the access to be referential.

Weak typing is still around in enough places to make me paranoid. `in_array('3', ['03'])` is true (and `in_array($x, [true, false])` is true for absolutely any $x). You have to pass an extra boolean argument for strict typing, which is not nearly as easy to spot as a == operator.

Relatedly, arrays can only have string or int keys, with mandatory weak typing. A string that's sufficiently int-like is converted automatically. So this code throws a type error when it reaches 3, even though it was a string when it was entered into the array:

  <?php
  declare(strict_types=1);
  
  function foo(string $s) {
  }
  
  $arr = ['x' => 1, ' ' => 2, '3' => 3];
  
  foreach ($arr as $key => $value) {
      foo($key);
  }
DateTime::ISO8601 does not implement ISO-8601, and is only kept around for backward compatibility with broken programs. You have to use DateTime::ATOM.

There's a lot more like this. PHP is much better than it used to be, and it's very much possible to write good PHP programs, but I find it painful to use.


All the things you say is true... but not really useful showstoppers. For the majority i think... sort of like how a tomato is a fruit - ja it is true but so what ?


They're not showstoppers, but there are a lot of them and it makes the language that much more annoying to use.

They don't prevent me from using PHP, but they make it unpleasant. A lot of mental effort that could be going into making sure my own code makes sense has to go into making sure that PHP's behavior makes sense and matches my mental model, more so than with many other languages. It increases friction.


Thats programming.... Everything is a tradeoff wheather its design or tech choices...


Little things like semicolons and no "else" in for loop


Well not exactly, but lots of company and businesses finally realise 95% of what they need could be done on PHP with ease. Not only it is cheaper as the talent pool is huge, it is also getting faster with lots of development still coming from community and Facebook.


Really nice article! Didn't know about the .editorconfig file. Thanks for the tips! Just wondering how are you deploying your php apps now ?


Hey, I didn't write the article but work with John... we deploy through a CI/CD pipeline using Concourse CI. Which builds the docker containers and eventually deploys them onto a Rancher cluster


Modern PHP is light years ahead of the procedural spaghetti-fest of yesteryear.

Craft CMS is fantastic, built atop Yii 2:

https://craftcms.com/

https://www.yiiframework.com/


Another commentator mentioned xampp.

For developers on Windows, I think Uniform Server[0] is really good. It's completely portable and gives the full stack as well.

[0]http://www.uniformserver.com/


While I used Uniform Server for many years, unfortunately it's long unmaintained and adding recent PHP versions isn't trivial.

My setup was so customized over years that I ended up just building simple custom stack from scratch (using Composer to manage dependencies) rather than struggle with choosing off-the-shelf replacement and tweaking it.


There's https://laragon.org/ not only for PHP, easy to manage. Using it for last 1,5 year now.


This looks very interesting. Have to try it.


Too bad that it is shipping only PHP5.x


That might be. But you can add PHP 7.0 if you so wish http://www.uniformserver.com/ZeroXI_documentation/plugins_de...


That's still pretty terrible. The version of "7.0.0" they have is actually a development preview from mid-2015, not a release version. The PHP 7.0 branch went end-of-life last month, along with 5.6; the current stable branch is 7.3.


Is this all in use in some private repos? I went poking around on the author's github for some examples (I've never used docker compose before, what on earth is that 'app' thing?) but I can't find anything like what is described.


I doubt there's any other programming language here that did such a tremendous job over the last decade on improving developer experience, language speed and syntax with consistency. ps. i was writing my first sites with php3.


Nice to see more PHP coverage. I personally think people should move along and stop this "why would I choose PHP for a new project" nonsense. It's time to get over it.


> jumpin is just me being lazy saving me typing docker exec -it <container-id> bash

The command uses run though? Is that a typo? (Really eager to try this setup.)


Good piece, and nice to see a local lad on here. waves from Park Square


Anyone else has problems with the usage of the word “modern”?

“Modern x written in y” etcetera. To me this often is a sign to not having to read it. As if you would make or do something new in oldfashioned style without mentioning it. Eg: “what my php setup was on amiga in 1985”.

Just call it “my take on a good php setup in 2019” or something. The setup is retro in januari 2020.

Anyways, I accept the down votes.

To me this is just another setup which slapped together a bunch of fancy pancy tools. Why is docker required? I use docker a lot, but to build containers and deploy apps with it. The way it is intended to be uses. Running (python) web projects works fine without docker for development. Most team mates use macos, which is linuxy/unixy enough until you do something specific.

Make is quite an old useful tool, but certainly not modern. As are linters.

.editorconfig is a thing now.


When languages have multiple versions in-use and significant updates, like PHP, "Modern PHP" is meaningful. It's a common phrase in the PHP community. PHP has a bad reputation, primarily due to the older versions of the language, and "Modern PHP" is the most common way to mark a clear break from that.


What word do we use when 'modern' is old though? How do we distinguish between 'modern' and 'modern modern' and 'old' and 'old old'?


Modern is a moving target, like it's always been.

Modern php in 2019 is php > 7.1 . Modern PHP in 2013 was 5.5

It's not specific, but it's implied you're referencing the most recent versions.


Ha. I asked my architect to design me something modern, and all I got was some 1950s bungalow!

I said, “Walter! What is this? I wanted something new and innovative.”

“Oh. You want postmodern then!”


What word do we use when 'modern' is old though?

Contemporary.


Modern 2.0


Next gen.


contemporary


Docker or some kind of container tool is great when you have a big team and need to maintain a stable copy of the environment for everyone. It's not without it's challenges though. We used Vagrant at a place I worked at, and for me at least it was a constant struggle to maintain then dozen different vagrant environments for the different projects. All kinds of version mis-matches and so on. No fun.

I wouldn't use it for solo-development or side projects. Not worth the brain-space.


Docker is not meant only for building and deploying containers. In fact, I would hazard a guess, it, and especially docker compose is much more commonly used in dev environments.

It is a huge help to get an identical environment to develop on. Especially when you have more complex apps with different services.


> It is a huge help to get an identical environment to develop on.

Until you stumble on some file permission problems if you use volumes; or some difference if the host is linux or macOS. Pure VM are the best: copy your virtual server, launch it, deploy your code. You can even have multiple containers launched inside your VM like on your production server.


Like any solution, there will be some kinks to work through. When you are deploying updates multiple times a day, it is nice to not have to upload a new VM everytime we push a change to the CI.


How do you copy dev server to prod?


Personally I feel like the use of Docker is overkill, at first glance. It's a neat way of dealing with multiple versions of PHP and quickly setting up a development environment if you lose your computer or hire another developer.

Overall though, it seems me that is an indication that something is very very wrong with PHP if it's easier to just spin up containers. Docker is just the work-around that allows developers to have sane PHP environments.


There is nothing wrong with PHP, any developer that is not too lazy can have any number of PHP version on the same host without any problems, a PHP "install" is basically unzipping in a separate folder and configuring the php.ini for specific needs. There may be something wrong with some IDE's where you cannot easily configure and switch between various PHP versions when you do any task that is version specific.


I'll preface my comment saying that my experience with docker is relatively light. But PHP is probably the one language/environment where using docker makes a lot of sense (vs others like node). There's a lot of versions of PHP and more importantly, anyone who's worked with PHP from the ground up knows, there's a lot of PHP modules you have to install to the system, as each project makes use of different libraries (especially ones coming from PECL etc.). Nowadays a lot of stuff are on composer instead, but there's still enough modules that don't come by a default yum/apt-get/pacman install of PHP, that are commonly used. I have side projects that I started years ago where I have to list out all the PHP extensions I use in the readme so I know what to install to get them working. Docker lets you get by all of that.

In contrast with other languages like nodejs, you can almost always just use nvm to switch to the desired node version for the project, do a npm install, and it will just run. For something like that, there's a lot less need of docker for dev.


I think you're right. If I find this article after two years then it won't be so modern anymore so the title won't fit. If the author needs to put a time indicator then -- as you said --the year could be a good fit.

Modern is used a lot in the js world with little other meaning than that it is not "what you write is what gets sent to the browser".


Yes, "modern" is in vogue right now. During the 90s I remember the word got so overused that designers turned to the word "contemporary" to mean exactly the same thing. We'll probably start seeing that word used for software soon.


In my art history classes in the late 90s, I remember 'modern' specifically being used to refer to a period between the 1900s ~ 1980s, while 'contemporary' just means the current period, whether that's 1999 or 2019. So not, those words are not the same.

Somewhere along the way, 'modern' has now come to refer to the current trends.


To me (not a designer), modern connotes modernism. But contemporary just means "current" or "present day". I could be totally wrong about this, but I always try to use contemporary unless I'm specifically referring to modernist art/design philosophy.

(SenHeng beat me to it)


Contemporary is a good word to use in discussions like these, because it's halfway to acknowledging that the choices of the moment may be as much fashion / aesthetics of a sort as they may reflect new heights of engineering quality.


[flagged]


Could we please ask you to put more effort into commenting civilly and substantively?

https://news.ycombinator.com/newsguidelines.html


That was not a very tasteful joke, sorry about that, thanks for flagging it. I didn't post anything similar since then. I just noticed my account is rate-limited (I wanted to post a submission), is it linked to this comment?


> Use a Makefile and make good use of it

Srsly?


Would you ever choose PHP over Node.js if you don't care about hosting on shared hosting?


Hiring/skillset of the existing team, existing legacy codebases that need to be worked on, simplicity... things aren't as black and white of you must use this technology over another, there are a lot of reasons involved


I upgraded my PHP dev setup a few years ago. The most effective thing I did was to stop developing in PHP.


Wrapping docker/docker-compose with makefiles or bash aliases is an anti-pattern, particularly on team projects.

It's a convenience to you, but it's a loss for newbies because they'll just learn that abstraction only. It's also a loss to experienced people because you're forcing your own opinions on them. I would git ignore that file.


There's really nothing wrong with it.

An anti-pattern because beginners won't understand the commands abstracted over? Come on. When I was a beginner I certainly didn't want to learn all the quirks of DOM manipulation in JavaScript, and jQuery held my attention long enough for me to build a career in this industry.

If it's your job to build a product, there's not much ROI on memorising the docker and docker-compose flags, which often don't match and are chosen quite arbitrarily.

I know what commands I intend to run when I use NixOps, but it doesn't matter. I'll still wrap them in easier-to-remember Make tasks. I'll even use tasks that just delegate to shell scripts. Here's an example from one project I'm working on:

  .PHONY: deploy-prod deploy-staging cachix

  build:
  	nix-shell -p nodePackages.npm nodejs --run "npm run build"
  	touch src/Settings/StaticFiles.hs
  	nixops modify -d moneygains services.nix aws.nix
  
  deploy-prod: build
  	nixops deploy -d moneygains --include moneygains
  
  deploy-staging: build
  	nixops deploy -d moneygains --include staging
  
  cachix:
  	./cachix.sh
> It's also a loss to experienced people because you're forcing your own opinions on them

Nobody is forced to use those abstractions…


You're replacing arbitrary docker commands with arbitrary make commands, you're just moving the goalpost really.

> Nobody is forced to use those abstractions…

Oh come on. You know that these scripts become canon, and anyone who deviates from them and has an error will just be told to use the build scripts. You're not forced in the same way nobody forced you to use docker, the app just won't work without it.


> anyone who deviates from them and has an error will just be told to use the build scripts

Good.

It's either:

- Throw all the commands into the README and force people to copy and paste

- Throw all the commands into a bash script and re-implement all the command parsing and prerequisite logic that Makefile syntax provides

- Be docker / docker-compose CLI tech support

- Write a Makefile


> It's a convenience to you, but it's a loss for newbies because they'll just learn that abstraction only. It's also a loss to experienced people because you're forcing your own opinions on them. I would git ignore that file.

ahh, but you force the newbies to learn MakeFile, and that's a net win imho ;)




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: