PHP, Node.js or React in 2026: Choose by the Numbers

My hosting customers are schools, small shops and foundations, and lately someone has asked me almost every month, "What should I use for a new website: PHP, Node.js or React?" So I went through actual market figures from primary sources as of 7 Nov. 2026, then asked two AI models, Claude Opus 5.5 and GPT-6.1 Sol, to weigh the options independently, each assigning scores without seeing the other's. This article is my opinion based on those figures, not a scientific measurement. Feel free to disagree.

These three names belong to different layers

The misunderstanding I encounter most often is the idea that you have to choose "PHP or React" as though they were competing brands of the same thing. React actually runs in the visitor's browser and handles the interface, while PHP and Node.js run on the server, and nginx and Apache are web servers that receive requests and pass them to the application. They can all work together: Laravel with React through Inertia, for example, or WordPress as the backend with Next.js as a headless frontend. I used to think PHP would hold a steady market lead for a long time, but this year's figures fell faster than I expected, as I'll show in the next section.

I've drawn a straightforward diagram of the request path, from the user clicking a link to receiving a page. The two highlighted boxes show where the things people often confuse belong.

Node.js is a runtime that lets JavaScript run on the server, and it has its own HTTP server, so people assume it replaces both Apache and PHP, which is true only when you manage the entire machine yourself. On ordinary shared hosting, you still need a web server in front. I've already covered separating the frontend and server layers in a real example in Moving Computation from PHP to the Browser, where moving formulas into the browser brought the runtime down to 12 milliseconds.

If you want to know what a website sits behind, start by checking the Server header. If you see cloudflare, the site is behind a CDN, and you can't see the actual web server behind it.

# ดูว่าเว็บตอบกลับด้วย Server อะไร (ต้องเป็นเว็บที่เราดูแลหรือได้รับอนุญาตเท่านั้น)
curl -sI https://example.com | grep -i '^server'

# ตัวอย่างผล: server: cloudflare  = อยู่หลัง CDN มองไม่เห็น origin
# ตัวอย่างผล: server: nginx       = เจอเว็บเซิร์ฟเวอร์ตรง ๆ

This year's market figures: PHP is falling, but still leads by far

These figures come from W3Techs on 7 Nov. 2026, and you need to understand the denominator first: they are percentages of websites whose server-side language can be detected. One website may count toward several languages, sites hidden behind CDNs often cannot be detected, and the figures count websites, not traffic or jobs.

This year's current figures also include Java at 5.5, Scala at 5.0 and Python at 1.1, while WordPress has fallen from 43.2% to 39.4% of all websites. A 4-point fall for PHP in one year is fast, but it is still at 69.1%, more than eight times the runner-up's share. So I don't interpret these figures as meaning PHP is dying.

The web server figures have shifted more sharply. Last year nginx still led at 33.3%; now Cloudflare has reached 33.3%, having overtaken nginx for the first time on 1 Oct. 2026 (31.2% versus 30.8%).

Web servers: scores for ordinary hosting workloads

Here I asked both AI models to score independently from 1 to 5, then combined their assessments. Their scores differed by no more than 1 point in almost every cell. The context was school or SME customers on DirectAdmin hosting, while also taking the wider market into account. I want to stress that this is judgment, not measurement.

What I see in the chart is that none gets full marks in every cell. nginx is efficient but does not understand .htaccess, while Apache fully supports .htaccess but uses more RAM under heavy load. The nginx-in-front-of-Apache mode used by DirectAdmin combines the strengths of both, at the cost of more complex configuration (just 2 for ease of setup). Other details worth knowing before choosing:

• OpenLiteSpeed reads only rewrite rules from .htaccess, and you must enable Auto Load from .htaccess and restart before changes take effect
• LiteSpeed Enterprise reads .htaccess in the Apache style, but not every directive, and it has a licensing fee
• Caddy obtains and renews HTTPS certificates automatically, making it better suited to machines you manage yourself than to hosting panels

The point I most want you to watch in this group is the general behavior of nginx in front of Apache. Static files served directly by nginx never pass through Apache's .htaccess deny rules. This is the general behavior of this mode.

The additional nginx rules look roughly like this. When testing, use only ordinary marker files you create yourself. This is just the location configuration to put in an include that the hosting panel lets you edit, not a new server block, because the panel overwrites the vhost during a rebuild, and if the site genuinely offers zip or log files for download, remove those two extensions first.

