161–170 of 398 posts
Earlier quoted context omitted.
I've been doing some research recently and it continues to be by far the most popular state management framework for React. The fact that there are alternatives doesn't mean that most projects have abandoned it.
Has it occurred to you that maybe “state management” is not something you need a framework for?
It's artificially inflated and I'm seeing this in almost all areas, not just frontend. Some of the projects I've seen could have been reduced in size multiple times with no effect on the outcome whatsoever. In one instance I rewrote a GUI app and made it 15 times smaller (!), that's my absolute record to date. Been wondering for years, so you need to actually be inventive to add unnecessary complexity, it's not that…
One of the best examples of this complexity inflation problem I always see is the Redux pattern in frontends. This pattern comes with a lot of overhead, a lot of things that need to line up (Actions, Reducers, Actioncreators, Selectors, ...). And most of the time the applications that use it are completely trivial. If you remove Redux, half of the code is gone, it's faster and easier to understand and extend.
I'll definitely agree that Redux _has_ been overused.
But it's also worth understanding _why_ Redux was created in the first place and why it got so popular.
As a brief recap: the first major wave of JS MVC frameworks had major flaws. Angular's dirty checking didn't scale and was impossible to debug. Backbone's event-based system led to events ricocheting around the app with no way to trace what would happen when a given value changed. Additionally, manual DOM manipulation made it hard to manage ongoing changes to the UI over time.
This led to Facebook designing React to let devs write encapsulated components with predictable output and behavior, but React didn't have a solution for larger global state. Facebook later announced a "Flux Architecture" concept that tried to make larger app state updates predictable through centralization.
The React community ran with this idea and produced dozens of Flux-inspired libraries. Redux took the ideas from several of those Flux libraries, and applied Functional Programming principles, with the goal of making it easier to understand when, where, why, and how your state is being updated and changing over time.
The community then adopted Redux because A) it was the best of all the Flux implementations, B) it _did_ address the issues people were running into around state management, C) it was designed to work well with React, and D) it also incidentally helped work around limitations in React's original Context API. (I've talked about the original intent and purpose extensively in my blog posts and conference talks [0] [1].)
After that, yes, Redux _did_ get shoved into many applications that didn't need it, in the same way that React has been used for many sites that didn't necessarily require that setup.
So, we've always recommended that people actually take the time to evaluate the specific problems they need to solve in their app, and make an informed decision on whether Redux is an appropriate solution for those problems [2].
Beyond that, we've specifically designed and built our official Redux Toolkit package [3] [4] to eliminate the old "boilerplate" concerns. "Modern Redux" with Redux Toolkit and React-Redux hooks is _much_ easier to learn and use than the original Redux patterns, and we get highly positive feedback on a daily basis from folks who enjoy using RTK. We also built an "RTK Query" data fetching and caching API [5], as data fetching is the most common thing that apps need to do today.
[0] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...
[1] https://blog.isquaredsoftware.com/series/presentations
[2] https://redux.js.org/tutorials/essentials/part-1-overview-co...
[3] https://redux.js.org/introduction/why-rtk-is-redux-today
[4] https://blog.isquaredsoftware.com/2022/06/presentations-mode...
Earlier quoted context omitted.
One of the best examples of this complexity inflation problem I always see is the Redux pattern in frontends. This pattern comes with a lot of overhead, a lot of things that need to line up (Actions, Reducers, Actioncreators, Selectors, ...). And most of the time the applications that use it are completely trivial. If you remove Redux, half of the code is gone, it's faster and easier to understand and extend.
To be fair most front-end projects have abandoned redux now. It was for sure boilerplate hell.
- https://blog.isquaredsoftware.com/2022/07/npm-package-market...
Unpopular biased opinion. Frontend development is mostly done by people who are into visual things and less into logic. Unlike backend engineering, where people working are primarily choosing technology based on logic/merit and less by visual appearance. This leads to the adaptation of large number of garbage frameworks in frontend primarily because their landing pages look visually appealing. After some time fronten…
> Unlike backend engineering, where people working are primarily choosing technology based on logic/merit. Sometimes I wish I could do the crying-while-laughing emoji on HN. Backend devs have biases and get tricked into making the wrong choices just like everyone else.
Earlier quoted context omitted.
This. No user wakes up and says, "I gots to find me a UI built with React* today, or I'm going to cry." Ever. Users. Don't. Care. We keep adding tech and tools and experiences - if you asked users - aren't improving all that much. * Or whatever technolgy being championed.
I dunno. Lots of users seem to wake up and say “Gimme a UI with rich interactions, super low latency, offline support, and real-time sync.” Even for B2B “back-of-office” software, the standards for software usability are really high, especially for new entrants. Those kinda features are hard without a pretty complex frontend. Not saying those things are always necessary, or that people don’t add bells and whistles wh…
I do think there's a place for real time web UIs in business apps. I spent a chunk of my career replacing green screens with web UIs. Usually ended up slowing people down because they lost the ability to chain commands.
With green screens they'd know that the navigation to change and address was like 3, 2, down, down, enter. So they'd get there in a split second. With a web UI they'd have to wait for the screen to render in between each action. Ultimately it's much slower.
Their complexity is so big, that even great programmers have a hard time creating browsers from scratch. The latest example of this is probably Ladybird[0]. Andreas Kling and others have worked on it for years("Just under 1000 days for a bunch of hackers to build a new JavaScript engine"[1]) and they know it will require way more time to just catch up the Chrome[2].
A year ago I started to build SkyAlt[3], which doesn't have anything to do with the web. It's not just a browser, but also an IDE where you can create apps with few lines of code or just drag and drop stuff on canvas. It's written in C and it's only 25K LOC. Compiling takes a few seconds and binary is under 1MB. There are tons of features that need to be built, but I like its simplicity(relative to the web).
[0] https://github.com/SerenityOS/serenity/tree/master/Ladybird
[1] https://twitter.com/awesomekling/status/1596783757125898243
[2] https://twitter.com/awesomekling/status/1595387284035145729
There are three main points I want to add to the conversation.
1. UIs actually have a lot of complexity. The number of states they can be in is often higher than what you see in other disciplines of software engineering. They also have to contend with managing data fetching over unreliable networks, including balancing bundle size. Additionally they are notoriously hard to test because “does this feel right to a user” is hard to encode programmatically.
2. The grass isn’t greener on the other side. I see a lot of people complaining about the needless complexity of the frontend stack but I don’t think they’ve worked in a modern backend engineering or data engineering project. Modern backend eng is a morass of kubernetes configuration, needless microservices and overuse of async queues, for example. Feels a lot like frontend in terms of accidental complexity. So I’d argue that this is less of a frontend problem and more of an industry wide thing (cynically, it might be a ZIRP thing)
3. With that said there certainly is needless accidental complexity in frontend and I am convinced content marketing is 100% to blame. An easy way to hire engineers is to create an open source project and write a blog post convincing people to use it. This is good for the company and good for the careers of the engineers who worked on it, but can cause people to needlessly complicate their tech stack if they can’t cut through the noise.
It is media that changed quite a lot - spectrum of devices that we need to show our UI on.
We had pretty much fixed 80x24 character terminals, then we had 640x480 pixel grids, sometimes 800x600 and more. But at that times you can still assume that pixel is presented to the user as a square of 1/96 x 1/96 of inch.
Such fix allowed us to use UI designs nailed down to pixels grids. That was time of flourishing WYSIWYG UI editors. Alice, designing her UI in Delphi (or VB) editor, can be sure that Bob will see it in the same way. Her cool 16px icons and bitmap fonts will make Bob and friends happy.
When we needed some "extremely cool" stuff at that time we were providing bitmapped skins. Remember WinAmp (https://skins.webamp.org/)?
Time is passing by and we have now huge variety of devices with different pixel densities (96ppi, 192ppi, 300+ ppi) and pixel grid sizes - from watches to wall sized TVs. But we still want to show the UI on all of them in reasonable manner.
The solution is to change paradigm an so to use a) vectors for UI definitions and b) flexible/adjustable UI definitions that are detached from pixel grids.
Web, as a UI platform, desperately needed vector UI with flexible layouts as the very same web page needs to be presented on all platforms|devices in reasonable manner. And so it was the first one that departed from fixed layouts.
So UI design have changed from simple 2D painting (physical brushes and canvas, paint.exe ... Delphi/VB/Glade IDEs) to procedural and rule (layout, style) definitions.
We speak now in quite different UI language and that's what was changed really.