Because new buildings these days are invariably the same boring gray dull shit that robs any place of its identity?

What are you on about? Redux is literally about global state everywhere. But with three to four layers of abstractions between.

You define your state globally. Then use hooks to fetch data from that global state, and then "dispatch" aka call actions on that global state. If something else somewhere else updates data in that global state your component will be affected if it uses that data.

But it also requires you to write an insane amount of useless stuff like "define your store, then reducers, then slices, then god knows what" to arrive at almost the same code:

   // redux

   import { useSelector, useDispatch } from 'react-redux'
   import { decrement, increment } from './counterSlice'

   export function Counter() {
     // note how we reach into magical global state that useSelector knows about
     const count = useSelector((state: RootState) => state.counter.value)
     const dispatch = useDispatch()

     return <>
         dispatch(increment())}>Increment
        {count}
         dispatch(decrement())}>Decrement
     ;
   }


   // solid

   // state is immutable. It's also not magical, you explicitly refrence and import it
   //
   // increment and decrement would use a `set` function to update the store to required value
   // see https://www.solidjs.com/docs/latest/api#createstore
   // and https://www.solidjs.com/docs/latest/api#updating-stores
   //
   import { state, increment, decrement } from './counter-store';

   export function Counter() {
     return <>
         increment()}>Increment
        {state.count}
         decrement()}>Decrement
     ;
   }

And you never use only local state. You advocate for Redux in a different comment which is literally a global state where you are going to have something suddenly change somewhere from the point of view of a component.

Let's see:

--- start quote ---

A gun in the Czech Republic is available to anybody subject to acquiring a firearms license. Gun licenses may be obtained in a way similar to a driving license – by passing a gun proficiency exam, medical examination and having a clean criminal record.

the issuing authority (police) firearm owners' database is connected to information needed for a background check and red flags any incidents that may lead to loss of license requirements. Similarly, health clearance by the general practitioner is needed for periodical renewal of license (every ten years).

* also very specific restrictions depending on license *

Obtaining the license requires passing a theoretical and practical exam.

https://en.wikipedia.org/wiki/Gun_law_in_the_Czech_Republic

--- end quote ---

Oh look, already more strict than many states in the US (and some states are busy removing any restrictions).

Let's say you're a teacher with known dissident tendencies. Boom. Suddenly the only place you can get work is one of these remote regions with lax control. Yes there is less government there, and you can even start a book club or something to read and discuss banned literature, and no one will bother you.

But try and get out because you're tired of rural life... and no place in the "mainland" will acept you. Or will only offer you menial jobs and unskilled labor.

This was a very widely and well-used tactic in the USSR. Can't see why China (or any other authoritatian state) wouldn't do the same. Especially China with their current state of surveillance tech.

Strange that you don't like spaghetti, but then praise Redux that is spaghetti exemplified: dozens of functions, and wrappers, and hooks eerywhere. Trying to trace how a value gets changed through the three-four layers of wrappers is like pulling teeth through the anus.

And looking at the current reincarnation of this abomination, it is marginally less spaghetti, and converging on the same signals code that everyone is converging on.

- The Evolution of Signals in JavaScript, https://dev.to/this-is-learning/the-evolution-of-signals-in-...

- React vs Signals: 10 Years Later, https://dev.to/this-is-learning/react-vs-signals-10-years-la...

- Making the Case for Signals in JavaScript , https://dev.to/this-is-learning/making-the-case-for-signals-...

Those two code examples are different because that's the tradeoff that Solid made. It allows Solid to track changes in a uniform way even if the data isn't inside a component. Because in Solid components are just a way to organize code, not a unit of rendering (like in React).

And on top of that if you think that React still somehow has unidirectional data flow, it doesn't. Hooks make it anything but unidirectional. And not that different from signals: https://res.cloudinary.com/practicaldev/image/fetch/s--upMC6... But often less predictable.

