Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The new wave of React state management

frontendmastery.com

Post reply on HN
Print view View original

71–80 of 310 posts

Re: The new wave of React state management

#71

Post by doodlesdev »

nine_k wrote: post #48
doodlesdev wrote: post #27

I'm pretty sad this is the point we are at with React frontend development, the library is becoming much larger than it's original scope and it's getting bloated while not solving the essential problems that happen. In my opinion the best solution we have right now for frontend JS development is to not use JS or JSX at all and instead use a DSL such as Svelte, this way the compiler abstracts all complication and ther…

Svelte does wonders to code size, indeed. But does it solve the problem of growing state which never gets GC'd when components which used to use it are gone? Does it solve the problem of only redrawing the required minimum (beside the normal VDOM approach)? I'm asking as someone not knowledgeable enough about Svelte.

> Does it solve the problem of only redrawing the required minimum (beside the normal VDOM approach)?

Yes, in fact I think it's actually pretty hard _not_ to redraw the bare minimum LOL. If you want to know more about Svelte (even if you're not looking to develop with it) I HIGHLY recommend listening to this presentation called "Rethinking reactivity" by Rich Harris (the creator) https://youtu.be/AdNJ3fydeao

> But does it solve the problem of growing state which never gets GC'd when components which used to use it are gone?

I think the answer to the question is yes. Although the problem I'm speaking mostly about state management is the source of truth problem. Svelte provides a global store to store data, and data stored on local components are just _variables_ (no useState or hooks or anything complicated) where the Svelte compiler handles everything.

Something else I'm really eyeing right now is SolidJS which takes a very similar approach to Svelte (compiler instead of library) for frontend development but provides an API that's very familiar to React developers so there's not much of a learning curve (although Svelte has a very easy learning curve too).

Re: The new wave of React state management

#72

Post by syspec »

nwh5jg56df wrote: post #54
jitl wrote: post #24

Earlier quoted context omitted.

This is because UI programming is inherently extremely complex, especially compared to something like a stateless API tier running in AWS. It’s stateful software deployed to countless different runtimes on hardware you don’t control. Instead of a smattering of API routes handling well-structured semantic datatypes like `POST /burgers?pickles=false`, input comes in the form of arbitrary UI events from various input de…

We went to the moon some +50 years ago. We ought to have solved "UI programming" already, no? Something is not working

By that logo , SpaceX shouldn't exist.

Re: The new wave of React state management

#73

Post by doodlesdev »

rglover wrote: post #51
doodlesdev wrote: post #27

I'm pretty sad this is the point we are at with React frontend development, the library is becoming much larger than it's original scope and it's getting bloated while not solving the essential problems that happen. In my opinion the best solution we have right now for frontend JS development is to not use JS or JSX at all and instead use a DSL such as Svelte, this way the compiler abstracts all complication and ther…

This is why I'm building Joystick: https://github.com/cheatcode/joystick . It riffs on the old, simple APIs of React but uses pure HTML, CSS, and JavaScript w/o any trickery (I'm also hardcore about not changing the component API so WYSIWYG). The bonus is that it's a part of a full-stack framework (the UI framework has a Node.js counterpart), so wiring up a full app is near-effortless.

Looks pretty interesting, I'm always kind of bothered about the lack of (true) full-stack frameworks for the NodeJS ecosystem that handles accounts, database, frontend, API, etc. like we have for Python with Django or C# with .NET.

Re: The new wave of React state management

#74

Post by acemarke »

ramesh31 wrote: post #68

I'm just tired of the redundant reinvention of new "terms" for literally everything in JS. I don't want to know what an "atom" or a "proxy" or a "thunk" is. These are meaningless abstractions that simplify down to a store and a callback. Stop inventing terms to make yourself feel smart.

FWIW, the term "thunk" is a long-standing CS term that long predates Redux [0] [1] [2].

In fact, my first job back in 2008 involved a C++-based emulator/VM framework, and the devs used "thunk" to refer to jumping from the original program binary out to altered/replacement code written as C++ to add additional behavior or replace functionality.

"Proxy" is also a long-standing term as well that describes wrapping or replacing functionality of a system, which is why it's used for HTTP servers and why it got used for a new JS capability in the ES2015 language spec.

[0] https://en.wikipedia.org/wiki/Thunk

[1] https://stackoverflow.com/questions/2641489/what-is-a-thunk

[2] https://devblogs.microsoft.com/oldnewthing/20081020-00/?p=20...

Re: The new wave of React state management

#75

Post by cercatrova »

kizer wrote: post #65
cercatrova wrote: post #53

Earlier quoted context omitted.

I've often found those that complain about these buzzwords are the people who do not actually do any frontend engineering. There are buzzwords in every language and every library. It's not an indictment of complexity (which exists outside of any one language or library), it is simply the terms of the trade of that particular technology.

