I think these arguments often miss the “for who” both in the producer and consumer sense.
If you have a team or teams of engineers, having one or two people deal with all the dev-ops stuff makes a lot of problems go away.
But if you have a large C++ project for example, you probably need more than a couple people focusing on build and target dev-ops work, or at least a lot more of their time.
It’s a lot easier to get a frontend person to help out with the backend dev-ops than it is to hire a new C++ guru and wait a bunch of time to catch up on the nuances of your build systems/org/whatever.
Anecdotally, I see the people who balk at Node are usually enterprise Java devs, backend Python devs, or junior Go/Rust enthusiasts.
At the end of the day, all these languages can interoperate with all the others in a bunch of different ways, and an organization’s ability to engineer and maintain systems is mostly orthogonal to its choices of “driver” technologies.
Anecdotally, I've met a ton of people who balk at Node for backend stuff. I've been at two companies where it was actually prohibited.
> At the end of the day, all these languages can interoperate with all the others in a bunch of different ways, and an organization’s ability to engineer and maintain systems is mostly orthogonal to its choices of “driver” technologies.
I think people say that in an interest to keep the peace, but the assertion doesn't stand up to close scrutiny. Poor technological choices kill companies, or at the very least, make them perform more poorly. Choosing the right technology is a core skill for technology companies.
The problem is that each company is a goddamn unique snowflake. Company X has a bunch of front-end developers and spends most of their money on headcount. Company Y has a bunch of back-end developers and spends most of their money on infrastructure. The "best language for a project could be R, Python, Go, Rust, C++, TypeScript, C#, Java, or something else. Picking the wrong language can sometimes be outright disastrous compared to picking a good language. But most of the time, there's no clear "best" language.
Even though there's no clear "best" language, these people balking at Node may have a point.
This isn’t merely about tools. They’re one piece of a much larger puzzle. The fragmented chaos of the Node ecosystem arising from that aforementioned ephemerality ensures that eighteen months is roughly the duration before bitrot of dependencies is corrosive enough to have folks talking about rewrites. In four decades driving keyboards in various capacities, I’ve never seen any language experience dependency rot in production apps so rapidly as JavaScript and its offspring.
Aside: any shop operating under the assumption that devops is a function you assign to someone, has already failed devops 101.
I genuinely don’t believe you’re coming at this from a business stakeholder POV, which is fair for HN. But if you have to advocate for a devops org outside of some massive global scale or as a small % of revenue, you’re doing something wrong.
Unfortunately a proven playbook for struggling devops teams is to just fire all the devops and infra folks, which seems to help with platform stability, recruiting, and velocity year over year.
Your opening assumption is false. I start and run businesses.
Any reference to “devops team” is also automatically failing at devops. It’s not a job, a task, or a team. I don’t spare much time for folks encumbered by a silo mindset. It’s the antithesis of a service/product-team approach, and (to the actual point) does nothing to oppose the myopia I’m accusing the JS ecosystem of.
If you have a team or teams of engineers, having one or two people deal with all the dev-ops stuff makes a lot of problems go away.
But if you have a large C++ project for example, you probably need more than a couple people focusing on build and target dev-ops work, or at least a lot more of their time.
It’s a lot easier to get a frontend person to help out with the backend dev-ops than it is to hire a new C++ guru and wait a bunch of time to catch up on the nuances of your build systems/org/whatever.
Anecdotally, I see the people who balk at Node are usually enterprise Java devs, backend Python devs, or junior Go/Rust enthusiasts.
At the end of the day, all these languages can interoperate with all the others in a bunch of different ways, and an organization’s ability to engineer and maintain systems is mostly orthogonal to its choices of “driver” technologies.