Generally have to agree there, but I do feel like there is a reason. ES6 modules (or typescript modules) and the simple fact that the variability is finally dropping:

It seems like there was one specific winner of all of the UI frameworks. React.

There is now pretty much one specific winner to package managers. Yarn.

There is one specific winner for language front-end: Typescript.

There are basically two front-end build tools left: Webpack and CRA (of which is basically a Webpack wrapper with babel and a million other things)

All of the latest npm packages are either coming with ES6 modules or, more interestingly either are completely written in Typescript or at least have @types now. And all that stuff helps people writing JS too.

Disagree on yarn - npm is still trying to keep up and the latest releases are doing well

Seems like within React, Redux/Apollo/plain is splitting the data layer again too

But the yarn/npm is a tiny difference and data layer is much more application specific

A look through the yarn issue tracker tells me it's not time to try it again yet, since the last time it burned me. Maybe some day.

Absolutely not the case. My own estimates are that around 50% of all React apps still use Redux, and the overall download numbers are continuing to increase consistently. I covered this in my Reactathon 2019 talk on "The State of Redux" [0], and my post "Redux - Not Dead Yet!" [1].

In addition, our new Redux Toolkit package [2] and React-Redux hooks API [3] are making it easier than ever to use Redux, and we've gotten a ton of very positive feedback from users who have adopted those APIs.

[0] https://blog.isquaredsoftware.com/2019/03/presentation-state...

[1] https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet...

[2] https://redux-toolkit.js.org

[3] https://react-redux.js.org/api/hooks

I've never understood that position. Hooks and redux solve completely different problems. Why would the introduction of hooks change anything about using redux?

I get Javascript fatigue, and all the criticisms aimed at the language, and while it's not totally ideal, I feel frameworks have helped tremendously by either being opinionated enough that you can do things in a predictable way (angular/vue) or are flexible enough to design complex flows and views as small, easy to reason about components (React/Redux).

I have seen some horrible stuff as an enterprise dev, from poorly constructed jQuery projects, to old frameworks like Struts/Stripes that just get out of hand. No real way to test, full of side-effects and bad choices, TONS of dependencies (outdated/unmaintained UI libraries etc). I often wonder if people complaining about JS and Frameworks have any experience developing or maintaining legacy web applications from the days of yore. Back when the web was young, there just wasn't a good blueprint for how complex web applications should be designed. We've come a long way, and for better or worse, the JS community has made improvements to the language, frameworks, etc, all of which make our jobs SO much easier.

I work with JS as a low percentage of my total work, and recently tried to bring a 2-year-old Vue-based project up to date with the latest versions of everything.

I failed in my task. With these frameworks, given enough time, there ends up being a lot of "deprecated boilerplate" code, either directly or via dependencies. E.g. Vue is closely coupled to Webpack, and Webpack deprecated so many things between versions 2 and 4, that there's essentially no mechanical way to migrate the code. One must figure out every detail of the auto-generated Webpack config from version 2 and figure out how to do the same thing in version 4. (I'm looking at you, CommonsChunk and splitchunks!)

Legacy applications from the days of yore didn't "bit-rot" like this.

Not saying that this isn't a problem, aka dependency hell. And giving some hand-wavy solution like 'well, be more careful about what packages you pull into your project' or 'well, f it, just don't upgrade your version of Vue or Webpack' is also not ideal.

There is another type of hell, where changes to modern browsers or the JS language itself cause the (long abandoned) library code that your entire application is coupled to to break completely. At that point, your only options are to tell your users they have to run the website in 'legacy-mode' in IE, or rebuild an application from scratch, teasing a decade's worth of business logic out of poorly designed code (i.e. business logic in JSP/php tags etc).

The "sharp downtick" is largely a shift from "strongly agree" to "agree". That doesn't seem too sharp to me. Mostly it seems like people are happier with where JS is now. There's less momentum behind changes the language, and fewer large developer-experience-changing features coming.

Maybe by now we're all conditioned to immediately respond with "argh it's moving too quickly" :P

But I totally agree. Things like the various cli tools, widely available documentation and good IDE support for frameworks has made JS a lot better in recent years.

I thought the interesting part was the fact the questions were strictly about JavaScript and not about the overall Browser/HTML/JavaScript ecosystem, which would probably have a stronger negativity bias I suspect.