I'm probably too fatigued with "js fatigue" to talk about it that much in depth, but I'll say that tool authors have a lot to deal with, and use-cases to handle that not everyone cares or thinks about.
This is a similar situation with TC39 and how people complain why there are so many OO features and that JS should be a "functional" language. But JS is used by a lot of people, and in many different situations/environments.
In a similar way tools should try to work "out of the box" but defaults can be hard, and not everyone will agree on what those are. It does seem to go back an forth in this cycle of "being able to do everything, everything is configurable" and "no config, only the basic use case is supported and you have to fork otherwise". Convention and configuration happens, and people have different views on whether you should build on top of tools, create new ones, integration, make "plugins", etc. I think we should admit it's a difficult problem? Something can be a lot faster, have less config but there are tradeoffs being made. But having new ideas can bring change to the larger/fatigued projects too.
Personally babel-preset-env has been my try at beginning to combat this kind of thing. Even though that itself is complicated it helps to make decisions easier for the end-user. It helps the project since there's less choice in the presets, and allows for other decisions to be made instead. Reducing the amount of choices is a goal for us, so there's always improvements to be made.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Dan had a nice talk/post about this.
I'm probably too fatigued with "js fatigue" to talk about it that much in depth, but I'll say that tool authors have a lot to deal with, and use-cases to handle that not everyone cares or thinks about.
This is a similar situation with TC39 and how people complain why there are so many OO features and that JS should be a "functional" language. But JS is used by a lot of people, and in many different situations/environments.
In a similar way tools should try to work "out of the box" but defaults can be hard, and not everyone will agree on what those are. It does seem to go back an forth in this cycle of "being able to do everything, everything is configurable" and "no config, only the basic use case is supported and you have to fork otherwise". Convention and configuration happens, and people have different views on whether you should build on top of tools, create new ones, integration, make "plugins", etc. I think we should admit it's a difficult problem? Something can be a lot faster, have less config but there are tradeoffs being made. But having new ideas can bring change to the larger/fatigued projects too.
Personally babel-preset-env has been my try at beginning to combat this kind of thing. Even though that itself is complicated it helps to make decisions easier for the end-user. It helps the project since there's less choice in the presets, and allows for other decisions to be made instead. Reducing the amount of choices is a goal for us, so there's always improvements to be made.