>useEffect was designed to allow shooting yourself in the foot, in a good way.

Ok... no... there is no good way to shoot yourself in the foot (metaphorically or real)

>There's never a situation when react doesnt allow you to do something

That is EXACTLY what I DONT want from my framework:

[allow shooting yourself in the foot] in a good way

>That is EXACTLY what I DONT want from my framework:

Unless you're happy about never going out of the guardrails set by your framework, there's going to come a point where, one way or another, you're going to need to interact with something outside of it. Are you going to wait for an official React-WASM way to interact with WASM (which is going to be using useEffect under the hood anyways)?

Frameworks with no escape hatches are hell. The escape hatch just needs to be bright, bold and with a warning on it that says "there can be demons behind that hatch, watch out".

So, that's accurate, but doesn't correspond to the situation. At all.

'Escape hatches' are definitionally exceptions to the rules, whereas effects in React are standard practice.

Because React evolves in an ecosystem which is wide and varied. It's easy to be Elm and have no escape hatches when you make the language, the libraries, the standard library and the world. It's a bit harder when you have to interact with 30 years of crap.

Sorry for the disgruntled snark in advance:

Heh, we already have that and it is called Elm.

By me, an Elm user until 0.18.

Yeah, it's a right pain to deal with non-Elm things in Elm (including JSON data sources). It's possible but you will want to avoid it. However, I think I'd still take Elm over React if I didn't have to care about anyone else but myself.

Yes