Ask HN: Why are so many PHP projects moving to Node?
But since then, and with the release of PHP 7, the language and ecosystem has matured massively. For one, Laravel is excellent - the framework is well designed, the docs are some of the best I've ever worked with, and the developer tooling is (in my opinion) unrivalled.
I work mostly on Node / Java back ends professionally these days, but I find myself almost exclusively using Laravel for my personal projects. THe reason being I'm so much more productive in PHP & Laravel compared to Java. And don't get me wrong, Java is great for building enterprise software, but for small to medium sized web projects it's overkill.
I also have PHP projects which I built well over a decade ago that run perfectly fine today. Meanwhile in Node land it's not uncommon for projects just a few years old to stop working altogether because some package I was using is no longer maintained and hasn't been updated to support the latest version of node. And even when the project still runs the ecosystem tends to change so much that you have to do significant refactors every few months just to keep everything reasonably up-to-date. I think any JS developer can relate to the fact that a good chunk of your time working on JS projects is spent refactoring code because Gulp is no longer being maintained, or LibSass has been deprecated in favour of Dart, or because the community just decided that you need to use React hooks now...
But another reason I don't use Node is simply because JS sucks, even when compared to PHP < 7. It's a poorly designed language that requires multiple layers of tooling just to make it acceptable for use in larger projects. And again, when the ecosystem is changing so often any tooling you're using needs to be updated constantly.
But this isn't a rant about JS. I'm just wondering why in 2023 I seem to love PHP more than ever and the developer community broadly seems to be migrating more towards Node? Can someone explain why I'm wrong about this because when ever I tell any of my Java / Node colleagues that I love PHP they tend to roll their eyes.
65 comments
[ 3.2 ms ] story [ 131 ms ] threadSo when I ask myself “how much do I trust complete strangers on the internet?” the answer is “not much, but even less than that if it’s written in PHP.”
I'd genuinely love some examples.
React: https://github.com/facebook/react
Vimium: https://github.com/philc/vimium
If you want more, here is probably a good place to start: https://github.com/EvanLi/Github-Ranking/blob/master/Top100/...
One could also argue, "why does it matter how it's written, it's not a book and it does what I need to do so that's fine." If it works and you don't have to do anything, great. If you have to troubleshoot it because it broke, then hopefully the code is structured in a way that lends itself to debugging. Otherwise, you might end up having a bad time.
For myself I'd say the lodash repo is well written. Would you agree/disagree?
1. Stylistically consistent for things like format, naming, control and logic flow
2. QA: linted, unit tested, code reviewed
3. Design: Modular, scalable, future proof, secure, stable, reliable, performant etc.
4. High adoption implies testing/verification of above design attributes
5. Follows (or establishes) best established practices for interfacing with platform APIs etc.
6. Keeping complexity low enough that a junior engineers can contribute
7. Descriptive commit messages
etc. etc.
https://github.com/outline/outline
I think the guy who built it posts here. There's also pg-promise, a "Postgres interface for Node.js":
https://github.com/vitaly-t/pg-promise
How did you came to this conclusion? I work with PHP teams daily and they don't think about moving, but even if they did I wouldn't expect them to seriously consider node. Overall I would say that in the last few years there was increase in number of competent PHP developers.
https://www.isitwp.com/popular-big-name-brands-using-wordpre...
So basically people get such misconceptions due to the perception-distorting bubbles that they are in. And not only related to PHP - it applies to any language, stack, technology even the Internet itself...
You wouldn't be able to tell from what's being discussed in programming circuits, but PHP is actually significantly bigger than Rust.
If you look at PHP vs Node in Google Trends, you can see the PHP decline was well on its way before Node.js came on the scene in 2009.
I used to love PHP, but these days JS is good enough that I don't feel the need to look back. My personal JS projects still look PHP-ish in the sense that they're very simplistic, often lacking a build step and often even lacking a framework. I do like having more control over the server logic than what I remember having with PHP (granted this was the days of WAMP and LAMP, and I hear with docker and nginx things are nicer now). I also like the fact that I can go to a single place (npmjs) for both my browser-side and server-side libs because sometimes I haven't decided yet where it'll reside.
Full stack typescript for me is SO much nicer. Occasionally there's code-reuse but more often it's interface reuse for type-safety and autocompletions. This yields a lot of correctness/safety in a large project.
No context or tooling switching.
On a more serious note, i've been thinking recently that the more experienced you become with programming, the more you will thirst for functional programming or something close to it. I think that we see this with the maturation of the modern JS ecosystem too - with a trend towards thinking functionally, rendering functional components, limiting side effects, top-down data flow etc. PHP is not the easiest place to do functional programming. PHP is also not a glamorous place to be. Laravel is cool, but you are still gonna want something like React or Vue if you are building a modern front-end so why not go all-in on JS? I am not arguing for this - but I can see the argument being made by the community at large so I am not surprised to see PHP devs moving into JS.
You are in like the 1% - the mythical PHP hacker who loves the language. You will live a lonely life in your mystical PHP dragon cave high upon the on the hillside of Mount Lerdorf. This is the life you must be prepared for.
Then I saw someone come in and modernize a legacy PHP project. It was a thing of beauty. I think modern PHP is seriously underrated.
Having circled back around to it recently due to full-stack work, I'm now also using TypeScript targetting ES2022, and things are much, much better.
I feel that ES6 was a game changer, it really brought about major improvements to the language.
To be honest, I find it hard to justify using anything BUT TypeScript these days.
* The memory is fuzzy what the comparator was, the point stands
Last time I applied to a PHP shop I killed in the interview, was in the wrap-up where it was totally obvious I was at least a front-runner if not a shoe-in, then watched everyone's faces go white when I named a comp figure. They quickly and politely ushered me out with some "we'll get back to you" niceties. I wasn't trying to be a dick, but after I left I realized I'd probably given a number higher than anyone in that room was making except maybe the owner, and I was not pushing the boundaries of normal comp for a senior dev (what they claimed they wanted in the job listing) in my area. Whoops. Never should have even applied, mea culpa.
[EDIT] Incidentally, this is one reason why it'd be nice if places put comp ranges in listings, and it's why I make sure our notions are at least in the same ballpark up-front, now—I'm never again putting more than a couple minutes into an interview process before making sure we're not irreconcilably far apart on that, since it's a waste of everyone's time if we are.
TypeScript, ignoring about half the language features many of which are "oh my god please never actually use this" (e.g. all the distinctive features of prototypal OO), and finally being able to concisely tell the language to please let you treat async calls the way everyone's always wanted to be able to treat them 90% of the time for the entire existence of JavaScript and Node (async/await) has made the language downright tolerable.
The culture and ecosystem still blows, though, you're not wrong there.
The thing is, most of this tooling isn’t even related to the language itself. In NodeJS, you need basically none of your the tooling. Here are reasons why tooling is used:
- Webpack. Files need to be minified because code is downloaded nearly every time you access a website. (Not a language problem.) This also leads to a whole other class of optimizations like dead code elimination.
- Babel. Can’t guarantee client-side runtime layer, so need to make sure new syntax is transpiled. Not a language problem.
- Eslint. Ideally you’d use a linter in any server-side project, like PHPCS for PHP.
- Typescript. This is a language problem. :p At least PHP has some types now!
On Node, you don’t need webpack or babel or any similar set of tools, because Node can resolve imports and you know which Node version you support. Other tooling, like dependency management and linting, would be normal in other languages too.
On the client, you need a huge set of tools just to deal with the fact that your software is literally downloaded over the internet as part of the startup process. That comes with a huge set of performance optimizations related to bundle size that other languages simply don’t need to care about. That’s why there’s so much extra tooling in the JS ecosystem.
Now IE is dead most people are using Chrome/WebKit based browsers like Edge/Google Chrome/Opera/Safari or other standards-compliant browsers like Firefox.
My main issue with using TypeScript is that you're building in the JavaScript ecosystem. For most things you'll need to use JavaScript packages which typically only have a few years of maturity to back them up.
There's also no standardised way of building things in TypeScript and this was a similar problem PHP had when I first started working with PHP. Back then it was common for developers to copy and paste bits of code from all over the internet into their projects. Every project would be structured differently. The tooling wasn't standardised. Etc..
But today PHP feels surprisingly mature. TypeScript is like trying to build something in Ruby without Rails, or Java without Spring. And now PHP has Laravel which is used almost universally in new PHP projects.
People will continue to roll their eyes. Whether deserved is besides the point. I was no longer interested in being a 'PHP programmer' and have to justify my worth. PHP is by all measures on it's way out. If you are looking at other ecosystems of course you're going to find things that aren't great. PHP has those too but in the 15 years you've been doing it you've created habits that perfectly avoid those. You're not going to attain those same skills immediately elsewhere, and the things that are worse from your perspective are going to stand out more than the things that are better.
You've tied your professional identity to a programming language that people dislike. It's not a fun place to be, but trust me you'll be better off in the long run. This has NOTHING to do with language features, and everything with your feelings and bitterness. Your post is full of emotions. It's not worth feeling this way, it's just a programming language.
Would be very interested to know what you are basing this statement on. 78% of the web runs on PHP.
https://w3techs.com/technologies/history_overview/programmin...
I wouldn't say my professional identity is tied to PHP. I don't even consider it my strongest language anymore because I haven't used it day-in day-out for years, plus the vast majority of my professional experience came prior to PHP 7 and Laravel. I'm more of a PHP 5 + Zend guy.
I use PHP for personal projects simply because I find I'm much more productive with it. Emotionally I love writing Java & TypeScript code because I find both to be beautifully designed languages. PHP is fine and to your point, I have grown to love it in a lot of ways. I do love working with Laravel though, but that's not because of PHP, but just because every 10 minutes I'm thinking, "holy crap, that was easy". Everything you'd want is there and works and it all works as you'd expect.
I eventually lucked into working for a consulting firm who trusted me to work on goland and python and JS projects for two years, and that job on my CV means magically my twenty years of experience is now worth much (~$100k) more on the job market and nobody asks about my PHP work anymore.
You're not wrong so much as out of fashion.
It's very important to recognize how much industry trends are driven by fashion. But being fashionable also makes an ecosystem good. Well, at least makes it better. For certain definitions of better. Lots of development attention that means there's probably a highly visible project building exactly the bells and whistles that will garner praise and more attention for the ecosystem.
You can make your slow, measured, careful decisions about tech to use. But webdev is full of YOLO projects too. Churn and fashion are always going to be at your door.
I also think it's interesting how many TS advocates seem to have popped up in this thread. I find Java to be a lovely language and I think it's fair to say generally most developers agree Java is a well designed language with a mature ecosystem backing it, but I've never met a passionate Java developer. But I hear there was a time many years ago when Java was the hot new technology in town and naming your crappy new language, "Java"Script was considered a good marketing strategy.
React, Typescript, and isomorphic/universal JS.
The reasons for React's dominance is a separate topic, but if you're working with react, node becomes a natural fit for the backed because you can render the same components on the server or the client.
Again, the reason for TypeScript's success is a separate topic, but node is the go-to backed if you intend to build with typescript. All things being equal in the interpreted scripting language world, typescript's type system sets it far ahead of php/python/ruby.
Being able to build with one language for both front-end and back-end is a nice perk, but being able to reuse business logic in both environments is massive. e.g. sharing object structure types and interfaces between environments ensures API ingress and egress remain consistent, the same code used to validate form inputs on the front-end can also be leveraged to produce API validations on the backend and many other use-cases.
One runner-up reason: npm. Yes, npm has had a reputational hit due to some excesses of the ecosystem in years passed, but at the time when node was picking up steam, the php composer experience was terrible, whereas npm set the standard for stupid easy package management... yes, it came at the cost of a 2gb node_modules dir but this is (mostly) a developer vanity problem rather than an actual problem (unlike resolving composer dependency quagmires)
> But another reason I don't use Node is simply because JS sucks, even when compared to PHP < 7. It's a poorly designed language that requires multiple layers of tooling just to make it acceptable for use in larger projects
Any specifics? The reality is that PHP and JS are both wart-filled messes, I certainly don't see any substantive justification for the idea that node is worse than PHP.
Absolutely. The sad thing for PHP is that they had the opportunity to pioneer static typing in web development that TypeScript has made so popular, and finally break from all the quirkyness and crappyness of the language in the early 2010's when Facebook released Hack and XHP (https://docs.hhvm.com/hack/). At the time I worked as a PHP dev and desperately wanted to use XHP (there was a regular PHP extension for it) but couldn't get employer buy-in as they didn't see the point in it.
XHP was basically what React/JSX is now to JavaScript, except for PHP. And Hack is what Typescript is to JavaScript, except for PHP, a sensible, and partial superset of PHP with static type checking. But for years, Hack and XHP languished to get any PHP-dev attention. Why? Ten years ago I couldn't figure it out at the time, but now in hindsight, I believe it's because no one in regular PHP-land at the time recognised the genuine engineering improvements Facebook had just ushered in, because most PHP devs don't approach their work with an engineering mind-set. Could be wrong but that was my experience - a lot of PHP code is just crappy, even in a post-PHP 7+ world, and the only explanation seems to be crappy devs.
> but at the time when node was picking up steam, the php composer experience was terrible, whereas npm set the standard for stupid easy package management
Yes, this is an understatement. Running composer on a Laravel project once, it regularly hit 1.5GB memory usage. This was in the mid-2010's, at a time when Macbooks had like 4GB of RAM. Though granted, npm had the same problem, but with disk space, not RAM.
There was a point where colleges were only teaching Node, as JS was very fashionable. I've reeived applications where the answer to languages known are: Javascript, TypeScript, React, C++.
But, anecdotally, we moved one server to Node during the hype cycle, and that taught us enough to not repeat the mistake.
Others in the industry I have contact with (admittedly somewhat of a self-reinforcing circle) feel the same way.
Unfortunately, it is harder to find a good PHP dev.
EDIT: Actually, in my experience, the pool of PHP devs is smaller, but the average quality is higher.
I'd venture to guess this is because PHP devs tend to be on the more experienced side anymore. Given the sentiment in online groups about how terrible PHP is, I doubt many younger engineers are opting to learn it at all. I know people that develop in PHP, but they have all been doing it for 10+ years now.
For all the love Node/JS gets for having wonderful and well-designed projects, junior programmers still do laughable things with it.
1. The TypeScript tooling with Node has improved tremendously. Frameworks like Nest make it simple to work with it.
2. There are some really good frameworks that, over the years, have remained simple and just work. Example - Express, Sequelize, etc.
3. Same developer can make changes on both the frontend and backend since the language on both sides is TypeScript now. That simplifies building features as less coordination is required for full feature development.
4. Deploying Node apps is overall simpler. Be it VMs, containers, or serverless. Horizontal scaling is cheap, and most applications don't need much processing optimizations there.
To call Javascript "poorly designed" when having a discussion about PHP is… a bit jarring… Both PHP 7/8 and Typescript are huge improvements over their forbearers, but it seems indisputable to me that fundamental Javascript is at least a better-designed language than fundamental PHP (circa v3), and contemporary Typescript is better-designed than modern PHP.
(creds: I've been writing PHP and Javascript since around 1997)
Let's say I want to create a simple app. Nothing complex, it just needs to connect to a database to support some some basic user auth and CRUD stuff.
TypeScript is probably my strongest language, and everyone says it's great so I'll use it for my backend.
Cool. So first thing we need to do is create a user API for signups. I'm going to need a framework for the API stuff. Express is good, let's go with that...
Okay, now we need to talk to the database. Let's install mysql2, seems popular and well maintained, should be okay.. Do I need a @types package? Nope. Great.
Now I need to create some environment config for connecting to MySQL. Going to need another library for that, I guess. dotenv is popular, should be safe enough...
Hm, actually I probably want to set up some logging too just in case there are SQL/DB errors. Going to need a library that. Looks like log4js would probably work. Is it well maintained / safe? Eh. Should be fine, just need to build this thing...
Right, finally connecting to the DB. How do I do DB migrations? Is there a library for that? Hm, let's check Google... Okay, typeorm seems like it might work. Seems quite popular. Let's try that.
Okay, our tables have been defined and we're connecting to the DB. Great!
Now we can finally create the signup code. Hm, actually, going need to validate email addresses. Do I write an email validator? No, don't be silly, this is the JS ecosystem! There's probably a library for that. validator seems popular, I'll go with that. It's probably safe...
Okay, signup done. That wasn't so hard was it? Just need to connect to the SMTP server to send the email verification email now... Erm, wait... How do I do that in TypeScript exactly? Guess I'll need a library for that.
I won't go on but this is the developer experience of just trying to do something extremely simple in TypeScript. But it gets worse because in two weeks when you come back to the project you'll find several of your libraries have been deprecated so you'll need to spend a few hours refactoring and the docs for the 50 libraries you needed are distributed across 22 websites (2 of which are 404ing) and 28 Github readmes.
In comparison all of this would probably take me about 15 minutes max in Laravel and I wouldn't need to install any 3rd party packages. And if I'm honest I could probably do this in Spring Boot faster too without having to worry about installing malicious, poorly maintained packages along the way.
Like, I swear I must be missing something here because while I acknowledge TypeScript itself is great, the JS ecosystem it's built on is awful. So yeah, sure, TS is better designed that modern PHP, but why anyone developer would choose to use TS for their backend isn't clear to me. Unless you absolutely need TS for writing isomorphic code or something then why bother with the headache?
I would also question you're mentioned frequency to update packages tbh. Just pin a stable version with a lock file, track the required node engine and use an OCI image to provide just enough reproducibility. I never had to do anything more than cd-ing into a directory and run npm ci after coming back to a project for a few years now.
I'm not talking about staying on the edge though, I'm talking about connecting to databases and logging - stuff that would be considered basic when working with other languages.
You're right though... If there existed a fully-fledged framework for the backend (with dev tools) which had been around for a few years and fairly stable, I'd consider it. Frontend JS frameworks like Next.js are pretty great. They still feel a bit immature and prone to large changes, but they're on the right track and get a lot of things right.
Also, yes, I would probably still use PHP even without Laravel. I have PHP projects which are over a decade old which use a very minimalist framework I created for simple projects. It still works fine and I haven't changed the framework in over a decade. You're right that you can just pick some stable packages, but what happens when you're running Node 12 and you want to upgrade to 14 or 16? Do you upgrade and risk breaking packages or just continue running an out-dated unsupported version of Node? I've had this specific issue several times now.
I think some people here think I'm saying Node is unusably bad, but I'm not. I'm just saying I don't get why people / projects who would have used PHP a few years back are now moving to Node when Node is still so immature and PHP has improved so much. I guess I'm not sure why my view of PHP has improved so much, while the industry as a whole seems to be dismissing it for the JS ecosystem which in my opinion has a lot of problems.
Most people in this industry are either junior devs that have no idea what they're doing, mid level devs that fall for the hype and don't like "boring" tech (battle tested, reliable) and end up using stuff that's not even production ready, and senior devs that overengineer and optimize prematurely.
Just keep on your path and don't pay attention to the dummies. PHP is great and will never die.
As if suggesting something that doesn't need 12 build steps, 2 transpiler passes, and 4 discombobulator demagnetizations before you finally serve your 2mb of javascript, that will then spend another 5 seconds of your crappy cpu cycles to render something that will inevitably break your back button is some sort of bad thing.
PHP is great and will never die.
Perl & PHP were two examples of languages that were particularly bad fits for their use cases – poor performance, buggy syntax that led to lots of runtime bugs – both were very successful for a time.
To answer your question: Node meets the above qualities reasonably well. It also is ambiguous enough to allow lots of navel-gazing over academic tangential topics so people can avoid actually getting work done and waste a lot of wall & CPU time doing so.
[EDIT]
> To answer your question: Node meets the above qualities reasonably well. It also is ambiguous enough to allow lots of navel-gazing over academic tangential topics so people can avoid actually getting work done and waste a lot of wall & CPU time doing so.
OMG, this is spot on, though. Perfect way to put it.
- PHP's capability is limited in a sense that its main use case is akin to a template engine rather than a full fletched executable. This puts a lot of limit in PHP
- TS steps up JS' game. Like what other have said, TS brings the hassle of maintaining complex codebase down quite a lot.
- NodeJS is a stepping stone for many frontend developers to learn backend because of the same language used.
- JS' syntax and capabilities, while having inherent unavoidable footguns, allow expressive code (I might be partial on this, the last time I used php is a long time ago)
Edit: formatting