This is childish thinking. Whatever we do, we cannot go back to "before". Which "before"? How do we go back?

You can't regress back to a being a kid just because the problems you face as an adult are too much to handle.

However this is resolved, it will not be anything like "before". Accept that fact up front.

I like how the product image is um... well-used.

There seems to be a great second hand market for the cottage cheese shredder!

They’re like cast iron pans. The flavour builds over time as long as you don’t wash them too thoroughly.

I remember solving this problem before. These are both global components, so you create a single global instance and control them with a global context or function.

You basically have a global part of the component and a local part. The global part is what actually gets rendered when necessary and manages current state, the local part defines what content will be rendered inside the global part for a particular trigger and interacts with the global part when a trigger condition happens (eg hover timeout for a tooltip).

React devs re-discovering DOM manipulation... SMH.

This is, in general, the idea that is being solved by native interaction with the DOM. It stores the graphic, so it doesn't have to be re-instated every time. Gets hidden with "display:none" or something. When it needs to display something, just the content gets swapped and the object gets 'unhidden'.

Good luck.

The post you’re replying to is saying they went FROM always having the component mounted (at least in the component tree if not in the DOM as display:hidden), TO only mounting the component when it needs to be open. They moved from the way you’re talking about, to creating the component/DOM nodes only when needed.

Excessive nodes - hidden or not - cost memory. On midrange Android it’s scarce and even if you’re not pushing against overall device memory limit, the system is more likely to kill your tab in the background if you’ve got a lot going on.

"Devs use React because they how to use the web platform, here's how to do it right" and then posts a vanilla solution that doesn't solve understand or solve the problem. Tale as old as time. Bonus points if covering the edge cases in the vanilla solution and making it work for a second component would involve a tiny homegrown reimplentation of most of React anyway.

Especially when you know the user won't be opening half of those. I did'nt use a global one because the modals themselves have some complex logic inside.

We're efficient once we have the energy, sure. How much energy does it take to go from raw sunlight to a calorie your body is actually able to use, and finally to your dinner table?

All of our food was alive before we ate it. All calories used by living things are efficient. Life is an end unto itself. It does not need to justify its existence by the moral code of technocrat materialism. The fact that this discussion is being had on this board in good faith is morally condemning of our worldview.

Since the original point of this chain was a comparison between the energy efficiency of biological vs machine learning, then we need to be trying to understand if the machine is more efficient than the human. You don't need to make some moral or philosophical argument about existential justification to accept that taking a more efficient approach is better, in that it generally enables more life for the same energy.

If the true, total cost of a machine to perform some task is less than a person to do the same task, then the machine should do it and the person should move to do what the machine cannot. This means more energy is available for everything else, living included.

I hate writing by hand the same way I hate walking through deep sand. It's extra effort for the same distance and I'm mentally way ahead of where I am physically.

Why not try to refine what you have in your mind for a couple of cycles before putting it down to paper, or typing it out?

Mind likes to run in circles with scissors at both hands and hurt itself while trying to think fast. Teaching it to walk slowly results in clearer and more refined results.

Not that person, but because there is an option to use a keyboard and easily edit, reread, reedir and again.

As why go in circles in own head when I can be moving forward with keyboard.

In this age of keyboards, cloud computing and AI, we think being fast is better. We lost our patience, and want everything instantly. However, there are some processes which needs time.

Life is same everywhere. It makes the same trade-offs. Fast growing plants have less mass, they are less dense, and if they are edible, they're less delicious and nutritious.

However, hard woods, strong plants and nutritiously dense foods grow slowly. It's the same for ideas, and human mind.

When you let your brain draw circles on an idea, you start to prune its illogical parts. When you put a speed limiter with a pen, you force your brain to reconsider what it just said to you, and as a result, you get better, more refined ideas in less time actually.

I have written elsewhere. I design my programs, their architecture and algorithms on paper, with a fountain pen. I keep lab notebooks. This allows me to refine everything before hitting my first key on the keyboard. I iterate less, produce more. The algorithms I design come out already refined to a certain degree, and when combined with architectural knowledge, their first iteration come out performant and efficient.

Let me ask you the same question:

Why bang my hands and head to a keyboard while trying to solve a problem while I can solve it with a cup of tea, a nice pen and paper and create elegant code in one go and enjoy all parts of the process, and spend less time as a result?

> Fast growing plants have less mass, they are less dense, and if they are edible, they're less delicious and nutritious.

I suspect you made that up. Mint grows fast and tastes great. Watermelon grows super fast and tastes super great. And plenty of slow growing plants are plain inedible.

It is not even clear what you mean by "nutritious dense". But, my family used to grow both vegetables, fruits and even potatoes/herbs. Speed of growing and how nutritious or tasty they are does not seem all that much correlated to me.

> When you let your brain draw circles on an idea, you start to prune its illogical parts.

You will prune them even gaster and more reliably when you see own thoughts written.

#2 I expect to wind up as a huge win professionally as well. It lowers the investment for creating an MVP or experimental/exploratory project from weeks to hours or days. That ability to try things that might have been judged too risky for a team previously will be pretty amazing.

Public API refers to the user of the class, not the implementer. You never call __init__ directly. __new__ allows modifying object creation itself for the implementer, but the user of the class will never call it.

Said unironically in a discussion about local llms and AI models.

Am I missing something about graphql being in the same metric as redux? They're not remotely in the same domain, are they?

It makes a little more sense when you consider the wider graphql ecosystem, like Apollo or Relay, which normalize all data received and keep your UI up to date automatically. In that light, graphql-the-ecosystem has solved a big part of frontend state management. With graphql and react hooks, I have found no need for redux anymore for typical CRUD needs.

That's what I was kind of thinking, but Apollo is also in the same graph. Seems a bit odd to me.

Hierarchies are possible with an RDBMS, but I'd suggest it's the wrong tool to model them with, unless they're static of course. Really any graph that can't be encoded in the table relationships themselves.