3 ms·

I've used nodeJS at 3 of the past 4 startups I've worked at (currently using PHP). I had a hand in choosing it at all those 3 places and my main reasons boiled

I've used nodeJS at 3 of the past 4 startups I've worked at (currently using PHP). I had a hand in choosing it at all those 3 places and my main reasons boiled down to: 1. most devs know JS (so it's easier to hire & onboard new devs) 2. while everyone claims node's dependencies are hell, I love the choice available (although over time, it's tiring). 3. The community is generally awesome (helps during meetings, online etc.) 4. Developer Exp: With TS, Tslint etc, devx is not too bad IMO (and there's no dearth of opinionated articles around on the correct way to do things) 5. Finally - we can quickly churn out prototypes for features to production (but I guess that's more experience than the tools?). 6. In general, we'd be using JS on the frontend anyway (React), so it just made sense to use one language everywhere. 7. In general, most tools have JS SDKs and JS language support is always around (an exception I found was Tensorflow) - as an example, AWS Lambda supports Java, Python and JS.

oddlyaromatic 9y ago
I'm pretty much a beginner developer, doing a few small things but not employed as a dev. I like JavaScript, and when I wanted to do server side stuff (like automate schedule emails at my company), solutions were really available in PHP and it worked right away on my local machine with mamp and on my super cheap web hosting, whereas I seem to hit various setup pains when I try to do something with node. The PHP syntax was close enough for me to be much more comfortable than I expected to be. I recently worked on something that logs a user in to a mobile-unfriendly website, scrapes and parses a specific page that you would want to see on mobile, and presents a nice mobile view, with some extra relevant information. All the scraping is done in PHP and it just returns json that gets displayed with a handlebars template. It's just a demo right now, but my point is that even knowing a bit about JS, PHP feels so much more accessible than node for me, and I've done stuff that a year ago I never would have thought I could do. I feel like solutions are close and only require language and library research. Node solutions also require this other layer of knowledge that I haven't clicked with. How is PHP treating you at your current job?
vacri 9y ago
> while everyone claims node's dependencies are hell, I love the choice available (although over time, it's tiring). So... at one place I work, we use nodejs. There are so many modules added using so many files, that we ended up not being able to use our packaged application - extracting the package into a holding dir before moving into place meant that we ran out of inodes on the filesystem (stock 8GB ubuntu ext4 cloud image)! The filesystem could not hold two copies of our app, basically, due to inode exhaustion. The easy workaround was "increase the size of the disk", which seems silly given it's 80% free space. This has apparently been fixed in recent times with flatter npm structures, but watching the nodejs community run into every single packaging roadblock that has been solved before is just disheartening.
- Daishiman 9y ago
  Seriously, Node has been the worst platform when it comes to managing its ridiculous (in a bad way) ecosystem of packages where there's no standardized solution for anything.
- nailer 9y ago
  > watching the nodejs community run into every single packaging roadblock that has been solved before is just disheartening. Deeply nesting packages was specifically designed to fix the issue that other packaging systems have: two dependencies needing different versions of a third dependency. Flat-where-possible structures (ie, npm v3 and up) were designed to improve this. They're excellent and npm is the only place I've seen them.
- ohstopitu 9y ago
  I had this issue initially when I was developing on Windows. We hit the limit of Windows's 255 char file path limit. We also have had issues with node_modules takes minutes to download to the point that we basically had to cache it in our CI builds - which in itself was a really bad idea (thankfully Yarn seems to fix a lot of those issues)
  - douche 9y ago
    Seriously. NPM/bower downloads are at least 50% of our CI build time - which also includes compiling a largish C# solution, running unit tests, generating PDF documentation, building an installer, and putting everything through ReSharper code inspections. That's when those download/install steps don't just fail for some unrecorded reason.

oddlyaromatic 9y ago

I'm pretty much a beginner developer, doing a few small things but not employed as a dev. I like JavaScript, and when I wanted to do server side stuff (like automate schedule emails at my company), solutions were really available in PHP and it worked right away on my local machine with mamp and on my super cheap web hosting, whereas I seem to hit various setup pains when I try to do something with node. The PHP syntax was close enough for me to be much more comfortable than I expected to be. I recently worked on something that logs a user in to a mobile-unfriendly website, scrapes and parses a specific page that you would want to see on mobile, and presents a nice mobile view, with some extra relevant information. All the scraping is done in PHP and it just returns json that gets displayed with a handlebars template. It's just a demo right now, but my point is that even knowing a bit about JS, PHP feels so much more accessible than node for me, and I've done stuff that a year ago I never would have thought I could do. I feel like solutions are close and only require language and library research. Node solutions also require this other layer of knowledge that I haven't clicked with. How is PHP treating you at your current job?

vacri 9y ago

> while everyone claims node's dependencies are hell, I love the choice available (although over time, it's tiring). So... at one place I work, we use nodejs. There are so many modules added using so many files, that we ended up not being able to use our packaged application - extracting the package into a holding dir before moving into place meant that we ran out of inodes on the filesystem (stock 8GB ubuntu ext4 cloud image)! The filesystem could not hold two copies of our app, basically, due to inode exhaustion. The easy workaround was "increase the size of the disk", which seems silly given it's 80% free space. This has apparently been fixed in recent times with flatter npm structures, but watching the nodejs community run into every single packaging roadblock that has been solved before is just disheartening.

Daishiman 9y ago
Seriously, Node has been the worst platform when it comes to managing its ridiculous (in a bad way) ecosystem of packages where there's no standardized solution for anything.
nailer 9y ago
> watching the nodejs community run into every single packaging roadblock that has been solved before is just disheartening. Deeply nesting packages was specifically designed to fix the issue that other packaging systems have: two dependencies needing different versions of a third dependency. Flat-where-possible structures (ie, npm v3 and up) were designed to improve this. They're excellent and npm is the only place I've seen them.
ohstopitu 9y ago
I had this issue initially when I was developing on Windows. We hit the limit of Windows's 255 char file path limit. We also have had issues with node_modules takes minutes to download to the point that we basically had to cache it in our CI builds - which in itself was a really bad idea (thankfully Yarn seems to fix a lot of those issues)
- douche 9y ago
  Seriously. NPM/bower downloads are at least 50% of our CI build time - which also includes compiling a largish C# solution, running unit tests, generating PDF documentation, building an installer, and putting everything through ReSharper code inspections. That's when those download/install steps don't just fail for some unrecorded reason.