Hacker News new | past | comments | ask | show | jobs | submit login
PHP in 2020 (stitcher.io)
286 points by kyriakos on Jan 21, 2020 | hide | past | favorite | 268 comments



PHP is a fantastic language, and my personal favourite. It was the first language written with web serving in mind. It is packed with features due to all the adding to it over the years, meaning you can write code how you want, no how they want.

What it also acts as is a good barometer of dev mentality. When a dev declares PHP is a [expletive] language, he's telling me how he's going to be to work with, how he's going to engineer his work, and how concerned with adding value to the business he's going to be versus playing with "hot new tech". Even if it's for a .NET role.

The plurality of the internet is PHP back, html/css/js front. Those who thumb their nose at that are profoundly arrogant, and probably currently experimenting with their 8th new framework for the year.

Junior devs do as they're told and don't form opinions.

Mid devs know enough to be dangerous, run their mouth on everything, and bad mouth anything that isn't precisely their opinion or something they personally like.

Senior devs see the big picture, have realised the folly of their earlier ways, have a healthy respect for practical reality, and are more concerned with codebase integrity than in if it contains "hot new tech" (fuckarounds).

This is why it's critical to have truly senior devs at the top of the hierarchy, as otherwise there's no one to suppress the mid level devs, who will in turn mislead the juniors.


Which other languages besides php do you know well? I'm asking this because of your outlandish claim that php is fantastic.

Also the rest of your comment seems highly defensive. You seem to imply that people who agree with you must be senior, while people who disagree must be junior or even worse, something in between. It sounds like you have been bitten by discussion where facts against your conviction were presented, and you were unable to factor that into your views. Am I at all close or completely off the target?


After years of working with PHP, my take away was similar to C++: There's a great language in there, somewhere. Limit yourself to a subset of the language which is sane, follow all of the PSR standards, and the result is quite nice.

After all of that, you look at your coworkers' code and realize they either (1) picked a different subset than you did, or (2) PHP is their first language and they have no idea what they're doing.

I mostly stay away from web development now, but if I were to do a new web project, I might still choose PHP if I knew I'd be working with a small, experienced team. It's a highly productive language.


This is why I think dev needs way stronger hierarchy. The typical flat hierarchies are trash for maintaining long term quality code and thus productivity.

All juniors should have to PR everything through seniors. All mids should have to PR at least a portion to seniors. All seniors should be vetted by the best dev the business can afford. That's the age old master-journeyman-apprentice structure, tried and tested.

At my firm, attempting to weasel out of that mentorship responsibility, such as seniors just clicking through trash PRs, or much much worse: trying to falsely automate it with git hook stuff, gets a "are you asking me to put you on a performance improvement plan?".


I get the impression he/she is saying that someone who uses explitives to describe a programming language is someone who has a higher likelihood of not having objective reasons for disliking it.

Even if I prefer tool A over tool B I can still find merit in tool B. By using explitives I demonstrate I may be unwilling to use tool B if it's requested of me.

As for the junior employee comment- I think the point was that someone with less experience is either repeating what they've heard or they don't yet have an opinion due to lack of experince.


BASIC, then C and C++ with some ASM (embedded systems), then Java (android apps), then Python, then node & PHP & js/html/css, as proficiencies. Smattering of other things as "have useds", inc. clojure, R.

Interestly, it's the contrary to what you've inferred. Last time I talked about this topic in person, one of the typical mid level language snobs loudly and obnoxiously declared "PHP is a shit language, a really shit language", with the typical arrogant dismissive tone.

But as all experienced devs know, you program _into_ the language, not with the language. The more opinionated the language, e.g. Java and it's traditionally zealous adhesion to OOP and obstruction of other paradigms like functional, the harder it is to do that.

Hence the reason I like PHP is because it's the opposite of the weak minded (who make up their mind of "the one true way", based on little, and stick to it come hell or high water), and instead it leaves it up to you, to program _into_ as is fit for the project.

Plus the fact that it's interpreted, which acts as a good barrier to the premature optimizers. And the fact it's been around so long that it dominates the internet so there's no shortage of work in it.


Your comment on the other hand comes off as very hostile - essentially, if you like PHP it's because you don't know better - it's because you only know that language.


Yes, that is exactly what I am claiming. I base the claim on my knowledge of programming languages, and also on my previous experiences with php teams.

To combat this claim, please provide us with data or anecdotes instead of false accusations of hostility.

When it comes to programming languages, I am hostile towards falsehood only, not towards any individual or group of people.


I don't doubt that PHP is becoming (has become?) a decent language. Especially with frameworks such as laravel which are mature and clean.

But PHP has a legacy, lots of bad PHP code exists already, bad practices are usually the first result on google and very "lazy" developers who never learned anything else exist and this muddies the waters very much when talking to people who prefer to build new things in PHP.

There's also the nitpicky fact that the old way of running PHP was that every page request runs the code from scratch, meaning you have to build state each time which is profoundly expensive and inefficient, although I believe people rarely do this anymore it's still definitely the default for most PHP projects I've seen. (both FOSS and proprietary).

I don't like your overgeneralisation about junior/mid/senior developers, the lines are super blurred in the real world. (I say this as a non-developer who works with developers)


> There's also the nitpicky fact that the old way of running PHP was that every page request runs the code from scratch, meaning you have to build state each time which is profoundly expensive and inefficient,

This also means that you always have a clean state and makes horizontal scaling super easy. Also simplifies the code significantly, async code is much harder to debug and to reason about. Unless you really need top performance, and for most of use-cases you don't, running code through fast-cgi (especially with php-fpm) does the job just fine.


Statelessness allows you to press the back key and expect to go back to the previous page without any surprise. Shift-click, ctrl-click on any link and open the page in different tab. Work on the main tab for some time and then jump back to the old tab and still find everything works as expected.

Plus you can have 10 servers for load sharing and users can hit any server at random and still expect the site to work perfectly.


"There's also the nitpicky fact that the old way of running PHP was that every page request runs the code from scratch, meaning you have to build state each time which is profoundly expensive and inefficient"

It doesn't mitigate this perfectly, but using something like apcu or redis to store startup state is pretty common and often makes this a non-issue.


Literally the same thing can be said about any language that is not niche tho.

Also, wee nitpick of mine; you don't have to build any state on your own, the interpreter does that for you as one of the core principles of the system.


Pardon me, but how would you know as a non-dev?


Fair question, I suppose.

I'm in SRE, so I work closely with developers and programmers who build business logic, in fact I am surrounded by pretty much exclusively that except for a small supplement of testers and technical managers.

So, I have some exposure.

That and the very plain fact that the mindsets that you would use to delineate between "senior" and "mid" bands are just traits that could be apparent in varying degrees between people of any level.

I've had mid-level developers identifying business needs on a macro level with a well broken down bite-sized methods of achieving what they set out to.

I've had senior developers "informing" me about operating system semantics which were just not true.

You can be senior in some areas and mid-level/junior in others. This is true across the whole spectrum.


Precisely, people should refrain from informing on topics outside their area of expertise. Pretty rife in western companies, "too many cooks" etc, must be the democratic mindset that every voice counts equally.


If this is a comment about me suggesting that your overgeneralisation is unwarranted because it is outside of my direct field then let me just say it this way: It is always true that trying to define behaviours of seniority is an overgeneralisation. It does not depend on the field unless there are formal qualifications, and even then it's tricky.


That would probably rule out about 90% of the discussion on HN.


I teach web development at a university. We have used, java, javascript, python and php for a basics course in webdev.

Php has built in web features and one doesnt need more than a php interpreter (considering the built in web server as well) to get started. For all other languages i know of, there is quite a process to get started (e.g. start with python flask one needs a package manager, environment variables, command line experience, ...). Php is a web native language and great for learning and getting started.

Considering professional development (https://en.m.wikipedia.org/wiki/Programming_languages_used_i...) it seems that it doesn't matter what language one chooses, various different stacks are used by the most popular websites..


> needs a package manager, environment variables, command line experience

Is this not the same with PHP? If you want to use packages then you'll need to use a Package manager, you still need command line experience etc.

Node.js comes with a package manager NPM, and has no need for anything like virtualenv's to keep packages separate per project.

Python doesn't need virtual env's at all, it's just good practice.

And to be fair, as a naive non-PHP user, I have 0 clue how you would go about setting up long running scripts that don't necessarily correlate to a web request.


The thing about PHP is that the language has built-ins for almost everything you need for classic web development.

Want to use a relational database? You don't need to install a library (often one that requires a C extension in a language like Python or Ruby). It's just part of the language. Just do `$mysqli = new mysqli("localhost", "my_user", "my_password", "world"); $result = $mysqli->query("SELECT * FROM x");`.

Want to get things out of the HTTP request? PHP has already parsed everything into the `$_REQUEST` associative-array (map/dictionary). You don't need something like Flask or Node to deal with decoding the request.

Cookies, response writing, uploaded files, GET/POST vars, sessions, and many more things for web development are built-in. Heck, PHP even simplifies templating because PHP is literally its own templating language.

If someone gave you Python without any packages, would you be able to handle a request, see a GET variable, and put it into a page? I haven't used PHP in a decade and I can immediately think how to do that. OK, create index.php with whatever HTML I want in there and then put `<?= $_GET['theVarName'] ?>`. Done. That's it. If I want to get something from a db based on that get var, it literally has the functions/objects to connect to and retrieve stuff from the db. With Python, are you going to write your own database driver? With Python, are you going to open a socket and start manually handling all the HTTP stuff?

I'm not arguing that PHP is a better language than Python. I'm just saying that it was literally built to handle web requests and create the kind of web app that a lot of people make. The point is that with PHP, you usually don't need to do anything. You can just create a file with the `.php` extension and put in bits of dynamic code and the language has everything you need to create an app of the kind users expect without having to add libraries.

Does this matter? I don't think it does most of the time. I think OP's point was that PHP gets new people from nothing to "WOW, it's showing up on the screen!" with almost no effort. "OMG, I can save the form to the database and then display the information!" Tools have gotten a lot better for a lot of languages over the past decade. Still, nothing beats the ease of not having to deal with anything. PHP offers that.

PHP also offers a dead-simple deployment. You put your files on a server with PHP installed and you're done. Lots of shared hosting supports this precisely because the PHP language includes most of what people want to use. Because the language includes these things, that code is shared between all the users on the server rather than re-parsed and re-stored in memory and re-executed for every user. I mean, if a bunch of people are using Python, they're all going to bring DB libraries with them and many will be slightly different versions, etc. Likewise, some will use Django, some Flask, some other libraries - and again, all different versions. That makes hosting a bit more expensive (though that has gotten cheaper with serverless).

Most of the time if you want a library, you can download a directory of files and then use `require` or `include` to bring it in using relative paths. No worrying about environments or installing things. Just copy a folder!

That's the thing about PHP: it's basically a language and web framework in one with a simple development model.

I don't think PHP is a great language. However, I think it's important to understand why it was so successful. Back in the day before Xen and VPSs, it was hard (expensive) to get a server with root or get someone to install a package on a server for you. Virtualenv wasn't around forever (I remember easy_install before pip). You'd come across things that you just couldn't use. You'd end up fighting with a lot of things. You'd have to start long-running processes or use fcgi or all sorts of things that were annoying. Today, it's a much better landscape - partly because tooling has gotten better and partly because compute and RAM costs have gone down. But back in the day, you could just stick an `index.php` file in a directory set up for you and go to town. Instant gratification with zero setup. Even today, we use tools like NPM, Yarn, Virtualenv, pip, RVM, Gems, etc. to manage things. And I think that libraries are a lot better than having all those things built into the language. However, if you're looking for someone to be instantly productive on a live server, PHP does that. You never have to reload things or stop processes or set up a reverse-proxy. You never have to install anything (presuming the server has PHP set up).

Again, I think that libraries are better. They let you upgrade code without a language update. I think package managers are better than just downloading directories and copying them into a folder. I think that a long-running processes has a lot of benefits over re-evaluating the code every time (and PHP has modes that support this, I believe). But the interesting thing about PHP is that you don't need to do any of those things which do incur cognitive overhead. I mean, I don't want to be a PHP programmer, but if you're looking to take a student with one CS course under their belt and give them some instant joy, PHP really hits the mark.

Even the way you can program simple things is so easy. Ok, we all get directory trees and so if I go to `/apple/pear.php` the web server will execute that file. I don't think that routing in Flask is that hard, but there's more indirection. We can just go to pear.php and make it whatever we want. Again, this isn't about clean design and many advanced PHP projects use their own routing. This is about someone who doesn't know much being able to access GET/POST variables, call functions with SQL statements in them, and generate some HTML. No MVC, no DRY, no whatever. Just code that executes top to bottom in that file. Maybe you've used `require` or `include`, but again, that's just like copy/pasting that file at that point in the code - and it can be done anywhere and do anything including output HTML.

To be fair to PHP, I don't think good PHP is written that way. I just think there's a somewhat special simplicity to being able to just start writing random code in a file and have a web server execute it - and that code can do real stuff. No libraries, no configuration, no worrying about how the whole application is laid out. Just a file that executes. And before VPSs and such, it was so much easier. If you don't remember years like 2008, there are amazing threads about people trying to deploy things like Rails apps and the problems they encountered. It wasn't like today where we have much better tooling - but PHP always just let you upload some files that it would execute.

Sorry for this rambling thing. I don't think you should be learning PHP or anything, but I'll always have a bit of a special place for it because it made programming real things really accessible when I was an undergrad. I wasn't going to be renting a server with 1GB of RAM for $100/mo to run a Java project. Even a smaller server to run some Ruby or Python would have been more expensive and required a lot more work (which, frankly, I wasted a lot of time doing out of interest, but that's beside the point). PHP let me get something for $5/mo and just stick files on a server that someone else admin'd that would just work. I didn't have to do security patches, monitoring, process management, etc. I could just write some files that spit out some HTML, read GET/POST vars, handled sessions and cookies, connected to databases, etc.


