Choosing a web framework: php, python or node.js? Personal reflections of a developer.

Published on
6,467 Points
2 Endorsements
Last Modified:
Editor's Choice
Which language to choose for your next web project? Python, PHP, or maybe Node.js? Which framework to choose? Should you go with Symphony, Yii, or Laravel in PHP world? Django, Pyramid or Flask in Python world? Or maybe go for Feathers, Sails, Meteor, or plain Express in the Node.js world?

Having spent the last 20+ years operating mostly in the CMS universe, the time has come for me to see what else the web development ecosystem has to offer, and what has changed in the recent years. In my half-year journey, searching through the plethora of web pages and fora, going through docs and tutorials to dozens of frameworks, I realised that the issue of "what to choose" for the next project is a problem facing so many developers. So, taking into account that everything I write here is my personal opinion, resulting from a particular time and context, here are my reflections on the choices available. 

The rumblings below are not to be read as anything else but my personal opinion on what I found to work for me. I do not intend to suggest what is the best way forward for you - as far as I know, there is no such thing as the best way forward! Creating software is a kind of a divergent task that has many possible paths, and none of them can be objectively called "the best one." One thing I am certain of is that whatever might "look best" today will be outdated and replaced by new tech very soon.

Frameworks come and go

I read this phrase on some websites, and it struck me as a very useful observation. There have been so many frameworks in the past, and most of them are today either gone or so obscure that no one bothers to use them. Other frameworks had their great place in history, and are also very much gone - but not forgotten! A couple of frameworks, like jQuery, have been extremely influential on the whole ecosystem of web development tools, and they changed the world. They changed the world, and can now rest in peace and glory! Fewer developers use jQuery, because it changed the javascript so much, that it is not needed anymore in most use cases where it was applied in the past - e.g., to ensure cross-browser compatibility of the front-end code.

Another aspect to the "coming and going" of the frameworks is that if your project is expected to live for several years, you may not necessarily want to experiment with newly discovered gems, no matter how shiny! In our world, not just digital, a simple rule seems to work almost every time: an older, more mature product (or service) has a better chance of surviving another day, than a younger product. Of course, only until the next technological disruption takes place, and makes that product obscure. For me, the conclusion was to put more weight towards the older tech stack - and in the universe of three kings: PythonPHP, and JS, for the server-side PHP is a clear winner in that category. People may say "PHP is dead," but my objective observation is that over 80% of all websites are powered by PHP. Not bad for a "dead" language. Node.js, while certainly a rising star, is the youngest one, and only time will tell if 10-20 years from now it will match the survival rate of PHP.

