4 ms·

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 p

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.

viraptor 3y ago
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.
- wouldbecouldbe 3y ago
  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 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.
  - viraptor 3y ago
    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.
    - wouldbecouldbe 3y ago
      that's simply not true. nodejs v12 is years old, its like using php5 and lots of platforms don't support 5 anymore.
      - viraptor 3y ago
        Security support for node 12 ended in 2022. For php5, in 2018. Those are very different. Rhel 7 is still alive, supports node 8, maybe 12, but nothing higher officially.
        wouldbecouldbe 3y ago
        Yeah that's more an issue with Rhel, but you can solve that easily with NVM https://tecadmin.net/install-nvm-centos-8/ https://tecadmin.net/install-nvm-centos-8/
- bmelton 3y ago
  Why do you have to wait? 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)
  - viraptor 3y ago
    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 https://news.ycombinator.com/item?id=39286669
    - wouldbecouldbe 3y ago
      You really think nextjs is difficult just because one person you knew had a very outdated nodejs version; it's really not.
    - bmelton 3y ago
      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.
hu3 3y ago
> Upgrading PHP version is even more painful, I've tried to do version updates, and was alway easier just to build a new server. I upgraded PHP 7.2 to 8.3 for a business client yesterday. It was a CentOS VM. It took maybe 5 commands, no server restart involved either. I could barely bill an hour and that is because I kept tail -f their logs to see if everything went smooth. And it did. How is that painful?
- Capricorn2481 3y ago
  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
  - hu3 3y ago
    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. Not only it is a framework that has minor usage: https://trends.google.com/trends/explore?q=codeigniter,laravel https://trends.google.com/trends/explore?q=codeigniter,larav... It is infamous for being hard to upgrade. No responsible PHP developer would start a complex project in it today. A typical PHP project in the last years use either Laravel or Symfony. Not to mention PHP has mature tooling to perform automated code upgrade between versions: https://github.com/rectorphp/rector https://github.com/rectorphp/rector The project I mentioned was 4 years old and so far no code change was required between PHP 7.2 and PHP 8.3. And again, my parent was clearly talking about server upgrade: "was alway easier just to build a new server". And the change I had to do was not even multiple lines, it was a single line in a Dockerfile. I found the Pull Request and it was from 7.4 to 8.3: https://i.imgur.com/MmemYSp.png https://i.imgur.com/MmemYSp.png
    - Capricorn2481 3y ago
KronisLV 3y ago
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#when 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.

viraptor 3y ago

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.

wouldbecouldbe 3y ago
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 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.
- viraptor 3y ago
  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.
  - wouldbecouldbe 3y ago
    that's simply not true. nodejs v12 is years old, its like using php5 and lots of platforms don't support 5 anymore.
    - viraptor 3y ago
      Security support for node 12 ended in 2022. For php5, in 2018. Those are very different. Rhel 7 is still alive, supports node 8, maybe 12, but nothing higher officially.
      - wouldbecouldbe 3y ago
        Yeah that's more an issue with Rhel, but you can solve that easily with NVM https://tecadmin.net/install-nvm-centos-8/ https://tecadmin.net/install-nvm-centos-8/
bmelton 3y ago
Why do you have to wait? 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)
- viraptor 3y ago
  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 https://news.ycombinator.com/item?id=39286669
  - wouldbecouldbe 3y ago
    You really think nextjs is difficult just because one person you knew had a very outdated nodejs version; it's really not.
  - bmelton 3y ago
    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.

hu3 3y ago

> Upgrading PHP version is even more painful, I've tried to do version updates, and was alway easier just to build a new server. I upgraded PHP 7.2 to 8.3 for a business client yesterday. It was a CentOS VM. It took maybe 5 commands, no server restart involved either. I could barely bill an hour and that is because I kept tail -f their logs to see if everything went smooth. And it did. How is that painful?

Capricorn2481 3y ago
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
- hu3 3y ago
  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. Not only it is a framework that has minor usage: https://trends.google.com/trends/explore?q=codeigniter,laravel https://trends.google.com/trends/explore?q=codeigniter,larav... It is infamous for being hard to upgrade. No responsible PHP developer would start a complex project in it today. A typical PHP project in the last years use either Laravel or Symfony. Not to mention PHP has mature tooling to perform automated code upgrade between versions: https://github.com/rectorphp/rector https://github.com/rectorphp/rector The project I mentioned was 4 years old and so far no code change was required between PHP 7.2 and PHP 8.3. And again, my parent was clearly talking about server upgrade: "was alway easier just to build a new server". And the change I had to do was not even multiple lines, it was a single line in a Dockerfile. I found the Pull Request and it was from 7.4 to 8.3: https://i.imgur.com/MmemYSp.png https://i.imgur.com/MmemYSp.png
  - Capricorn2481 3y ago

KronisLV 3y ago

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#when 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.