soft_dev_person

I understand that is what you want, but you cannot reserve yourself from being interpreted when posting on a public forum.

The language you chose to use and the details you chose to focus on is what triggered the response. If your point was that the cartoons was distracting, you could have made that clear in a less disrespectful way (or let the content speak for itself), or perhaps consider if it was worth contributing to the discussion.

Again, you double down on one definition of this particular subculture in another reply. It is reminiscent of how others have tried to define what certain subcultures related to sexual orientation (some now more mainstream) entail, while not being part of them, and I hope you understand how this can be problematic. I appreciate that this may not have been your intention.

sneak wanted OP to be less openly queer in their personal blog for their own comfort, due to their own inability to imagine that the subculture OP is part of is more than their own narrow definition of it.

I guess the disrespect is clearer when one has grown up with its many forms, but assuming your request for more context comes out of a sincere desire to increase your understanding, I hope this helped.

Do these metrics count "no framework" as an option? With hooks, context and separation of concerns, most apps can live very well without any "state management framework" at all.

Because complex applications are now delivered as web apps instead of as desktop applications, and these require complex tooling to maintain. Then everyone wanted to use the same tools in other areas (I guess), where it is probably not necessary in a lot of cases. You see similar trends elsewhere (e.g. cloud, k8s), perhaps CV building is the real reason.

Then again, a lot of the complexity is mostly optional these days. But knowing how to avoid it is tricky, given the amount of tutorials online that will happily convince you to use webpack, redux and whatever else that was made for bigger problems as if they should be used everywhere.

I don't envy young programmers these days, the amount of stuff to wade through is just mindblowing.

I probably wouldn't, since it is very use case specific what concerns are relevant. So more a suggestion to get an overview of the security requirements and privacy requirements one needs to deal with at some point and sketch some possible ways to make those requirements easy to solve when the time comes.

Examples of things to consider: zero trust, multi tenancy, permission structures, user data classification (for GDPR removal/extraction requests).

As a European, GDPR has far reaching consequences that may even dictate what other services you rely on. I.e. can you use that SaaS service for your product when it's located outside of the EU/EEC?

Yet, plenty of tools of this caliber have been made illegal (in some parts of the world).

I can guess the modern slaves producing our cheap clothes would have an opinion on that.

Should maybe add security and privacy to that list, in this day and age. Not that it all needs to be implemented right away (depending on jurisdiction you're operating under) but having a plan for how to solve security and privacy considerations and working with that in mind from the start can make it a much less painful experience in the long run.

I did this on my Android as well, intentionally. My Galaxy S20 defaults to an animation speed that is just so horribly slow, everything feels sluggish. It also uses more battery.

I, too, was a bit confused at the frozen arrow in the beginning, until I realized it was just the loading indicator used when animations are disabled (they could probably improve that one). It is the one place where some sort of movement might still be appropriate.

Anyway, I recently disabled this feature due to it breaking the scroll behaviour in Play Store. Ironically the only app (I've noticed) that uses animation for scrolling in a way that makes this accessibility feature break it, making it a very jarring experience.

Instead, I went into developer tools and scaled all animations down to 0.5x. This at least makes all the annoying transitions bearable. I think this setting should also be exposed under accessibility settings.

Good for the 24% of users, then.

It doesn't change the fact that tracking your detailed location and who you are around in combination can be used to determine your affiliations or sexual orientation. If you, with your secure iPhone, are located around numerous people with Grindr installed, they may jump to conclusions.

They are capable of targeting gays or political opponents with this, which is the point of the story.

Android and iOS have almost equal market share in Norway. Worldwide Android is a lot bigger (~70%). This affects most people, just not in the US.

If you want to quickly assess the quality of component libraries like these, especially in terms of accessibility, just take a quick look at their Select/Dropdown implementation.

Their variant breaks all keyboard navigation features and doesn't respond as expected to keyboard only input. If they want to up their game, they should address this before moving out of beta.

> The author talks about non of the downsides of their approach

The whole article is a counterpoint to a common falsehood. The downsides have been overstated a lot already.

> useEffect in your component should be rare.

Route is state too. Loading data based on route is very common. There is no reason to avoid useEffect for triggering side effects based on state or props in components. It's the whole reason it exists...

Or do you only use libraries for loading data, without realizing they rely on useEffect, perhaps?

> I can tell from what you've said so far you use useEffect too much

And I can tell from what you've said that you have fairly limited experience with React, or have not developed a variety of web applications with it.

> Assume I have?

Your statements make that difficult.

> The author here is taking their very valid and necessary use case for the optimization of memoization - non-trivial and expensive operations - and extrapolating from that to "just use useMemo

I would say that was your extrapolation, also it never says use useMemo everywhere.

You mention memo, which is different from useMemo in React, so I'm not sure if you are conflating them.

Either way, the main point is using useCallback by default, and using useMemo for non-trivial computed values. This will help you when your app grows in complexity.

If you understand hooks and why react triggers renders, you probably know when useCallback would not be necessary. However, most don't, and tend to err on the wrong side. Then they end up in hook hell when some component 6 levels deep need to use that callback function in a useEffect.