6 ms·

I’d still pick PHP between the two for usual web apps. There is beauty in the statelessness of PHP and also leverage on Nginx (+ Lua) for more critical and high

I’d still pick PHP between the two for usual web apps. There is beauty in the statelessness of PHP and also leverage on Nginx (+ Lua) for more critical and high-speed work. The issue I have with Node JS is that the entire ecosystem moves way too fast. However, when I need realtime interaction via WebSockets fe. it really feels like a good choice.

eropple 8y ago
The notion that the node.js ecosystem moves way too fast is a time-traveling statement from, like, 2012. When it really was, in a lot of ways, true. But today it really has congregated on a relatively small set of best practices and the tools you see today are mostly the tools you would have seen two years ago. They're also mostly the same tools you would have seen five years ago, and plenty of people use "old" tools completely and perfectly acceptably. You don't have to throw out Grunt if you like it, you don't have to rush onto Parcel if Webpack works for you. Because other people still use them and other people still maintain them. Node is no less stable, today, than Ruby or PHP, and is only arguably less stable than Python because Python has largely ossified. SQL database usage is still an ongoing bummer, though.
- randomsofr 8y ago
  I just had a project crash that was setup on 2015 (using gulp), i had to update one dependency and that dependency forced me to update the entire package.json to latest versions, so i had to fix the entire build setup and config files. Same happened with a Rails/React project that was setup last year, i tried to update one package that was marked as vulnerable, but it ended up requiring the same thing. I opted to leave that package. I've been working with node for a long time, but i feel like is the same level of stability since the start. Thats very different with Ruby or PHP, you can have old setups working just fine, maybe requiring some extra steps to build certain dependencies but overall working.
  - eropple 8y ago
    1) React is frontend JS which can be consumed on the server side--but I think a reasonable person might hang Express on Node and raise eyebrows at React. 2) Can you explain to me how updating a Gemfile or composer.json file is not going to result in a similar dependency cascade? 'Cause, from experience, it certainly will if the project isn't dead. About the only environment I've ever worked in where keeping up on your dependencies on a regular basis isn't required is a Java one--and that's assuming you don't care that much about security patches.
    - randomsofr 8y ago
      I know this can be the case for any project with dependencies, but the js community is know for introducing breaking changes even on small releases. There's not such thing as security patches on most js packages.
    - sgslo 8y ago
      Regarding #2, the Ruby sensibility on pulling in dependencies is very different than the Node world's. As an arbitrary example, consider the deps of two similar packages, delayed_job (Ruby, https://github.com/collectiveidea/delayed_job https://github.com/collectiveidea/delayed_job) and Kue (JS, https://github.com/Automattic/kue https://github.com/Automattic/kue). Delayed_job has two dependencies if you're running on Ruby (rather than JRuby): rake and sqlite3. Neither rake nor sqlite3 have any dependencies of their own - in production mode, of course. On the other hand, Kue has nine direct dependencies, each of which have their own. The full dependency tree of Kue has one hundred and eighty two separate dependencies.
- taurath 8y ago
  I've been working about the same way with Node for the past 4-5 years, with only minor adjustments, most of which have been QOL net increases. The paradigm hasn't changed much, and it solve's my employer's problems.
- clon 8y ago
  I had managed to instill into my brain that Webpack is the JS moving target du jour. I am blown away that it has already been "surpassed" before our team managed to even have a serious review of it. Parcel it is then.
  - eropple 8y ago
    It isn't, though. I expect Parcel will eventually be superceded again by Webpack, and continue to use it for new projects because it's more entrenched. And, moreover, it basically doesn't matter. Pick what you like, change it later if you care. (You probably won't.)
- s73v3r_ 8y ago
  "But today it really has congregated on a relatively small set of best practices and the tools you see today are mostly the tools you would have seen two years ago." Has it? I'm pretty sure if I were to ask what those best practices and tools are, I'd get a number of different answers.
  - eropple 8y ago
    Maybe. But I bet they'd be the same ones those people used two years ago, or at least a really close variation.
  - tchaffee 8y ago
    React is more than five years old. webpack is six years old. npm is eight years old. nodejs is nine years old. Anecdotal, but I personally feel like things have stabilized a great deal.
    - s73v3r_ 8y ago
      I'm not sure I agree. React itself, sure. But the tools around a React project? Same with Node.
    - Izkata 8y ago
      I've seen a lot of comments praising Vue in place of React. Likewise, yarn in place of npm.
      - tchaffee 8y ago
        Once every five years? I'm OK with that. I actually see Vue as more filling the gap for Angular. React uses JavaScript as the templating language instead of trying to use HTML attributes to turn HTML into a programming language like both Vue and Angular do. For that reason alone I have zero interest in Vue and learning yet another templating language. I'm pretty sure React will be here for a few more years. User base is still growing in fact. And Yarn is a drop in replacement for npm. Took me 10 minutes to learn. If you already know npm, there is almost zero learning curve.
