How is that possible? In Portugal, for me it will be 0,26€ / kWh in January.

Long and complicated reasons, but basically multiple pricing areas within Sweden, no good HVDC connections from the north, where most of our power generation is, and a very power-hungry Germany just over the Baltic.

Just for the card

holy ...

I have not seen any desktop GPU that is competitive with Nvidia or AMD yet. What surprises me is how naive Intel seems to be. It is extremely hard to enter the GPU market right now, so it should expect a lot of years of losses. Hopefully they will continue and fix their drivers and hardware problems so we can have more competition. For Alchemist, if they do not price it extremely aggressively ( like 200$ for a A770 ) they will not get much marketshare, I am afraid.

I think ICat | IDog is perfect. It means exactly that, the value can be of type ICat _OR_ IDog, so in that sense, we can only access properties that are in both of them until we know for sure if we are dealing with a ICat or a IDog specifically.

>Servers are often weaker than many consumer computers anyways, so I don’t thin it’s because it can render faster than your own browser.

Isn't this the other way around? I mean a server is supposed to be fast enough to handle a lot of requests.

An individual server is more powerful than one client, but your client computing power multiplies by your user base.

Same reason DDoS attacks are generally more powerful than DoS attacks.

Power in numbers.

Well, servers often come with more but slower cores.

But servers have a much higher power budget compared to phones or most laptops. That's supposedly the target user base for SSR + hydration.

I don't think the purpose of SSR + hydration is to simply move the wait time from first render to server response, or that servers can somehow render faster. To fully yield the benefits you'd have to enable caching, so that the server spits out something without rendering and the client side can simply hydrate.

Caching is not something individual distributed clients can do, which is why the server is the only way able to reasonably take on this role. You can also easily configure nginx to serve just-in-time caching.

I don't mind dying really and I am in my 40s and haven't accomplished much of what I wanted. However, my life is getting better and better. Better job, better pay, working from home, got a few cats that are amazing for stress and bought a new place for me. As I love to learn new things everyday, life is just getting better and better.

Just get inside a fridge

A reference to an indiana jones movie where one survives a nuke by being inside a fridge before the blast wave flings the fridge quite far. He crawls out, groans a bit, and walks off unharmed.

Brings new meaning to "self-preservation"

Waste of memory by creating new function objects on each render.

Micro-optimisations aren't useful. If you get to the point where the performance cost of inline functions is a bottleneck, you probably shouldn't be using React at all.

Maybe, but I just prefer to have a named function defined with a useCallback and just call it.

That's fine, but that's more of a stylistic preference than a performance concern.

Won’t V8 just optimize this anyway? I doubt there’s any real difference in memory usage.

I am not sure, it has a closure for the 'error' local variable.

Yeah probably best to move this to a function outside the render loop with useCallback

M1 God

M1 Greta in 2030 (when it is "carbon neutral")