# ใส่ใน include ของ vhost ที่แผงเปิดให้แก้ ไม่ต้องสร้าง server block ใหม่

# ไฟล์ที่ขึ้นต้นด้วยจุด (.env .git .htaccess) ยกเว้น .well-known สำหรับออกใบ SSL
location ~ /\.(?!well-known/) {
    return 404;
}

# ไฟล์ backup และไฟล์บีบอัดที่มักถูกลืมทิ้งไว้
location ~* \.(sql|sql\.gz|bak|old|orig|swp|zip|tar|tgz|7z|log)$ {
    return 404;
}

# ตรวจ syntax แล้วค่อย reload ห้าม reload ทั้งที่ยังไม่ผ่าน nginx -t
nginx -t && systemctl reload nginx

# ทดสอบด้วยไฟล์ marker ที่สร้างเอง ต้องได้ 404
echo test > /home/webuser/domains/example.com/public_html/marker.bak
curl -sI https://example.com/marker.bak | head -1
rm /home/webuser/domains/example.com/public_html/marker.bak

Backend and frontend: scores the two AI models agree on

The backend scores use 7 criteria. The last is "AI coding accuracy," which I included because AI now writes the code for many new projects, so I also need to consider how accurately it writes each language.

PHP gets full marks for easy and inexpensive hosting, fast development, finding developers in Thailand and AI coding accuracy. Its low score is 2 for realtime, which matches the familiar pattern: PHP is good at answering a request and finishing, but less suited to holding connections open. JS/TS gets 5 in four areas: realtime, libraries, finding developers in Thailand and AI coding accuracy. Hosting gets only 3 because it needs a process running continuously, which I'll discuss later in the Node.js on DirectAdmin section.

For the frontend, there are 5 criteria.

React gets 5 for both complex UI and ecosystem, but only 2 for ease of learning and 3 for load speed. Personally, I think React should be added only where the interface really needs a lot of interaction, such as filterable tables or multistep forms, without turning the whole site into an SPA just because it looks modern.

Which stack for which job

This chart is what I actually use to make decisions. I asked the two AI models to score independently, then combined their assessments. The scale runs from 0 to 3: 3 recommended, 2 a good alternative, 1 viable but not the first choice, 0 unsuitable.

What I notice in this chart:

1. The first seven rows are jobs I encounter often, and PHP gets 3 in every row
2. For realtime and high-load microservices, PHP gets only 1; these call for Node.js or Go on a separate machine
3. For AI/RAG features, Python leads at 3, matching its widest selection of libraries
4. Enterprise, government and banking give Java/.NET a 3

Other options worth knowing: school or company websites whose information changes infrequently can use static HTML or Astro; shops that want no server maintenance at all can use Shopify; forums such as Flarum (PHP) can run on shared hosting, while Discourse (Ruby) needs a VPS with Docker; and PHP can handle high-load work with Laravel Octane, Swoole or RoadRunner, though it is not the first choice.

Node.js on DirectAdmin needs a persistent process

JS/TS gets 3 for ease of hosting because Node.js needs a process running continuously, unlike PHP, which the web server calls on to do work in rounds. On DirectAdmin, I know of three approaches that match DirectAdmin's documentation.

1. The administrator enables NGINX Unit integration for the packages that need it, then users create their own apps under Advanced Features by selecting Nginx Unit
2. Use CloudLinux Node.js Selector, which uses Passenger behind the scenes
3. Move it to a separate VPS or container with PM2 or systemd and a reverse proxy in front

With a static export, Node does not need to run at all when serving the site. Just build once and upload the files like an ordinary HTML website. The administrator's commands for enabling NGINX Unit look like this.

# รันด้วยสิทธิ์ผู้ดูแล ฝั่งเครื่องที่เป็นผู้ดูแลเองเท่านั้น
da build set unit yes
da build unit

# จากนั้นเปิด nginx_unit=ON ในแพ็กเกจ, reseller หรือ user ที่จะให้ใช้
# ผู้ใช้เข้าไปสร้างแอปเองที่ Advanced Features -> Nginx Unit

AI coding: which model is good at what, and how accurate is each language?

I now use AI to write code for almost every new project, so I personally consider "languages AI writes accurately" a real criterion for choosing a stack. For the broader developer landscape, there are some figures to provide context: GitHub Octoverse 2025 says TypeScript reached number 1 on GitHub by monthly contributors in Aug. 2025, overtaking both Python and JavaScript, with GitHub explaining that typed languages make code written by AI agents more reliable. Stack Overflow 2026 puts JavaScript first at 62.0% for the 12th consecutive year (14,099 respondents), followed by SQL at 58.4, HTML/CSS at 58.2, Python at 58.0, Bash at 51.3 and TypeScript at 43.8.

For figures comparing the two AI models, I use Vals AI because it is an independent organization that runs both models on the same tasks, rather than figures published by the vendors themselves. The numbers are pass percentages.

Reading this chart, Claude leads on multistep changes to real repositories and building large programs, while GPT clearly leads on SRE Bench, which covers system administration and troubleshooting, and has small leads on IOI and Terminal-Bench-Science, where the uncertainty ranges overlap. Those two rows therefore cannot establish a real winner. Another point to know is that there are still no benchmarks for the current models that break scores down by language, so I cannot say which is more accurate at PHP or Python based on actual measurements.

For that reason, I divide the work roughly by strength: Claude takes the lead on multistep code changes across multiple files, GPT provides another perspective on incident analysis and SRE work, and I always have the other model review important work rather than trusting just one.

Next are the language proficiency scores, with each model assessing itself and GPT scoring without seeing Claude's results. A warning first: these are self-assessments on different scales. Only the rankings are comparable, not the numbers directly, and 9 out of 10 does not mean 90% correct. The two rankings are almost identical (Spearman 0.96).

What stands out to me is that widely used languages sit at the top, while older or more specialized languages score lower, which aligns with the MultiPL-E and MultiPL-T research finding that models perform better in languages with more training data (Python, Java, JavaScript) than in languages with less (R, Julia, Racket, OCaml). This is a trend, not a fixed ranking. As for actual measurements by language, there is only one set I could verify from the primary source: SWE-bench Multilingual from 2025, with 300 tasks, 42 repos and 9 languages, where Claude 3.7 Sonnet with SWE-agent solved 128 out of 300 overall, or 42.67% (Rust 58.14, PHP 48.84, JS/TS 34.88, Go 30.95). But each language has roughly 40 to 50 tasks, so the figures reflect repository difficulty more than proficiency in the language, and the model is already old. I use it only as supporting context, not to make decisions.

What I recommend doing every time is checking package names before installing, because AI sometimes suggests packages that do not actually exist, which is as dangerous as incorrect code because someone can register those names for real. For PHP, add strict types to every file AI writes so that types help catch errors before the code runs for real.

# ตรวจก่อนว่าแพ็กเกจมีอยู่จริง และดูว่าเวอร์ชันล่าสุดคืออะไร
# ถ้าไม่มี จะได้ error 404 แล้วอย่าติดตั้ง
npm view some-package-name name version

<?php
declare(strict_types=1);   // ส่งชนิดผิดจะ error ทันที ไม่ถูกแปลงเงียบ ๆ

function lineTotal(int $qty, float $price): float
{
    return $qty * $price;
}

echo lineTotal(3, 49.5);   // 148.5
// lineTotal('3', 49.5);   // TypeError เพราะ strict_types เปิดอยู่

What I would choose for customers

I've put my conclusions in the order I actually use them. Both Claude and GPT agree on the first point.

1. For school or SME customers on shared hosting, choose PHP (WordPress or Laravel) first, even though PHP has fallen 4 points in one year.
2. For sites mainly used for reading, render HTML on the server and cache it at the CDN; it is faster and better for SEO than an SPA.
3. Add React only where the interface needs complex interaction (Inertia, islands), without turning the whole site into an SPA.
4. Use Node.js when it is genuinely needed, such as realtime or Next.js with SSR; enable NGINX Unit only for packages that need it, or move to a VPS.
5. For new projects where AI writes much of the code, choose a language with types and tests (TypeScript, PHP 8 strict types), specify versions clearly, and check package names before installing.
6. Divide AI work by strengths, and have the other model review important work.

My conclusion is that PHP remains the first answer for small hosting customers' work, even with its declining share, and all the scores in this article are judgments made independently by two AI models that came out very close, not measurements. I'm not saying you have to follow this. If your work has other conditions, such as a team already skilled in another language or servers of your own, choose according to your team's skills and your budget. Market figures may change again after 7 Nov. 2026. If I've left gaps in the explanation or newer figures differ from what I've written, I'll come back and update the article later.