> Want to use a relational database? You don't need to install a library (often one that requires a C extension in a language like Python or Ruby). It's just part of the language.

I'm being pedantic here, but technically it's still a C extension that most package managers install by default.


Yea, I was thinking about writing that, but it seemed really pedantic given that it's basically always there. I mean, Python never comes with Flask or a MySQL driver. You never end up paying for a PHP host without it. But you are technically correct, the best kind of correct!


You can use sqlite in python out of the box.


What you describe is certainly how people used to work with PHP two decades ago, however things have changed a lot:

> Want to use a relational database? You don't need to install a library

These are optional packages in most distros, so you (or your admin) effectively need to install a library.

> Want to get things out of the HTTP request? PHP has already parsed everything into the `$_REQUEST` associative-array (map/dictionary).

And yet we have PSR-7 (https://www.php-fig.org/psr/psr-7/) which define HTTP messages and most frameworks comply with it.

> Most of the time if you want a library, you can download a directory of files and then use `require` or `include` to bring it in using relative paths. No worrying about environments or installing things. Just copy a folder!

There are gazillions of libraries at packagist.org, meaning these are installable via composer. Many of these expect composer to resolve dependencies. Major frameworks can't practically be installed without composer.

> PHP let me get something for $5/mo and just stick files on a server that someone else admin'd that would just work.

There are cheap cloud solutions for most languages...

> PHP also offers a dead-simple deployment. You put your files on a server with PHP installed and you're done.

... with push-to-deploy.

> Heck, PHP even simplifies templating because PHP is literally its own templating language.

And yet we had alternate templating engines for PHP since forever (remember Smarty ? know Twig now ?). Stuffing templates with "htmlspecialchars" or "htmlentities" is no fun.

> if you're looking to take a student with one CS course under their belt and give them some instant joy, PHP really hits the mark.

As stated, Javascript is better at this.

I could go on, but my point is that you're describing qualities that were competitive advantages in the past (somewhere between 1 and 2 decades ago), but are no more.


> And yet we had alternate templating engines for PHP since forever (remember Smarty ? know Twig now ?). Stuffing templates with "htmlspecialchars" or "htmlentities" is no fun.

One of the best decisions after I decided to stick with PHP for my web site was ditching all those alternatives and go with PHP alone, using functions as tag libraries.


> using functions as tag libraries.

Care to post an example ?


Basically you split the PHP code into three layers, trying to do a kind of bare bones MVC.

You have the PHP business logic code as usual.

Then instead of doing

    <a href="http://somewhere">A link</a>

You have a view function that does that for you

    function web_link($url, $title) {
        echo "<a href="$url">$title</a>";
    }
And then on the HTML markup, you place those calls as tag libraries in other similar frameworks,

    web_link("http://somewhere", "A link")  
Very low tech, but does the job similar to JSP tag libraries and provides some organization.


It seems too low tech to be useful for any project of any complexity. Existing HTML template frameworks do a lot of things like character and syntax aware data escaping (and avoiding double-escaping), template caching, plugins, code generation, tag extension, filters, etc.

Other than being slightly more concise and appearing more functional, I don't see the benefit of this over something like Twig or Smarty. At some point you're going to wind up re implementing features that already exist in a framework anyway.


Naturally if one is doing it at scale, this is NIH.

I used it only for my web site, and many alternatives did not exist back when I did this.



Yes that is the idea, it just did not exist in 2003.


Low-tech is fine, however I'll assume your example has been excessively simplified for the sake of brievity because as-is it's prone to break your page.


Yes, I was making it basic, just describe the idea behind it.


Maybe PHP is a shitty language if you're coming from a CS background but Javascript is absolutely not better at "looking to take a student with one CS course under their belt and give them some instant joy". It's FAR more complex than PHP


I won't argue about the complexity and I'm not a fan of JS either... but surely you can agree that firing a browser console and do live dom manipulations can bring instant joy ?


Yeah, I even demonstrated this hacking tool to a friend to show I could (temporarily) change the content of any website


I am baffled by the argument that's repeatedly advanced in different comment threads in this post: that php is easy for complete novices in web development to pick up, and that therefore... something. It reinforces the mindset that php is an entry-level language for amateurs; and if this is the case, then why would you want to keep using it for professional development once you are past your first web dev baby steps?


I posted the link to the dev stack of the most popular websites already: https://en.m.wikipedia.org/wiki/Programming_languages_used_i...

So with php is definitely possible to build large web apps as it is possible with other stacks. However compared to other languages with php it is very easy to get started as well as mainly the first dev setup is quite easy, although for professional work there might be no difference between the different stacks...


"something" => "it is popular and will not be dethroned except by another language that makes getting started even easier"


`<?= $_GET['theVarName'] ?>`

Is vulnerable to XSS

This I assume is another reason why HTML "aware" templating engines are now popular in PHP rather than toggling with <? and ?> between HTML and PHP

PHP makes it really easy (IMHO) to write insecure code, and most samples you find online are. Not many people starting with PHP learn

`<?= htmlspecialchars($_GET["theVarName"]) ?>`

or equivalent.


Well, any language that has the capacity to take raw user input and output it as-is is "vulnerable to XSS" so... ;)


> Want to use a relational database? You don't need to install a library

Well, it depends. On Linux you may need to install a package like php7.3-mysql, depending on what was installed as a part of the initial setup.


Which is most probably already done and correctly set up for you, even if you pay only 99 cents a month on your hosting. No worries about that.


> If you want to use packages then you'll need to use a Package manager, you still need command line experience etc.

PHP has a package manager IF you want to use the vast offering of open source PHP libraries and frameworks.

https://getcomposer.org/download

To use it, create a composer.json and run:

  php composer.phar install
On my systems, I like to alias it so that I just have to type:

  composer install
Alternatively, if you use a Jetbrains IDE (i.e. PHPStorm), you can usually install dependencies with one click.

> And to be fair, as a naive non-PHP user, I have 0 clue how you would go about setting up long running scripts that don't necessarily correlate to a web request.

php /path/to/script.php

It can run as long as you'd like.

If you want to do it on demand (i.e. writing a webserver in PHP), that's difficult. But generally: Why would you want to do that? It becomes an X-Y Problem.


I don't think the person you're replying to said it was not possible with PHP. Just that similarly to other languages where it's just as straightforward as the example you gave, it's not built-in.


They said "I have no clue how to X" so I told them how to X, with caveats for corner cases.

I wasn't trying to debunk a claim that something is impossible.


so I told them how to X

No, you didn't.

What you probably meant is "run it from cron, or create an OS service that starts from init.d/systemd/whatever". Which answers the question, but isn't very impressive from a technology stack.


No, what I meant is: Run this command. It can run for as long as you want it to. That's a long-running process, by definition.

If they wanted something more specific, they should ask for what they really want.


Except that "PHP is meant to die", i.e. doesn't perform well as a long-running process, you'll keep running into bugs and warts. Software Gunslinger has explained that well: https://software-gunslinger.tumblr.com/post/47131406821/php-...


I kinda meant both. I feel silly not knowing that it's only "php ./script.php".

I also meant long-running processes, which it sounds like is still problematic. To be fair, it doesn't sound like PHP was ever designed to be used for long-running processes, to which I guess "Fair enough", but that might make things like a job worker queue more complicated if you want to write the workers in PHP (it sounds like you'll need a dispatcher in a different language because that would be a long-running process).


