SinParadise

Its the same "solved" pattern, but with the pattern being more deeply rooted in a project.

Its OK magic of technology will swoop in and save us. Any time now.

>I don't think React ever pitched view as a function of state actually. Many in the community latched onto that, and some React-inspired projects tried to make that a thing, but I'm positive that was never the pitch from the core team, in fact very certain of this.

If it quacks like a duck..

> We very rarely need specific minerals.

Because historically we do not have technology complex enough to need specific minerals. Now we do.

> Most of these needs we can fulfill with many different minerals. And the amount of all [1] minerals in earths crust is staggering compared to any foreseeable futre, so we are just going to flip to whatever is easiest/cheapest to dig.

There is another factor at play though: energy required to extract the minerals. Ones deeper in the earth's crust are likely more energy intensive to extract and perhaps even purify. At some point it won't be worth it.

>If we really can't find any more, then billions or trillions of dollars will be redirected to bring lithium extraction from seawater to commercial scale.

And we are probably going to burn fossil fuel to obtain the energy for this?

> We have not run out of any mineral ever and I don't believe we ever will.

Is mineral not a finite resource? I don't understand your source of optimism here.

That imo is our only way out, but this is effectively deus ex machina moment for humanity.

Thats a cool project.

>But I don't think the "pretend it isn't" makes any sense

Well, let me expand a bit more. React's pitch is that view is a function of state, and essentially designed around the idea of an immutable state which re-renders everything when changed. It then offered some APIs to allow fine-tuning of rendering via hooks which either ties with data changes or some rendering life-cycle. To me the API screams of stubborn refusal to let go of the "view as a function of state" mantra: When you encounter a scenario where it breaks the mantra, lets add another lever to handle it. This lever also has to be pulled by you the developer, and it is up to you to know when to do it.

>I actually like React more than Svelte for many reasons, but magic compilers and templates are two big ones.

I don't really have an issue with compilers. They are the accepted magic that bridges between language for people and language for machines. The ideal language might be something that is functional and immutable language that it is easy for us to read, but compiles to the optimized, imperative updates that machine can run well.

I'd probably like React better if it had a compile layer on top of its more functional parts?

As for templates, JSX is probably the one great thing that came out of React. It is no wonder that many other frameworks are embracing JSX, but none of them are really forking the idea of hooks.

I mean, I am OK with magic, but it has to remain magical to me. The moment I have to deal with the magic, I don't want it anymore.

I like Svelte. It embraces the fact that UI is stateful and doesn't try to pretend it isn't.

Not useEffect specifically, but wiring something very stateful like a map library into the React rendering paradigm while keeping the state management in React via useState etc. can be very difficult to do so in a performant way.

I recalling using a lot of useRef to manually tune when to re-render, and in an ideal world I shouldn't be this granular about it.

You can certainly use one of the many React map wrapper libraries to lessen the pain, the pain is still very real, just dealt with by someone else.

70 year old enterprise telecom, but in F#?

You guys have any blog posts detailing this transition?

Not sure if Kotlin is conductive to currying. I find it harder to read with currying, not easier.