For example, I have a little webapp that I built with create-react-app with typescript and redux. Very convenient overall admittedly. It's not very big, maybe 1k lines of code total, and 3 fairly minor packages added to do various things. The node_modules folder has over a thousand items in it, and takes up 350MB. The yarn.lock file alone is half a megabyte. Ahem, what the hell? At least the built artifacts are pretty small.
This might be seen as just a problem with create-react-app. But in my experience so far, pretty much everything in the Node world does this. Seriously, has anyone managed to do something useful in the Node world without ending up with a thousand packages?
I also don't particularly care for "async everything" by default. It makes your program more difficult to reason about. Rather than dealing with concurrency in a subset of your application, you now have to worry about it _everywhere_. There are only a few classes of software where the async-everything approach even makes sense.
Throw in the fact that the ecosystem is an absolute dumpster fire and you have more than enough justification.
I hate Python and could go on all day about what's wrong with it, but it doesn't suck. I use it when it is appropriate for the task at hand, but find it is rarely the best language for the job - given what I know and what I prefer.
Most people that hate a language also avoid it and, therefore, tend to not have made their peace with its shortcomings, so don't have an honest reckoning.
It is unfair to completely disparage a language until you have fully figured out how to understand and work with it, warts and all. Frankly, until then, you aren't yet informed enough to make a summary judgement. You are just cherry-picking your dislikes.
I have rarely heard a criticism that did anything but highlight the critic's lack of knowledge. For example, there is a common criticism about the lack of a standard library. Well, that is how the ES or Node ecosystems are structured. It is not a flaw - it is just a different approach. If you work intelligently within that paradigm, it is actually quite nice. If you hold onto your expectation that a standard library is a part of any respectable ecosystem, you're going to be perpetually dissatisfied with ES/Node. It may not be what you like or expect, but it is not inherently wrong or lacking.
Parenthetically, anyone who makes the standard library complaint about Node just doesn't know Node. It has a very complete set of functionality natively, for its purpose. It is not going to offer much in the way of math operations, sorting algorithms, etc. That is not its purpose. If you want those things, you can add them.
If you think that a given dependency is too big, too small, incomplete, or poorly managed, write your own, and publish it like many have done.
But be warned - if it gets popular, there will be no end of complaints about what's wrong with your library because ... well ... it is actually developers who suck. We have opinions and are quick to convince ourselves that those opinions are fact and anyone who disagrees is not as smart as we are.
That is, Node.js out of the box is really just a javascript runtime. You need a package to serve html, you need to decide on an application architecture and organizational structure, you need to choose an ORM. You need to make a lot of decisions that other web frameworks like Django or Rails just make for you when you build a project.
The lack of opinionated defaults has some benefits: - It gives you a ton of flexibility - It makes it easy to learn the framework, since there's no magic. - It forces the team to really understand what the application does from first principles, again since there is no magic.
The other side of this coin is that flexibility often leads to architectural chaos, and working with Node can feel very slow, since you're constantly reinventing the wheel.
The reality is that 80% of the things I'm building basically just need some variety of MVC with a reliable and predictable way to connect to a SQL database, and Node doesn't feel like the right tool for that job.
EDIT: To add a more constructive comment: Don’t worry too much when people hate on a given language and don’t try to make a decision based on what tool or language people are complaining about. Every tool has its usefulness and its drawbacks.
https://i.redd.it/h7nt4keyd7oy.jpg
I remember back in the late 2000's/early 2010s, there was a blogger, I think at google, who claimed that "the next programming language has already been chosen for you". In retrospect, he was clearly talking about javascript, which got a tremendous push from the big tech players despite all its obvious problems. Now we are stuck with a mess of code written in an ugly language.
Why the big guys picked javascript, I don't know. Maybe to ensure that everyone was so bogged down in dependencies, language incompatibilities and callback hell that no competitors would arise?
EDIT: It was Steve Yeggie, back in 2007: https://steve-yegge.blogspot.com/2007/02/next-big-language.h...
That said, I have found that the .NET ecosystem is an agreeable way to build the kind of software I need to build. I don't think my product would be infeasible in a Node.JS ecosystem, but it would certainly be more painful for reasons that are specific to our problem domain.
If I had to take a shot across the proverbial HN language war deck, I would say that dependency management is the biggest reason I would prefer to avoid Node.JS on future projects. I have a very complex .NET code base which uses 3rd party dependencies you can count on one hand. Our customers really enjoy that kind of thing.
It has some flaws sure, but unless you’re going out of your way to use poor practices or using node for a task it isn’t great for, that’s kinda on you right?
Used node for many things, including services currently in use by many millions of users. It’s just a tool in the toolbox, so use it like one where it makes sense.
- lots of people don't like Javascript
- lots of people don't like V8
- the guy who made Node.js (Ryan Dahl) doesn't like it either
- programmers think anything without thread support is a toy
I like Node.js, Javascript, and Ryan Dahl, and have no strong opinions on V8.
The early perceived coupling with MongoDB didn't help.
Go's standard library comes with a lot of the same batteries built in and while I write more code in Go, the compiled binary is small (good for container management) and I use less dependencies.
So that last sentence is the key. When I was writing a lot of Java, I learned to curate my dependency graph carefully. When writing in Go, I've become even more careful to only use widely-adopted packages though I'm a bit more lenient with test-only package.
I've predominately stopped using Node.js because it's dependency graph is simply unmanageable. Node.js itself provides a facade of multiprocessing as well as other niceties you'd expect to find on the server-side but to do anything substantial you either need to code it yourself or you adopt a huge dependency tree. Downstream security vulnerabilities and bugs mean you're continuously updating versions and it's not always pretty.
Now that I've adopted the write a bit more code and use fewer dependencies mentality, perhaps I should try another project in Node.js. I have to admit that Typescript (and even some of the EMCA improvements) also make it more attractive.
I work with a range of languages - go, rust, python, ruby, and yes even JavaScript. In my 15 years as an engineer most of the engineering teams tasked with a node project I've worked with enjoyed it quite a bit. Those who didn't struggled because they were still learning the more functional patterns used in the node community, and it required some relearning given the languages they came from. In my experience 99% of the time those who express a hatred for node have never programed with it, or lack experience. Now given that there are shortcomings like any tool or language. But hating it - doesn't make any sense to me unless your ignorant of it. It's a fantastic programming environment. By the way if anyone thinks that JavaScript is on the same level as PHP I invite you to visit PHP sadness.
If you design a tool (or DSL) you must tailor it to the problem it needs to solve. It must not be overly generic while still covering the entire scope. This is extremely hard and it usually takes a few versions for a language to get it right.
Then we take the DSL and implement it in an entirely different situation(????) Look, I can use my wrench to hammer in nails!
What to say? The nails are indeed going in. Massive structures are erected. They are structurally sound but it just doesn't look professional to people who are used to hammers. I'm going to be using a hammer until end of time. I tried holding the wrench over the nail but I just couldn't bring myself to hit it.
(with hammer I mean PHP)
First of all: 1) I'm a self-taught developer 2) I spend last year building my app on MERN stack
The problem with JavaScript technologies is that you have to add many dependencies into your project. Each module / library / framework has their own documentation which is time consuming if you are self-taught to go through it
The question really is: - Is .NET or any other framework so called "battery included" ? or I also need to add hundreds of dependencies i.e. authentication -> password hashing, jsonwebtokens etc.. - As .NET or any other framework requires more code vs Node.js -> does it pay off later on during refactoring? Means is it more productive vs any JS framework?
I'm really considering to spend next year learning C# with .NET because being solo dev it's really time consuming constantly monitor what did change and what needs to be refactored. JS stack doesn't help with maintaining the project in a long run (or I have limitted knowledge) it is really time consuming stack tbh
I agree that creating a simple CRUD app for web course it is easy but if you need to do something more advanced...
Should I start learning C# ? or .NET also require thousands of depedencies i.e. file upload (multer docs!!! Man I know them almost by heart now...)
Whereas... I had worked with php, python, R, and once I got to NodeJS I fell in love with it. Then picked up ReactJS
And man, so glad I went this route. I never have to apply to jobs again, given the hunger of recruiters for full stack JS devs
I don't use it for full applications so I don't have some of the same issues that @ufmace mentions (ouch!) and those are clearly a problem.
I suspect that a lot of the hate comes from people that would like a better Node.js so they could use it but resent that it isn't available
https://insights.stackoverflow.com/survey/2021#most-loved-dr...
Being popular means you get a lot of criticism. Same happens to java, PHP, and any other popular language.
I think this is self evident but maybe someone else will care to list some usage statistics.
Most arguments, even in this thread already, are just wrong. Obviously they have never had any experience with the Node.js ecosystem and another.