“One ring to rule them all, one ring to find them, One ring to bring them all and in the darkness bind them.” – J.R.R. Tolkien’s Lord of the Rings
The article talked about how one of the most popular blogging platforms on the planet, WordPress, went through a major refactoring of its core architecture. When I say WordPress is one of the most popular blogging/content management systems on the planet, I’m not kidding. According to recent web statistics, there are roughly 75 million websites on the internet powered by WordPress.
Seeing how wildly popular and widespread WordPress has become these days, it stands to reason the company responsible for the commercial version of WordPress would think long and hard before deciding to make any major architectural changes to their wildly popular product.
Yet that’s exactly what happened, according to the article.
To understand why they changed the server side language, it’s necessary to understand the basic architecture of every web application since the birth of the web.
Every web application has two major components
1. The client layer
2. The server layer
The client layer is what you actually see inside your web browser when you type a valid URL address in your browser’s address bar.
Where does the browser get all the client files from? The browser retrieves these files from the server layer, which is the actual remote computer server host.
If you use Google Maps or Google Mail, perhaps you’ve noticed that once your web browser loads either of those applications for the first time in your browser, anything you do inside those apps, like drag the map or zoom in, or move messages from one e-mail folder to another, never causes the browser to do that annoying refresh action, where the page sort of blanks out, while the browser waits to reload the entire web page from the remote server and back to your client’s browser.
Suddenly static HTML websites, thanks to AJAX technology, acted and behaved a lot more like traditional client desktop shrink wrapped software.
Of course, technology like AJAX wouldn’t be possible without corresponding server-side programming language code running on the remote server, to do things like connecting to a database to retrieve data, or web remote HTTP calls to other systems, or any number of things your web application needs from a remote web server to bring back down to the client web browser.
As a software developer, it was a little tedious having to mentally switch gears between using one programming language for all client side code that lived in the user’s web browser and then switch to a DIFFERENT programming language for all the stuff that had to run on the SERVER.
No more mental “context” switching as you force your brain to switch from one programming language to another language.
Now I’m not saying it’s this Herculean task for a software programmer to make the switch. For the most part, other than syntax differences, most programming languages share the same basic constructs like looping, if-then branching logic and object oriented features.
That said, there ARE significant advantages to using a single programming language for a web applications.
Say you’re an organization looking to hire a team of software developers to build out a major new greenfield enterprise web application.
Before the advent of NodeJS, your Human Resources department would have to place different kinds of job postings to the public at large, to find the necessary set of programmers needed for a web application.
Then you’d need to hire a different programmer to handle the server side code that needs to run on the web server. Maybe a Java programmer. Or a C#, Ruby or Python programmer.
It creates additional overheard from a human resources perspective, to have to worry about hiring different kinds of programming with specialized language skillsets.
The cost savings of avoiding the need to hire a new developer to handle server-side programming is HUGE … the company is eliminating the need to hire a full-time salaried engineer to handle server programming.