35
votes
"Java is fast but in practice, PHP sites run faster as PHP coders take more straightforward approach to design and don't get lost trying to implement exotic design patterns and endless abstractions"
Granted that it's highly subjective and opinionated, but what this author James Anderson states in this StackOverflow post very much resembles the voices of many like myself who are trying to switch from interpreted/dynamic languages to static and compiled ones like Java/C#. How do Java programmers tackle or respond to this stance?
I don’t have an answer to your question, and I’m also interested, but I do want to point out that comment was written 13 years ago. In case the landscape maybe has shifted since then.
The biggest difference between then and now is that PHP is now significantly faster.
Note that I have no experience with Java in the context of web apps, so I have idea how it would compare with PHP.
I'd imagine the difference would be small, Java being compiled and PHP handling the majority of the work with built in functions written in C.
The caveat being that those C functions are written specifically for the problem space and have been tested and iterated for nearly as long as the web has existed. I doubt there are any web frameworks for Java that are as efficient.
As a professional web application developer that’s used Java, Ruby, and Typescript professionally and Python, Elixir and PHP in various hobby projects, your programming language doesn’t matter too much if you’re just writing an app by yourself. It all comes down to what you’re familiar with. As long as you know the good and bad parts of the language and its popular frameworks you can make informed decisions and write a good app. Likewise, If you’re going to be hiring people to work on it then you need to pick something that people know. Otherwise you’re hiring people ignorant of the footguns awaiting them around every corner.
For younger developers that means, IMO, Typescript is the language of choice. I also think it’s just a good language in general and if you have a complex front-end you’ll get benefits from both sides of the codebase being in the same language.
Any talk about PHP vs. Java isn’t super useful. Pick the tools you know and want to learn more about. And always always pay attention to what’s working and what isn’t so you’re actually learning as you go. I spend hours reflecting on designs, functions, and APIs to pull apart what makes them good.
Edit: I want to add that web applications are almost always I/O bound. Worrying about the performance of the language itself is wasted time. Performance issues are usually down to poorly thought out database queries and the interplay between the client and server.
It’s so rare for the language performance to matter that when a company switches languages for performance reasons it’s a big deal and a very interesting read. If you need to handle hundreds of millions of requests per second then you’re going to hit CPU limits. If you’re streaming tons of bits or actually doing serious computation then you need to worry about your poor CPU. But there are only a few thousand web developers in the world that really need to worry about that. A concern with language performance for web request handling is fantasy football.
Looking at the original question:
It isn't clear what faster means here. Is it raw execution speed? Is it development time for new features? Is it the time to get familiar with a code base?
If we start to benchmark a super simplistic CRUD webapp serving up some dynamic content read from a database (which is a likely one of the most common usecase), then for most of these the speed of execution won't be an issue in practice. Hardware is blazingly fast. Modern frameworks in either language will steer the implementation to something good enough.
I think a much more interesting question to answer in practice is the subjective version:
For the sake of argument let's assume PHP is 10000 times faster than Java. But, you know java and have worked in it for several years. You are familiar with the language ecosystem. You know how to set up an efficient CI/CD pipeline for it and know how to tweak the runtime when needed. Then you will likely be faster to get something in production using what you are familiar with. Your implementation with Java will likely also be more efficient than if you need to start out learning PHP.
So, context matters a lot for this question. What are you optimising for? Pushing out new features (go with something you know)? Ease of onboarding new people to the code base (perhaps choose the most popular language/framework in your area)? Fast execution time for hot code paths (profile your code and optimise, perhaps reimplement that part in another language)?
I'm not a Java programmer (not a huge fan of it tbh) but my two cents: This seems like it's going to be highly dependent on the experience level of the programmer in the space. PHP has been around in web dev for ages, but it's not as popular recently as it once was and it's not as popular among beginners in my experience. Java, on the other hand, is one of the most popular teaching languages in CS courses. As a result, I suspect PHP programmers are likely to be more experienced on average than Java programmers.
I'm not convinced the portion you quote is inherent to the languages themselves (though I'll admit I have only a passing familiarity with either). It's certainly possible to write convoluted code with "exotic design patterns and endless abstractions" in interpreted/dynamic languages -- my primary coding language is Python and I can attest to that. It's quite strange to me that you present this as a dichtomy between interpreted/dynamic and static/compiled languages when imo that's completely orthogonal to the actual criticisms in the StackOverflow answer.
I have plenty of things I dislike about Java and object-oriented programming more generally, but I'm not particularly convinced that there's some inherent feature of PHP that makes it more suited to straightforward code. If anything, PHP has the opposite reputation in my experience -- while I've never used PHP for anything non-trivial myself, my main impression of it from others has been that it's far too easy to write bad, insecure code in PHP. It's worth considering why PHP does not have a particularly great reputation as a language, despite still being used for web dev stuff. Here's a pretty detailed comment from a PHP dev on r/PHP going into some of the reasons people dislike that language in particular.
I haven't been using PHP in recent years, but note that that comment is itself very outdated, and the points it makes no longer apply. That's about the age of "drupal and joomla" (not saying wordpress because it's still in use, but consider it strongly implied, because that thing was a huge mess).
I'm not really in web dev so I don't have a good sense of what's currently in use and what isn't (other than recognizing WordPress). It's worth noting that at least one of the points from that comment certainly still applies despite its age-- most people developed their opinions on PHP in the past, when it was worse than it is now. I'd be curious about changes to PHP that make their other points no longer applicable, but since I don't use the language I obviously can't know whether or how much the language has changed.
In any case, the reddit comment I linked is newer than the StackOverflow thread that inspired the original topic.
I'm not really a Java programmer (though Java was my first language), but I'll instead address this:
The answer is simply to use a better language than Java or C#.
If you're looking for a statically-typed and compiled language, I think Rust is the best answer for most people these days unless you have a specific reason not to use Rust.
Writing a large web stack in Rust sounds like entirety too much work unless you have very particular resource constraints and the time/money to spend on overcoming them. For many use cases, a GC'd language will do just fine, and will open you up to a much wider dev talent pool.
You also have to separate the language and tooling process from the actual runtime - I'm not a huge fan of writing Java (I think they're too weighed down by early-version design decisions that they should have broken a while ago), but the JVM is really good, and there's a large knowledge base out there for optimizing and tuning it even further.
I often find that criticism of C# online comes from an outdated view of it, back in the Framework and Windows-only days. C#8 just released last week, and you might be surprised how it performs nowadays, and especially what the development workflow is like.
*C# 12 just released last week (.NET 8). Long gone are the days of C# 7 and Windows-only .NET Framework.
Yup I got mixed up with the language version and runtime version
Rust shows that the distinction between GC'd and non-GC'd isn't necessarily important. Rust is not GC'd, but it is managed in the sense that you don't have to worry about managing memory yourself. That, plus its memory-safety guarantees, means that the actual experience of programming in Rust is much closer to a traditional GC'd language than an unsafe language like C++ (except it also has a bunch of nice PL features from languages like Haskell).
I don't recommend Rust because it's fast---I don't think performance matters all that much for most applications---though, of course, it is nice that you can squeeze it if you really have to, and that things tend to be pretty fast "by default". I recommend it because it's that rare thing: a mainstream language that's actually well-designed.
Similarly, languages that do have garbage collection can easily make you wish for that level of attention in the compiler when the abstractions start to break down. PyTorch is the de facto standard for a lot of GPU compute nowadays, and it’s a phenomenal library, but keeping a mental model of what’s in any of nine different “buckets” of RAM (eight GPUs plus system memory) and convincing Python to clean it up efficiently can be an exercise in frustration. The GC becomes a toddler that you’ve got to handhold the whole way, rather than a part of the system you can just leave to do its job.
I like Rust as much as the next rust-fan, but I think people give it more credit in certain areas than it deserves. It is novel in the borrow checker, it is standard ML in type system and everything else. You have had Scala, OCaml, Haskell, Kotlin, F# with “better type systems” for many many years, and some are just as big, if not bigger than rust (though I wouldn’t call rust “mainstream” still).
Yes, Rust is sort of like "baby's first ML" for a lot of people (except the borrow-checker arguably makes it harder to learn than regular ML), and so maybe it does get more credit than it deserves. I really think it's the braces and semicolons.
On the other hand, it does have the legitimate advantage that it can be used in a wider variety of situations than any of those languages. Also, due to network effects, it has more "serious" libraries than most of them.
I suppose Kotlin is more mainstream than Rust, seeing as it's the main language for Android development. I don't know much about Kotlin---I didn't even know it had an ML-ish type system---but I'm not a fan of what I've seen of Scala---it always seemed C++-ish in a bad way---too complicated, too many paradigms. I'm deeply suspicious of any attempt to marry the traditional OO paradigm with the ML-ish paradigm.
It's still sort of on the periphery, but it's making it into the Linux kernel. To my mind, that matters more than the absolute number of people programming in it.
I believe Scala and Kotlin are unrelated other than both being JVM languages, so using experience with Scala to judge Kotlin doesn't seem fair to either.
There are in fact a great deal of languages better than Java or C#.
The only specific reasons I can think of to not use Rust (for a new codebase) are if you're writing code for the mobile or the web. If you're writing code for Android, you're locked into a JVM language. Kotlin is a better language than Java, but IMO modern Java really isn't too bad. You're locked into Swift on iOS - luckily, Swift is in fact a quite good language and Rust stole a lot (but not as much as it should have) from it. If you're writing code for the web, you should probably use TypeScript. Or Wasm and Rust.
There are other domains where Rust hasn't quite taken over lol. I wouldn't want to do data science in Rust atm, and golang is perhaps a better option if you care more about concurrency than guaranteed memory safety for your task (and especially if you need to onboard new devs quickly, as it's much easier to learn). Rust is cool and I've got some interest in learning it but there are still plenty of places where it's at least not yet the best tool for the job.
Not really on topic, but IMO Erlang really has the best concurrency story of all languages. The embracing of failure as inevitable in the erlang community is alo refreshing. It puts you in the mindset of ensuring there are recovery paths for when faults occur. This makes erlang systems very resilient over all.
Ooh interesting! I only know about golang in particular because it's used (by others) at my work, and I'm definitely not an expert on that domain so erlang is new to me!
Ah, good callouts. Yeah, Python will never be dethroned for scripting I think, and Julia/Python are definitely both better choices for data science (I do not know much of R but think I would have negative opinions).
I wish Rust's concurrency story was better. It's a damn shame. I think Zig's is the approach I'd like to see new languages take - it's fairly similar to Go in terms of usage (not implementation) I think?
R as a language is bad, R as an ecosystem of statistical packages written by actual researchers, professional statisticians, is unmatched unfortunately.
I think there are great reasons to use C# or Java instead of Rust. Chief among them being ease-of-use, and their absolutely massive collection of libraries that probably already do what it is you need to do in your app.
I don't really know anybody using rust for web development without a very specific use case for it.
Opinions vary here. People have their complaints about Rust and its borrow checker, but my opinion is that languages like Java and C# encourage bad cognitive habits and have poor abstraction mechanisms, and that the entire idea of a classic gang-of-four "design pattern" is just a way to make up for deficiencies in mainstream OO languages. The borrow checker is a small price to pay for an expressive language that has learned from the last 20 years of language development. (And also, it turns out that the borrow checker tends to encourage good design.)
That sort of falls into the "unless you have a specific reason not to use Rust" category. If you're programming in a domain for which Rust lacks a good library, you probably shouldn't use Rust.
(Although, while I know essentially nothing about Web programming, I know that Rust has no shortage of Web frameworks, so I really don't think that Rust is unsuitable for Web programming.)
Rust has design patterns, unfortunately, but there's far fewer of them and they're even more obviously a hack to make up for a deficiency in the language. The newtype pattern comes to mind.
As a long-time Haskeller, I don't see the problem with newtypes, and I especially don't see what deficiency they're making up for. A newtype is just what happens when you consider the idea of bundling n things into an abstraction and take the limit as n goes to 1.
The main problem with newtypes is you have to reimplement all the methods and traits you want to be public on the newtype. Often times, using the newtype pattern is just a workaround for Rust's overly-strict coherency rules disallowing implementing an external trait on an external type. Even when used for its own merit, the reimplementation of methods is tedious, and necessitates a lot of boilerplate that a language feature (something like a
distinctkeyword, or I thinkdelegatehas been proposed) could fix.Ah, I see. The problem is not really with newtypes as a "design pattern" but with the lack of support for them.
In Haskell, you could do this (for typeclasses, at least) with
GeneralisedNewtypeDeriving. For Rust, it looks like thedelegate!macro does some of that work, though I guess it's still more boilerplate than it has to be for some use-cases.I write enterprise Java software daily. To be honest, I don’t really see the stereotypical “endless abstractions” thing that much these days. The language certainly doesn’t enforce you to write anything like that.
I think in the end, it really depends on the team. For example, our team practices TDD which results in simple designs by default. During TDD’s refactoring steps, we might generalize some piece of code, but usually it's just to remove duplication. Sometimes we might want to add some less trivial abstractions, but only if it makes sense given our current needs. If you want simple design, then you don't want to make too many assumptions about potential future requirements.
But some teams (even in the same company) don’t do that. I think by nature, some people are drawn to gold-plating, generalizing and abstracting things. (I probably would do it too if I didn’t have a team writing and reviewing the code with me.) The problem is, most of the time we don’t know whether that abstraction or pattern was really useful or necessary in the long run, because we’re always working on limited knowledge of the future. At worst case, abstractions can just end up being overkill and increasing the cost of change in the future without adding any value.
The most important factor for choosing web framework (i.e. language), is what kind of website you’re building.
The best choice, when possible, is none of them: make your site 100% static. Either write the HTML (+ CSS + JS + assets) by hand, or use a static site generator like Hugo. Use a host like Github Pages: it will be significantly simpler, cheaper, faster for your users, and handle large request volumes better than anything you could do with any web framework.
This is for sites whose content changes infrequently: personal sites, company homepages, news or blogs with infrequent updates and without comments. Even if your site hosts dynamic content like games or full-on apps, if there's no multiplayer/server-interaction and the download never changes, you should probably use a client-side framework and language which compiles to WebAssemly instead of JavaScript, but the server-side part can still be static.
If your site does have frequently-changing content, then I'd recommend PHP if the server-side part is simple, Java otherwise. Some of PHP's original use cases are: a tiny "today's date and time" widget, a comment section, displaying data from a database. Using Java for a site with this kind of stuff is overkill, and I can totally understand all the unused features and unneeded abstractions slowing the site, plus making it more buggy and making the code harder to read and modify. But if your site is complicated (social media app like Facebook, content platform like YouTube, banking app) then those features abstractions aren't going to be unused and unneeded, and quite the opposite, if you try to implement everything in simple PHP you'll most likely end up with dysfunctional spaghetti code.
Also, both PHP and Java frameworks like Spring Boot are old. They're certainly not bad choices given that they've had constant updates and are used by many sites today. But there new frameworks with new languages you may want to check out like Ktor and rocket.rs, and I know ones like PHP exist as well (no examples right now you could probably do something like that in Racket with a DSL)
I can't think of a reason why this would be true. Maybe you're thinking of earlier versions of PHP from 20 years ago? Even then it could power a site like Facebook, which of course it eventually did.
Yes, I should add a caveat that it only applies to old PHP. Modern PHP has classes, type declarations, and other features which make it suitable for building large-scale systems. Although at that point, I wonder if modern PHP with classes, explicit types, and design patterns isn't really different from Java.
Facebook was (and in some places may still be) powered by PHP, but I know for a fact they've had major issues with it. Hence why they built a whole new language to interop with PHP, Hack.
Also see this blog post from 2020, where they claim they've rebuilt the site from the ground up and mention some of the issues they've faced with the old site (like, how "dark mode and saving your place in News Feed had no straightforward technical implementation"!)You're right that they eventually decided to (sort of) move on from PHP. That wasn't because there was anything it couldn't do, though. It was because they wanted the extra speed of a compiled language and so they created their own (as I understand it, essentially a modified version of PHP that could be compiled).
The post you linked is about rewriting their frontend (javascript, CSS, etc..) rather than their backend, which is where you'd find the PHP.
The classic one is the problem of “how do you redraw a form if a user filled it out wrong?”
Very early cgi-bin scripts failed at these completely because your form was on some HTML page and the cgi script was something entirely unrelated.
Eventually people developed the “model view controller” paradigm which, for the web, was really about having your whole application served by one cgi-script which had “routes” internally so it could decide to draw the erroneous form or draw the next page. You need that and some helper functions to deal with the other missing features like HTML like the fact it is awkward to set which option of a select is selected…. without the right helper function.
If you have a master plan for how you are doing to deal with these problems you can do OK in any language but PHP doesn’t come with out of the box answers and if you don’t have your own answers boy are you up a creek without a paddle.
In fact, early PHP was designed for just that sort of thing. Your form handler script would both generate the HTML and handle the input. At the time the HTML would have been embedded in the PHP script, the MVC pattern changed that as part of the philosophy was that display (view) should be separate from logic.
I would say PHP did not answer the question of how to implement a multiple-view page but it did give you the tools to do so, for instance your first “router” is likely to be an if-then-else ladder and you are probably going to use includes to put the form and the confirm pages in different files and if you think systematically and the application expands it is going to look like synfony.
What language does answer that question? What you're describing is a role often filled by frameworks.
Circa 2000 it was all dynamic web sites where the back end read a form you submitted and then “prints out” some HTML that goes to the browser.
You can still do that today but it seems to be a black art, there was a whole bag of tricks that were really pretty simple that would help with things like user authentication and redrawing a form if the system finds it is in error, but on some days it seems like a lost technology like how they made Stonehenge or the Pyramids.
Today it is much more fashionable to write a big mass of Javascript that makes structured requests to an “API server” that updates itself when it gets JSON replies. For that matter you can often do a lot in Javascript with no backend server at all or using somebody else’s server.
If you want to make the case that web sites are much more complicated than they are spozed to be in 2023 I think you would blame Javascript more than Java since an awful lot of projects start with a cookiecutter like create-react-app and the people doing them know there is a lot going on behind the scenes but often don’t know a lot more than that.
One advantage of Javascript is you can do really amazing things like use WebXR and WebGL to make a sure with 3-d content that you can view with a desktop computer, a phone, or a VR headset. I was lucky to get a lot of work early on on that kind of project but I remember about 10 years ago all the web shops that could pound out ruby on rails apps for form handling efficiently at that time decided they could only sell Angular apps and I don’t think any of them have recovered their footing completely. To me I look at React or Redux and such and compare it to what I did almost 20 years ago and I feel like I am a contemporary engineer and some cave man is trying to impress me with his hand axe.
JavaScript is Awesome without a Backend Server.
I’ve used html + js in iOS shortcuts with Data Jar for storage to do math, record keeping, and some other stuff that wasn’t possible - or easily possible - otherwise. For example to take some input and stored values and do some fancy maths you can:
data:text/html;base64,Base 64 EncodeIn the above example the html + js throws out a
document.write(JSON.stringify(dict)).But with html + js + css you can do all sorts of fun things with shortcuts like automate wallpapers with pretty, informative tables.
All that’s to say, I 100% agree a lot can be done with JavaScript with no backend server at all.
Nostalgia
I know there were exceptions to this, but it surely gave me a chuckle. For the young ones around, or people 20 years from today, I hope you’ll find some time to explore the wild transitions we’ve seen in web dev between 2003 and 2023.
You might be interested in htmx, which does thing the “old way”. It uses JavaScript under-the-good but lets you write most stuff in HTML, and isn’t slow and bloated like what I think you’re alluding to.
Yes, you can implement web forums entirely in HTML and I believe some websites still do so today. When the user clicks the “submit” button in an HTML
<form>, the browser sends a request with the form data; the server can respond with a page containing the same form and any validation errors, or it can respond with a “success” page or anything else. There's also pure HTML client-side validation, which you should use whenever possible, because it reports errors instantly and is super easy to use.But importantly, with pure HTML forms, the server must send and the client must load an entire webpage, so this approach is actually slower than well-written JavaScript. JavaScript can communicate with the server before the user submits, to validate form inputs against server data as the user is typing, and it can send only relevant data, e.g., the validation errors instead the entire page.
In this sense, htmx gives you the best of both worlds: you can write forms in plain HTML with the added features and efficiency of well-written JavaScript. The htmx website has many examples including one for this type of inline validation.
I like HTMX, I use it for my RSS reader YOShInOn and appreciate being able to use that and some other high-powered Javascript like D3.js by just inserting a few snippets of JS here and there.
I push design patterns a lot at work because they result in testable code, despite taking longer to implement most of the time. The lack of them just leads to chaos people hand off to the next guy. You can do that on Fe a bit though. Fes get thrown away and rewritten more frequently. The next guy can throw away and restart... Sometimes. And the time he can't he'll probably curse your untested undocumented php.
I wrote Java from about 1.02 up to Java 8 and then managed to avoid it. I think I was happiest using Java 4 on a team that was doing extreme programming.
The language is very old now and has lots of nice features. I believe it would be possible to set up a nice environment, but it would require ignoring the ecosystem and doing something rather different, which would be hard.
For example, all the popular build and packaging systems for Java are terrible. This is pretty unreasonable, but I were going to use it again I would not want to use Maven or Gradle. Ant was also pretty bad. (A more reasonable person would use them but keep things very simple.)
This alone might drive me to see if C# is better. (I don't know how they do builds.)
These days (for hobby programming) I use Typescript; I'm giving Deno a try. I admire Go but don't use it anymore. If I were doing mobile apps I would try Flutter; yes the Flutter tools will call Gradle for Android but you can mostly ignore it.
Since JDK 17, Java has added all the features from functional programming languages that are actually useful, like pattern matching. Java’s lambda syntax is one of the most concise in the industry so you can sometimes code functional-style programs in Java that are more concise than the alternatives.
As for maven I think it is more misunderstood than bad. If you think maven is like make and you expect to solve all your problems by writing POM files you are going to hate maven. If you realize that the core of maven is like spring and all it is doing is configuring a bunch of plugins you will discover a few lines of code in the language you are using already can do anything. That is, if you want to do some code generation just write a Java class that does the code generation, pack it up in a maven package and done…
Note maven has a dependency solver that works which is more than one can say about some other languages, such as Python.
My knowledge of Maven has bit-rotted, but I expect that I wouldn't like the plugins. Having actual commands (that you can run manually) seems better than plugins. You should be able to do a dry run and see what commands it would run, and try running them yourself to debug the build.
The thing that drove me away from Gradle was attempting to figure out how the Android plugin worked to add a feature needed for Flutter. Dived into the source code (verbose, uncommented, frameworky Java), couldn't understand it, there was no help out there, and I eventually gave up. I expect most people use it by fairly blindly following the Android docs and nobody really understands what it does.
By contrast, Go doesn't have plugins in its build system except on the edges: you can run a command to generate Go code, but each package has to include its generated Go code (it's checked in to source control just like hand-written source code). Nobody downstream needs to care about whatever generators a package happens to use, since they don't run them. This keeps builds fast. It seems like the way to do it if you can get away with it? (But it doesn't do everything; people write makefiles that run the go command.)
And I think that's enough for a single-language ecosystem. Multi-language is much harder. I was sort of okay with Bazel having had to do a lot with it at Google, but that has hidden depths too.
I haven't used it, but Ninja seems like a nice, transparent approach - you have a top-level build that generates a ninja file, which is just a clean way (though verbose) way of defining dependencies and running commands. So, studying the ninja file and whatever it commands it wants to run should tell you what's going on.
I was surprised to read through this thread and not see any real numbers, so I filtered the latest round of Tech Empower benchmarks and came up with this, which shows Java consistently beating PHP across all the categories: https://www.techempower.com/benchmarks/#hw=ph&test=cached-query§ion=data-r22&l=zik03j-cn3
When a web site gets more complicated you get into a situation where there is more and more configuration data. That is you wind up looking up things in tables a lot. For instance there many frameworks where you write something like
@GET(“/some/path”)as an annotation to make a function that responds to a path.The framework has to scan all your code, find those annotations, then make a routing table.
In Java you can figure all that stuff out when the app boots and then keep the results in efficient data structures and reuse them for each request. PHP has a very fast compiler that can parse all your code for each request but it means you can’t retain tables like that from one execution to the next. (This was a good feature for PHP at a time because it made PHP quite robust…. You didn’t have to worry about one request corrupting data structures that break the next request because… There is no next request)
With other dynamic languages it is different, for instance I write aiohttp apps in Python for fun all the time and these work basically like how Java works in this respect.
This is just one example but there are many similar ones. Some applications have text for different languages loaded into RAM, some have an arbitrary set of objects that help the system serve requests (this is the whole point of Spring, Guice, etc.). One of those objects could be a machine learning model that takes 0.001 s to run but 5 s to load, for instance.
You have options here, a PHP application could be very selective about data it loads, it could keep more configuration in a database, that ML inference could be done in a microservice, etc. But in Java you really can make any objects you need ahead of time and use them when you want and this is not so easy with PHP. Java is itself reasonable fast and it has excellent support for threads both in the sense that they are reliable but also efficient (it is not unusual at all to make something that runs 14x faster in a 16 core machine) and you have all the right tools to prevent one thread from stomping in data from another thread so it is easy to cache results in RAM in a Java system.
I know there are workarounds to these issues in PHP but are they really any easier than just having data structures survive requests and you can just code with them?
I’ll defend “table driven development” against those who would call it overcomplicated in that there are many things straightforward to write with tables (text adventure games, parsers) that are between impossible and “unheard of” otherwise. It is common in the SaaS space for instance to have “multi tenant” software that is shared with a bunch of customers and table driven is one of the royal roads to that kind of system.