I don't know why but front-end terminology always makes me cringe. I know it's useful jargon. I don't know why I have a visceral distaste for them. Maybe because it feels like taking a small, simple thing and making it seem like it's something more. But you're right. I haven't done much front-end at large scales. Only at one employer for a short while.

> Maybe because it feels like taking a small, simple thing and making it seem like it's something more.

Perhaps it makes more sense to treat frontend engineering as thick client desktop development of yore. Websites are no longer small, simple things, they are now the primary apps that many people use (through the broswer and especially through Electron), so there needs to be sufficient tooling around managing that complexity.

Re: The new wave of React state management

#76

Post by sachinraja »

doodlesdev wrote: post #27

I'm pretty sad this is the point we are at with React frontend development, the library is becoming much larger than it's original scope and it's getting bloated while not solving the essential problems that happen. In my opinion the best solution we have right now for frontend JS development is to not use JS or JSX at all and instead use a DSL such as Svelte, this way the compiler abstracts all complication and ther…

How is React not solving essential problems? Suspense solves a pretty essential issue. Also Svelte can quickly increase in bundle size and if you have enough components, it can become bigger than the equivalent in other frameworks: https://github.com/yyx990803/vue-svelte-size-analysis.

Re: The new wave of React state management

#77

Post by rglover »

jeroenhd wrote: post #7

I've used Redux but I've never heard of any of these alternatives. I have no doubt they're popular, but what is it about frontend that makes everyone reinvent the wheel every five years? Everything from the tooling to the tiny details somehow expires and gets recreated in a similar-but-not-similar-enough way that keeps the ecosystem in a constant state of flux. Is it the lack of platform API support? Is it the commun…

A few different problems...

"Necessity is the mother of invention" comes to play here. The reality is that the community hypes certain tools, but in practice, they tend to have gotchas buried far beyond the surface level demos and documentation. The problem with that is that you only figure that out after committing to those tools and using them. This leads to tool abandonment, or in some cases, developers taking a swing at their own version. What they come up with is more often than not a rehash of the old ideas but lacking any "why" or long-term vision.

The other one is employability by obscurity. An old grifter trick is to make something far more complicated than it needs to be as a means to guarantee employment (both on the tool developer side and the end-user side). For the tool developer, the more they can twist and turn their tool (introducing novelty and potentially confusion), the more sought-after their services will be. For the end-developer, they can hold a "monopoly on intelligence" and become difficult to replace in a company because they're the only one that understands that thing. Couple this with the conference talk circuit where you see the same people constantly pitching some new-fangled widget every year and you realize the goal isn't to solve the problem, it's to get paid to look like you're solving the problem.

Another problem is inexperience. A developer might have just enough experience to feel confident at the code-level, but they lack the practical experience to let them know why a certain pattern is incorrect. Assuming that they never get that practical experience, they will continue to iterate the tool into an utter mess or deprecation.

Re: The new wave of React state management

#78

Post by ativzzz »

petilon wrote: post #31
wilde wrote: post #26

Earlier quoted context omitted.

How do changes to that cache get displayed? Your cache emits events that each UI element has to listen to? Congrats you’re using redux! (It would perhaps be more accurate to say that React folks had to reinvent these patterns, but the problems were definitely present in the postback era)

> Your cache emits events that each UI element has to listen to? It doesn't. How often do you have the same information redundantly displayed in multiple places, on the same screen?

It's not even necessarily the same information, but small pieces of one bigger piece that need to be updated once some of the other smaller pieces change

Re: The new wave of React state management

#79

Post by weeksie »

etimberg wrote: post #16
jeroenhd wrote: post #7

I've used Redux but I've never heard of any of these alternatives. I have no doubt they're popular, but what is it about frontend that makes everyone reinvent the wheel every five years? Everything from the tooling to the tiny details somehow expires and gets recreated in a similar-but-not-similar-enough way that keeps the ecosystem in a constant state of flux. Is it the lack of platform API support? Is it the commun…

I think it's because redux is quite painful to use with very modern apps. Most of the time you need something like `redux-saga` or `redux-thunk` to deal with async side effects. I'm not sure which is the most popular today, but sagas are based on generators and trying to use those with typescript is very very painful and the underlying issue [1] is marked as a design limitation in TS itself. In addition, if you want…

You don't need _any_ of that. You can use vanilla redux and put your asynchronous code in middleware.

Re: The new wave of React state management

#80

Post by phreack »

nikodunk wrote: post #43

For anyone struggling with the complexity and boilerplate of Redux, at my day job we added Redux Toolkit (the newly recommended add-on by the Redux project itself!) and it solves most of the verbosity issues! We use it to share all our state logic over mobile and web and it works excellently now. I'd actually recommend Redux w/ Redux-Toolkit, for the first time ever.

There's a library called rematch that's been implementing most of these ideas for a long time, but sadly it didn't get popular enough and it seems to be somewhat lacking maintenance. It was such a pleasure to use (in comparison) that I just can't believe how people ever work with those massive switch statements.
Post reply on HN