This article is from 2013 and is not relevant anymore. Dozens of concepts useful even for writing desktop apps with PHP (I don't claim that it is the best choice) were presented in book "PHP Beyond the Web".


Not saying it's not possible: from where I am in 2020, long-lived PHP 7.4 processes still exhibit the described symptoms (memory leaks, even segfaults). In other words, tools for the job.


Memory leaks don't surprise me. Segfaults do.

Have you reported them upstream? That implies a memory safety or garbage collection bug.


Yup, GC bugs, mostly; some fixed, some are hard to repro...


He means for example if you want to make database connection PHP has build-in function. But in Java you need few libraries. In one end it is one line code, in the other one it is several lines of code.


I agree PHP is vastly better than it used to be. It is also a bit more "batteries included" out of the box if you're doing things in a very very bare standard library/simple server sort of way.

That said, when learning web development, PHP, Python, JS, and Ruby are all very similar. You absolutely use a package/dependency manager of some sort, and they all have pretty simple startup with their major (similar) frameworks, whether Laravel or Django, Yarn or Bundler, etc., for their respective languages.

That said, there is one place where PHP is very different, and that is configuration. PHP still has a lot of configuration options that live in global config files, and a number of things that could be easily managed dependencies or are core in other languages are still extensions that need to be installed and enabled at the language level in PHP which seems worse from a "getting up and running" perspective.


Not to mention that actually debugging with PHP is a pretty big chore.


I recently switched to working with Python over PHP. When I started working on this project no one on the team used a debugger nor knew how to set it up. VSCode became the easiest path for debugging so I use that but it doesn’t handle multi-threaded code well yet so it’s been a bear trying to debug. On the other hand. I added three lines of xdebug config to my PHP.ibi and I can remote debug the PHP stuff no problem. Granted it doesn’t have as much introspection as other languages it was still a much less painless process to dive in and see what the code was doing.

On the framework side, Laravel beats the pants off Flask or django IMO when it comes to deployment, asset build pipelines, queues and database migrations. Almost all of those can easily be configured with laravel and are very flexible. In Python world I had to do a lot of setup to get that kind of thing going.

Virtualenvs and pipemv and poetry weren’t terribly hard to configure but it took a lot more time to learn than PHP composer. Granted the ease of switching envs and versions in Python seems a lot simpler than PHP once it’s all setup.


If you're using Laravel + Homestead you can configure PHP versions on a per project basis in your yaml file and changing it just requires a vagrant reload


To clarify - are you seeing issues with multi-threaded debugging in VSCode with Python, or with PHP?


Python. I have been watching the PTVSD development very closely since 5.0 aims to address most of the problems I have. They just got spawn and fork support in recently so things should be much better now but it’s still pre-release and there’s a number of open issues left to solve. I didn’t have to work on threaded code in PHP so it may not have been fair to bring that up at all since it’s mostly irrelevant to the point that it was very easy to setup PHP debugging for my use cases and it was slightly more work to setup Python initially.


The improvements in the new version of ptvsd are around multi-process debugging, though, not so much multithreading, hence why I was curious. Multithreading was supported before VSCode even, going all the way back to PTVS 1.0, so if we still have any major issues with that, I'd definitely like to know!


How so? In my experience, Xdebug (https://xdebug.org/) provides a solid set of debugging tools.


Xdebug is great, but the setup process is not friendly. There's tools that try to automate the install process, but it's very far from having an OOB experience.


I used to think this since I've been writing PHP for decades, but XDebug and Visual Code has come a long way. It's above-average at this point.


> for all other languages i know of, there is quite a process to get started

It's funny that you included javascript in the list when you can literally just type javascript code in an html <script> tag and open it in the browser that comes with your OS.

You quip at flask for requiring "command line experience" then talk about PHP's built-in web server that's also a command line tool.

And let's be realistic, if you're using php without a package manager, you're either no doing anything serious or you're reinventing the wheel, and you will need to get comfortable with the command-line sooner or later anyway.

I will say that PHP is probably the the most frictionless server-side web-development language to get started with, but it's not by a huge margin.

And considering that in web-dev you're gonna need to learn javascript anyway, I'd probably consider it to be the best introductory language.


> It's funny that you included javascript in the list when you can literally just type javascript code in an html <script> tag and open it in the browser that comes with your OS.

Let's be fair: you're going to be very limited in terms of the type of web site you can make with this approach compared with a PHP app via web server


Is he?

Somebody built a photo editing app in JS which runs locally in your browser.

https://www.photopea.com/


Of course, such things are perfectly possible and for an image editor I'd consider in-browser js superior to anything but native apps.

However, consider this, you want an app that has to use a database, you can't store everything on the client or use things like Dropbox integration. Plenty of situations where you want that, but that just can't be done with clientside js without also making your database acces keys and encryption keys available to all. So all in all, it depends on what sort of app you want to build or form your course around


Or I just use node on the server side and write the server part also in js?

This was not about building anything sensible, but just to counter the point that js allows you less than php.

I think today the only big language with is a pain to setup is perl, java and sometimes python, the rest is just a matter of ecosystem, needs and personal taste.


Just because it can be done doesn't mean it's the ideal way to do it or to learn.


This was about your post saying you can't do anything with only JS and me disagreeing, not on how sensible language X or methode X is for anything.

Nobody would write a php app without js today and you can use js server side with nodejs, same as php and php fpm.


> your post saying you can't do anything with only JS

I ... didn't say that?


I meant your comment:

>Let's be fair: you're going to be very limited in terms of the type of web site you can make with this approach compared with a PHP app via web server

Which translates to me that you have the impression that JS is limited in usage, which it simply isn't.

Things like webrtc and other node, changed the way JS can be used and for the things it can be used.


That's not a fair translation of what I said at all.


That script tag alone isn't going to do much without a backend.

JS frameworks (angular etc) have substantial learning curves for noobs and the language itself has at least as much WTF as php does. Then there's Typescript, Node, ...

Python & Flask are amazing but if you're taking your first steps at programming they do need a bit of effort to get up & running. What caused friction for me when I started out with Python was:

* V2 or V3, why, what ...

* pip / pipenv / virtualenv

* circular dependencies

You can start out with PHP using something like XAMPP + CodeIgniter MVC + PhpMyAdmin + FTP. Most people starting from zero should be able to build & deploy a todo list app in 1-2 days using this "stack". It's all old & outdated but as an introduction it works great.


> That script tag alone isn't going to do much without a backend.

When you're starting out, you're not going to do much in the first place

> the language itself has at least as much WTF as php does

Oh absolutely! My argument was mostly that for getting started, JS has actually less setup than PHP, not that it's a better language, or that it's a better learning language (although I happen to also believe both of those things but for different reasons, mostly because of the easily available REPL and debugger available in browsers, whereas debugging PHP is much more involved)

> Most people starting from zero should be able to build & deploy a todo list app in 1-2 days

and you can make a (local) todo list app in JS in the same amount of time without installing anything (because let's be real, setting up a database and web server, even bundled solutions like XAMPP can be a real challenge when you're starting out if anything at all goes sideways), and you can deploy it for free by just uploading the files to github from your browser. And if you feel that doing this without a framework is too hard there's a slew of tutorials to do it with jQuery (in the old and outdated category) or React/Vue (which don't have the added typescript complexity of Angular)

I am not saying that PHP isn't great to start with, but I feel like more and more JS can really compete in that space, and has some key advantages for further progression.


Or push three buttons from any webpage in Chrome and get a js console


Ok. The focus of my argument was only on server-side development as php was the language of comparison... however as you mentioned javascript is easy to get started as well and more or less the only option for front end dev anyway (as typescript, coffeescript, etc are transpiled to js and webassembly has no direct dom access)...


PHP has its appeal with a install and then run script situation. Its simplicity of lacking any "project" structure (like what node.js has with project.json and .NET has with .csproj) or more complicated setup (Python with setenv) makes the first days of teaching a lot easier. Also the 1:1 mapping of urls and files is appealing.

However, after that first days, all of them rely on package managers (PHP, Node, Python, .NET, ...), custom routing and a structured project organization. This also explicit includes PHP.

You should try .NET Core (in your scenario maybe with ASP.NET Core Razor Pages). Its setup is very easy (dotnet new webpage; dotnet run) and normal projects rarely need the package manager. The only challenge is the sub folder containing the web pages ;).


I’m using mainly ASP.net Core for my projects but PHP is still simpler to get started with IMO. Microsoft’s framework does a lot of things, and a lot of magic involved which means sometime searching for hours in doc and stack. Another difficult thing is Startup.cs and all the magic middlewares whose declaration order actually matter.


That is right. And I agree. ASP.NET is already a framework on top. PHP is the best choice for immediate entry without explaining millions of concepts (like routing, middlewares, http, ...).


