Our great sponsors
-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
Hi, I'm a Redux maintainer. A few thoughts:
First note is that while both of Redux's original creators (Dan Abramov and Andrew Clark) later got hired to work on the React team, Redux has always been an independent project, and is not "a React team" project.
Second, per "why Redux": the primary goals of Redux are 1) helping developers be able to understand where/why/when/how state has changed over time in the app, 2) predictable data flow, 3) writing more app code as predictable pure functions [0] [1]. It's true that earlier Redux usage often did involve a lot of unnecessary boilerplate. The good news is that "modern Redux" with our official Redux Toolkit package is much easier to learn and use [2] [3] [4].
Next, while I agree that modern front-end development _is_ overly complex and the tools and configuration _are_ often hard to understand, the post is unnecessarily dismissive. I'm a big believer in the idea that it helps to understand historical context, why tools were invented, and what problems they were designed to solve. The JS ecosystem has evolved dramatically in the last 15 years, including the types of apps we build and the scale of those codebases, the APIs available in browsers and Node, module formats and ES syntax versions, and many other constraints.
I'd specifically suggest reading some posts on why tools like bundlers exist and how module formats have changed over time as background that explains why modern front-end dev normally involves these tools [5] [6].
(It's also somewhat ironic that the author complains "why isn't developer experience a priority?", given that these tools and patterns were _created_ to help with DX.)
[0] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...
[1] https://redux.js.org/tutorials/essentials/part-1-overview-co...
[2] https://redux.js.org/introduction/why-rtk-is-redux-today
[3] https://redux.js.org/tutorials/essentials/part-2-app-structu...
[4] https://blog.isquaredsoftware.com/2022/06/presentations-mode...
[5] https://www.swyx.io/jobs-of-js-build-tools
[6] https://blog.isquaredsoftware.com/2020/11/how-web-apps-work-...
Hey, thanks for the feedback. Sorry for being dismissive, I can rant when I am angry. :) I checked the new Redux and honestly, it's still a bit confusing. For eg,
> export const { todoAdded, todoToggled } = todosSlice.actions
Where is ".actions" coming from? Because in the object we have "reducers". Is it implicitly generated? Although boilerplate has been greatly reduced, it seems the project is still sticking to the same set of terms, just hidden from the plain sight. Ultimately, I want to understand why we need anything more than actions and state. You call actions, that update the state, that updates any component which is subscribe to that store. What am I missing?
On Bundlers, my problem isn't the fact that they exist, but that you there isn't one that works easily out of the box. What compounds the problem is that practical examples are often missing from docs. This issue is a great example[1]. Crucial plugins are missing from the bundler. Even if you add plugins, you run into problem like sourcemap isn't being generated.
[1]: https://github.com/rollup/rollup/issues/385