- kapv89 8y ago
  "SQL database usage is still an ongoing bummer, though." ... have you looked at Typeorm (http://typeorm.io/ http://typeorm.io/)?
  - eropple 8y ago
    I have, actually. This week has made me decide to move away from it. I have been using it, and filed an issue[0] asking them to document the schemas emitted by their entity-tree code; I was then told that I was doing it wrong and that I should use their code-first/synchronization feature and trust in their magic rather than writing my own explicit migrations which are informed by my (tbh, pretty extensive) understanding of PostgreSQL. The code seems fine. But I don't really trust anybody who is that insistent on owning the changes made to my database schema--I am certain it is well-intentioned but it makes me itch. Although I will say that there's an interesting project[1] that creates entities from a database that I need to examine further and see if it's worth using to get around TypeORM's unfortunate primary design goals. [0] - https://github.com/typeorm/typeorm/issues/2453 https://github.com/typeorm/typeorm/issues/2453 [1] - https://github.com/Kononnable/typeorm-model-generator https://github.com/Kononnable/typeorm-model-generator
    - tannhaeuser 8y ago
      That's a common pitfall with ORMs and dumb stacks like Spring data: they're made for unexperienced developers who can't be bothered to understand other technology than their favourite programming language. When it comes to databases however, SQL is the standard, is already at a higher level of abstraction than a primitive record-like abstraction build on top of it, and direct SQL access will be required for any meaningful data manipulation at scale, for locking, for schema evolution, BI, etc. anyway.
    - loliboli 8y ago
      I’d recommend you to have a look at Objection.js: https://github.com/Vincit/objection.js/ https://github.com/Vincit/objection.js/ Objection.js is an ORM for Node.js that aims to stay out of your way and make it as easy as possible to use the full power of SQL and the underlying database engine while keeping magic to a minimum. ^^ copy+pasted from github

eropple 8y ago

The notion that the node.js ecosystem moves way too fast is a time-traveling statement from, like, 2012. When it really was, in a lot of ways, true. But today it really has congregated on a relatively small set of best practices and the tools you see today are mostly the tools you would have seen two years ago. They're also mostly the same tools you would have seen five years ago, and plenty of people use "old" tools completely and perfectly acceptably. You don't have to throw out Grunt if you like it, you don't have to rush onto Parcel if Webpack works for you. Because other people still use them and other people still maintain them. Node is no less stable, today, than Ruby or PHP, and is only arguably less stable than Python because Python has largely ossified. SQL database usage is still an ongoing bummer, though.

randomsofr 8y ago
I just had a project crash that was setup on 2015 (using gulp), i had to update one dependency and that dependency forced me to update the entire package.json to latest versions, so i had to fix the entire build setup and config files. Same happened with a Rails/React project that was setup last year, i tried to update one package that was marked as vulnerable, but it ended up requiring the same thing. I opted to leave that package. I've been working with node for a long time, but i feel like is the same level of stability since the start. Thats very different with Ruby or PHP, you can have old setups working just fine, maybe requiring some extra steps to build certain dependencies but overall working.
- eropple 8y ago
  1) React is frontend JS which can be consumed on the server side--but I think a reasonable person might hang Express on Node and raise eyebrows at React. 2) Can you explain to me how updating a Gemfile or composer.json file is not going to result in a similar dependency cascade? 'Cause, from experience, it certainly will if the project isn't dead. About the only environment I've ever worked in where keeping up on your dependencies on a regular basis isn't required is a Java one--and that's assuming you don't care that much about security patches.
  - randomsofr 8y ago
    I know this can be the case for any project with dependencies, but the js community is know for introducing breaking changes even on small releases. There's not such thing as security patches on most js packages.
  - sgslo 8y ago
    Regarding #2, the Ruby sensibility on pulling in dependencies is very different than the Node world's. As an arbitrary example, consider the deps of two similar packages, delayed_job (Ruby, https://github.com/collectiveidea/delayed_job https://github.com/collectiveidea/delayed_job) and Kue (JS, https://github.com/Automattic/kue https://github.com/Automattic/kue). Delayed_job has two dependencies if you're running on Ruby (rather than JRuby): rake and sqlite3. Neither rake nor sqlite3 have any dependencies of their own - in production mode, of course. On the other hand, Kue has nine direct dependencies, each of which have their own. The full dependency tree of Kue has one hundred and eighty two separate dependencies.