PHP uses composer as a package manager, which is quite simple to use and very easy to install (it's a phar archive, basically an executable zip file). And frameworks like Laravel can be installed with a single composer command. This is still very little setup to come to the same point.


The problem an educator has is the time from start till first success (from early happiness but also time constraint perspective). In the first lecture.

Important programming tools like Projects, Package Manager, Routing, separate view/model, ... are a delay in that timespan. They are all worth it and in most frameworks not too complicated. But each item needs time to explain.


Its a rather poor reason to choose a language in my opinion, but given the popularity of both PHP and JavaScript, one that has worked for many people.


> We have used, java, javascript, python and php for a basics course in webdev.

Soooo...... How about Ruby on Rails?


Has it gotten easier to actually get running, without resorting to a pre-built docker image?

One of the biggest advantages of PHP is ease of actually doing the web server config, especially compared to dealing with an external app server along with its init script or systemd unit.


Ruby Rails doesn't even work work out of the box on Windows.

Which makes teaching it 10x harder. ( US seems to be outliner in that every student is on MacBook )


You'll eventually need a package manager. The only question is whether the language ships with one, the OS does, or whether you're on the hook to provide all package management by hand. I agree that PHP lets you go a bit farther without one, however.


Composer (getcomposer.org) is the package manager of choice for php.


PHP has built-in web features... or it's a web server with built-in programming features... ;)


imo the best way to get started is html + js. And then write the backend in a backend language, flask is pretty good for beginners.

Completely separate the concerns. PHP gets people all mixed up. Backend is for data and frontend is for display.

And also, for most needs you don’t even need a backend. If your need is trivial, just get a lambda.


> it seems that it doesn't matter what language one chooses

"there is a successful website written in X" does not mean that it is deemed appropriate or acceptable to use whatever you like. Anybody who has started a new project from scratch as a professional at a company can tell you it absolutely does matter what language one chooses, and if you opt for something non-standard or for whatever other reason deemed unsuitable, you will be corrected.


PHP, Ruby, Python and JS and their popular libraries or frameworks are standard for web dev, though.


PHP is, and always has been a practical language.

7.4 has been especially exciting with the introduction of FFI. Few other languages even have runtime FFI, and in most cases you have to do the binding stuff in C.

I even ported a terminal-mode text editor (which uses FFI somewhat) from C to PHP: https://git.timshomepage.net/timw4mail/php-kilo

I would guess most of the PHP haters got stuck working on Wordpress, or someone's old business app, or they just hate PHP because it's popular to do so.


This new FFI support intrigued me. But looking at the source, it's just a wrapper around libffi. I don't know of any language that doesn't provide a wrapper around libffi, though not all provide it as a default-installed module. PHP's bindings also provide a simple YACC-based parser for automatically extracting simple size and layout information from C header files, though this is easy enough to write in-language (heck, there's a full C99-compliant LPeg parser). Notably, PHP's parser, like LuaJIT's, doesn't handle the preprocessor, so its useless without resorting to a separate program (e.g. cpp(1)) if you want automagic bindings.[1]

So, kudos for PHP for doing this. Not exactly a game changer, though. The performance cargo cult dislikes libffi as it can be relatively slow compared to an inline binding (static or dynamic) due to the need to copy input parameters (by reference, not by value) to an intermediate data structure on every invocation, and due to the fact that some JIT'd languages can JIT through the external function invocation (LuaJIT can do this, IIRC). It's ridiculous, but it is what it is; libffi effectively "taints" FFI support as non-native, which is a death sentence these days.

I think PHP is a horrible, cobbled together language. If the core maintainers had a strong grounding in language theory, design, and practice, they do an impeccable job filtering it out of the final product. It's been this way from the very beginning, and by everything I see today, remains so. That said, it's the first thing I turn to when I need to put up a simple web page with server-side logic! I have absolutely no desire or tolerance to fsck around with CGI, modules, packages, or anything else, and the PHP ecosystem Just Works out-of-the-box on every system (Linux, BSD, Windows) I've ever tried it on.

[1] Such parsers are kind of useless. Better to provide built-in sizes for core system data types like time_t and then, optionally, provide a simple, quasi-C grammar for expressing redundant definitions that you parse inline. Which is presumably how such parsers are used in practice, notwithstanding the pretense. Plus, I run all my web applications in jails (chroot, pledge, seccomp, etc). If system and library headers are visible at runtime, something is broken. If someone really wanted to go the extra hundred miles for proper automagic bindings, one could use ELF symbol information, for example debug symbols (e.g. DWARF) or simpler symbol info (e.g. BTF on Linux, derivative of Solaris' ABI metadata, which was directly supported by OpenBSD before the Linux project got started).


>I think PHP is a horrible, cobbled together language. If the core maintainers had a strong grounding in language theory, design, and practice, they do an impeccable job filtering it out of the final product.

urg and then ?? We will have just another Python, C, .Net or Go, which are all good for some ppl and some things.. Sometimes you just need some outside the box thinking...


None of PHPs warts benefit the language. At best they benefit the implementation, which is presumably why it happens. (Various inconsistencies and warts in Python and JavaScript can be readily traced back to implementation barriers, as well.) But languages like Lua show that PHP could have implemented all its features wart-free without undue implementation complexity or any runtime cost as almost no language element in PHP was added and implemented until long after it was added in other languages, including Lua, which is a fraction of the size of every major comparable language out there and generally faster to boot.[1]

PHP is great despite itself. But great it is. You can say that about many popular software tools, but PHP is unique in effectively going unchallenged in its domain, iteration after iteration, decade after decade, quirk after quirk. ColdFusion was the only real competitor, but it died when they tried to replace CFML with CFScript. (Well, also because ColdFusion was proprietary.)

People believe languages become popular because of their design features, but if that were true we'd all be writing in Haskell and Scheme with shims for C-family, imperative-style syntax. In truth language features, including syntax, are usually driven by implementation barriers that arise early in a language's evolution, starting with the choice of GC or no GC. The language succeeds despite itself. Lua is a uniquely elegant language precisely because the Lua authors eschew backwards compatibility between every significant release. Every major release of Lua (which looks like a minor release if you expect SemVar) involves a wholesale refactor of the implementation, and syntax breaks are judiciously allowed (i.e. more weight is given to implementation complexity than to compatibility convenience, relative to other languages). It drives people nuts, but the product of this process is the only reason one comes to use Lua in the first place. Functional language families have a leg up in this regard, but ultimately it still plays out the same way, which is why not all functional languages are the same. PHP stands out for having no legitimate excuse for its quirks beyond, "we don't need to bother because we're unchallenged [for myriad accidental reasons]."

[1] For example, JavaScript's lexical scoping quirk derives from its original half-baked implementation. But the Lua authors published a paper many years before PHP got closures (possibly more than a decade before?) that explained their technique for implementing proper, quirk-free lexical closures in just a handful of lines of C-like example code. And Lua's compiler compiles to bytecode as it parses, much like early C compilers, so it doesn't have the benefit of arbitrary lookahead or multiple passes. Someone elsethread asked why PHP (and some other languages) require explicit variable bindings for closures. People like to say that they prefer this syntax, but regardless of whether it's preferable, the fact of the matter is that in practice it happens because it's easier to do it that way, especially for statically typed languages. (Except it's not necessarily easier, as Lua shows.)


> the Lua authors published a paper many years before PHP got closures (possibly more than a decade before?) that explained their technique for implementing proper, quirk-free lexical closures in just a handful of lines of C-like example code

That sounds interesting, do you have a link to that paper? (I couldn't find it with a quick Google.)


FWIW, JavaScript fixed its scope problems with modules, which default to strict mode.


"Few other languages even have runtime FFI, and in most cases you have to do the binding stuff in C."

The most often cited siblings to PHP have ffi implementations. Built into python now. Ruby, Perl, and Node.js all have popular extensions for it. Libffi opened this up for a lot of languages.


Fair enough, but it still looks like most of those require an extension that isn't usually bundled with the language.


For anyone wondering like I was, it's "Foreign function interface" [1].

[1] https://en.wikipedia.org/wiki/Foreign_function_interface


What mainstream languages are you thinking of that don't have runtime FFI? (that have runtimes making it necessary in the first place)


PHP is, and always has been a "Personal Home Page"


Hasn't been since about version 3, which went obsolete in the previous millennium;)

Not even technically correct: I mean, Windows for IoT doesn't even need to have any windows, therefore it's not actually Windows, eh? (No. That was a joke.)

In other words, PHP is still "PHP hypertext preprocessor", even though it is used far more generally.


A lot of people hate PHP because they don't think it's possible to write secure PHP code.

Sometimes companies enshrine this ignorance as official policy, and their knowledge of PHP security is as shallow as "php.ini hardening".

When anyone encounters such ignorance, point them here: https://paragonie.com/blog/2017/12/2018-guide-building-secur...

Or for more general code quality complaints: https://phptherightway.com

I'm looking forward to PHP 8, and beyond. Mentalities that were only relevant in PHP 5.1 (or earlier) are outmoded and should be laid to rest.


Absolutely, most of all your points can also be applicable to the same reasons why many programmers complain in their hundreds of thousands about how much they hate C++ due to its footguns and sheer complexity which they assume that they have to literally learn everything in the language and from their bad experiences from C++ 2003.

So Rust becomes the most loved alternative to C++ but is also equally just as complex, slightly harder to read, twice as frustrating due to some having bad 'anecdotal' experiences fighting with the borrow checker and a large lack of post-1.0 libraries. Those wanting to "Rewrite it in Rust" from a C++ code base will be quickly disappointed...

Perhaps the answer to both the PHP, C++ and Rust issues from programmers is always a reply saying "You'll get used to it"...


Agreed. Most of the historical PHP security problems are mitigated with practices that are common for any language. Like "use a template DSL", "use SQL bind variables" and "don't let the web server user have write permissions to the docroot".


Wow. I'm honestly surprised by the amount of people (on the HN!) in 2020, thinking PHP is some pre-historical language clearly inferior to... I'm not even sure what. JS? That would be funny.

(It feels like I'm defending PHP now, which is feels weird, because I can go on for hours talking about the stuff I hate about PHP. But there is a difference between hating it for problems it actually has, and just not treating PHP as seriously useful modern tool which it definitely is.)

That aside, I cannot really treat seriously author's recommendation of Amp, ReactPHP and such as a solution for async. Don't bring up HHVM either. There's no real solid support for async/await in PHP, not even in the form Python has for quite a while now. And for me, it might be the biggest problem it has right now, which seriously hurts in some applications.


> There's no real solid support for async/await in PHP, not even in the form Python has for quite a while now.

I'll second this. Async/await support in PHP is at best an ugly hack.

I don't know if we'll ever get first-class async/await support since there is no event loop in the PHP runtime, and because of how PHP works (build and teardown on each HTTP request).

> And for me, it might be the biggest problem it has right now, which seriously hurts in some applications.

What problem are you trying to solve where a lack of async/await would help?


I've encountered dozens, maybe hundreds of problems where it was actually something that would matter. Here's one example. Consider you need to process lots of requests, that require making multiple requests that take a long time to finish (like 10-30 seconds) and you need to do it nearly in real-time. Given there's no sane multi-threading in PHP as well, you end up building your own parallelism support, which requires running lots of workers. Now, every of these workers does some pre-processing, makes a requests and waits for multiple damn seconds, to get the result back, make some computations and get to the next job. Consequently, to handle the same number of requests/sec you need much more workers, which has a lot of overhead, which results in needing more servers.

Sometimes you can use CURL to just make multiple similar requests in parallel and call it a day, but in practice I rarely could make use of it (consider that service you need to call might require some fucked up protocol, like SOAP, so you best option would be to rewrite SOAP client using CURL with parallel requests, which is not fun at all).

At that point you really start thinking some (any?!) other language would be a better fit for the application, but you have tons of very domain-specific business logic written in PHP that you'd need to rewrite for that app, as well as a team of PHP-developers that are not necessarily ready to learn whatever you have in mind, sooo...


> to handle the same number of requests/sec you need much more workers, which has a lot of overhead

When doing multiprocessing, it's advisable to fork() instead of creating fresh processes (or launching them in containers etc). As long as you preload the necessary libraries/modules in the parent process before the fork, children will reference the same memory in a copy-on-write fashion. It keeps overhead extremely low.

This [1] article is for the Unicorn (ruby) webserver but the way it explains forking, signals, and pipes for inter-process control it's absolutely illuminating. These techniques are applicable to any unix-based applications, including php daemons.

[1] https://thorstenball.com/blog/2014/11/20/unicorn-unix-magic-...


Thanks, that's a nice idea. Kind of hard to implement in the setup I'm thinking about right now, but, still, that never occurred to me, so this is something to consider.

But, of course, it doesn't replace proper async/await. First of all, there are other situations where this solution wouldn't apply. And even in described scenario it isn't ideal. For starters, pre-loading everything before fork is really easier said than done: quite often data you need to fetch depends on the result of request, but just so happens to be very much reusable between multiple jobs. Then, it complicates the code quite a bit, makes to constantly keep in mind across the whole codebase things you wouldn't really want developer to think much about to start with. Additionally, it makes DevOps harder as well: people want to rely on LoadAvg (which is very unreliable metric, but explaining this to people every time is not what makes for a friendly environment) and multiple jobs doing nothing just waiting for I/O to finish sky-rocket it. Then some DevOps tools (you don't necessarily know about because of department communication) try to be smart by relying on loadavg and start actually breaking things.


It is a hack, but it works well if you follow the rules. We've deployed stable and scalable APIs using PHP(Laravel/Swoole.) We would have loved to use something more fitting like Go but the time to MVP would have been much longer. While not perfect, it's been great to develop with. Using production code, it provides us ~5x rps (over php-fpm+opcache,) lower latency, better efficiency, and better scalability. However, if variables are set outside the event loop they will not update, so we had to add some additional tests to help avoid this.


> Wow. I'm honestly surprised by the amount of people (on the HN!) in 2020, thinking PHP is some pre-historical language clearly inferior to... I'm not even sure what. JS? That would be funny.

Erm, well, if I compare with any language, that has a thought through type system (PHP: generics missing, no base type one can use instead), proper closures (https://nullprogram.com/blog/2019/09/25/) and actually consistent standard library ... Yes PHP is still a kind of prehistoric language. Basically one cannot do FP properly without proper closures and that forces people to the other end, usually OOP, but that is terrible in PHP as well. Some kind of patched on top "here you have classes" kind of OOP basis, without generics. Great.

And then all the bad practices PHP encourages, with its hundreds of PHP open tags and PHP close tags, intermingled with HTML and JS, which you can see in many popular open source PHP projects (especially Wordpress plugins lol). Sure, you don't need to do that, but then again PHP gives you the gun to shoot yourself in the foot with. Basically you can throw away all the "output HTML immediately" stuff of the language, use a template engine and you will be better off.


I have a good friend, full time full stack dev for the last 2 years. PHP + JS, on a 2 man team/project/product.

He is the epitome of the late bloomer programmer (bachelors in CS and masters in econ math), they started using composer 3 months ago. No package.json yet! No make file, no linting, no CI/CD, no deploy. Though they feel that it'd be great to bundle JS files.

No templating engine either, though they are doing AJAX, so no <?= spaghetti.

Probaly on their next project they might venture beyond PHP. Who knows.

We can't force people to start with Rust. :|


Ha, well, we all started somewhere. My first website also use PHP, although I never did the spaghetti, not even as beginner programmer, but then again I learned it differently in school and also did not make use of JavaScript on that website ... Ah but actually that's not true, my first website was HTML, CSS, JS on a file hoster and uploading in the correct sequence to update the links in the files.

> We can't force people to start with Rust. :|

Yep, we cannot and should not force. Perhaps Rust is also quite difficult for beginners to use, even if with that comes great learning. I consider it a fine language. I only wish it had proper tail call optimization. If it had that, I would probably start a project in it tomorrow. sigh.

Good luck to your friend, hopefully they will dip their toes into something beyond PHP soon.


> proper closures

That link is laughable. Author angrily tries to persuade me (the reader) that "PHP doesn't have closures!" while essentially showcasing multiple ways to use them to do everything (and a bit more) that you could with a JS closure. It could be argued that PHP implementation of those is actually better that in JS, since you actually have a choice if you want outer scope variable to be mutable or not and default to the safe option (immutable), but allows you to use reference if you want it to be mutable. It all boils down to the definition of the word "closure", at which point I'm: okay man, PHP doesn't have closures, I won't argue. Now please show me actually important use case where it prevents you from doing FP, because I can list way better reasons why PHP closures are fucked up in my opinion than that.

> generics missing

True. I hope they'll add them eventually. It's not like PHP competition has (or had until very recently), though. And more generally with types: still not there and, furthermore, some relatively recent additions that could fix things, actually are fucked up.

> OOP, but that is terrible in PHP as well

I don't like how people currently tend to use OOP in PHP, because they try to emulate Java, and Java is awful. But actually, its OOP is pretty much fine. The only thing out of my head that actually feels like a problem in this department is absence of polymorphism. Otherwise, especially since traits were added, there isn't too much to complain.

> actually consistent standard library

A myth. Well, TBH, I was often bashing PHP for that as well (and often sardonically joke about that still), but, honestly, the more experience you have, the better you know that, sadly, every PL is fucked up in this regard. In practice, it's not a big problem though. Half of that is handled for you by the IDE, some I solved for myself by basically writing my own "underscore.js" in PHP with a consistent interface. Anyway, these are coder pet peeves, not real technical indications for or against the language (as opposed to real reasons why PHP sucks: i.e. no async/await, parallelism, lots of broken low-level stuff, etc).

> hundreds of PHP open tags

> which you can see in many popular open source PHP projects

This is a strawman. You use people that apparently are not skillful programmers and use the result of them using the language to demonstrate that the language is bad. I mean, Wordepress probably can be used as a demonstration of "success of PHP in the real word", but, personally, I would never use Wordpress, and its plugins are probably the showcase of the worst programming patterns imaginable. No professional programmer that knows what he's doing uses PHP as a template engine in 2020 except for a quick demo, and the ONLY tag he ever needs is <?php to put in the beginning of every file. So, this is not a problem for an actual programmer, who chooses PHP as a language for his project, because, surprisingly, every alternative just sucks.

> any language, that has ...

Uhm, Rust? I'm not sure I'm familiar with that language, because this "any" language you describe surely isn't Python, JS, Java, C++, Go and pretty much everything else people actually use in production. And I wouldn't use Rust for a generic backend for a generic enterprise, at least not yet.


I agree with some of the points you made and disagree with some of the others.

When a language is missing generics _and_ polymorphism, it becomes really cumbersome to implement something like a chain, to which you can add operations and then run the chain. This is only one example, that I recently tried to do and then was surprised at how bad the type system of PHP is. I could not use generics to make operations generic in their return type and also not for the chain. OK, I thought, I can just use Object then. Nope, because the other types are not subtypes of Object. So Object becomes useless as well. Also you cannot write your own super type for this, because what kind of values can that contain? Cannot use generics to express it! All the same problem again. I believe in the end I settled with only using numbers and limiting operations to math calculation. I stopped investigating further how to do it, because I felt, that already enough of my time had been wasted by PHP. At least give me one of these, Generics or Polymorphism.

With inconsistent standard library, I mean for example the naming of string procedures: https://www.php.net/manual/en/function.mb-strpos.php omg, really?! It simply adds more to all the issues, that give me this sensation of touching something I don't want to touch, when ever having to deal with PHP. Of course I agree, that no matter how inconsistent something is, as long as it works, you can build an interface around it, to make it more consistent. However, we were discussing PHP and not user created libraries.

The type systems or at least the existing types of the standard libraries of Python and Java (Haven't used C++ much and JS is .. well, JS.) are much more usable and consistent than anything PHP has to offer in terms of standard types. This is what I am talking about: https://www.php.net/manual/en/language.types.php.

Yes, WP plugins might be a strawman argument, but then again it is one of the biggest parts of the ecosystem of PHP, as far as I am aware. On the other hand, what you wrote sounds also like a "true scotchman" argument ;) as in: "Well, that's just those WP plugin developers. A true PHP developer would never do that." -- Which might be correct! I've yet to meet that developer though. It's probably also WP's fault, at least in parts, because of how bad the WP API is. Everything relies on mutation and global state, which you can magically get into your posts by calling a procedure which accesses that global state in the middle of your theme code, instead of making sure to pass things in. It leads people to do many bad hacks instead of fixing actual problems. Is all that shit actually thread safe? With so much global state attached, I'd not be surprised, if it has complex locking logic somewhere internally, slowing everything down, or even no such thing and simply failing in a concurrent scenario. I do agree with the practices you mentioned, using template engine, only ever needing 1 PHP tag etc. because of better ways how to structure the code. If I had to use PHP, I'd definitely do all that. But then again, why should I torture myself by using PHP, when I know how to handle more elegant languages? I'd probably look for another job, if people told me, that I have to work with PHP all day. Fixing a bug here and there, applying knowledge about how to write safer, cleaner code, is fine, occasionally.

Perhaps PHP acts as a magnet for a lot of inexperienced developers, who "quickly want to do something on the web" and stick to it, because they do not yet realize how bad PHP is or the code they write in it. Then some of those graduate and realize the mistakes they made and improve upon that. However, their better work is drowned by all the shitty PHP code that's out there. Others never graduate from that level and keep producing shitty code.

I agree, that other languages are also fucked up. And at least we seem to agree, that PHP is seriously fucked up too. Perhaps I would say that there are many languages, which are a little less fucked up though.

I used to think, that Java's "everything is a class (or interface)" approach forced me to do OOP right, but then I realized it is not true and that patterns like the decorator pattern are needlessly verbose to express, when I saw how it Python its just a decorator. Now I dislike doing anything in Java. Java did not even have a way of passing a procedure as an argument until some time ago. One needed to create at least an extra inner anonymous class plus the corresponding interface. Looked really ugly.

I then liked Python a lot. Then I also realized its shortcomings (difficult to manage correct types in big projects or even when you did not look at some code for some time, still the standard "use a class for everything" type system, although at least not as encouraged as in Java, only one expression lambdas, not so convenient way moving of code, because of whitespace sensitivity ...). I am not a Python fanboy.

My tolerance for BS in programming languages has decreased over time, having seen some truly elegant and minimalistic programming languages (Scheme and the books SICP + The Little Schemer), as well as more type safe languages like Haskell or Rust and dipped my toes in "Learn you some Erlang for great good".

My projects have become more abstract over time as well. I used to create useful (or me at least) tools for natural language learning with Python and GTK+3, but now I am looking at things like "How to implement a thread pool for my machine learning library?" or "How do I write a macro, that defines procedures in different ways, depending on the name of the procedure to define?". PHP or Python or Java don't even have macros. I would not even ask myself any of those questions and I would continue to learn.


I hear you.. I think it has just became the popular millennial thing todo to bash php.


Just like it's become popular to attribute things you don't like to millennials, when you have no idea if they are millennials or not.


Although I don't use PHP, I'm impressed by its staying power and the improvements in speed (which are substantial compared to other dynamic languages). It has almost universal support amongst web hosts. It can be deployed by simply uploading your code to a directory on your web host. It's a widely criticised language, but still accounts for the vast majority of server side code (80% according to some sources).

And in 2020, it's still the only language that gives your users a relatively easy method to self-install web apps or products. (Sorry, but Cloudron, Sandstrom, Docker etc will never match your customers definition of 'easy'.)

Having a ridiculously easy web app installation process for servers would unlock countless opportunities for developers to reach more users or customers. PHP is closer than most. No other language has tackled it (or cares).

This is an excerpt from a blog post by programmer Jeff Attwood:

"If you want to produce free-as-in-whatever code that runs on virtually every server in the world with zero friction or configuration hassles, PHP is damn near your only option. If that doesn't scare you, then check your pulse, because you might be dead."

To broaden choice, Attwood argues we should:

"build compelling alternatives and make sure these alternatives are equally pervasive, as easy to set up and use as possible."

That was written in 2012 (https://blog.codinghorror.com/the-php-singularity/).

It's 2020 and none of the alternatives are 'as easy to set up and use as possible' for server-side installs as PHP. Why?


Because the industry is obsessed with over-engineering. React and Angular were originally developed to power the likes of GMail and Facebook. Now the simplest of sites have to be redone as SPAs simply to support the React/Angular/Vue industry. With deployment it's even worse. Now we have to wrap our simple PHP/Ruby/Python apps in a goddamn virtual OS. Kubernetes and Docker were originally designed for managing massive fleets of servers but now every startup with a 2-bit website seems to think they're missing out if they don't wrap their code in all this infrastructure. Chef and Puppet were good enough for most jobs a few years back so why the obsession with Docker and Kube* ?


I agree, though for local development environments docker is pretty handy for getting the full stack up. Especially if you just came aboard.

But this is the name of the game. More and more complexity. I am not sure how green engineers manage to learn everything. Woof


> Why?

PHP was designed from the start to be a web-first language that solved the issues people had using Perl as a server-side scripting language. I think experiencing the pain points people were having trying to repurposed other languages for the web lead to a lot of good* design decisions.

* Good, in the sense of ease of use.

It also didn't really give you many options in the beginning: everyone just used the LAMP stack and made it work. You could use Windows or Postgres, but you just didn't without a compelling reason.

Nobody today wants to design a single-purpose language that locks users into a platform. Users don't want to learn a single-purpose language and be locked into a platform.


We love forgetting lessons we learned the hard way. With Rails we forgot that dev environments and deployments should be easy like they were with PHP. With Node.js we forgot that programmer time is important and boilerplate can be automated like it was with Rails. We’ll see what the next popular language holds for us, and what we forget along the way.


That's strange because I hear of lot of "best practices" for PHP, particularly Symfony and Laravel, involve jumping on the Docker/Kubernetes bandwagon. AWS RAM prices are a joke compared with, say, Hetzner.com yet PHP authorities are to be heard recommending leaving behind that which made PHP famous - FTP-ing PHP files to a cheap web host or VPS.


API Platform, a Symfony bundle (thats a library, but I guess they thought bundle sounded better), gives you a pretty verbose docker-compose.yaml to get started. I looked at it, shook my head and downloaded it.

https://github.com/api-platform/api-platform

I'm sure they had good reasons...or they just wanted to say hey, we're modern.


I always see hetzner come up as a cheaper alternative to cloud. But why is everyone using them as a baseline for regular hosting? They don't even have a data center in the US that I can tell. Are US companies really hosting their apps in Europe? Seems like a lot of latency.


FTP to production is probably a bad idea, sure, but you have to be careful following best practices from people whose business depends on constantly selling you more. Whether they’re bloggers who need you to click the new article or Udemy teachers who need to sell new videos or cloud providers who need you to buy more or bigger hosting options.


It can be easier, just install xampp and you are up and running within a minute.


I'm fairly language agnostic. What keeps me working in PHP is the Laravel framework, with all of the application plumbing and core functionality built-in and tested for me, so all I have to do is write the code specific to my application. Every once in a while I search for other frameworks but still haven't found anything that competes.


I also like Laravel, though nowadays Symfony wins it for me. But it's probably also a matter of taste.

Doctrine's DataMapper vs. Eloquent's ActiveRecord pattern and the use of configuration in Symfony vs. convention in Laravel (e.g. facades) are my 2 main pain points with Laravel.

But having 2 big frameworks is awesome, both are upping their game constantly and the whole ecosystem is benefitting. (E.g. I use Laravel's Homestead for Symfony development, but I might also use Blackfire.io to improve Laravel performance).


It’s possible to use a data mapper in Laravel though, and it works very well!


It's a shame that Hack didn't replace PHP in general use. I didn't see a mention in the article, but it was created to be exactly this safer/faster/more elegant version of PHP. For example, it has a broad type system including generics.

My first decent sized codebase was web site for my high school in vanilla PHP. It was a total mess (mostly due to my lack of experience and the need to support Netscape 4.7). I understand that some PHP apps are good, though I got burned by WordPress vulnerabilities enough to swear it off.

I wrote a little code in Hack while at fb, and the incremental typing was slowly evolving a messy codebase to some kind of order. (https://hacklang.org)


Wordpress is not PHP. Wordpress would be just as bad in Hack.


Seconding this.

As someone who built (5 years ago now) and maintains a client application that runs along side a Wordpress/WooCommerce shop of pretty high volume - it's absolutely mind blowing to me the kinds of decisions that Automattic/Wordpress/WooCommerce make... from a code and operation viewpoint.


I agree, it's a shame we don't push Hack more broadly (in general I think the reason is our teams are focused on internal adoption and improvements, and don't feel they would benefit from supporting open source community), it's such a pragmatic language, so familiar that folks pick it up super quickly, it's getting an awesome standard library now, it's a got a great type system, great IDE integration, scales to our bizillion lines of code...


I think part of it was because it was being pushed at all. I didn't see a lot of collaboration from Hack towards PHP. It was a - sadly typical - "Hey, here's our thing, it's better".

A few select individuals came forward (or were part of PHP core already) but it felt like a Silo, so I'm not surprised there wasn't a lot of participation from outside.

PHP 7 and the speed improvements were a direct answer to HHVM, though.


I should probably get around to making a ShowHN, but my co-founder and I, having worked with loooots of clients that are still very actively working with PHP code bases (sometimes even still in datacenters!), aggregated and productized our "dream" stack as a PHP PaaS. Please check it out, kick the tires, and let us know what we forgot!

https://www.lamp.io/


Interesting project. And it's great to learn about your company. My project, Amezmo [0] is providing a similar service, but focused exclusively on php hosting along with continious deployments and managed databases. We bundle deployment and hosting. I've been working on this since 2018.

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


very cool, I like your design eye better than mine!

I think the overall market is huge here, plenty of room for both of us (and fortrabbit). The EIG family of companies and the 5.6 "issue" is creating a giant market for next-gen-php hosting.


Nice implementation! I really like the pricing page's variability,

But it does seem kind of expensive. Probably about 30$/month to run a wordpress install....

Are you using AWS or GCS? Maybe Kubernetes would be a cheaper option...

Definitely submit this as a "Show HN"!


Thank you!

Its built on kube (gke) on gcp. For pricing we just started with the standard retailer keystone margin without oversell/oversubscription. We're hoping ease of use trumps saving a few dollars a month, it has for our first few customers, but we're still testing it out. Our goal is not to be the bottom-barrel-cpanel hosting world, but rather the freelancer/professional market for whom the extra 10 -20/month is a rounding error if it makes life easier. Also as a clustered service where we handle the os/image layers for you its more akin to a failover pair of vps's with some devops services (like forge) so its actually right in line with those as a bundled price, we just need to communicate it better. Also we're working on improving the webhooks/ci-cd functionality to eat into the $/month people pay for stuff like envoyer or travis-ci too.


Little off topic: you should check your site on mobile. The header takes almost half of the site, making browsing it super horrible.


yikes good catch. we had to de-prioritize mobile compared to so many other things, but we shouldn't let it get outright bad.


I think PHP suffers from the java migration, we now write code like this https://github.com/aran112000/Advent-of-Code-2019-PHP/blob/m... when functions in a namespace would have sufficed

It seems like collectively developers are patting themselves on the back for putting the same old crap code in classes, as if putting data into a change by reference data structure is a good idea

Personally I'm trying to migrate out to Clojure where mutation is hard and controlled by default & we don't pretend modelling reality with a tree of nouns is a good idea


Classes are/were thought as awesome because you can do dependency injection via providing an object, but you can't easily do that with just providing a different implementation namespace.

That said, maybe PHP is not the language where you need to do DI. Just have a few different config files around, do the includes and wiring there and that's it. And hope for the best. (After all there's no compile, no checking of interface correctness with any kind of DI either.)


I have a love/hate relationship with PHP but it has undeniably gotten better than its reputation would imply. That said, I think that regardless of the language's continued improvements its reputation will continue to suffer simply because it IS so easy to write and deploy code. Any sufficiently popular and widely supported web language will be the most common entry point for new coders and entrepreneurs who learn just enough code to get that MVP out the door. They will blog about their successes and add to the the number of 'not serious' coders putting poor quality code out in the world. If Python or Go were this easy to deploy, we'd be see their reputations suffer as well.


Very true. It is the same with Basic.


Can anyone suggest anything that is superior to PHP in its development cycle: save file.php = instant result? As far as I've seen, everything else needs to restart a server, obviously much slower.

What about its die-hard intention of fulfilling a request no matter what? What about autoloading? And what about the amount of things you can do in vanilla PHP, no libs, no extensions.

Hey i've worked with it for some time and sure, its got its nasty things, like gotos :)


My workplace has both PHP and Node/React apps. PHP, instant result. The Node/React app takes 10 seconds at minimum to restart. Also, to start it for the first time takes a good minute or two. Annoying. Something no one else ever mentions is router systems. Everything under the sun uses router systems, even the PHP frameworks. Go ahead and benchmark those compared to just saving a file and having Apache or Nginx serve it because it's there. Go ahead, I'll wait. The router system is much slower. Not to mention, it has to be manually configured to even work.


People use router systems because file system can't map all the routes. Also, your web server also has a router system, it just happens that it, by default, maps /potato to potato.php (I like potato better than foo). Instead of configuring this, people tell the web server to forward all requests to a php based router so people so not have to rewrite routing logic when they switch web servers, and everything is configurable through one language.

This applies not only to php of course.

Also, I'm one of those guys who was lucky to do enterprise react projects before it was a thing, and even converted a huge react codebase to typescript, and I'm telling you: If it takes 10 seconds instead of 2 for a giant codebase, there's a misbehaving plugin or a misconfugiration. Shed all of them and also explore hot module reloading.


No one denies that. But this is another entry burden removed. Routing Systems are important and key to any framework. But explain the concept in the first day of a fresh Web Dev (w/o loosing him).


"This part examines the URL and figures out which code should run in response." Easy.


What kind of bloat do you have with your nodejs app?

My nodejs app (not react) restarts in about 3 seconds, which is still hugely annoying as I can hit reload after alt-tab in a second and I have to wait a few seconds or else I get "Bad Gateway" errors.

It's monitored by pm2 for auto restarting ts-node.

I wish there's a better solution that reloads faster than you can alt-tab and reload.


Clojure. Changed namespaces automatically recompile. Instantly reevaluate changes. Never have to restart the server. On the front end you never have to even hit refresh in the browser with clojurescript.


That's cool!! Had a nag for learning lisp/lisp-likes for a while now. My favorite part is the absence of concurrent problems due to immutability.

How popular is the functional paradigm for The Web?


React has its root in the FP model, and the React ClojureScript binding (Reagent) works really well with it.

(reference: "I had implemented several iterations of what eventually became React, in a few languages - one of the first explorations began as a rough implementation of the reconciler and component model in [the functional language] Standard ML (CreateClass was a "module function"). This was really great because SML embraces immutability by default which is natural when building React style components. " - https://www.reactiflux.com/transcripts/jordan-walke )


Basically any other framework/language will have some sort of dev-mode autoreloader that will restart everything faster than you can switch tabs.


yeah, I know, but PHP does not even need that. That's the point.


I would argue that PHP does need it, it just ships out of the box while other languages need a “npm install” step first.


Hot reloading is very different but cool because it could involve rebuilding assets. But slower and not really the same.


It's not an actual advantage, and PHP's "throw the world away" execution model is so so dumb.


It's an advantage and stateless is great for scaling[1]. Loading configuration is a pathetically small sliver of your execution time budget.

[1] https://12factor.net/processes


It adds a lot of complexity to write performant code (you basically need another middle layer), yes.

But it also has some security benefits - with that model it’s harder to have exploits (as in your request you don’t carry over any other state), session swaps, no need to care about concurrency, locks, etc.

It’s by accident, but it’s a real benefit of php.


It pushes people to find hacky solutions when they need "just this memoization for this simple use case" and years later when you take over the project you see it's been dumping request data to a publicly accessible folder.

Luckily PHP is very damn fast so you don't see it often, but you'll start questioning the whole industry if you are hired as consultant into many middle-to-large-sized projects and see the hacks people have come up with.


with that model it’s harder to have exploits

The PHP community's track record on security is abysmal compared to all those other environments that don't throw away the world.


Security record is due to enormous popularity, low barrier to entry and some questionable/archaic design choices. But clean state at start of each request is clear security advantage.

I can have a car with super safe airbags, that does horrible in crash tests. That doesn’t make those airbags bad.


I see your point, it makes sense to me in application development. However, regarding a web request, for me it's totally fine to throw it away :). Same as the statelessness of REST.


Well, I don't what to tell you except that that is a very shallow view.

Every non-trivial web app I've ever worked with has tons of persistent state. DB connection pools. Translations. Configuration. Recreating that on every request is just wasteful.


PHP's caching system doesn't make it recreating from nothing on every request. PHP can take advantage of connection pools but rarely does it make sense to hold a connection open.


For a quick and dirty proof of concept, do these things really matter?

Have you measured the overhead and impact on performance compared to other development stacks?


What happens when your "quick'n dirty proof of concept" has to become production? Rewrite?

As for the other stacks: I do what everyone says not to do. I write stateful servers in native compiled languages with no GC. So far I've yet to encounter any scalability problems. They simply do not exist when said servers are runninig on 32 core monsters with gobbles of RAM and not slowed down by interpreters, garage collection and bazillion of abstraction layers. Sure I could not serve Facebook using this, but hey it works just fine for the 90% of the rest and that is where I make my money ;)


I like all the replies you get denying the obvious truth. Yes, every modern JS framework has autoreload. Use React, Vue, whatever, and the page will have reloaded between when you save your file and look at the tab. It’s not a secret, PHP heads! Your language is not as good for web development. JS sucked in 2000 but now it’s a way better language than almost anything.


Tell me how to do that with nodejs. It still takes almost 3 seconds to restart which makes me wait a second or 2 before I can reload.

pm2 with ts-node is the best I can achieve so far but not fast enough not to hold for a second.


Not really faster than switching tabs unless you are deploying a hello world app.


> As far as I've seen, everything else needs to restart a server

Everything else as an autoreload of some sort, so you don't have to think about it while developing.


I've used Common Lisp for this purpose. You get instant results without even having to reload. You can simply compile a single function while the code is running.

I did a talk about this a few years back: https://www.youtube.com/watch?v=bl8jQ2wRh6k


Any language that has an "eval" mechanism makes this really easy. I've used Groovy's GroovyScriptEngine to build something like what you're describing. These scripts are provided with a "Binding" that gives the script access to the HttpRequest and HttpResponse.


I used to be on the hate side and kept searching for alternatives for my site, until I decided to actually spend some time learning PHP best practices.

Quite happy that I took that route, and that I was able to keep getting the language and eco-system improvements along the way.

Modern PHP is quite good for the context of building web sites, its original purpose anyway.

Languages don't need to be good at every domain.


PHP was intended to be a templating engine and nothing more. It's the community that pushed it in that direction even though that wasn't the creator's intention. And though that has lead to some bad decisions, let me be the one to say it: though it is by no means a good language, it's far not the worst. Surely, dive into most other dynamic languages and you will quickly want to stay as far away from php as possible. And in the modern day and age if I were to start any project from scratch, regardless of what it was, I can't think of a single reason to use PHP over most other available options. As a matter of fact java and javascript are the only two languages I'd avoid more than PHP. Java for all the annoying boilerplate code you have to deal with as well as the incredibly strict way of how you need to structure your application and javascript because it's horrible in every way - syntax, type system, ecosystem, npm is probably the worst thing to ever come out of mankind. I think this might be the result of a small number of js developers who were above average and wanted to prove the "haters" that javascript can do more than juggling dom elements. I can probably write an entire book of why both java and javascript are horrible languages but that's not the point here. PHP has evolved and while I can't really find a single vallid reason for using it in 2020, other than legacy systems or maintaining something that isn't worth the effort doing from scratch, it isn't the worst language out there. Certainly not as horrible as people portray it to be.


It became popular because accessible (for both 'developers' and hosting company). It's a case of "worst is better". The alternative around 2000 was either Perl CGI or ASP classic or Java.

Java was too complex for most beginners because it forced OOP, and there was not a lot of resources on OOP back then, unless one already knew Delphi or C++.

The irony is that professional PHP development can now be deemed more complex than Java, as the language is trying to fix itself with pragmas and what not for type guards and co...

Strangely, there is no real alternative to the whole "drop a script on a server", aside from using basic CGI or FCGI which many classic hosting companies do not provide.

> I can't think of a single reason to use PHP over most other available options

Many online news or organization web sites are still running Wordpress, Drupal or a heavily modified version of it. But like everything they tend to disappear as it becomes costly to maintain, compared to SAAS solutions which are rapidly replacing all that code.


I guess those are personal preferences. I would rather use typescript and Java moreso than PHP, Python, Ruby, C++, C#, etc...

Not exactly sure what exactly is specifically wrong with npm, have you tried yarn?


Both tpescript and yarn live under the npm ecosystem which, to put it mildly, is a meal that was un healthy and tasted horrible and in attempt to make it better, thousands of cooks tried fixing by eating it, puking it out, cooking it again and repeating that process thousands of times. As I said, I can write a book about the bad things which from all the languages I've used, are only applicable to js & co.


So no real example or specific reason it is worse than maven, cpan, or any other.


Well cpan hardly matters in 2020. I haven't even heard of perl in a good 6 years or so. Marven, though largely a java(also a horrible language) thing, targets languages which at least aren't used and abused by people who believe that "6" + 1 = "61" and "6" - 1 = 5 are acceptable behaviors. What's more is the fact that compiling the entire linux kernel takes less time and resources then it takes node to figure out how to "compile" x = 1 + 1 into the gibberish it makes. Also the preinstall, postinstall, preuninstall and postuninstall, all of which are horrible concepts and I have no idea what kind of an idiot thought that this isn't literally inviting the security hell into your bed while you are strapped down naked. I can go on for days, those are just off the top of my head while I'm falling asleep.


NPM kinda annoys me too. Like you have to pay to do private packages or you could run your own server, etc...

Been thinking on that lately. However looks like you could point to a tarball on a http server or on your file system, so that might be a solution for shared libs too.

Really like the idea of mono repos but hate the idea you have to publish everything to say if you wanted to build a container image. unless you built and linked everything then your container would include code for your other apps too...

I been wanting to play with a tool called NX though, hoping that might be more what I want, and then for the few packages I want to reuse outside of the mono repo or say you had two mono repos for two separate products I like the idea of just downloading the tarballs to a file location and referencing that way. Also could give it a GIT HASH and using a GIT repo too as another alternative.

But yeah, dealing with private packages has been my big thing that annoys me but might have a better solution. Not sure how other devs or teams handle this sort of thing.

The other big thing people hate about NPM I think is nested packages, etc... Sometimes you might not even know what your downloading since some packages can pull in a bunch, but I think other package managers have this same problem maybe like say Ruby's but haven't looked into it much but remember trying to run some Ruby app years ago in a container but forget what for but I think it mentioned downloading the same thing multiple times. I don't think this problem annoys me as much though but it's something to be aware of and I know some might be annoyed more by it.


> Surely, dive into most other dynamic languages and you will quickly want to stay as far away from php as possible.

I always think these kind of comments are nothing but pedantic. PHP is a good enough tool to get the job done and it's stable with good amount of ecosystem and is a good choice if the app is consumed broadly as many hosting providers would at least have PHP installed. If you can't get something done with PHP, I doubt you can using other languages anyway.

Then, what else would you use? Python, Ruby or node.js? Which one provides instant reload of code upon saving the file? These aren't far better than PHP to stay far away from PHP.

PHP isn't my primary language any more but I'd still use it if I need max pool of future maintainers.

The only real annoyance is PHP requires semi colons which does get in the way of coding as you need to type it along with closing quote and bracket when it's already there after each autocomplete when other languages don't need to.


As I said already, I hate js and node with a passion. Having gone through many operating systems, technologies and languages over the last 21 years, I can say that the two languages I'd ban immediately if I become world emperor would be java and js. As for ruby, I never really worked out what's the deal with it. Personally at this point if I were to start a new project targeting the web I'd opt for either go or python, depending on what needs to be made. Side note, I never really understood why people hate semicolons.


Why is nobody reading the damn article?

>I hope I was able to show you that PHP has evolved tremendously over the past years, and you're perfectly able to write clean and maintainable code with it.


People have been writing this take (and it has been true) for something like 5–10 years. I doubt anyone who didn't believe it was just waiting for PHP to get type annotations to be convinced.


HN mostly goes straight to the comments. And this is what people have to say about PHP...


I have no php experience so I have absolutely zero conception of what the language used to be like, just what it looks like now. I can't help but see it as some kind of frankenlanguage put together with pieces of java/python/javascript and a ton of dollar signs.

In other words, it seems too similar to languages that I already know to be worth learning. Lisp was fun to learn because it is an alien language. C was worth learning because of its usability and centrality to modern computing. The only benefit I can see from learning php is being able to understand more of software history. Cool but I'd rather learn another lisp.

Does anyone disagree with my analysis? I wish the language well but I don't see what it offers me. Obviously it offers a lot to the people who see JS as franken-php and so forth.

Union types are cool though.


The PHP ecosystem is similar to the language (I work on it daily), tools are a mishmash of features that may or may not be relevant to the tool. PHP ORMs in general (compared to say Ruby or Python) are absolutely painful to work with, which leads to most large projects that need a DB making a hard dependency on MySQL.


Do you have any examples of "tools are a mishmash of features that may or may not be relevant to the tool"?

Or why the ORM's make MySQL a hard dependency?

Honest questions, genuinely curious. I, too, work with it daily and am curious as to what you're doing/seeing/running into that I'm not.


> PHP ORMs in general (compared to say Ruby or Python) are absolutely painful to work with

Which PHP ORMs are you thinking of? I've worked with Doctrine ORM, I would not say it's more painful than SQLAlchemy.


There's an excellent Postgres data mapper called Pomm: http://www.pomm-project.org/ with similar concepts to Java's jOOQ.

I can't think of any ORM that makes MySQL a hard depedency. Doctrine, EasyDB, Atlas ORM, ... all support Postgres or any other DB.


PHP nowadays has almost all the syntactical candy of Ruby, and Laravel has all the neat stuff of Rails. But PHP is so much faster and easier to deploy. All it has against it is its bad past and ditto reputation.


> PHP nowadays has almost all the syntactical candy of Ruby

Seems like a stretch. Ruby's whole mantra is about offering a very flexible and forgiving syntax. Matz wants to make programmers happy. The whole language is candy. You get powerful tools to make your own candy. It's extremely sweet. For some people, it's too sweet, which is understandable.

PHP is not that.

You may have a point if you're limiting the conversation to people who use OOTB Laravel or Rails to build basic CRUD apps. I'd argue Ruby is a much richer language for those who explore it beyond Rails.


> PHP nowadays has almost all the syntactical candy of Ruby

Umm, no? Ruby's syntax is far better. No war against where opening brackets go, no semi colons (which is quite important for typing less after auto completion) and apparently you don't surround with multiple functions to chain which would make the code totally unreadable on PHP with random prefix/suffix/underscore separated function names.


Array destructuring: already existed, list() pseudo-function

Array spreading: already existed, array_merge

Variadic functions: are probably better implemented as a function accepting an array, especially now that there's a proper array syntax instead of a pseudo-function. Also already existed, func_get_args.

Argument unpacking: already existed, call_user_func_array

Arrow functions: are not any shorter, and are less clear, than anonymous functions.

Literally the only item on your list that was any good for the language is the null coalescing operator. The rest are just re-implementing something that PHP already had, in yet another incompatible (and often unclear) way.

Hell, good luck coming across '??' and trying to find any documentation on what it does. Searching Google for 'php ??' returns results for 'php', searching php.net for '??' returns seemingly random functions, going to php.net/?? gives you the homepage.


If I were to teach a course in basic web development, there are three languages I would introduce students to. These would be Go, JavaScript, and PHP (alphabetical order, not pedagogical order).

All three are forgiving languages. Each of the three focuses on a different part of the stack. None of the three will save you from writing gawdawful shitty code, but none of the three will prevent you from writing the most elegant code known to man either.


Brilliantly put ! >writing the most elegant code known to man either. Lol oh the PHP-haters will agree and show you a "Look at my perfect code in xyz"... but the thing about perfect elegant code is no two ppl can agree on it.


Wouldn't it make pedagocially more sense to introduce languages that are more different (paradigm) from each other than those languages you listed?


In a single course? I don't think so. Choosing languages that are this similar will make it easier to make the transition between them. The intent is to teach foundational skills in different areas of web development, and not to teach everything about programming.


If it's a single course, then I'd say teaching more than one language is already too much.

Javascript is necessary to learn as a webdev no matter how you look at it, while the other two are not. Javascript can do all the aspects required from a programming language in the web domain so focusing on that would make the most sense.


I would just quote Fredrick Brennan's statement on PHP in 2020:[0]

> “There was nothing wrong with the PHP 5 language specification. The problem with PHP is PHP Group.”

[0] https://www.youtube.com/watch?v=9crnlHLVdno


The PHP group works best when small groups within breakaway with an idea and remerge.


I would not.


It's kind of interesting (or incredibly mundane) how the feature sets of popular web languages have converged. The examples could almost be typescript (and the only reason I don't say Javascript is because of the types.) My understanding is that new versions of Ruby and Python also will have (or already have, I don't follow either language very closely) optional type annotations. It seems like the real difference is on the operational/deployment side, which tends to be elided (or only addressed on the surface level) when we talk about languages on HN.


This is why the development of new languages and constant iteration of “reinventing the wheel” (as some say) is worth it, I feel. Ideas from new languages make their way into old standard languages. If over time, every language starts to look the same, that seems to indicate we are honing in on a sort of global maximum. The power and expressivity of programming languages is immense but not infinite (practically speaking), and it is quite arguable that eventually we will find ourselves with no major improvements to make. At that point, it will make sense to settle. Until then, it makes sense to keep building new ones and using them as inspiration for the existing ones.


I could not even begin to consider using PHP again until php.ini is completely eliminated. Not even optionally eliminated, I need to know I won't have to deal with a hidden php.ini with all it's configured extensions somewhere on a system before use, surprising me with missing, insecure or completely changed PHP behavior. The fact that I didn't know what features a server supported until I investigated or configured this file was a sinkhole of my productivity in any new project.


Why not run phpinfo()?

Lists all loaded configuration as well as extensions and their configuration. Basically everything about the runtime environment your in.

Beginner level stuff.


Yes, that was the first thing I had to do when starting a project. Create a file called pi.php that ran that very function and scan pages of configuration looking for a specific key. I would have to do this not once but many times, whenever I thought I was losing my sanity because some random extension wasn't available or the configuration enabled something unpredictable that I only found out about at runtime (e.g. magic quotes was a perfect example).


you couldn't just run "php -i | grep xdebug" ? Or even explicitly set/unset the phpini settings from the app in question or even your nginx settings? Lots of ways to ensure everything works as needed. You can also include excensions as requirements in composer so it errors if they aren't installed so you don't forget to install them.


I spent 10 years in the PHP world and yes I can do all that stuff. I had to do it just to use PHP. Grepping around configs isn't even the problem I'm trying to point out. It's the surprises, and having to do anything at all to prevent these issues.


really? Arguably webpack + babel.config.js + eslintrc.js + postcss + typescript config + package.json ... ALL just to be able to get your ui/ux built -- and still the entire stack can fall apart w/ one wrong version, or one wrong babel setting, etc.... JS is way worse than PHP... yet I'm not going to throw it out w/ the bath water. Not to mention all the damn dependencies inside node_modules...

Vue and react have some amazing things going for them, once you've got all the tooling setup. But it's still a nightmare config wise that makes php way better. I generally touch php.ini maybe once or twice over the lifetime of an app. Can't say the same about JS tooling/webpack configs.


You could just run your app in a container.


The problem with PHP is that every discussion is about PHP's reputation. It's a language that is overly self-conscious.


The language isn't self conscious. Programming languages have become subject to fashion trends, unfortunately, and "discussing PHP's reputation" is the tech equivalent of virtue signalling that one is too hip to shop at Wal-Mart like a common pleb.


PHP is so polarizing... so much so, that it's enough for me to pass entirely. Even if the language has improved I think the culture is still broken.


for system coding you have c, c++, rust, even java and go.

for scripting you have bash and python these days, no need for php.

for web frontend, js remains to be the king, the sole ruler.

for web backend where PHP used to shine, you have python(django,flask,etc)) and js(nodejs,etc)), plus go and java, very crowded area.

In short, PHP is only good at web backend, nothing more, but that place is getting really crowded these days, PHP no longer is the first choice.

While recent PHP added nice features and performance boost, I feel it might be too late. Its high time has passed.

I can learn Python do CLI/web-backend/AI/ML, I can learn JS for frontend/backend, I can learn C/C++/Rust for system programming, I use Java for enterprise,etc. I really do not need PHP anymore and there is only so much time left to master all the languages.


I'm happy for the PHP developers.

I still find it an eyesore to read, but everyone is free to use their preferred languages. Stuff like this article shows that good software can be created in any language if there's the will.

Even in brainfuck (I assume).


This is a quibble but reminiscent of the kinds of inconsistency PHP programmers are known for:

$value = $object->property ?? 'fallback if null';

$value = $array['foo'] ?? "fallback if key doesn't exists";


I do not understand, both of the expressions on the left-hand side are NULL, which looks like ?? is doing the same thing in both examples. A non-existent array key and a non-existent property on an object are logistically identical.


I was referring to the single-versus-double quotes.



is there another language that was written domain-specifically for building websites?


ColdFusion / CFML was essentially that. It started as a pretty simple tag language that made it very easy to implement basic web application logic. Its ambitions in the beginning did not go very far beyond building websites and connecting to a database.

ColdFusion was probably the only language of that era that was easier to learn than PHP.

https://en.wikipedia.org/wiki/ColdFusion_Markup_Language


Back when I was doing a lot with server-side rendering of HTML I made one: https://brl.codesimply.net/

These days I generally make SPAs. I occasionally think of reviving BRL but don't have any plans.


VBScript, for doing ASP web sites, scripting COM libraries in the process.


javascript?


No, that was written for client side DOM manipulation. Only.


like rgj says its first class citizens are document and window, not fetching data and outputting html/whatever . Perl comes to mind as another string-manipulation-heavy language.


Does PHP have the ability to be run as a WSGI script yet?


What would the benefit be? (I don't know WSCGI that well)


Nice overview.

I like how it seems like PHP has a lot bigger built-in standard library compared to Node, as some people install NPM packages for little simple things. Then PHP has a built-in time and date helpers, like timezones.

However, the $ dollar sign for variables kinda annoys me, as switching back and forth between PHP and other languages like JS. Like recently ran into an issue where I forget $ in front of a var and JSON encoding it, and then went to var_dump it but realized I forgot the $ so it was outputting the variable name instead of the variable contents. I guess muscle memory.

I know I was reading a blog post though where someone built a React frontend around Wordpress as a headless CMS, thought that was interesting but haven't looked into how to do it yet 100% but was proposing it to someone I know that has a large site built around WP but seems like a mess of plugins and theme tweaks so I felt moved to something else would let controlling the design and changing things without forking plugins when there are tweaks wanted that isn't part of the official plugin, etc as I feel like that would allow more complete control of the presentation layer without tweaking multiple things and stuff. However some businesses don't really care about the tech under the hood, they just want it done quick with results, don't really understand all the technical stuff and care about costs, so not like a tech startup where you care about a lot of the little details or maintaining things for the future. Then some people don't even really know what they want either, but I guess business people managing tech people, but even big tech companies I doubt all of their CEOs are even technical either though but maybe they hire technical project managers to help bridge the gap between the two parts of the business but their product is mostly tech though anyways so I assume a different culture than tech in a non tech business.

Looks like some projects to do server-side react with PHP too, but haven't played with any personally - but that's useful if someone cares a lot about SEO even though Google can crawl SPA's but other search engines might not be as capable, then sharing on social media not sure if they use server-side rendering when grabbing the metadata for open graph for example. That'd be neat to pitch to non tech businesses who might just be running on a cPanel server and don't want to really invest in servers and managing them much yet, so mix both PHP and React would be prefect maybe for some types of companies, PHP and MySQL for the data part with a nice clean modern and fast react front end with near instant page loads.

Kinda interesting about support for web sockets and more async stuff in the future, I guess in theory than you could write real-time game servers in PHP for example? I know some game servers are in C, C#, C++ or Node though, but long-running PHP code would be useful for other types of applications that aren't just mainly restful web pages or APIs.

Then another thing is you might find examples or libs in PHP but have to dig for equivalents in other languages, probably since PHP is so popular and easier to get into maybe. Then somethings you'd find a good lib in Python like I was looking at something and didn't see an official JS client but they offered a C, Go and Python one... Would be neat if somehow you could easily just combine the languages, I seen there is a Node PY bridge though and sounds like some experiments of compiling PHP to WASM but haven't played with it(wondering if it compiles only the code you wrote(I guess perfect for code you happen to strongly type) or the entire PHP binary along with it, but I know FB was working on compiling PHP to C with the HACK project, so a similar idea might work for WASM but not sure if it's a sane idea - maybe just porting the code you need would be a better answer maybe... but that'd be an interesting way to develop, but I guess with microservices you could mix and match too but some little tiny things seems a waste with all the networking calls.


[flagged]


Why exactly bother with anything else than PHP?


PHP isn't an application server. It's tightly coupled to the request/response cycle. There are things you can do to sorta get a longer running environment but for the most part you are loading and tearing down everything for every single request.

Contrast this to Python, Ruby, Node, Go, really any other platform where you tend to model applications with an application server that is long running. In a scenario like this, your application is running all the time and doesn't boot up on every request.


For that matter MS Asp Classic works fine too which is my favorite.


I can only offer my reason: I don't know it.


Why bother eating anything except cold gruel?


My understanding is almost all PHP dev is done because it’s improving a legacy system or it’s integrating into a legacy system, or the first engineer could just move faster in PHP because of personal reasons.


I'm mostly Frontend developer recently so I haven't been much up to date with Backend technologies. If I need a CMS for my frontend, what technology(-ies) can I use?


I'd go with Ruby on Rails if it's mostly CRUD operations. You'll be very quick to get something up and running to power your frontend.

You could also use some hosted services like https://firebase.google.com / https://www.contentful.com but that depends on your use case and if you want to be dependent on someone in return for being a bit faster.


You could use Wagtail (built on Django) in headless mode. Drupal also supports headless mode.


Hugo and Gatsby come to mind. They are based of tech like react, go, and graphQL.


Those aren't CMS...


Applications are open for YC Winter 2022

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

Search: