Strictly speaking, PHP is… an interpreter with compiler-like qualities.
the nature of PHP (or Javascript, for that matter) is more of an… interpreter with multiple passes.
Javascript does execute line by line…. but it also knows about functions within the entire scope of the current line’s execution, even before encountering the function declaration in the code in its pass. So… it’s parsed the file, one might call that compiled it, and then executes it line by line.
To muddy the waters more, things like Node.js implement JIT (Just In time) compiling, which mixes interpretation and compilation more.
PHP takes the source code and compiles it into what is known as a bytecode. This bytecode is then interpreted by the PHP engine. Relatively recently, PHP also added JIT support that takes things a step further and compiles some of that bytecode into machine code, which can improve speed when code is run repeatedly (like the contents of a loop).
Generally this compile and interpret cycle is performed every time the script is run. In some circumstances one can setup Opcache which allows PHP to save the compilation result and skip it on future runs of the script, improving performance.
I entered the world of programming in 1970 on a mainframe. In those days source code was usually on punched cards that were run through a compiler that produced an object deck of punched cards.
In those days, the definition was that a compiler produced an executable. Later, we used terminals to create source code that was submitted online for compilation, but the output of the compiler was an executable on disk (and backed up to tape). My old brain still thinks that compiled code produces an executable (.exe, for example) that can be stored separate and apart from the source code.
Compilers were invented to reduce code to as close to machine language as possible so that it would execute as quickly as possible. We had interpreters but our processors were so slow that they could not be used for applications that required as much speed as we could muster. IIRC, we only used interpreters for BASIC which was used only for training and for ad hoc answers, not production code.
The world turns and things change. I haven’t had to keep up for several decades; so I’m not too surprised that terms have become a bit amorphous.
I met Adm. Hopper (when she was a Captain) on several occasions. When I was VP of my DPMA chapter, I was programs chairman. We asked Captain Hopper to speak to us. It was my privilege to meet her at the airport and escort her to her hotel and provide transportation locally. I met her on a couple of more occasions at trade shows. She was a remarkable lady and could be as salty as any deck swabbie. They should have given her general rank much earlier than they did.
Web site development can be done using both interpreted and compiled (executable) languages. And interpreted languages are dominant in web development. PHP, Javascript, Phyton, Java, C# etc (interpreted or hybrid) needs an help engine to run the script.
I find interpreted language harder to both grasp and maintain (personal opinion) as I need both a script and an engine (runtime) to run the script. Hence I have chosen the odd path to use a compiled executable language (Go). One single executable with embedded assets was a relief to me.
Start the executable and you are up and running. Way faster than most interpreted languages (as you mentioned). Close to machine code.
I think and hope that the dinosaurs (compiled) will be more common in web development. Rust and WASM. Go and PWA etc. But I guess this will take some time to evolve…
It it still the same today for compiled languages: C/C++, Go, Rust, etc.
Correct, processors are much faster now, making interpreted languages: Python, PHP, Ruby to run fast enough. Some of them uses JIT (Just in Time) compiler to speed up things up.
The Unix OS was created 1971. Linux, MacOS and other Nix types OS, copy from it.
C was created around 73, still the fastest language outthere, in my opinion. The father of C++ (Object Oriented C) and curly braces.
COBOL, is still running in the banks. There is a joke that says, that only 4 people in the world understand what the hell they are doing.
So yes, one of the best things in programming happened in the 70s.
No, not always. For example .Net programs are compiled into an intermediate language (not any specific machine’s instructions) that is then compiled to executable code during execution. My understanding is that Java is similar.
I do not consider the conversion of the intermediate language to the machine’s specific language to be compilation but they say it is. It really blurs the definition of compiler.
Not just banks. COBOL is primarily used in the finance, insurance, government and retail sectors. Nearly 90% of Fortune 500 businesses use COBOL.
I am not one of those four but I do try to correct inconsistencies when I believe they exist. I hope I do not make mistakes but I admit I sometimes do.
You’re right that understanding the environment matters, but I’d also suggest mixing in some practical JavaScript projects so the concepts stick. For me, working on things like scientific math calculators really clarified how frontend JavaScript handles input, performs logic, and updates the UI without needing backend code.
For example, here’s a project I built where the entire functionality runs in JavaScript: online math tool. Playing with projects like this helps connect the dots between theory and real-world application, and it gives you confidence before moving on to backend runtimes and environment setup.
So yes, get familiar with the runtime, but don’t wait too long before coding—both paths reinforce each other.
