[Cymen]

What tooling are you using that is slow? Sometimes it's all down to configuration and "you could do it that way but it takes eons..."

For example, on a recent project I added prettier to eslint and tried eslint-plugin-prettier however it was very very slow (like multiple minutes for an eslint run). I discovered it's basically a deprecated package and the right way to use it is eslint on it's own (with ruleset for prettier so it ignores what prettier should do) and prettier on it's own. Then each command runs lightning fast and there is no slowdown. Their docs even go into this issue under Notes on this page:

https://prettier.io/docs/en/integrating-with-linters.html

No doubt tooling can be slow but looking for configuration issues or bad practices is a good place to start if things are slow.

[pdimitar]

Let me put it like this: your second paragraph would take me 2-3 hours (as a backend dev). Does that put things into perspective?

It's never about "I am an expert and can do it quickly".

What frontend devs seem to not realize is that backenders and sysadmins have to occasionally do something quickly on the frontend. And when I visit webpack's site and copy-paste a config and then adjust a few variables and run a command... yeah, it can be faster. Much faster. Not to mention that it rarely works the first time around and the error messages are absolutely not telling me what I do wrong.

---

This isn't intended to flame anything or anyone, mind you.

---

But please understand that for many the frontend tooling is a bitter disappointment because we intend to do a quick tweak and move on and it of course disagrees and I lost half my workday. And as you can guess, the next time it will take me half of my workday again because enough time has passed that I'll forget those lessons. Why can't the thing just be intuitive?

Can I do it better after I become an expert? Absolutely.

But that's the whole point: I don't want to become an expert. I want to install the tool, execute 2-3 incantations and get my work done. And most of the web dev tooling fails miserably at that task.

(btw, GIT is guilty of the same for like 90% of its commands.)

[ofrzeta]

> .. occasionally do something quickly on the frontend. And when I visit webpack's site and copy-paste a config and then adjust a few variables and run a command.

This fails quite often due to subtle differences not only in major but also minor versions of tools such as webpack or babel and because there are so many variables (nodejs version, npm modules etc) in that equation.

[pdimitar]

Not my problem, is it? I have to use the same tools as the rest of my team and those tools are as fickle as a teenager's mood.

There are ways around those problems but nobody from the core team even attempted it (one example: have a stable set of sub-commands that get translated to now-modified-in-next-version internal APIs; is that really so hard? almost every commercial dev has to do it).

But no, let's throw the devs under the bus every time we change our minds.

See, that's why a lot of people hate the JS ecosystem, and that's why this perception will not change anytime soon.

All languages have idiosyncrasies. I'd be an idiot to hate on JS in particular because literally all languages I ever used have strange and weird deficiencies. But that's not it. The ecosystem and the tooling (and for some languages, like Erlang/Elixir, the runtime is also included) make all the difference to novices or casual dippers.

If that experience is bad, then the JS ecosystem will remain the same old meme of youngsters experimenting at the expense of everybody else like it has been viewed for 6+ years now.

---

Don't think I am blaming you for anything. I just ranted and vented. A lot of devs lack the insight to be able to look from the outside and say "hey, if I was coming here for the first time I'd be puzzled by this" -- and that grows to be a big problem when enough time has passed.

[IshKebab]

No amount of configuration tweaking is going to make Webpack fast.