plus you don't need to restart any services or rebuild servers. Just git pull and you have the new code on the live server without even a second of downtime
Nah, not simpler, nextjs is simpler then php to start working with. Also running & deploying nowadays is easier. PHP used to be easiest, but fell behind.
This very much depends on what you are building and how experienced you are.
If you just want a few pages, no need for background workers or database migrations, PHP is still the king. You download one of many single-executable LAMP servers, and start writing your index.php. Deploy? Just copy files to server. Zero downtime deploy? Copy files to server and use symlink to atomically switch versions. Dependencies? Composer (package manager) is a single-file script, you can place it wherever. Pain only begins when you want to break away from file-based routing, or need custom .htaccess and nginx.conf, or want to isolate components, or need Redis and cron for background jobs.
On NextJS side, I knew a few people who wanted to start their career with it and the experience wasn't smooth. You install nodejs... but your distribution only ships Node 12, so everything is failing with cryptic errors. You search how to upgrade Node, and get caught in nvm vs n vs asdf flamewars. Once you found a working solution (which probably required you to edit env variables), you run the npm command... and it wants root access? To install packages system-wide? So you google around, find a way to make it use the user home directory. Then you are up and running, you aren't sure what this "React" thing is, but you get stuff done. Time to deploy - and you are told to either learn Docker (and Kubernetes if you want zero downtime), or to use one of few hosting companies with a price markup. Well, at least there is a free tier (for now), so most people choose the latter. Was this a simple start?
Now, when it comes to big apps, I'd very much rather use Nextjs than PHP, it is production-tested, gives you a lot "for free", JS LSP is built-in to VSCode, I already know React and most of JS ecosystem. But if somebody tells me that they just finished learning HTML and vanilla JS, and they want to do something simple server-side, I'm torn on what to recommend nowadays.
You haven't worked with Vercel. Just connect your git account and you have a fully git-flow based server, with preview urls for every PR. Especially for small projects ideal.
Running it on a VPS is a skill on it's own, for both, if users had known to use NVM (which is explained in most top articles in Google) it would have not been a problem and if they don't know they should accept the learning pains of running productions apps (PHP, node or whatever), or otherwise use a managed service such as Vercel.
Upgrading PHP version is even more painful, I've tried to do version updates, and was alway easier just to build a new server. And also requires specific knowledge of apache, or nginx. Let alone deal with server outages, backups, restart, memory issues.
This is just intellectually dishonest. It completely depends on whether your libraries have breaking changes and how your app is structured. Many legacy projects use old versions of ORMs and frameworks that don't support PHP 8. So now you're also upgrading code igniter and you're looking at hundreds of files that call it's ORM
No. If we're talking about tech debt (that's not what parent was talking about by the way) then JS is a magnitude worse. Running old projects from JS ecosystem can require multiple miracles, not only code refactoring.
And your example, codeigniter, is one of the worst examples in PHP.
Nobody said js wasn't worse, just that your experience is not the experience of most PHP upgrades.
Saying Code Igniter is not used in a lot of places because of Google trends is wrong for a lot of reasons, but the biggest of which being your graph shows laravel and codeigniter neck and neck a decade ago. Who cares whether new projects are started in code igniter? PHP is mostly legacy apps, and there are other frameworks with similar nightmare stories.
Again, JS is bad too, but we have to completely rewrite sites due to some PHP framework upgrades because PHP let's people do really dumb ORM templating.
I have no idea what you're referring to with your distinction between tech debt and server upgrades. I'm talking about server upgrades, clearly. I'm just saying if you upgrade PHP on an old project chances are things will break. This happens with Laravel and Slim too.
Then it sounds like we disagree on what the thread is about. When I hear "I updated PHP and everything broke" I think "because libraries break between version upgrades." You seem to be arguing against a position that people aren't taking, which is that there's something inherently wrong with PHP as a language that makes it break when upgraded (which nobody has said).
The same goes for Node, which doesn't break servers just because you upgrade it. I have updated from 12 to 20 with no problems because of the dependencies.
> Again, JS is bad too, but we have to completely rewrite sites due to some PHP framework upgrades because PHP let's people do really dumb ORM templating.
I even quoted this part specifically in my reply:
> because PHP let's people do really dumb ORM templating.
You misunderstand me, I'm saying it has as much to do with PHP as it has to do with JS. Node doesn't break on upgrade because of JS, it breaks because of dependencies that don't work on new versions, as does PHP.
it was when I had to move php5 to php7 5-6 years back, and if I remember correctly a few OS libs didn't support php7 so that was really hard. Was faster to build a new VPS, since no big DB or storage was easier.
You might have had a smooth experience, and happy for you. But PHP didn't have, maybe it does now, such a good version manager as NVM.
But yeah we also had once where all the way back where we didn't do it with NVM and that was a pain in the ass.
You normally want to see things locally as you develop them. Vercel is cool and all, but doing a git push and waiting for the build every time you want a refresh? Nah, that's not viable. And almost everything mentioned above for deployments applies to your own dev machine as well.
Okay then your comment is weird, windows & mac dont have distribution with node versions lower then LTS. It can be an issue on ubuntu/linux having an outdated registry. But nextjs clearly states minimum node version in their docs: https://nextjs.org/docs/getting-started/installation
And how to install every version you want NVM, that's on the user if it didn't work. That's not something different then can happen with PHP or other tools as mysql in the LAMP setup.
The context here is the "starting with" situation. It's much easier to do that with PHP since you normally don't have to care about versions there - barely anything requires version higher than in LTS. On the other side it doesn't matter what is clearly documented, or which registry is up to date - a person looking at this for the first time is either going to have an easier life or not. Nextjs effectively has extra steps you need to know about and follow.
It's fairly normal to run some version of `npm run serve` with a filesystem watcher that will hot-reload changes as they occur so that you can see changes every time you hit :w (or CMD+S or whatever saves a file on your filesystem)
The context is about the initial setup and the parent comment recommended vercel git flow. Yes, you can run it locally, but that's back to the "getting started" issues: https://news.ycombinator.com/item?id=39286669
Okay. I think it's fair to say that if you don't install the tool you're developing in, it does make it much harder to work in locally.
That's equally true of PHP.
Moreover, it's equally true that distros aren't always shipping the latest PHP versions, and that there are similar flamewars surrounding phpenv/pvm as there are nvm/asdf. There are options, and people have opinions. The more ensconced one gets in an ecosystem, the more easy it is to know which tools offer which benefits relative to your needs. None of those decisions are easily made when new to an ecosystem -- Elixir is newish and has enough coalescence around most of the mainstream things, but as someone new to it, if I needed to choose between Cowboy and Bandit, I would have quite a bit of learning required upfront.
From where I stand, both of you have some good arguments, but in my eyes the technologies are similar enough for the differences not to matter too much.
I just use Docker for both local development and remote deployments, with bind mounts of source code when I'm working the code, sometimes with appropriate remote debugging set up. I don't even care that much about what packages or versions are available on my workstation OS, as long as Docker (or another OCI runtime like Podman) works. Same for external dependencies, like Redis, RabbitMQ, MariaDB/MySQL/PostgreSQL and so on, they can just be throwaway containers, or maybe something more persistent in a cloud deployment.
I can even start with an Alpine/Debian/Ubuntu/whatever base image and install the packages myself in whatever order I want, to use as a base image for all of my apps. And on the server, I can run whatever cluster I want, since Docker Swarm or Nomad will be way easier to use for most use cases than a full distro of Kubernetes (although K3s is fine). That takes care of scheduling, health checks, restarts, resource limits and reservations, storage, networking and a lot of other concerns.
I usually have some sort of a web server as a reverse proxy in front of everything anyways (Apache/Nginx/Caddy/Traefik/...), so it's no big deal to add a bit of configuration. Even on PHP side, setting up PHP-FPM is a few commands and any configuration for either is sufficient with either environment variables, or changing a few files. Maybe a Bash script for an entrypoint that does the setup for every container launch, based on the needed configuration.
As an aside, with Apache you often don't really need to use .htaccess since disabling it and using configuration files under sites-enabled is better for lower IO, much like Nginx, since you don't need to scan every directory to look for the file: https://httpd.apache.org/docs/current/howto/htaccess.html#wh...
Node is fine. I don't even need to use nvm locally, I can just have different base images for containers with different node versions and then easily check how easy it would be to carry all of my software over to something else (by swapping out the base image), without messing around with installing stuff manually. As for installing packages "globally"? Who cares, it's all inside of the container image anyways, so suddenly that distinction doesn't matter in the slightest.
I don't need any external services or PaaS providers, it's just a container that I can run on pretty much any VPS host and horizontally and vertically scale as far as I need. Regardless of whether inside of the container there's JS, PHP, Java, .NET, Ruby, Python or anything else. This is especially nice when I can use Woodpecker CI or Drone CI, or GitLab CI or pretty much anything else and not worry about polluting workspace folders, the builds use containers.
And with modern frameworks and libraries, it's pretty hard to go wrong: Express and Next are okay, Laravel is okay, Spring Boot is okay, ASP.NET is okay, Ruby on Rails is okay, Django is okay, there's a lot of established options out there. Do they have pain points? Sure, but they hardly matter. Docker solved software development for me.
Honestly, just use whatever works for you. jQuery has its place, so does Node and PHP. I think I even have some Perl running somewhere.
PHP is great for getting started, but I think it gives you a fundamentally flawed idea of how the web works. You tend to think in files, and not worry about what Apache or Nginx are actually doing.
Then when you switch to node, or basically any other language, you wonder where your file based logic is, and everything feels annoying and painful.
Do you really need to host your own server to run a single file? Yes, you do with PHP too, but it’s hidden in Apache and php-fpm.
The funny thing, even with React and Next, it’s ultimately just files served via a Webserver and I believe it’s the least flawed version you can get without building your own implementation of a TCP server which support HTTP (good luck with that btw ;-)).
Nowadays the basics are just abstracted away and talking with developers today who might even have never seen the basic version of an on old-school Webserver or a simple HTTP request executed manually via telnet runs sometimes into really weird error and root causes analysis.
So sometimes I wish the younger developers would know a bit more from the old world while the older developers now a bit more of the new world of web technologies (apache and a cgi driven bash script are not always the best solution even if you can squeeze ultimately everything into making even that work depending on your time and sadistic level :-)).
Most of the modern solutions out there have been developed to solve very specific problems for a certain group of people (see the difference between React and Angular in that regard) and not always the solution everyone seems to use is the best for your problem, team and business.
Opinion: If more product teams had one person high up who felt embarrassed by even one of the things in your third paragraph we'd have significantly better tech.
I guess as someone that likes php and is meh on Next JS and uses both for most of their job, this seems like an unfair comparison. You have node woes listed here, but nothing about different PHP versions or the headache of migrating from 7.4 to 8 (which every app is overdue for). And while composer can be good, managing php extensions is a nightmare in my eyes. Xdebug in particular is bizarre to me. I'm so used to being able to debug something in an IDE by default that I'm surprised when I switch to a certain PHP version for a project and forget the debugger won't work here until I set up the extension again.
Two years ago I learned from some Twitter post a new habit: every time you install an app on your phone, you must do one more step: block its notifications.
You don't need any notifications from apps as long as this is not an instant messaging app. (You can make additional exception for your banking app, but that's it for 90% of users)
I've had almost the same apps installed for years now, but is that really necessary? Just disable the notification channel after the app sends the first undesired notification.
Instant messaging apps don't need notifications either. It upsets some people at first, but it is for the most part perfectly fine to just check and respond messages in your own preferred frequency.
For me this becomes worse: If I don't get (reliable) push notifications for things I want updates on, I tend to become obsessive over checking it. The more different things I am checking this way, the worse it becomes in terms of disruption to my focus. Push notifications unify multiple streams together and let me go 'I don't need to check this, I'll get a notification if there's any update'.
I could agree: it always depends on personal preferences or usage scenarios. Even I have some IM apps' notifications disabled and I check them only once in a while.
But some IM I treat as a really instant communication channel with my family: I don't want to miss any message from my kids or "I am at grocery, do you need something?" from my wife
the only apps that i have with notifcations are, as you mentioned, instant messaging apps and apps that i'm using to build a habit (language learning, meditation that sort of thing). everything else is turned off
my story: when my kids were in age around 5 yo, obviously they were watching YT cartoons, but this will not be story about ElsaGate, this knows everyone.
Some algorithm decided it is good to show during cartoons vasectomy ad. This is weird enough, but somehow I can understand this failed reasoning (kids -> tired parents -> no more kids -> vasectomy).
But this ad consisted only from one slide presenting intersection of penis and nothing more. For long seconds my kids were staring at it before I reacted and turned it off.
I also reported this to my country's authorities and I got some answer they gave Google some fine for this.
I tried figure out what I can build with this framework (web apps? native apps?) and what programming language I have to know to use it and after few clicks, also into doc, I gave up.
From the code samples it looks like it might be Ruby, but the documentation doesn’t seem to confirm or deny it either way.
EDIT: I accidentally clicked on the ‘past submissions’ link on HN, and if the titles of its other submissions are to be believed, the language is actually Elixir.
EDIT2: Yes, it’s probably Elixir — the front page mentions it once or twice (though not prominently; I had to search for it).
I asked for flights from Poland to Cancun, Mexico in May 2024. It told me I can with Wizzair (the operator operating in Europe only) with stopover in Kyiv, Ukraine (lol).
Maybe it can connect to Google Apps but can't give reliable results.
I learned this hard way (ok not hard way, I had balance of 2 USD at that time) when Revolut locked me out. They simply stopped releasing new version of their app for Android version I had. Day by day I lost access to my money.
I simply got error that I can't log in and I should update an app but there was not any update.
Took me two days to get to their support (I don't know how it is now, but at that time all ways was directing me to use support option in app which was not functioning). And support told me if I want to get my 2 USD I should buy a new phone.
2 USD is nothing to continue the fight but I've understood I don't want to give any money to such operator. I am not Revolut user for more than 6 years now.
I'm not sure how it is in the US, but if you cancel a bank account here in Europe, you're supposed to add your new bank account number so that they can transfer your remaining balance there. The issue with PayPal is that you don't have any rights when it comes to your money. If they lock you out, as far as I can tell, your money is just gone (or in order to even have a chance of getting it back, you'd have to go to court).