taurath 8y ago
I've been working about the same way with Node for the past 4-5 years, with only minor adjustments, most of which have been QOL net increases. The paradigm hasn't changed much, and it solve's my employer's problems.
clon 8y ago
I had managed to instill into my brain that Webpack is the JS moving target du jour. I am blown away that it has already been "surpassed" before our team managed to even have a serious review of it. Parcel it is then.
- eropple 8y ago
  It isn't, though. I expect Parcel will eventually be superceded again by Webpack, and continue to use it for new projects because it's more entrenched. And, moreover, it basically doesn't matter. Pick what you like, change it later if you care. (You probably won't.)
s73v3r_ 8y ago
"But today it really has congregated on a relatively small set of best practices and the tools you see today are mostly the tools you would have seen two years ago." Has it? I'm pretty sure if I were to ask what those best practices and tools are, I'd get a number of different answers.
- eropple 8y ago
  Maybe. But I bet they'd be the same ones those people used two years ago, or at least a really close variation.
- tchaffee 8y ago
  React is more than five years old. webpack is six years old. npm is eight years old. nodejs is nine years old. Anecdotal, but I personally feel like things have stabilized a great deal.
  - s73v3r_ 8y ago
    I'm not sure I agree. React itself, sure. But the tools around a React project? Same with Node.
  - Izkata 8y ago
    I've seen a lot of comments praising Vue in place of React. Likewise, yarn in place of npm.
    - tchaffee 8y ago
      Once every five years? I'm OK with that. I actually see Vue as more filling the gap for Angular. React uses JavaScript as the templating language instead of trying to use HTML attributes to turn HTML into a programming language like both Vue and Angular do. For that reason alone I have zero interest in Vue and learning yet another templating language. I'm pretty sure React will be here for a few more years. User base is still growing in fact. And Yarn is a drop in replacement for npm. Took me 10 minutes to learn. If you already know npm, there is almost zero learning curve.
kapv89 8y ago
"SQL database usage is still an ongoing bummer, though." ... have you looked at Typeorm (http://typeorm.io/ http://typeorm.io/)?
- eropple 8y ago
  I have, actually. This week has made me decide to move away from it. I have been using it, and filed an issue[0] asking them to document the schemas emitted by their entity-tree code; I was then told that I was doing it wrong and that I should use their code-first/synchronization feature and trust in their magic rather than writing my own explicit migrations which are informed by my (tbh, pretty extensive) understanding of PostgreSQL. The code seems fine. But I don't really trust anybody who is that insistent on owning the changes made to my database schema--I am certain it is well-intentioned but it makes me itch. Although I will say that there's an interesting project[1] that creates entities from a database that I need to examine further and see if it's worth using to get around TypeORM's unfortunate primary design goals. [0] - https://github.com/typeorm/typeorm/issues/2453 https://github.com/typeorm/typeorm/issues/2453 [1] - https://github.com/Kononnable/typeorm-model-generator https://github.com/Kononnable/typeorm-model-generator
  - tannhaeuser 8y ago
    That's a common pitfall with ORMs and dumb stacks like Spring data: they're made for unexperienced developers who can't be bothered to understand other technology than their favourite programming language. When it comes to databases however, SQL is the standard, is already at a higher level of abstraction than a primitive record-like abstraction build on top of it, and direct SQL access will be required for any meaningful data manipulation at scale, for locking, for schema evolution, BI, etc. anyway.
  - loliboli 8y ago
    I’d recommend you to have a look at Objection.js: https://github.com/Vincit/objection.js/ https://github.com/Vincit/objection.js/ Objection.js is an ORM for Node.js that aims to stay out of your way and make it as easy as possible to use the full power of SQL and the underlying database engine while keeping magic to a minimum. ^^ copy+pasted from github