See also The Cost of Consistency in UI Frameworks, https://dev.to/this-is-learning/the-cost-of-consistency-in-u... which is slightly related to this.

Even those that you assume "just have it" most likely just have enough means and connections to try and fail and eventually succeed than most of us.

18% of households in the US say they can't afford home internet service: https://ntia.gov/blog/2022/switched-why-are-one-five-us-hous...

This comment has the relevant quote: https://news.ycombinator.com/item?id=35024721

A smart authoritarian government will have these "free" zones as a pressure release valve:

- Most active dissidents jailed

- Active dissidents allowed to flee the country

- Somewhat active ones allowed to "flee the regime to the free-thinking zones far from government control"

/s

And it's hard to overstate, but to also properly explain, how important this is and how it feels like magic when you do it. Because it lets you tap into everything Elixr (and Erlang VM) have to offer on the backend without ever having to think of "how the hell do I bring all that to the client".

My use-cases are: a big chunk of data is being processed, and while its being processed regular updates are sent over PubSub. Most actions a user initiates are long-ish-running and their updates are also sent over PubSub. Things that other users are doing are sent over PubSub and possibly need to be reflected in the UI.

In "traditional" JS-on-the-client-whatever-on-the-server model you have a plethora of questions of how to get that to UI: which endpoints to query, which updates to send over the wire, the formats, the frequence, authorisation, auth...

With LiveView your "client" is an Elixir view living on the server which just updates the view based on those PubSubs (or timers, or Kafka streams, or user-initiated actions, or...) and LiveView takes care of upating the DOM/HTML in the browser.

"Build a real-time Twitter clone in 15 minutes with LiveView and Phoenix 1.5" will give a good overview of this: https://www.youtube.com/watch?v=MZvmYaFkNJI

[1] Built-in in Phoenix, https://hexdocs.pm/phoenix_pubsub/Phoenix.PubSub.html

Those designers were/are more illustrators than designers [1]. Design is, or at least should be, as much about the function of an object as about it's looks. A design that hinders functionality isn't a good design.

[1] I call the modern breed of such designers "Dribbble-driven"

GQL literally allows unbounded queries.

All the "tooling" around like "field complexity", "data loaders" and other hacks are literally that: hacks and workarounds, and they are not even consistently, evenly or even efficiently implemented among the various GQL libraries and frameworks.

> it automatically comes with documentation for your API

Unless it's specified in code, and to create actual documentation you have to run a server, connect to it with a tool, and dump it (can't remember which lib did that, was it in Java or in Go).

> you think that using GQL automatically comes with the infrastructure I described.

This: GQL doesn't come with infra. And for every thing that REST aready has and for every issue that GQL has, and REST doesn't, you need to add more and more infrastructure and "rich ecosystem":

- Caching is literally built-in in HTTP. GraphQL's default method is POST, so to "solve" caching frameworks like Apollo have to act as middlemen unpacking every incoming request and every outgoing response looking for certain fields to figure out what to cache. Of course, this isn't available in other libs and framewroks

- Unbounded queries are literally not an issue in REST (unless you build something weird). In GraphQL you need to "specify field complexity" if you framework allows that

- Your REST endpoints know what exactly is requested, and can have specific hyperoptimised queries for that specific thing. GraphQL is ad-hoc by nature, any query is potentially n+1, so you have the workarounds with dataloaders which by definition cannot be optimised unless your specific framewrok gives additional insights into what's being requested.

Literally everything around GraphQL is "nothing works well, and if you're lucky, a particular graphql implementation for your programming language will have some solutions for some of the problems".

How do I know?

I built a service prototype for an internal tool in 5 different languages with 6 different libs:

- Typescript, Apollo

- Java, graphql-java

- C#, graphql-dotnet

- go, glgen and graphql-gp

- Elixir, absinthe

GraphQL sucks ass for everyting and everybody except client developers who couldn't care less how it looks on the backend