PHP in 2020
stitcher.io
stitcher.io
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.
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 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.
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?".
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.
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.
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.
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)
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.
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.
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.
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.
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.
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..
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.
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.
I'm being pedantic here, but technically it's still a C extension that most package managers install by default.
> 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.
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.
Care to post an example ?
You have the PHP business logic code as usual.
Then instead of doing
<a href="http://somewhere">A link</a>
function web_link($url, $title) {
echo "<a href="$url">$title</a>";
}
web_link("http://somewhere", "A link")
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.
I used it only for my web site, and many alternatives did not exist back when I did this.
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...
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, 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.
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
composer install
> 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 wasn't trying to debunk a claim that something is impossible.
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.
If they wanted something more specific, they should ask for what they really want.
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).
Have you reported them upstream? That implies a memory safety or garbage collection bug.
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.
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.
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.
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
Somebody built a photo editing app in JS which runs locally in your browser.
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
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.
Nobody would write a php app without js today and you can use js server side with nodejs, same as php and php fpm.
I ... didn't say that?
>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.
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.
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.
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 ;).
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.
Soooo...... How about Ruby on Rails?
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.
Which makes teaching it 10x harder. ( US seems to be outliner in that every student is on MacBook )
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.
"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.
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.
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).
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...
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.)
That sounds interesting, do you have a link to that paper? (I couldn't find it with a quick Google.)
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.
[1] https://en.wikipedia.org/wiki/Foreign_function_interface
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.
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.
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"...
(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.
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?
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...
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-...
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.
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.
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. :|
> 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.
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.
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.
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?
But this is the name of the game. More and more complexity. I am not sure how green engineers manage to learn everything. Woof
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.
https://github.com/api-platform/api-platform
I'm sure they had good reasons...or they just wanted to say hey, we're modern.
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).
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)
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.
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 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.
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"!
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.
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
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.)
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 :)
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.
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.
How popular is the functional paradigm for The Web?
(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 )
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.
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.
The PHP community's track record on security is abysmal compared to all those other environments that don't throw away the world.
I can have a car with super safe airbags, that does horrible in crash tests. That doesn’t make those airbags bad.
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.
Have you measured the overhead and impact on performance compared to other development stacks?
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 ;)
pm2 with ts-node is the best I can achieve so far but not fast enough not to hold for a second.
Everything else as an autoreload of some sort, so you don't have to think about it while developing.
I did a talk about this a few years back: https://www.youtube.com/watch?v=bl8jQ2wRh6k
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.
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.
Not exactly sure what exactly is specifically wrong with npm, have you tried yarn?
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.
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.
>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.
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.
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.
Which PHP ORMs are you thinking of? I've worked with Doctrine ORM, I would not say it's more painful than SQLAlchemy.
I can't think of any ORM that makes MySQL a hard depedency. Doctrine, EasyDB, Atlas ORM, ... all support Postgres or any other DB.
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.
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 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.
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.
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.
> “There was nothing wrong with the PHP 5 language specification. The problem with PHP is PHP Group.”
Lists all loaded configuration as well as extensions and their configuration. Basically everything about the runtime environment your in.
Beginner level stuff.
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.
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 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).
$value = $object->property ?? 'fallback if null';
$value = $array['foo'] ?? "fallback if key doesn't exists";
PHP in 2019: https://news.ycombinator.com/item?id=19917655
ColdFusion was probably the only language of that era that was easier to learn than PHP.
These days I generally make SPAs. I occasionally think of reviving BRL but don't have any plans.
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.
I self taught myself PHP almost 15 years ago, and I've completely developed over the years, from the ground up and from scratch by my self, a complete network of businesses: RadioReference.com and Broadcastify, that does
Public and Private APIs in SOAP, JSON and XML. Complete user authentication and session for millions of users. Integration with third-party best of breed apps like MediaWiki and Xenforo. Database, Ticketing, Location, Admin, User, Payments management. Provisioning, Scripting, Web Services consumption etc
The code is ugly, barely any OOP except for some reusable internal classes. Tons of copy paste from Stackoverflow. I'm still using mysql_query() in a lot of places. Did we hit some security issues, sure!
But it works, it generates millions of dollars in revenue, and it's all managed and developed by one person.
So, to all the PHP haters out there. See above.
You can build a house out of kindling coated in gasoline too.
Doesn't mean it's a good idea.
The objective is to build a business, generate value and execute on a vision using a programming language, not win a popularity contest by proclaiming your use of anonymous classes, unicode codepoint escape syntax, and the spaceship operator.
I'm doing some really cool things in PHP, and some really ancient things as well. Who cares? The business is killing it, delivering some of the latest and great technologies to end users. That's all that matters.
And no, I'm not advocating for using the latest and greatest just for bragging rights. There is a middle ground.
> "Who cares? The business is killing it"
What happens when you want to sell the business, or the sole developer of this monstrous codebase becomes ill? Based on the picture you've painted of it, a good developer won't want to touch it with a ten foot pole.
Anyhow, I am very glad for your success. It does sound like an interesting story. Just don't be surprised to see a negative reaction from a community of professional developers when you brag about how poorly written (and vulnerable to attack) your "million" dollar application is.
I can only hope that you aren't operating anything that other businesses rely on, or worse — handles personal data.
Lol the same can be said for any website written in plain-js+jquery, or C++
"PHP is a great programming language because of feature X, principle Y. It's not like old PHP because of 1,2,3..."
or
"PHP is a great programming language because I made a lot of money"