Hello, community. I hope to spark a thoughtful discussion rather than ignite a war among us. I'd love to hear your perspectives on the following topic.
Over the past decade, I've been immersed in the world of PHP, witnessing its remarkable evolution alongside the growth of its ecosystem. Throughout these years, I've cultivated a robust and maintainable design philosophy rooted in principles like DDD, Clean Architecture, and SOLID. While PHP may not be a flawless language, its continuous improvement has resulted in a positive and smooth programming experience.
PHP boasts an active community, a plethora of libraries, outstanding frameworks, adherence to standards (PSRs), the convenience of Composer, Dependency Injection (DI) containers, and much more.
However, the current trend in the market and among companies leans heavily toward the Node.js, TypeScript, and React/Angular stack. Despite adapting to and working with this stack, I find it doesn't quite match the same ease and fluidity that PHP provides.
Perhaps it's a matter of personal preference or a gap in my knowledge, but the JavaScript stack, especially with TypeScript, presents challenges. While TypeScript offers significant power and expressiveness, it can be easy to inadvertently create a tangled mess in your code. Generics, though potent, are sometimes overused.
Error messages often prove cryptic, leaving me puzzled about what went wrong. Functional programming, while effective in managing application flow, demands strict discipline.
Contrary to the organized principles outlined by Uncle Bob in his Clean Code book, the functional approach seems to encourage a more chaotic coding style with chains, folds, maps, and various other constructs. These constructs, while intending to enhance code readability, often hide behind the original intention of the code. This can lead to an increase in cyclomatic complexity and a departure from the Single Responsibility Principle, which should be applied even in the context of functional programming.
Library stability and standardization, comparable to PHP's PSR, seem lacking in the JavaScript community. While there are libraries for almost everything, custom solutions are frequently necessary. For instance, working with message brokers reveals a notable absence of mature options akin to Symfony Messenger.
My experience has been marked by moments of frustration. It could be attributed to my reluctance to leave the comfort of what I know best.
Nevertheless, I persist in believing that PHP remains a viable and compelling stack even in 2023.
What are your thoughts? I'm eager to hear your perspectives on this ongoing debate.
Top comments (32)
PHP is and will consistently be a viable choice for at least the next 10-15 years and beyond as it is taking the right steps to modernize itself, yet the JavaScript panorama has almost gone over all the challenges thrown at it becoming, today, a totally legit leader in the developers' world.
I agree with the fact the ecosystem still has to reconcile with all the latest changes and trends, but a new wave of developers will surely help with it.
I want to conclude by remembering one thing: Languages shouldn't fight with each other, but prosper in a continuous improvement cycle.
Thank you for sharing your opinions.
PHP is undergoing a non-trivial evolution, thanks to the professionalism of many capable people in the ecosystem: cleaning up the type-system, and the core libraries, strengthening and updating the core functionality/performance, strengthening the concept of a programming language and not that of a scripting language. it is not a simple path but notable features have been created. The difference will be made by additional elements such as structured pattern-matching and the possibility of nesting elements and/or more effective data structure, leading arrays to specific roles. These aspects together with the strengthening of the CLI model and the possibilities of execution in the Cloud (not just the Web, going beyond the Web) can lead to a serious reevaluation of PHP in addition to its simplicity of learning and immediacy of implementation. Some resources are: nativephp.com/ static-php.dev/en/ roadrunner.dev/ frankenphp.dev/ bref.sh/ github.com/hyperf/hyperf and all async framework as AMP, Revolt, ReactPHP, FrameworkX, ...and youtube.com/watch?v=5YtNugpMhyQ
Peace For All! ;-)
Hello Christiaan and fellow developers,
First off, what a refreshing call for peaceful dialogue in the sometimes tumultuous world of programming languages! As a veteran in the PHP arena, with more years under my belt than I'd care to admit, I'm delighted to hear about your experiences and insights.
PHP, the Grand Old Duke of York of programming languages, has indeed had its ups and downs. But like a fine cheese, it only gets better with age. The evolution you describe, from a simple scripting language to a fully-fledged platform rich in frameworks and libraries, is nothing short of remarkable.
Your remarks on the 'newer' technologies like Node.js and TypeScript are spot on. They're like those new, flashy sports cars ā everyone wants a ride. But let's be honest: in everyday reality, we often benefit more from the reliability and familiarity of our old, trusty SUV, or in this case, PHP.
The dilemma of TypeScript's complexity and the cryptic nature of its error messages is something many PHP developers can appreciate. We've had our own battles understanding PHP's quirks, but at the end of the day, it feels like coming home ā familiar, comfortable, and efficient.
The strict discipline required by functional programming and the quest for stability in the JavaScript community are interesting points. PHP, with its PSR standards and Symfony Messenger-like mature options, offers a kind of structured freedom that's missing in many other languages.
It's true that we sometimes get stuck in what we know best, but isn't that the essence of being human? PHP is like that old friend who never lets you down, even when the newer, shinier things catch your eye.
So yes, PHP in 2023? Absolutely a viable and attractive choice. It's like that comfortable chair in your living room ā maybe not the most avant-garde, but definitely the one you always return to for reliability and comfort.
Keep coding and let's keep the flame of PHP alive ā not just as a legacy of the past but as a robust platform for the future.
I personally do not consider Node.js nor TypeScript to be the hot flashy cars people think they are. If anything deserves that kind of recognition (based on performance and ease of use) it should be Golang. It's a refreshing language that encourages strong typing and has performance out of the box. True, Golang is not built for UIs, which is why I much prefer Dart for that space. My main point is, people just simply can't let go of JavaScript and move on to better things
There is much said in your post and you are tackling the problem from many sides. But one thing may be above all - your love for design.
I started with a PHP 5 that had OOP itself, but the code was PHP 4 procedural obeying what the company mentors decided (no frameworks). PHP code not only didn't bother to behave with good manners, but people were laughing at the matter to the point where it was thought you are lazy and not doing work if you are thinking too much of such "high-spirited" things. The complexity of the code was managed by people that were paid more - there weren't that much people that could do it.
With time, design principles and patterns were adopted in communities, companies, developers and we started wanting more and more to write clean code and to have a unified understanding of what it is. The complexity started becoming an issue and simplistic code started becoming preferable. The computer science was recognized much like mathematics you could talk with people all over the world and they would know the meaning of the symbols.
It isn't PHP that makes good code, PHP adopted good code from elsewhere when good code became fashionable. There is nothing traditional in strong typing, anonymous functions, generators and traits. We were fine coding without it. Systems were working, no one complained. TypeScript doesn't break the rules and discipline is about mentorship (how the science gets applied in practical context).
Good code also is shades of gray. Laravel promoted certain degree of good coding, but you could still argue that facades aren't promoting good discipline - you could use facades everywhere for example. See Tailwind - writing CSS classes and using no external CSS. You could say that it violates the responsibility principle but the author of Tailwind argued that in time he saw the opposite. Tailwind earned millions. Laravel was packed with Tailwind and now companies are looking for Laravel developers who are writing Tailwind.
If you ask ChatGPT to write you code obeying good principles, it will generate it and you just copy-paste it - you can ask it to be a DDD with repositories and services and entities. It generates the code in 0.1 ms. and it does it for everyone no matter of experience. The code is good enough and now it's just time to glue it all together and design it without coding it. We cannot make a point that it's good to do manual labor when there is an automated solution.
So to answer the question of whether PHP will be the viable alternative, we have to find and measure its social value somehow (the value of information plus the value of authority/source of information plus the value of connections between people which cannot be measured).
It's not going anywhere any time soon. Laravel is a great PHP framework that I'd recommend.
Yes, I agree.
I know and appreciate Laravel.
I also did several speaks at the Italian Laravel Day (the Italian Laravel conference)
Honestly IĀ“m not a PHP specialist. I do not even like PHP very much. There is just a simple reason to use PHP, it is available on most servers and it is a way to access data on the server. So, I cannot really jugde about the language. Attributing all variables with a $ reminds me a bit on thimes when variables could only have 8 characters, feels a bit like using punch cards.
The way, PHP is integrated in HTML is a pure nightmare. Substituting source code by echos is an absolut nogo, and I have seen quite a lot of source code that did exactly this: Generating lotĀ“s of HTML by Echos. What a poor way to do things - a shell game for freaks, definitely a noGo!
Usually I would like to separate codes, put every language in a separate file, but this does not seem to be the way PHP is intended to be used. Is there any good reason to use different languages for the same purpose? It would be ok for me to use PHP, if I could use it on the frontend too, but frontend code is written in JS or TS. So, why not use it on the backend.
A computer language is just a way to tell a computer what to do. Why use different languages to do the same?
Your perspective on PHP is understandable, and it seems you may have encountered some outdated practices. The issues you raised about variable naming conventions and PHP's integration with HTML are valid concerns, especially if you've come across code that doesn't follow modern best practices.
However, it's essential to note that PHP has evolved significantly in recent years. The problems you highlighted, such as generating HTML using echoes, are considered outdated practices. Nowadays, developers leverage frameworks with template engines that separate logic from presentation, offering cleaner and more maintainable code. Standards like PSRs (PHP Standards Recommendations) have been established to guide developers towards best practices, and a plethora of libraries and tools are available to enhance PHP development.
Regarding your question about using different languages for the same purpose, the diversity of languages often stems from their strengths in specific areas. While PHP is commonly used for server-side scripting, JavaScript (JS) and TypeScript (TS) dominate the frontend. However, with the rise of technologies like Node.js, developers can use JavaScript on the backend too, providing a more unified language experience.
In essence, the landscape of web development has evolved, and PHP has adapted. Embracing modern PHP practices, exploring frameworks, adhering to standards, and leveraging the available tools can significantly enhance your development experience and the overall quality of your projects.
Thank you much for your detailed answer. It is not easy to guide yourself through the jungle of moden web development.
Different languages āāhave existed for as long as computers exist, but in the case of PHP and Javascript there are mainly historical reasons, why one or the other is used. There had been a good chance that we had to use Visual basic on the browser, if Microsoft had been a little more successfull. So, it is as it is.
For me itĀ“s more question: do I really want to learn another language? The triage of HTML, CSS and Javascript is confusing enough. PHP adds another level of complexity that I would like to avoid. I had been working with Pascal for a long time, and it took me month to stop me from writing := for everey variable assignment.
I think, we will have to live with PHP for a while, and maybe the ecosystem evolves and makes the usage even more appealing. But currently I would be completely happy to find some usable code that was written by people that know better than me how to do things right.
I used to work with Delphi about 20 years ago, then switched to Java, and later to HTML/CSS/JavaScript and PHP as the backend.
After that, I used to work with Flex/ActionScript and Java as a backend before going back and sticking with PHP for the last ten years.
Changing languages can be tough, but it's part of our field. The industry and the languages we use keep evolving, so continuous learning is necessary.
The triage that you described, HTML / CSS / JavaScript are frontend technologies. PHP instead is for the backend.
So if you're not into full-stack development, you can stick with the frontend. Otherwise, if you're not keen on learning a new language, consider trying out Node.js.
But, if you're open to something new and miss writing
:=, why not give Go a shot? It could bring a fresh perspective and add excitement to your skill set.Just remember, being adaptable and open to change is important in our ever-changing field.
Hy Christian,
the Browser ecosystem is pretty powerful and uniform today, so this was my first choice as a platform. I tried to remove some of the limitations of the "HTML / CSS / JavaScript"-system and enable a more "Delphi-like" design pattern. Maybe you like to check out my "DML"-project, which I have used in a number of projects now. This allows to build applications very close to the DOM, so results are pretty fast. You can use the homepage as an example, as it was built completely with this approach.
Anyway, thank you for your advice. I know many people work with Go, so I will have a closer look on it.
Hi Eckehard,
Thank you for sharing your project. It's an interesting approach, and I've actually used something similar in the past, before JQuery became popular.
In my humble opinion, this approach is great for study purposes. However, for larger projects, it might pose challenges such as browser compatibility issues and the risk of "reinventing the wheel."
Just to clarify my stance, are you able to leverage npm packages? Is importing/exporting through files an option in your project?
I strongly believe that "standing on the shoulders of giants" is often a more prudent approach than building something entirely from scratch. There are numerous opinionated libraries and frameworks, tried and tested daily by thousands of developers. These established tools provide a level of reliability and versatility that can be challenging to replicate in a bespoke solution, especially one tested in limited scenarios.
Certainly, there are instances where creating something new is necessary, and that's perfectly fine. However, it's essential to recognize the wealth of existing solutions that can save time and offer a more robust foundation for your projects.
And for your request to see something well-built in PHP, I want to link another article of mine, where I talk about a good design pattern applied to PHP.
Let me know what you think
Following your advice I had a close look to Golang.There is also a Go to JS-compiler, but the most common way to write applications in Go seems to build some server siDe app, so it is a replacement for PHP, right?
For my purpose I will need at least some code running in the frontend, and there are a lot of interactions that can be handled in the browser.
My ultimate environment would be one where you write just one single code, and decide later (or even dynamically) which part runs where. So, depending on the target platfom, different code and ressources are generated. Sounds impossible? Its just what people do with "partial hydration", just in a more general sensel
Yes, that's right. Go is a server side language. I suggested it only for the
:=notation. But of course, I don't think one should choose a language/framework only for a small detail like this.I'm not sure I understood 100% what are your purposes. But it sounds like you are looking for a Full-Javascript stack, like Nest.js or similar, with a server-side rendering. With this kind of framework, you write your code in Javascript/Typescript, and part of this code could run in both, frontend and backend.
But I'm not a Javascript expert and I never develop anything using those frameworks. But give it a shot and let me know if it does satisfy your needs
IĀ“m using the browser more like a traditional programming platform, so ultimately I don't care where the code runs. Just the result matters. There are good reasons to run some code on the front end and some on the back end, but the internet adds a layer of delay and complexity between them, which is complicated to deal with. IĀ“m just looking for a system that helps to bridge the gap.
The browser ecosystem is very uniform today, if you avoid to use the latest features (see caniuse.com), your code will run on virtually any machine. So Javascript was a good option for me. But even if you run javascript on the server, it does not fully solve the problem. But running anything on the backend is not an option for me.
Browsers provides a large number of very powerful APIĀ“s, which are most valuable. The HTML5-canvas is one of the best 2D-graphics systems I have ever used, and it is increadibly easy to create images and flawless animations with it. And, ontop you find tons of visualization libraries like D3 or Plotly, that help you to do amazing things. If you use PHP all the time, how do you use this features?
Yes, browsers nowadays are very powerful, and now I think I better understand your use case.
I used to work in cross-functional teams as a backend developer, then as Team Lead and ultimately as a Training Manager, so back in the day, there was always someone who did the frontend part for me.
There are two main problems that I can see in a browser-only approach, and they are:
1) Storage: Yes there's a browser local storage, but it has limits in size and can be erased very easily
2) Security: Everything is pretty visible and you can hack the application very easily using the debug bar. You can also change the values of properties in real-time.
If you then want to create a local application that runs without the internet layer, an interesting option could be a standalone Desktop Web Application. The trick is to wrap your HTML+JS+CSS code into a "naked browser", a browser that runs without all the menu and buttons, and also that has more powers than a classic web application. For example, you can write on the disk or call several OS APIs. This will solve the two issues mentioned above.
For doing that, several frameworks help you a lot.
ElectronJS is one of them: electronjs.org/
Absolutely true, there are a lot of limitations on the "browser only" approach, as much as there are limitations on the "server only" approach. But maybe we can make an advantage of the structural limitations of the internet if we choose an approach where a code can run anywhere. So, you may run tasks on one or several servers but on the same time run some code in the front end and care only to limit the data shifted over the internet.
There are some examples that show the direction IĀ“m looking for:
I could think of something pretty similar for application development, but this would not go far if you need to fiddle around with fetch requests. Think of HTMX, where all the Ajax is done in a layer, that is hidden from the user. But HTMX is not a programming language, but an extended HTML package. We should have something similar for a full featured programming language (not necessarily Javascript).
Use templating engines who writes php.code in html
Sounds intersting. Any example?
Laravel has got blade Symfony has got twig. Ideally you wont use vanilla php now even if you do you would use twig
PHP is still a viable choice for programmers in 2023 and will continue to remain so in the years ahead, depending on the project requirements and preferences. According to April 2023 statistics published by W3Tech, PHP is used by 77.4% of server-side websites.
vm.pl/news/why-is-php-still-a-good...
While PHP does have its advantages that you have already outlined, PHP also has some disadvantages, such as security vulnerabilities, inconsistent syntax, lack of native support for multi threading.
PHP is still a good choice for web development especially for small to medium-sized projects, legacy systems, and data-driven applications. However, for large-scale, complex, and high-performance projects, PHP may not be the best option.
dev.to/robertobutti/why-php-2e4h
PHP is not going anywhere, I have worked on Node, Rails, Python and PHP is still a great choice.
I think yes, but you need to use async libraries, or runners alternative to PHP-FPM (like Roadrunner, Swoole, ReactPHP, or similar).