I still love PHP and JavaScript
the.scapegoat.dev
the.scapegoat.dev
- it's stateless by design (much easier to scale)
- it was "serverless" before Serverless
- surprisingly performant
- no "unknown unknowns". it's so tried-and-true, there's no surprises
- deployment is so simple, just drop a file on a web server. No middleware needed.
- No long compile times because there is no compiling needed.
EDIT: why the downvotes? If you don't agree, just reply so we can have a healthy dialogue.
EDIT2: I also think there is something unique about PHP documentation. It has plenty of real life examples, and the ability for users to leave comments allows you to hear directly from others "gotchas" that people have experienced. I feel like PHP documentation is very undervalued.
If you're using something other than cgi to get your httpd to talk to your webapp, your answer lies in understanding the architectural decisions of that tool.
> - no "unknown unknowns". it's so tired and true, there's no surprises
(I do like modern PHP well enough.)
This part is laughable. People who have been programming PHP for 20 years (several of them at my company) still routinely discover hidden bugs, quirks or general behavior that is totally unintuitive and nowhere found in the documentation.
i suppose it's fitting for a web-centric language to crowd source its docs on a website, but does any other mainstream language do this?
Much more frequently I’m looking up something related to the tools and libraries I’m using.
The only surprising thing I’ve learned about PHP at the language level in the last 6-10 months is that you can call array_filter() without a callback to cull nulls.
It's mostly things like parameter order for certain built-ins that aren't intuitive and/or finding built-ins I've never used or heard of because there are so many obscure ones (there are nearly six thousand) that keep me coming back. For example, how do you disable errors in a DOMDocument? It ought to be as easy as DOMDocument->setAttribute("errors", "false"), but no it's a separate function call to libxml_use_internal_errors(true). There are like five other similar function calls for this too. PHP has abstraction leaks and little inconsistencies like this everywhere.
Granted, languages with small standard libraries, like JavaScript, by contrast get an easy cop out to blame the community of various package maintainers here. But at least in that case someone can always just write a better library.
(a) you're a true, deep expert who uses the language all day every day
(b) the docs are so poor it's not even worth having them open
I’m also willing to grant implicitly that there are tradeoffs here. Languages with small standard libraries usually have big community libraries and vice/versa.
I've only used Go sparingly - I heavily relied on docs, but yeah it may have a shallow learning curve. It's certainly much saner than Python (which seems to be the other language used in my "space" for e.g. ad hoc ops tooling, etc.)
All the above said, do enough real work in any language and you'll find cases where the idioms of the language don't map to your work.
Of course I’m speaking succintly above. It’s not that bad, but it’s not that much better either. I’m not going to stockholm myself into using a language just because it’s “mature” if I don’t have to. I may have that relationship with JavaScript but at least in that case resistance is somewhat futile and there are practical benefits to be had.
A classic boiled frog statement.
__It's not undocumented, someone posted a comment about that bug...__
I will quietly place my face in my hands and weep to the memory of php coding I did 20 years ago.
Seems the same nonsensical masochism is still going strong.
I remember no discernible border between 'official docs stop here' and 'user contributed opinions start here'.
I do agree with the sentiment though that these unofficial notes should be taken with a grain of salt. In my experience, they have been more help than hindrance.
You should revisit the language. PHP7 was a huge leap forward. It's a different language now.
Need to do something new in Node? Sift through a bunch of search engine spam, read a few dissenting answers on stackoverflow that refer to a previous version, eventually find a library that does what you want, written by skullM4ster2004, plug one's nose and install it.
If you never upgrade, sure. PHP 7 and each minor version in it have deprecated and removed plenty of stuff that was legal in 5.6. PHP 8 is on track to do more of the same. I think the backwards incompatible changes are pretty much all good for the language, but claiming backwards compatibility in PHP is completely wrong.
If you aren't on PHP 8, you aren't supported, and if you're on anything earlier than 7.4, you aren't getting security releases. And the new versions released yearly all have breaking changes, and get three years of security support. It's not 2015 anymore.
Which is more important really? I genuinely don't know the answer to this.
Labeling these things as "gotchas" doesn't make them predictable imo.
If predictability means to predict, that standard library will behave nonsensically, then yes, PHP has the one high predictability.
Oh, so you _haven't_ used any of the recent versions of PHP, then. You're just talking shit with no actual recent experience. Gotcha. Well, thanks for your input.
docker run -it php:8.0 bash
# php -a
Interactive shell
substr("abcdef", 3);
// no result
php > echo substr("", 3);
php > echo substr(null, 3);
php > echo substr("abcdef", 3);
def
EDIT: Of course the docs also do not mention this to happen at all and tell you, that the first argument must be a string. So I guess that means, that in PHP terms, null is a string. Great for type safety!
https://wiki.php.net/rfc/engine_warnings
https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_a...
If you choose Hack, you lose the entire PHP ecosystem (composer) that could back you up and save you time. The only ones really using it are Facebook/Meta, so it would be a mistake to choose it for a new project, IMO. It doesn't really have a future.
The anti-PHP cult is strong here on HN. List 5 benefits of React and watch your upvotes skyrocket.
I always have a hard time understanding what exactly is meant with comments like these. We can all agree that PHP has a wildly uneven standard library, had its fair share of security-relevant footguns, tends to have unexperienced developers. That's not extremely different from python and node.js, for example.
The language significantly cleaned up its act, it has had classes, traits, closures, introspection, namespaces, packages for well over 10 years now, a robust third party library ecosystem and many successful projects to build upon (wordpress, drupal, woocommerce, phpbb, etc...). This makes it a pretty good choice for many applications.
The stateless model and the resulting "no crazy stuff" approach makes it a much more reasonable choice for web development than say, python+django or ruby+rails to me. There's nothing I loathe more than trying to find which duck-typing, method-injecting package is causing a slow-burn memory leak in production.
I also don't understand where the "most web technology is terrible" stance comes from. I find the quality of software engineering and the care put into developer UX and productivity in the web world quite inspiring. It has been a forcing function on all programmer tooling since the cambrian explosion in the earlier 2010s.
Then comes the shiny new car - it has way too many gadgets and gizmos, you don't know how most of them work. Heck, you don't even know what half these gadgets are for. You don't know when or how it will break. But most importantly, you don't know how to fix something when it breaks, because there is too much magic going on. High maintenance, constant stress.
The first case is PHP. People can dunk on it all day, every day. But it is good enough for most projects. And with tools like Laravel, Composer etc, PHP is constantly improving too.
The latter? I dunno, there are lots of candidates for it I suppose.
These days most organizations will not tolerate just copying files over. There will be a process for testing the code and then stuff will probably be put in a container, to be even easier to run on another server.
At that point the advantage of just sftp-ing files over disappears. It is no longer deemed safe enough to do so. Usually it is not the end of the world, if your website is down for a minute, but it does tarnish the public image of reliability, so organizations are not willing to put up with developers making a typo somewhere bringing down their website or causing at least an annoying error on the website.
Instead of copying files over to another server, you would typically do some docker pull or other container engine pull some image or what have you. Then you would run that previously tested thing on the server.
There is a whole range of projects like that out in the wild, once you leave the realms of startups and big tech.
It's about as easy to do "proper" deployment using bundles / containers / CICD / kubernetes / gitops with PHP as with any other stack. It's also possible to click a wordpress domain for $10/month and upload 2 php files and start making revenue.
For a small business that is starting up, choosing between $10k of freelance work to get a nice github actions workflow on GKE + a monthly retainer of $2k for "maintenance" vs a one time $1k of freelance work to get a wordpress where you can configure the plugins and theme yourself is a no brainer. Many of those small business then grow much larger and reach a point where in hindsight you can say "should have gone with docker containers". But the original decision was not just perfectly valid, but probably the only reasonable one.
I've always been a fan of PHP too; it was my first programming language that I used to build a shipping application, but saying there are 'no unknown unknowns' in a language as quirky and old as PHP is akin to denying the sky is blue.
PHP 4 + 5 had so many weird quirks, and they lasted a long time because PHP 7 took so long to ship (note there was no PHP 6). When 7 hit, they followed it up with many minor releases to try deprecating/removing/correcting some of those quirks, which itself introduced more unknowns when refactoring legacy code. Suddenly the quirks you were used to for so long were now gone or behaving differently (or more sensibly at least), but this required even more refactoring to account for.
When a language is always changing or evolving you can never know in advance with certainty how new features or changes will change how existing code will work.
https://www.brightball.com/articles/no-such-thing-as-real-pr...
(Old article with a lot of dead links now, just FYI).
In this case PHP is unexpectedly rounding floats for display.
~ python3
Python 3.9.13 (main, May 24 2022, 21:28:44)
[Clang 13.0.0 (clang-1300.0.29.30)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> b = 46333.48000000001
>>> b
46333.48000000001
~ php -a
Interactive shell
php > $b = 46333.48000000001;
php > echo $b;
46333.48There are better examples of PHP being bad.
According to the Twitter thread:
> First value was retrieved from a db, second was calculated, which has introduced rounding errors.
I think downvote = disagree is expected. If someone thinks your comment is not making valid points, downvoting is a way to bury it below other comments.
So that, naturally, the comments that the community most agrees with (in addition to adding quality content) bubbles to the top.
I noticed being stateless made it difficult to scale for any complex app. It’s been 7-10 years since I used it but Drupal used 60-128MB+ plus per request. As it was stateless it had to do a full bootstrap for every request coming in, set up a new database connection, module discovery etc, all which was heavy to do for every request. Most people scaled Drupal by putting Varnish in front preventing the origin from being hit so not really scaling Drupal as such, varnish is taking off some load where it can.
Drupal is probably the extreme though. If you have a simple app with a few scripts, light use of a DB it’s not to bad. I’ve heard it’s come on a lot in the past 10 years and Laravel. I certainly had less issues using PHP than I do with JavaScript.
Then, for app performance:
My approach is to usually design the app / refactor the app so static content can be fully cached. In ecommerce sites this can make an absolutely impressive difference. Then, leverage opcache and object cache and further separate cacheable path from dynamic path in dynamic SSR queries. Always drive using APM performance metrics as a guide. No need to optimize the DELETE /user endpoint called twice a week.
Then, identify the heavy hitters in the dynamic DB queries, and basically write those in hand rolled SQL. It usually boils down to 4 or 5 queries doing 99% of the work (GET /posts, GET /categories, GET /products, etc...). I do this fairly late in the game, but think about it very hard up front. I like to use some kind of ORM for everything writing to the DB, and sql builders / pure SQL for reading.
The split between cacheable / non-cacheable can be subtle depending on the application, and might require some non-obvious structures in the codebase.
For real tricky performance issues (not something I had to do in PHP projects), I will either ducttape some AWS infrastructure or handroll a microservice in C++ or golang. This is something I had to do for realtime / transient loads.
It doesn't make scaling hard, it makes scaling very easy because you can just horizontally scale out as many instances as you need. The constant factor is pretty awful, but that's the tradeoff you make for statelessness.
In practice it makes scaling hard for financial reasons if you require 128MB+ per request. A 32GB server will struggle with more than 256 concurrent requests at 128MB+ per request. A 32GB server is an extremely large server for such low request numbers.
If you can bring the memory usage down stateless works well. I use a bit of rust on aws lambda with the lowest memory settings so pay fractions of a cent and can handle more traffic than I ever need. I do set up persistent connection pools for the life of the lambda and only bootstrap once to bring down latency per-request but treat it as an ephemeral horizontal scaled service.
With that said, I think the stateless nature of php is talked up too much.
While not enforced by the nature of the language like php, writing stateless apps in other languages comes quite naturally.
Scaling difficulties are almost always to do with the database solution rather than the app, and overcoming those problems has little to do with the choice of language.
I of course value at least partial "stateless" (functional core / hexagonal architecture, event driven architecture) in any language, because they reduce complexity so much.
In Laravel it's not too hard to avoid this problem but a lot of noobs don't get the lazy / eager loading thing and then you end up like this.
Drupal seems to add hundreds of queries for every module you add.
I do think very hard up front what the product will require in terms of: - static content - dynamic content that is cacheable and which keys can be used to cache it
Static content can use ORM as much as it wants, cloudfront will take care of it. dynamic content that is rarely hit doesn't really need much help either if there are no UX latency requirements. dynamic content that is hit very often (usually only a couple of endpoints) can be rewritten into manual SQL.
If you think about it, most page hits with dynamic content can be rendered basically by the DB + templating engine, and no other logic should be involved.
- worst way to do templating
- weird mental model of putting all logic and templating in one file
That's up to you though. You're welcome to put all your logic in one file and your templating in some other file.
Not just as easy if they don't allow you to insert arbitrary code at arbitrary points as PHP does.
Personally my preferred approach is Wicket where you can't have any logic in your markup at all, all of your logic lives in code and the only thing you can put in the template is IDs for where the code can insert child components or plain text. (OK, it's not quite that strict, but it gets pretty close in practice).
> at some point it boils down to the programmer's level of expertise, but also to the programmers' opinions as there are still a lot of varying opinions on what exactly are best practices.
That's neither here nor there; "programmer's level of expertise" is just abdicating responsibility, when in fact a programmer at the same level of expertise might produce much better code in one language than another.
By using Wicket you are making a choice to opt in to a template system that encourages best practices. This is the same reason people in the PHP ecosystem opt in to Twig/Blade/Mustache, or how people on Ruby opt out of ERB for Slim or Haml.
Also, to be frank, it's a real shame that people look down their noses at PHP so much just because of the sheer amount there is that can be learned about the practical application of design patterns from spending some time in the Laravel code base.
PHP has had solutions from the beginning or at least early times.
PHP lacked that cult figurehead and was always community based. Most new languages are corporate sourced (open source by corporations).
I think the "the more things change, the more they stay the same" is a great thing, and something to very much be aware of and study. The move back and forth from backend state to frontend state to slim apps to fat apps has been going on since the 60ies, and is driven by ultimately hardware and networking costs.
The underlying patterns are all fairly well understood, which means that knowing both approaches and being aware that things are going to slosh back and forth heavily simplify long term design.
I haven't written these thoughts out, but in many ways the codebase (as in, how your files are organized) is largely independent of how your code is actually deployed and where it runs. If you are aware that some business logic might one day run in the frontend on the client device, and 4 years later might make more sense ot run in a lambda, that's something you can architect for.
Serverless / stateless is ultimately "functional programming". If you write your code as a side-effect free function, leveraging technologies like WASM, you can keep the same code, and deploy it frontend or backend or both or as a lambda or as a single node worker, and the code itself won't change. These are the things that next.js and vercel and edge computation leverage, but it is true in every codebase (embedded, desktop applications, etc...).
Back in the day PHP got big because most of the larger shared-hosting sites provided mod_php out of the box, along with MySQL.
If you wanted to run CGI scripts you were probably capable of doing that, whether in Perl or something else, but most of the other options came later or were unusual.
I know when I tried to setup a few sites a long long time in the past I had to get a VPS of my own, with root, to configure Apache appropriately. None of the shared hosting sites would have run the kind mods I wanted to have.
Edit: Not sure why this is controversial. Here is a "hello world" benchmark I just ran on my machine, in units of hello worlds per second: Perl – 1020 runs/second; Python – 78 runs/second; Ruby – 30 runs/second.
Drop a file on a server, it notices filesystem change, reloads an app (or spawns a second copy of app, waits for it to initialize, kills original app and switches over to a new one)?
One problem with this approach is what happens when you're updating multiple files. If the server restarts immediately on the first change, you end up loading a mix of old and new files, which probably won't work properly. But if you delay the restart to wait for all the files, how long do you wait? If the delay is too long it's confusing and annoying (did the server restart yet?) and if it's too short you get mixed versions as before.
So it's better to explicitly signal when it's time to restart. You can still have automatic restarts in the development environment.
[1] https://docs.gunicorn.org/en/stable/settings.html#reload
Ex. First even triggers a 5 seconds wait. If before those 5 seconds have passed there is another trigger (say after 1 second) another 5 seconds wait starts, for a total of 6 seconds in this example.
In the most primitive ways, you would at least do cache warming, which usually means "building" the app instance in a separate folder and swapping the active directory served by the web server. That's basically what a basic Capistrano deploy would do.
Nowadays I'd expect most shops to be using containers for PHP too, and that means building your container like any other language.
What I'm saying is, the days where PHP deployment was simple have been long gone, for at least a decade in my experience.
PHP is documentation done right because of the comments, essentially "Stack Overflow" for PHP before stackoverflow.com was a thing.
I've found an example of documentation done wrong recently with Microsoft .NET 6.0. Apparently, Microsoft has decided that code samples are no longer important
It's funny really, for a programming language to rely on comments made by random people, instead of having those aspects covered in the documentation itself. Shows a bit of lack of care. It seems half-assed as many things in the ecosystem seem. What happens, if they ever lose that database of comments? The whole world scratches their heads wondering how to use standard library functions? Ridiculous. I hope they have good backups.
> I've found an example of documentation done wrong recently with Microsoft .NET 6.0. Apparently, Microsoft has decided that code samples are no longer important
And for as long as important documentation resides in comments in PHP docs, the same can happen to PHP docs. Lets say they push out PHP 9 and some things change. Someone thinks "Ah those comments are not actually true any longer. Lets get rid of them." Bam, massive resource lost, because the knowledge has not been integrated into the documentation.
Assuming they backup the website, how's it going to get lost?
I had one web host where magic_quotes_gpc was enabled. Good luck figuring out what the hell is going on with all these extra quotes in your variables.
And I kept looking up how to do prepared SQL statements in PHP, finding the mysqli functions, and then eventually figuring out that mysqli wasn’t available on your average web host with PHP back then.
(Yes it was that long ago. I also think a lot of the hate comes from that era)
I remember the documentation as well, with usually all the gotchas in the comments. Which is great, but there were a lot of gotchas. like, A LOT.
In any case, I definitely agree with all those pros. What I dislike about PHP is that as you start growing a codebase, especially with includes, your attack surface just grows and grows and grows. In other frameworks where a stack is involved attack surface generally grows as well, but since any PHP script has access to the request, it's much much worse.
> - it's stateless by design (much easier to scale)
I'll grant you this one. Though PHP in practice goes to great lengths to add state back in for performance reasons (e.g. memcached, or for a while APC).
And Haskell is stateless, too, yet not a frequent choice for web work.
> - it was "serverless" before Serverless
This is retconning. It was never trivial to set up a LAMP stack, especially at scale. I can't tell you how many times I've seen the PHP "too many open database connections" error because someone just treated their Wordpress blog as "serverless" and it went to the top of HN.
> - surprisingly performant
I can't speak about the latest stuff, but PHP5 in ~2014-15 was abominably slow. There were certain "benchmarks" which indicated it was fast, but on closer inspection, these were simply calls where PHP provided thin wrappers around C calls.
I had to once take an Excel file, parse it and then present certain fields to the user for the DB to be updated. This was possible in PHP, but it took excruciatingly long (like 8 minutes - in fact, sometimes Apache would just drop the connection), and third party library support was just awful. I implemented the same task in Python, and not only was the code much simpler and and easier to write, but the task took a second or two each time.
> - no "unknown unknowns". it's so tried-and-true, there's no surprises
The standard library is a toxic sludge of surprises. Nothing is consistent. "Will this function treat an array like a list or a dict? Who knows?"
Maybe this is better now, but the last time I dabbled in PHP, I spent a while trying to get a workable debugger set up and gave up. Stepping through code is apparently impossible, and every now and then you hit some fatal error that immediately crashes your code.
> - deployment is so simple, just drop a file on a web server. No middleware needed.
What does this mean?
First, PHP has middleware (e.g. memcached, Apache/Nginx).
Second, the complexity of deploying a Python, Node, Rust, Go or Ruby application is not the "middleware." The complexity is ensuring that the update is correct, the update is applied consistently, can be rolled back, doesn't cause downtime, etc. I could also do updates by running webpack dev server in prod and dropping files in there for deployment. As easy as PHP, yet a terrible idea.
> - No long compile times because there is no compiling needed.
This is odd to say the least. PHP's biggest weakness IMO is that each thread must entirely parse and interpret its executing program on every single call. That is a ton of wasted work, and there are literally sections in the PHP docs about tools to circumvent this problem.[0] And the solutions involve caching, which mean we give up (1) the "stateless" benefit and (2) the "just drop in a file" benefit, or else we need to add a bunch of cache coherence logic. It would be so much easier if someone could compile the PHP code to a bytecode format and drop _that_ in, which could just start executing on an interpreter ASAP.
Ultimately, I think the list is getting downvoted because it deviates so much from developers' experience with PHP. PHP started out as a sub-Turing templating tool that had a Perlish language bolted on, which then mutated to look a lot like Java. Eevee's classic blog rant[1] calls it a "fractal of bad design," but the reality is PHP has no design: it's just a kludge of duct tape and bolts.
Also, maybe this is totally incorrect now with PHP6--er PHP7 and PHP8. But my experience with PHP4 and PHP5 was so horrific that I will not be working with it again. I've yet to find a PHP use case that is not better solved with a combination of a static site generator and something like AWS Lambdas or Cloudflare Workers.
[0] https://www.php.net/manual/en/book.opcache.php
[1] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
Install opcache, done. No need for hyperbole.
Do you ever run into race conditions? And how does it handle cache coherency?
I don't understand the purpose of your post.
Do you judge all languages according to your experience from 8 years ago?
Do you go on python boards telling everyone how much you hate working with python 2.7?
Maybe spend your afternoon on rust threads to complain about it not being available to the public yet?
Do you need to like a language for 8 entire years before letting anyone know about it, or just some time within the past 8 years?
GGP was wondering why there were downvotes rather than comments detailing disagreements.
I decided to write down the reasons why I personally would not touch PHP again rather than give a downvote.
Maybe PHP8 or PHP7 or whatever it is (I know they skipped 6?) is awesome, but I've moved on.
Also, FWIW, a few of my objections are certainly still relevant based on the claims in GGP's post and some cursory review of the documentation, particularly around caching & in particular op caching.
> Do you judge all languages according to your experience from 8 years ago?
No, only ones that left mental-emotional scar tissue.
> Do you go on python boards telling everyone how much you hate working with python 2.7?
Python 2.7 was highly pleasant. I wouldn't use it now, but it didn't abuse me. :)
> Maybe spend your afternoon on rust threads to complain about it not being available to the public yet?
GGP: <X> is awesome for these reasons!
GGP: HEY! Why are people downvoting rather than commenting?
GP (me): Here's why your reasons don't persuade me based on my admittedly outdated experience
P: Why are you so critical?
> Do you need to like a language for 8 entire years before letting anyone know about it, or just some time within the past 8 years?
Non sequitur. But the answer is no.
Perhaps it might be more productive if someone commented which of my claims are obsolete rather than ad hominem them. I know that those relating to compilation, deployment & statelessness are still valid, given GGP's comments and my cursory examination of the PHP docs, plus experience with other platforms.
Maybe modern PHP has truly excellent performance. Maybe using a breakpoint debugger has been solved now. Maybe design is better, e.g. the standard lib has functions that can work with arrays as lists and arrays as dicts without being surprising (e.g., `filter()` used to preserve all indexes, since it treated arrays as dicts from numbers to values; often, you needed to use fold/reduce or a loop to re-number after a filter).
As a counterpoint, I used PHP5 when writing https://www.goldeneaglecoin.com/ and it was always < 50 ms on my endpoints, running on some crusty hosted celeron at the time. Adding caching and opcache doesn't invalidate the stateless approach.
Programming is about adding abstractions on top of underlying computational substrates. Ultimately our CPUs don't care if we run haskell or PHP, they just run machine instructions. I never found it too complicated to use useful abstractions in PHP.
I usually prefer inheriting a subperforming cache-free PHP site, because devising a consistent cache strategy is usually not too hard (cache static content + opcodes on deploy, determine which invalidation keys you need for the subset of dynamic content that does the bulk of the load / has latency requirement, don't cache the rest). If I have a big collection of lose php files, that's reasonably easy to do. If i have a tangled web of middlewares and ORM'd business logic, it's much harder, and I usually have to unfold it to "lose leaves".
> Adding caching and opcache doesn't invalidate the stateless approach.
> Programming is about adding abstractions on top of underlying computational substrates. Ultimately our CPUs don't care if we run haskell or PHP, they just run machine instructions. I never found it too complicated to use useful abstractions in PHP.
I'll push back a little on these. TL;DR: it's a trade-off.
My point with Haskell is that the entire language itself is stateless, so if per-request statelessness ("shared nothing") in PHP is a virtue, then certainly total statelessness ("purity") in Haskell is even more of a virtue. The problem is that, despite having similar performance to PHP, Haskell is hard to write.
This is illustrated with caches: if a PHP program had a line something like `if ($cache.retrieve('foo') != null) { echo "Success!<br />"; } else { echo "it's broken"; }`, then now global state matters again.
Haskell doesn't allow code of this form, but forces you to think harder about how to make it work using e.g. monads, and this can be frustrating. But if you can get Haskell to work, you can get caching nearly for free.
function get_all_products() {
return cached(function () { return Sql::Select(PRODUCT_TABLE); }, Cache::GetSessionCacheKey());
}
render_template(Page::GetTemplate(),
[ "products" => get_all_products(),
"user" => get_user_data()
]);
/*
* @url: /products
* @cache: session(1h)
*/
function get_products() {
return Sql::Select(PRODUCT_TABLE);
}
render_template(HTTP::GET("/templates/products"), HTTP::GET("/products");
GET("/products").then((products) => render_template("/templates/products", products))
I wrote this code 12 years ago, and porting to react doesn't require any change on the server side. We just put RTK-Query in front and let it do all the rest.
I agree that the comments should be removed or at least hidden by default as they're usually not relevant anymore.
That's sort of true, but the default state mechanism (session files) doesn't scale well, or even work across load balancers that don't maintain server affinity for each client. Scaling a PHP app isn't hard, but it can be non-trivial if you've written the code without considering scaling. Other serverside scripting languages (Python, Ruby with Rails) nudge you in the right direction in ways that PHP doesn't.
This is perhaps one of the better things about it! It feels like lots of different languages and frameworks would benefit from comments at the bottom of the page, from the community, explaining various common use cases and gotchas.
Somehow it feels like docs being on GitHub with people being able to contribute to them there somehow can have higher friction, versus a forum-like system.
The killer feature of PHP has always been the hosting ecosystem. A simple FTP upload would do the job without knowing much about the hosting infrastructure. Recently we've got that kind of "serveless" experience for other languages as well but the deploying is proprietary and the providers are very few. I'm aware only of Google Cloud Run.
As for JavaScript even its inventor said it's time to move on. It's time for a new language and a new DOM interface. Maybe we can fix the "language" issue with WASM but we are still left with the DOM.
I hadn't seen that quote, do you have a link?
Facebook manages quite well with PHP. Maybe it's your fault you didn't learn how to use modern PHP practices which have been well-documented for over a decade now.
Sources?
I didn't say you can't make it work. You can build great stuff using just bash scripts. I'm pretty sure you can have success with any programming language. That doesn't mean it's the "best" way to do it.
>> Maybe it's your fault you didn't learn how to use modern PHP practices which have been well-documented for over a decade now
I doubt it's my fault. I'm not "special". I think PHP is prone to bugs and bad practices both due language design and bad documentation.
Not in 2022. I avoided PHP for a long time. I got back to it and found that the Internet and books are full of best practices and I have not had an issue with documentation either. Would you please give me an example of how PHP is more prone to bugs vs. other languages in this area? I have found it to be really difficult to write buggy and insecure code. For example if you have not heard of PDO and you do not prepare, bindValue/bindParam, and then execute, that is your fault (make use of filter_input() as well!). It is advised literally everywhere today. Regardless, my return to PHP was pleasantly surprising. I finished my project pretty quickly and I have not used any frameworks. Security vulnerabilities? Perhaps, but so far so good. We will see. I tried my best and I have done my research. Every time I mention that it is written in PHP, people frown because they are stuck at PHP 5 or so. That said, subpar defaults in php.ini is still a thing though.
"By design" PHP encourages very very stateful procedural programming. It is one of the languages, where making things not mutate state seems like a mostly unused strategy. The amount of beginner code people find online and that mindset of "if it works it works shrug" continues to keep bad code alive.
The thing that might be referred to here by "stateless" is that a PHP "application" runs the code from top to bottom, as if all was one long script. This primitive handling has its own issues of course, but I will admit, that sometimes it is useful, that you can change the code and do not need to restart PHP or anything, because you will get the new script executed when the next request comes in.
> - it was "serverless" before Serverless
Where "serverless" is just a buzzword. PHP runs on a server just like many other languages. You will need a machine acting as a server, you will need PHP installed, you will need some webserver, usually something like Apache or NGINX with fpm or some other shenanigan. Nothing really special there.
> - surprisingly performant
Which in part, I would claim, is due to its reckless way of handling types, introducing hidden bugs. The type system is quite underdeveloped and cannot give many guarantees. No generics, no general object type, which everything inherits from, but only an object type, which not every other object inherits from. Then that "mixed" type, which just makes things even more fuzzy in a signature of a procedure and encourages bad design again.
Of course, if you throw all safety overboard, then you can get a bit more speed. Not really impressive.
> - no "unknown unknowns". it's so tried-and-true, there's no surprises
I just recently looked at defining constants in PHP. But I could not see in the docs, what the scope of a constant is. Simply not to be found. I just had to try it and hope. This is often the case with PHP and its half-baked docs.
> - deployment is so simple, just drop a file on a web server. No middleware needed.
But the webserver is the middleware you need. Like mentioned above, some Apache you need to configure, or some NGINX, or some other server. Maybe you have only ever deployed on managed infrastructure and never done the actual full deployment? Always enjoyed other people setting things up for you? I guess this is true for most of the people claiming, that PHP deployment is simpler than in other languages.
> - No long compile times because there is no compiling needed.
That again comes at the cost of safety. PHP types if you declare them in the code are not checked at compile time, but only when the code runs, making them merely annotations to read for another person.
In the PHP world we have learned not much from the past decades of programming language design. It is understandable. Lots of people have build tons of almost breaking things on top of PHP's design flaws and would start a riot, if things ever changed. For the sake of backwards compatibility PHP will remain in its swamp of bad design choices.
Sure, people can try to build on top of that, abstracting from it all through more modern web frameworks, plastering over all of the flaws. Sooner or later though, you will need to use some actual PHP code in there somewhere and the bad design will rear its head again.
I do think people who react so viscerally negative to it in 2022 are only doing so from an old preconception and not judging it for what it is today. I build seriously large and complex applications and never once have I felt that I was fighting PHP or it was holding me back. I don't really get the hate.
I respect that some people accept dynamic typing as a better tradeoff for various reasons (I've worked with Ruby for many years before I discovered my love for type systems), but to me that statement reads similar to:
"No long CI builds because we skip all the tests."
:)
Compile-time type checking is a soundness proof of your program, which is an entirely different thing.
I am not a JS fan. This is not because I have anything against the language; it's just that I have no real need for it, and have treated it as a "necessary evil," in my frontend work, so I don't believe that I have much of a platform to lob spitballs at it.
PHP, on the other hand, is a language that I have used for over 20 years. I think it was 3 or 4, when I started. If I do backend work, these days, I'll be doing so, in PHP.
I always like looking at the "fishtank graph"[0]. That sort of puts things in perspective.
[0] https://w3techs.com/technologies/history_overview/programmin...
So I am sure some professionals write brillant code in php, particularly in large organisations, but my guess is that the median code base quality out there is probably pretty lousy. Anything below the 80th percentile probably too.
Also it’s for websites only.
One of the things I do like about PHP is that while most legacy codebases out there are lousy (even when good developers are involved), and often lousy for totally legitimate reasons, PHP with its "don't even try to do clever" approach makes many things easier.
Of course, I only dealt with so many legacy applications. My worst experiences have always been with python legacy code because there were strata of conflicting "better code" approaches piled on top of each other.
Once you start abstracting into patterns, and you don't have the experience needed to get a sense of good architecture, it's easy to make a real tangled mess.
I think it's the best documentation out there, and that part of the reason it's easy to document, is because the language uses a standard library, and functions, as opposed to the structure of the language, itself, to provide most of the utility. Functions are easy to document.
They do a good job of "cleaning out the cruft," as well, so that there isn't much in the way of "no longer applies" stuff.
Part of it, too, is that the language probably supports stuff all the way back to 4. They tend not to deprecate, and accrete, instead (not always a good thing). That means that examples and discussions maintain relevance, even years later.
One of the biggest issues that people tend to have with PHP, is that it allows you to write bad code.
I came from a C++ shop (another language that people love to hate). If you think you can write bad code in PHP, C++ says "Hold my beer."
I am a big believer in Discipline. With Discipline, we can write excellent, maintainable, code in any language. I have written stuff in Assembly, FORTRAN, Pascal, PL/1, Perl, Bash, BASIC, C, C++, ObjC, and Swift, that is quite well-structured, maintainable, and well-documented.
fun thing I also wanted to add a point about documentation but you did it yourself, life is fun sometimes :)
> A legacy codebase means that the product is performing well. It means that I can often make immediate and impactful improvements.
Wow. This person must have worked on very different legacy codebases than me.
Legacy Javascript code, to me, is something that I do not want to touch with a 10 foot pole, because every little piece of it can be intertwined with and used by many other hidden places. Plus, I've never found a legacy JS codebase that has a robust test suite, so any refactoring I do can be hard to test and verify.
From a practicality perspective, I get that the best programming language is the one you can use to build your product, but I tend to long for languages like C# or even Go when I'm trying to deliver a product on a team with 10+ people. Static typing really helps when you're interfacing with someone elses code, and Typescript only aids this point.
Maybe if your target audience is genuinely 10 year olds learning to code, fine. But also if you're building a serious product for a company, please don't choose a "Janky programming language" because I really don't want to have to debug it after you left before really thinking about sanitizing user input.
I feel like, in the hands of a really talented programmer, they can be super productive in PHP or Javascript or really anything. But I've just had a lot of bad experiences with quickly written, undocumented code.
Every legacy codebase I have worked with was actually a successful business. That probably plays a big role in why I enjoy working with them. The job is not easy, and in one case (800kLOC of PHP without a single function), I had to rewrite everything from scratch.
Legacy JS with its strata upon strata of framework du jour and jquery and porous language are indeed notoriously annoying. To be fair, I just isolate the legacy JS to its own little DOM sections, and then introduce a new framework in parallel until I can nuke the old code out.
Revamping a legacy JS codebase often comes with a design revamp as well, so it often becomes a matter of strangling [1] out the old API. I do really enjoy how typescript allows me to gradually introduce typing and leverage static analysis for more adventurous refactoring.
I use golang, rust and typescript as my daily drivers lately, but I must admit that my most horrendous legacy codebase experience was a tiny 20kLOC go program that was just a mess of concurrency nonsense. PHP codebases have a certain "flatten it out and don't be clever" style to them that make for easy strangling [1]. Highly abstracted codebases where the abstraction doesn't fit the use case anymore, or the abstraction was thoroughly eroded by generations of misinformed developers are much trickier.
What language I would use to greenfield a new application would depend highly on the experience of the team, but my usual approach is "whatever we are already using".
[1]: https://www.redhat.com/architect/pros-and-cons-strangler-arc....
This. Languages like Java and C# are great for teams and codebases starting to scale out. Hence their popularity in enterprise.
Wouldn't you just... make a test suite?
If you're so disconnected that you don't know the user's perspective or have no way to see the program in action, then ..best of luck!
Legacy code bases are more often that not huge monstrosities. Maybe you do start with some tests and increment, but there's no "just" involved.
I tried adding tests to a legacy AngularJS application (it was in the process of being phased out but was still business critical). I sunk days into trying to get a test to run, let alone pass, before giving up and deciding that eventual replacement was going to be quicker than finding good AngularJS documentation.
Not sure if sarcasm or serious.
Though, being optional, it creates its own problems that are time consuming. I have spent a fair amount of time trying to find the right versions of npm dependencies and accompanying @type/whatever packages that work together and aren't saddled with open vulnerabilities, etc.
Like 1.2.3 of xyz has issues (or dependencies with issues), and you need 1.2.4, but the @type package won't yet work with 1.2.4.
Also, not just vulnerabilities. Bugs, whatever.
and if they're actually using frameworks and libraries.. well that's just being a good programmer. if you don't know how it works, leave it alone and go rewrite a piece that doesn't require rewriting something core
Fast forward a few decades, and things look very different. Tons of web app backends being written in go, nodeJS/TS, and I recently learned people write them in rust+webasm. It's just crazy to me. I've worked on FOSS projects that are massively over-complicated because of their platform/language choice, when they would've been very straightforward php choices. But php still has this weird stigma about it despite most of the old concerns having been addressed.
I do have to say, though, that front end web development is way better than before with the advent of React and co, webpack, css libraries etc. Doing all that html/js/css by hand was always painful.
pretty much says it all.
let me finish building this shitty app by deadline, while you guys continue argue about which static type checking system is better.
Honestly, that sounds much more like a dev who is always chasing the new shiny, rather than a dev competent in a boring, stable old tech like php
They've each been running over a decade, and while there are some frustrations, it's not so bad. The biggest issue is lack of compatibility to migrate to later versions of the frameworks involved.
They perform adequately for their purposes. These are business applications that are not designed to scale to huge audiences, although one does aggregate ludicrous amounts of sensor data. Both codebases interact with a lot of external systems via APIs and/or batched data transfers. When it comes time to integrate with a new/different backend system, it's not difficult.
Could it all be implemented more elegantly in some other language? Sure. But in long-lived business tools, there's always an evolutionary process going on, and your pristine design from year two won't be useful with the changes they want in year seven. The ability to make fast changes is important.
Lastly, none of this would be possible without functional and unit tests. Those are probably more important than the languages used. They're a pain in the ass to maintain as the business uses and functionality evolves, but it allows the refactors that keep the codebases sane.
Agreed - I've used Yii in the past and it was just great.
For many other reasons, my languages of choice are mostly PHP, Perl, and JavaScript. And I have experienced the types of bugs that static typing (and also immutability) can help with.
What I have found extremely helpful is to write as if variables are immutable, not allowing myself to change them. And to do sanity checks in the beginning of every function which expects a certain type of value.
Perl's taint and strict are of great help, but I haven't thought of an easy way to port them to JS and PHP. So whenever I can, I do the heavy lifting in Perl, and then use PHP and JS as glue.
The main reasons I have chosen these three languages is their ubiquity and their committment to backwards compatibility. With all three, I can carefully write something reasonable 20 years ago and have it still run today. Sadly, I recently came across a GNU/Linux distribution without Perl, but it is rare. PHP is widely available anywhere with a web server, Perl is ubiquitous in modern (post-2000) *nix, and JavaScript can still be written in ways which work in Netscape 3.x and up.
I think if you want to write software which continues working without too much fuss, it's helpful to exploit the Lindy Effect to your advantage.
It misses that Good Software is cheap to maintain and can easily have features added.
This goal is hard to meet and there are lots of ways to get there. You can get there with PHP and JavaScript but both languages allow developers to create a mess. Don't get me wrong all languages allow developers to create a mess but these are on the end of the spectrum that requires more tooling to avoid a mess.
I'm a huge fan of strict typing. Because I make lots of stupid errors. Spelling mistakes in variables, that sort of thing. My brain seems to function well at the high level of problem solving but no so well at the details (you might be able to tell from my grammar). Strong typing helps me immensely. Many people don't have this struggle so would rather work with a language that doesn't require the same hoops to jump through. They can do it in manually, and it frustrates them to have to setup types that offer them no value. But for me, to build good software that is easy to maintain, I'll lean on the type system. It will help prevent my mistakes.
So I try to avoid JavaScript. It's more difficult for me to maintain than a strongly typed language. I love Typescript as it fills that gap for me.
PHP is not as bad as it's reputation but old poorly written PHP is. I once witnessed a developer come in an update a legacy code base such that it could be tested. I didn't understand why he spent months working on it. I didn't think it would pay off when there were so many important features to get out. His work completely turned that horrible mess into something maintainable.
I guess my point is that new languages are desirable as they can bring down the cost of maintenance. Some of my favorites are TypeScript and F#. TypeScript is a mainstream way to put the training wheels back on JavaScript and F# is like a dream to use. With Fable, FableRemoting and the Elmish architecture I love it for frontend. It's a hard sell because it's so niche but it's great.
Edit: After reading my comment I felt it was more negative than I'd intended. I liked the article and think the author makes good points, I was just adding my two cents.
I find "problematic PHP" much easier to untangle than say, "problematic node.js" or "problematic python". Because PHP is often older codebases that have survived the test of time, this is actually a big feature of the language.
The world and web development has much progressed since PHP3/4/5, and pretty much all of that progress can be leveraged with PHP as well. If I were to green field a new project, get to pick every developer on my team and a budget to match, I would probably not chose PHP.
But, if the problem were "we want to try out an ecommerce SEO idea and don't want to sell our soul to shopify if it is successful", wordpress/woocommerce + a few janky plugins and templates + a custom plugin with 1k LOC is totally something I would consider. And I absolutely loathe wordpress database legacy sludge.
If I have a team of experienced PHP and wordpress developers, a set of internal plugins that can be repurposed, and I can pay a freelancer to build custom react CMS components, using PHP and even wordpress for a new project is a no brainer.
One weekend I got sick of that and threw together a tiny website that automates the entire process. My tool of choice was PHP because it takes no effort to get started. TBH it was a great choice for such a simple tool. It's been running for five years and has easily paid off the time it took to build.
I guess I agree with you more than I realized.
Angular was still in its infancy and I was not aware of AJAX at the time. PHP frameworks, specifically Laravel and Code Igniter, made it very easy for me to put my computer science education to practical use. And I was dropping files off into our student workbenches via FTP! There was very little overhead for me to get anything online.
"3 months later w/ Laravel, I have a full SaaS that does [list of batteries-included SaaS app functionality]. No other stack is this productive"
Which amazes me, I thought I’d never find something that can compete with Rails.
From the stack overflow dev survey, php devs get paid much less than others.
Laravel and php is a beast, super easy to use. All that annoying shit is setup for you. But, how many ppl hire Laravel devs? Job boards are stacked with react, vue etc. Personal use is great though.
So all that’s left is low end wordpress jobs.
That's a bit of a reach, I would work for a company like Slack or Wikipedia of course even though they use PHP and so would many other devs. In fact the further I am into my career the less the tech stack matters to me; I've come to realize the bosses and the company's culture and leadership and how they generally treat employees is WAAYYY more important than whether the stack is Rails or Node or PHP. To me. They are all web stacks that do more or less the exact same thing and the work you do is really quite similar on all of them.
I was sure being a Rubyist is what makes me happy because I like Ruby...well guess what, you can be miserable in a Ruby shop...that's the lesson I've learned.
If I ever become super choosy about tech it's only because I really wanna switch directions - e.g do low level development or something like that which is dominated by C. But all the high level web languages ...are all the same to me (my preferences aside).
I'm 22 years in the business, 16 years working at the same place. At this point, there's various bonuses next to salary. After so many years, it's the domain knowledge and ability to figure problems out what gets me paid.
I don't have to work with the tool that someone tells me to use, I'm free to choose language/stack that I think is appropriate to solve the problem (deliver the project that's maintainable/useful for the customer).
I also don't take part in any surveys which makes the accuracy of the data questionable. There's plenty of people like me, what I learned is that a lot of senior/capable devs don't use social networks or sites like SO.
Approach the results of the survey very careful, false data is dangerous.
I haven't looked recently, are there a lot of remote positions for US employees writing PHP for $200k+ base plus bonuses?
I'm not even talking about the crazy-high comp from FAANG companies here, just Principal developer roles paying more than $200k base, with bonuses as well.
My anecdote and your anecdote combined don't make data, of course, but I know my comp climbed pretty dramatically when I left PHP behind.
Choosing the IT field because of compensation alone and then relying on top charts to choose the tech is what yields low quality.
Ultimately, every dev with 2 decades of experience will know more than 1 language and learn that tribal language/framework wars aren't helping anyone.
Getting things done and being of use is what our profession is. When one becomes useful, then the real career starts.
I didn't choose to leave PHP for comp alone, I was surprised at the dramatic shift on comp after the fact. I certainly don't think I've said anything that suggests tribal warfare. PHP can make for some amazing productivity, for sure! I think I last coded in PHP about ten years ago, maybe a bit longer, but it definitely has its place in the market.
I only note that you didn't answer my question, so I think I'm going to carry on with my assumption that there aren't a lot of PHP jobs in the US paying $200k+ base. Not that someone should choose a career path solely to pursue higher comp, of course.
The good parts were a small memory footprint, fast soap/xml parser, and stateless finite execution. Unlike the 200MiB+ "hello world!" async nodejs standard popular today... one can run small php cms/wiki sites on budget servers.
although if you're talking about your deploy process being dragging and dropping files onto an ftp server, not only is that horrifying but it doesn't win out on automating it with any one click deployment tool out there
It was quite sane, I had a very nice time. My application works as expected and it took me a few hours to complete, while learning the sort of get-up-and-go bits from the documentation.
So overall, I think it's nice.
I still love laravel until now, would choose it again sometimes just to have fun with it. However it's just never used in big companies so I always end up with python or java (not even c# around here except MSFT lol)
It's so omnipresent that that Spolsky used a sort of translator from ASP to PHP to be able to run Fogbugz un Unix systems[0], which I think is a neat idea (at least for a source lang subset and with tons of problems to be solved, but a neat idea nonetheless).
[0] https://www.joelonsoftware.com/2005/03/30/the-road-to-fogbug...
I think the package manager should be part of the PHP distribution itself, not some other thing that people have to find and install separately. I am fine if people want to implement other/better package managers, but I think the PHP distribution should include something, if only a rudimentary tool.
I also don’t believe a bundled package manager is necessary — NPM isn’t bundled with JavaScript, and it seems to be doing ok.
I'm not sure what point you're trying to make here. If you install the Node runtime, it comes with NPM. So it seems you're not correct about this, unless you are referring to some other runtime. And even if you are, why would some other runtime include NPM?
>I'm not sure what point you're trying to make here. If you install the Node runtime...And even if you are, why would some other runtime include NPM?
Node nor any other package managers are included with JS. You seem to be emphasizing their point.
When you install Node, you also get NPM, which is essentially what I said in the previous comment.
The other person said that JS also doesn't include a package manager. It sounds like you wanted to take issue with the colloquial use of NPM rather than their point about package managers not being included.
> I also don’t believe a bundled package manager is necessary — NPM isn’t bundled with JavaScript, and it seems to be doing ok.
> NPM isn’t bundled with JavaScript
which, if you install Node, NPM is included
You're splitting hairs about Node/NPM which is completely irrelevant to their point about JavaScript not having package managers built in.
Back in the day, there was PEAR, but it was never particularly useful.
According to common PHP culture, there's no need - since it's already good enough. Instead of re-inventing something you can just move on and get your own sh*t done. :)
(edit: formatting)
Composer is atleast undisputed, embraced and works well. Anything PHP is on there. Package formats are unified not like in JS.
Pythons PIP is also separate project.
1. designing "big" enterprise software from scratch, on paper, and then building a toy implementation.
I would say 95% of the actual work that goes into a big enterprise codebase are error handling, logging, changing requirements, covering the 80000 different user cases, while the architecture itself (a message bus, a pub sub pattern, a cache) can actually be written out in a few hundred lines of code.
This toy implementation can then be used to run multiple experiments: what happens if the message bus gets choked out? what happens if messages get reordered? how do you change a message schema?
These are rare and intense efforts in real life, but you can cosplay them with a few docker containers.
2. reading big existing enterprise codebases.
This is a skill that is not often taught, and people starting to read big codebases from "main.go" are usually doomed to fail, as they will hit the "big wall of enterprise indirection". Instead, try to get the codebase to compile, skim all the files at random until you think you recognize something, set a breakpoint in your debugger and run some part of the test suite or the real thing if you are adventurous. Then, try to mess with it some.
Once you found your marks, try to understand where all the big blobby nebulous enterprise nonsense comes from, and why it is there. Often, it helps to look at the source control history to see when it was introduced, and if design documents relevant to the change can be found.
I try to "read" a big unfamiliar codebase every couple of months. It could be kubernetes, or nginx, or webpack, or typescript, or react. You learn a lot about real world production code.
The amount and quality of opensource projects out there is nothing short of incredible these days. When I was coming of age in the early 2000s, it was linux, GNU, apache and a few other autotools driven monstrosities, with a CVS repository and a crusty mailing list.
3. learn to write RFCs
I started practicing writing relatively late (in fact, my blog just got started a few weeks ago), but learning to communicate clearly about design is vital. I have always done a tremendous amount of whiteboarding, and do most of my development on paper with boxes and arrows. I think this also develops a sense of "architecture" vs "code".
The more PHP work they forgo, the better for me. Less guys doing it, always in demand. Making good bank and am quite good at using it.
In web development, I find that there is a certain freedom that comes with dynamic typing that I wouldn't tolerate in other systems software (my other specialization is embedded software), as easy templating and logging are givens.
The fact that so much in web can also be "caught" at runtime (monitoring, logging, tracing) changes the game quite a bit as well, giving dynamic typing a bit more breathing room.
I will never argue against types, but unless I am working with somebody else, I don't need them.
The language isn't as good as Java, but is familiar, and has made lots of improvements, including around types.
It is just more complicated, to run a PHP site you need to have knowledge of PHP, PHP config, server config, the tooling is poor, there is always something else you need to bolt on to get a similar experience to a modern development language, there are so many ways you can write bad code or write code in a different style to others around you sharing this in a team is hard.
At my company we still run PHP apps and everything we want to do as an organisation is relatively simple in Go, but hard with PHP. I imagine the issues and problems we have with it are why it is not well used in large organisations
I dislike the direction that PHP has taken since the introduction of PHP 5. For the last 18 years or so, the language has been trying to become something like Java, but without the speed benefits we might get from it being compiled, and without the strictness benefits we might get from being strictly typed. Nowadays it has most of the heavy rituals of Java, but without any of the benefits.
The single greatest thing about PHP, circa 2000, was the abstraction it calls an "array" which combines what other languages would call a vector (or a list) and a hashmap (or dict in Python). That array construct was very flexible and allowed me to get away with a great deal. Later on I discovered the "seq" abstraction in Clojure, which is even more incredible, and has the added benefit of being done correctly, in an academic sense.
After 2011, I increasingly relied on Clojure, for any task where dynamic programming was reasonable. Clojure puts me on the JVM and allows me to drop into something like Java, and strict typing, in the rare cases where that seems necessary.
PHP in 2000 was extremely lightweight but nowadays it demonstrates of envy of heavier object oriented languages, but again, it still lacks the speed benefits of being compiled or the correctness checks offered by strict typing.
The article lists these benefits of PHP:
* speed
* ease of deployment
I don't think anyone would pick PHP purely on the basis of speed, again, there are many languages that are faster.
In terms of easy of deployment, any deployment of PHP (or Python, or Ruby) tends to mean deploying tens of thousands of files. By contrast, when I work in Clojure, I typically uberjar the code, and then I only have to deploy one file, which makes deployment ridiculously easy.
When it comes to interpreted languages (perl, python, ruby, js), PHP is hands down the fastest.
An amazingly fast specialized JS runtime solution [1][2] does indeed have the #1 spot on the most recent rounds, but full PHP frameworks hold spots #2 - 29 and then it's a mixture of PHP and JS all the way to #58 before we see the first other language (python, uvicorn) emerge.
[1] https://github.com/TechEmpower/FrameworkBenchmarks/tree/mast...
This is still running https://goldeneaglecoin.com/ whose framework (and HTML/CSS) is pretty much untouched since 2011. It is running on an ec2 t2.medium instance and is one of the fastest e-commerce sites i know.
JavaScript, if we are talking about VanilaJS and script tags, great, everything else I can happily ignore.
does that mean every other language the people don't get anything done?
In case you're not familiar with the book (i.e. "M. Feathers, 2004. Working effectively with legacy code."), it is a classic and widely regarded as "The" book on how to approach legacy codebases (even if a bit dated by now). A highly recommended read. It was also very enjoyable to read, which is remarkable for an otherwise technically-oriented book. Here is the relevant except from the introduction, defining what legacy code is and why it's a problem:
> In a strict sense, Legacy code is simply code you've gotten from someone else. However, clean, easy to work-with code is rarely referred to as 'legacy' code; the term usually implies a tangled, unintelligible structure, difficult-to-change code that is difficult to really understand. Therefore, a more pertinent description is:
>
> Legacy code is where any of the following questions fail to apply:
>
> - Is your code easy to change?
> - Can you get nearly instantaneous feedback when you do change it?
> - Do you understand it?
>
> If the answer to any of these questions is no, you have legacy code, and it is draining time and money away from your development efforts.
> Legacy code is code without tests: Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.
As I'm gaining more experience tackling project from a business perspective, when encountering a legacy codebase, it makes sense to start reviewing the business assumptions. Does this codebase even make sense in view of the current business strategy? If not, there's probably big chunks of code that can be entirely "written of", yet need to be kept alive long enough to migrate without disruption. Unit tests can help, but I often found deleting the unit test suite and starting a new one a more productive approach (again, with my experience of 6-7 projects).
But we agree. The book is a bit out of date, and it's focus on approaching the problem using 2004 agile techniques is not something I would fully recommend anymore, but I have yet to find a replacement (maybe there is one out there, I haven't looked recently)
Of course, some people will cry "spaghetti code" but sometimes you just want to get work done.
I mean, everyone knows tech is moving fast. Especially the JS ecosystem. So now why are you talking sh*t based on your experience like 3 or 5 years ago? At least just go around and read more before you comment.
Modern CMSes like Craft, Kirby, Twill, Bolt, October… it is very different story.
I'm sure the other CMS are fine but I want my site to auto update itself and all its plugins for the next 20 years with me hardly touching it.
Reality of that is that most people will use some plugins or their theme wont update or your code will have breaking change.
The auto update is nightmare. Because so many people are trying to hack WP you gotta do it and every other update becomes stresfull event. Good luck updating someone elses plugin.
Much higher chance of website working 20 years is - take simple preferably file based system. Make manual update every 5 years. If its good system then the migration will be well documented and painless probably taking 5 minutes.
I legitimately can't imagine willingly not using a statically typed language for anything that matters that's gonna have more than just me working on it.
How is Django different from, say, ASP.Net Core in that respect?
Is it still really verbose with lots of too small classes?
Edit
https://www.javatpoint.com/java-8-type-inference
Wow that's pretty cool.
More? Less? Interesting is just how far I checked out of that language years ago.
Anyone have a suggestion on a good resource for making my first PHP backend?
Search results have felt a little messy / all over the place in the past...
JavaScript is still my favorite/default language to program in.
But now I prefer typed and compiled languages for the compile-time checks. So many bugs found this way.
But speed is inversely proportional to the linecount.
At some point it is better to use a compiled language like Go.
I'm freelance (aka ronin) and so the job security is actually a bit spotty. :)
I've been a paid programmer for over 40 years. When some code has seriously gone off the rails I can help.
Often times, as a programmer, it's easier for me to change my environment, language, or learn their stack to be helpful to them than it is for the company to switch their stack because of my unwavering views on "right" languages.
There's a lot of really great developers that got their feet wet with dev work because Wordpress is immediately accessible and helpful. They just needed a playground to write shoddy code before they matured and perfected their craft.
In my opinion, I'd rather people write shoddy code and improve it than wait until they've ready enough books to write perfect code, but never actually start.
Doing something subpar now is often better than waiting till it's perfect and not doing it at all.
So by doing CMS dev you end up with pretty good skills with php+MVC. Why not use it for webapps?
Rails of course is a great alternative. Depending on your requirements, experience and preference etc you might choose that over Laravel given that from what I heard they're similar in productivity and features.