Another aspect of framework popularity is the size of the community (i.e., how easily you can get help? How many people before you stumbled onto a similar problem and asked for a solution on a Stack Overflow? Interestingly, there seems to be a correlation between how popular a framework is and how well it is documented.


When it comes to front-end, you have just two basic choices: generate your pages on the server-side, or use full-blown JS engine to run your front-end. You may want to choose some full-stack JS solutions like Meteor. However, you should be aware that the creators of Meteor have pretty much abandoned it's further development, focusing on GraphQL for the last couple of years. Since October 2019 Meteor has a new home, where it may start growing again. You may also consider approaches like Vue+Nuxt or Vue+Quasar, which support SSR (server-side rendering), but these, in fact, trick you into setting up a back-end node.js server, while claiming to be front-end solutions. To me, it meant that they the SSR solutions employing tricks like hydration of the content, and client-side takeover, are useful mostly if you plan to use JS for your back-end development. 

Realistically, it is not possible to escape JS in the frontend these days, e.g., for reactivity, animation, and ajax calls. All one has to choose is one of the available toolset ecosystems, e.g., jQuery, Angular, React, Vue, etc. My personal choice was Vue, but only because I found it easiest to learn and most pleasant to use.

As of the beginning of 2020, a new approach is gaining popularity - server-fetched partials. A technique used e.g., on GitHub site, uses ajax calls to dynamically replace parts of the page with new content. As a result, the page is both dynamic, replacing only part of the page content with each update, and at the same time, server-side rendered.

Front-end --dev tools

In the old days, you could just code your CSS and JS, include it in the head of the HTML page, and push it to deployment. Not any more. With tools like webpack available to the developer, even if you use a non-js stack for your backend, you may not be able to escape the necessity of using a bit of node.js tooling for pre-processing your stylesheets and scripts. If you want your assets compiled, scripts minified, and optimised for fastest page loading (e.g., using code-splitting techniques), as of today, you may need to include some node.js-based tools to ensure smooth compilation of your assets. Some non-js frameworks include a simple set of tools to assist you with this - e.g., PHP's Laravel includes Laravel-Mix which installs all required node modules for you.


First of all, I decided to skip Ruby and Java in my search for the next framework to use. Why? Ruby - because it is still a niche solution, after so many years, so I do not expect it to suddenly gain popularity. Java - because, (a) from my experience many years ago, Java typically usually requires more lines to achieve the same solution compared to Python/PHP/JS, but most of all, because there is no big choice of cheap java hosting out there. Granted, there are some options, but most likely, you'd have to go with a VPS - and for me, it was not a preferred choice. 

So, three kings left on the stage: Python, PHP, Node (JS).

Initially, I wanted to drop the PHP from the list - it was supposed to be dead, right? I also despised the fact that a typical PHP app is not a long-running process; it re-starts from scratch for every single request - not very optimal, right? That's why JS solutions looked so advantageous in tests measuring how many "Hello world" requests per second you can squeeze out of your app.

Given that I spent a couple of years focusing on data science, Python looked like a decent choice to me. Sadly, it was an alien body to pretty much all other developers I cooperated with. And it did not work that easily with front-end frameworks like Vue (e.g., Flask Jinja templating system had a conflict using {{ syntax }}). In fact, I was not able to find that many pros of using Python against using Node.js. The only exception was when the application used a lot of data analysis or machine learning tools, like sci-kit, pandas, etc. - then Python would be my first choice.

Then I turned my search towards Node.js universe. I studied FeathersSailsStrapi, plain Express & KoaMeteor. All in all, I decided to give Strapi and Feathers a solid try. I liked them both until I stumbled onto three issues that actually made me turn away from Node.js:

  1. The size of the node_modules folder. It's like a black hole! An empty app scaffolding takes anything between 200 Mb and 0.5Gb. And once you start adding modules to do this and that... enormous, and without a really good justification! Moreover, once you try to deploy the app, most of these modules go onto the target server, too - effectively, I would have to reserve at least 1-2 Gb per application, no matter how tiny! I did perceive it as a problem, given that on a shared server I was able to host 10+ PHP/CMS sites. So, costs would actually go up, rather than down, and I'd have to purchase many more.
  2. The complexity of deployment. Ok, I admit, I'm lazy - but going through the steps to deploy a Strapi or a Feathers app, got me rather discouraged. I do tend to use web tools on an ad-hoc basis, rather than for huge projects, which you deploy very rarely and then only maintain. In my particular setup (and I realise I'm quite atypical here), when I expect to deploy 10+ small apps each year, it was a strong argument against choosing this path.
  3. Most of my current stack is PHP+CMS. I had to create a number of additional, small tools dedicated to special support tasks (which is the main reason I started the whole research of the web frameworks), so mixing it with either Node.js or Python was a bit more difficult than adding another PHP tool to the stack.

Following a number of conversations, I turned again towards PHP. Here, my choice seemed to be easy: go for YiiSymfony, or Laravel. I dropped Yii as the less popular one. Then I got stuck with a choice of Symfony vs Laravel. Symfony is smaller, which I liked - a scaffolding of a basic app with authentication was about half the size of Laravel, and about one-tenth (!) the size of most Node.js frameworks. Well, almost... I soon realised that to use Laravel Mix, I have to download the Node.js stack as well - but at least it stays on the dev end, absent in the production environments.

Based on the data available online, Symfony is supposed to be less popular than Laravel. However, that turned out to be huge misinformation. Why? Because Laravel uses Symfony! So, quite naturally, frameworks and CMS systems like Laravel, Drupal, Joomla, which use Symfony, actually should be added to the numbers describing the popularity of Symfony. Furthermore, Symfony got me with its documentation - the best one I have seen for any framework. With a massive library of videos, and each of the videos with full transcription.

Surprise-surprise, in the end, I decided to go with Laravel. After a bit of further research, and after getting through a couple of tutorials for both frameworks, this article helped me make my decision: PHP Frameworks: Choosing Between Symfony and Laravel

And the rationale was very personal and very subjective - Laravel works well with Vue.js (which I chose as my front-end framework), and it requires less code to achieve each of the typical core tasks, compared to Symfony. And, as I already told you, I'm lazy - so that made my choice ;-)

Ed: To learn more about the author, please visit his Experts Exchange Profile Page.

Ask questions about what you read
If you have a question about something within an article, you can receive help directly from the article author. Experts Exchange article authors are available to answer questions and further the discussion.
Get 7 days free