4 ms·

php stands out for being extremely simple to use for new comers

by sdfb 8y ago

jadell 8y ago
You can do event-driven and non-blocking IO in PHP. Check out a library like ReactPHP.
Lazare 8y ago
There's a ton of basic CRUD apps and REST APIs being written in node for which the event-driven model is useless at best, and actively harmful at worst. Looking around at actual production node code, huge swathes of it could easily be written in Rails, Django, or Symfony with no real loss of performance or developer productivity. (And given the maturity of those ecosystems, probably a net gain in developer productivity. Example: ORMs aren't great at everything, but sometimes they save you a lot of time, and Node doesn't have an ORM that can compare to ActiveRecord, Doctrine, or SQLAlchemy.)
- outside1234 8y ago
  CRUD is literally what node.js is built for - lightweight APIs that then have to do some slow operation async against a store - which they overlap requests across with an event-driven model
  - Lazare 8y ago
    I'm honestly unsure if your post is sarcastic or serious.
    - abraae 8y ago
      Ha, I have the same feeling, even after several re-reads.
  - benatkin 8y ago
    Yes, and it doesn't have a big enough advantage for it to be picked up. Usually developer productivity and memory use (node doesn't cause memory leaks but it doesn't prevent them either) is more of a limiting factor than the execution model. Node has found plenty of use outside of what it was originally built for (the canonical examples are web servers). As far as I can tell, it's used more widely and critically as a tool for packaging client-side scripts or for client-side applications (vscode, electron, Slack). Examples of places where it seems like node would be an obvious choice, but it's not: blogs (WordPress still reigns), Mozilla's Add-ons (runs on Django [1]), Slack (very heavy user of JS on the front end, but backend is coded in PHP [1]), Zapier [2] (Python backend, though custom integrations are often written in JavaScript) 1: https://github.com/mozilla/addons-server https://github.com/mozilla/addons-server 2: https://slack.engineering/taking-php-seriously-cf7a60065329?gi=c414f3d4bb41 https://slack.engineering/taking-php-seriously-cf7a60065329?... 3: https://zapier.com/engineering/automating-billions-of-tasks/ https://zapier.com/engineering/automating-billions-of-tasks/
brightball 8y ago
RoR changed the entire scene with convention over configuration and a total commitment to developer productivity. It's still top of the line in that regard. There's nothing out there that will get you from concept to market faster with a polished product. Even as a giant fan of Elixir, Rails still has a firm place in the "choose for a new project" bucket.
- lucidone 8y ago
  I'd use Laravel over Rails for a new project in 2018. The community is more active and correspondingly the freebies more modern. Rails' front end story became a ghetto once SPAs became a thing.
  - brightball 8y ago
    That’s a bit strong. I’ve extensively used both and there’s no advantage for an SPA with PHP over Ruby. If your goal is an SPA and your backend performance is a concern you’re better off with Go or Elixir than either of them.
    - lucidone 8y ago
      No inherent advantage, but Laravel shipping Vue as a default requires 0 config and the community has crystallized around it as a result, whereas Rails' Webpacker isn't a default in the install and puts the onus of choice on the developer (no convention over configuration there) for framework, structure and best practices. If you're an experienced dev, this is a nitpick. But for new users, this is a major hurdle. Edit: as an aside, I'd rather use Rails or Laravel for an api unless the backend had to be a set of microservices for some reason. Less time writing architecture, more time writing biz logic :).
      - brightball 8y ago
        That makes sense. I can appreciate the pragmatism, especially if you're a Vue fan.
seba_dos1 8y ago
If I would have to decide between PHP and Node on who changed the status-quo the most back in the day of introduction, I'd rather say it was PHP.

php stands out for being extremely simple to use for new comers

by sdfb 8y ago

php stands out for being extremely simple to use for new comers

jadell 8y ago

You can do event-driven and non-blocking IO in PHP. Check out a library like ReactPHP.

Lazare 8y ago

There's a ton of basic CRUD apps and REST APIs being written in node for which the event-driven model is useless at best, and actively harmful at worst. Looking around at actual production node code, huge swathes of it could easily be written in Rails, Django, or Symfony with no real loss of performance or developer productivity. (And given the maturity of those ecosystems, probably a net gain in developer productivity. Example: ORMs aren't great at everything, but sometimes they save you a lot of time, and Node doesn't have an ORM that can compare to ActiveRecord, Doctrine, or SQLAlchemy.)

outside1234 8y ago
CRUD is literally what node.js is built for - lightweight APIs that then have to do some slow operation async against a store - which they overlap requests across with an event-driven model
- Lazare 8y ago
  I'm honestly unsure if your post is sarcastic or serious.
  - abraae 8y ago
    Ha, I have the same feeling, even after several re-reads.
- benatkin 8y ago
  Yes, and it doesn't have a big enough advantage for it to be picked up. Usually developer productivity and memory use (node doesn't cause memory leaks but it doesn't prevent them either) is more of a limiting factor than the execution model. Node has found plenty of use outside of what it was originally built for (the canonical examples are web servers). As far as I can tell, it's used more widely and critically as a tool for packaging client-side scripts or for client-side applications (vscode, electron, Slack). Examples of places where it seems like node would be an obvious choice, but it's not: blogs (WordPress still reigns), Mozilla's Add-ons (runs on Django [1]), Slack (very heavy user of JS on the front end, but backend is coded in PHP [1]), Zapier [2] (Python backend, though custom integrations are often written in JavaScript) 1: https://github.com/mozilla/addons-server https://github.com/mozilla/addons-server 2: https://slack.engineering/taking-php-seriously-cf7a60065329?gi=c414f3d4bb41 https://slack.engineering/taking-php-seriously-cf7a60065329?... 3: https://zapier.com/engineering/automating-billions-of-tasks/ https://zapier.com/engineering/automating-billions-of-tasks/

brightball 8y ago

RoR changed the entire scene with convention over configuration and a total commitment to developer productivity. It's still top of the line in that regard. There's nothing out there that will get you from concept to market faster with a polished product. Even as a giant fan of Elixir, Rails still has a firm place in the "choose for a new project" bucket.

lucidone 8y ago
I'd use Laravel over Rails for a new project in 2018. The community is more active and correspondingly the freebies more modern. Rails' front end story became a ghetto once SPAs became a thing.
- brightball 8y ago
  That’s a bit strong. I’ve extensively used both and there’s no advantage for an SPA with PHP over Ruby. If your goal is an SPA and your backend performance is a concern you’re better off with Go or Elixir than either of them.
  - lucidone 8y ago
    No inherent advantage, but Laravel shipping Vue as a default requires 0 config and the community has crystallized around it as a result, whereas Rails' Webpacker isn't a default in the install and puts the onus of choice on the developer (no convention over configuration there) for framework, structure and best practices. If you're an experienced dev, this is a nitpick. But for new users, this is a major hurdle. Edit: as an aside, I'd rather use Rails or Laravel for an api unless the backend had to be a set of microservices for some reason. Less time writing architecture, more time writing biz logic :).
    - brightball 8y ago
      That makes sense. I can appreciate the pragmatism, especially if you're a Vue fan.

seba_dos1 8y ago

If I would have to decide between PHP and Node on who changed the status-quo the most back in the day of introduction, I'd rather say it was PHP.