I agree about that specific patterns post being a bad example... but if you google for "react patterns" you won't be starved for examples of more terrible drivel. That's just what's out there, people repeat it ad nauseam. So _good luck_ to anyone who really does want to learn the right thing. From that standpoint, that article is as good or bad as most others out there (old man shakes fist at dev.to).
Even the venerable libraries like useQuery introduce as many surprises as they do benefits. The complexity cost of understanding what is going on under those 20 LOC is quite high – you need to understand "stable values" (which is only relevant to React components), re-renders and how they're triggered, maybe need to understand how graphql fragments are collated into one query document... maybe need to know when useRef is the right way to memoize over useMemo.
I agree with the author, that it feels insane. I would even add to the insanity the lack of quality when searching for help, and the weird rabbit holes that GPT can send you down if you don't already know what "good" looks like.
Yes, it's bad code, and aren't we all having fun laughing at the anonymous dev who wrote it.
However, I've seen this kind of code in the wild, and I'd be shocked if you hadn't, too. _Who_ wrote it matters a lot less than the fact that _so many people_ write it. I think that React has optimized for developer velocity, but the primitives make it so easy to shoot yourself in the foot, that in a large codebase with lots of devs, it becomes hard to avoid.
I was one of the Ello devs (mobile, then web, then backend, then all of it).
My guess is that you'll have some diehard fans early on - Ello did, and they stayed to the end (thanks!) and they'll bemoan every single change - just roll with it, trust yourself but also listen to them.
If you get some success you will have a spammer problem (esp porn), but if you limit (better: don't have) public feeds maybe you can avoid the worst of this. Mutual follow makes sense as a way to limit the blast radius of bad actors, but then people will get spammed by friend requests. It SUCKS. Maybe you punish accounts that blast lots of requests but get very few follows back. We did something like this.
Actually one idea that I think would work well: once you have a "this is a spam account" determination, hide those spam accounts from real users, but let them engage with other spam accounts. This will cost you some compute time, but it will give them the feeling that they are being successful without distracting users.
There is a very common thread here- the objc users are happy where they're at, the Swift fans don't understand and want to tell them why their opinion is wrong.
My god, sit down and just nod and say to totals "oh you like ObjC, neat ", or better yet try to understand what they're saying. You do not have to offer your trite condescension.
ObjC is a fantastic language, Swift is fine too but the compiler is slow and breaking changes to the language are painful.
The migration assistant? FFS it only goes so far, and only when it works.
Has anyone mentioned the Book of the Long Sun by Gene Wolfe? If not, I will, and if so, I second it.
Other favorites are Ted Chiang's stories, Children of Time, Dune, and if you want some real escapist but thoroughly fun pulpy hilarity: Dungeon Crawler Carl
I've been enjoying RubyMotion since its inception, so I'm always surprised by how many people haven't tried it. It's been a huge boon to writing apps.
I cut my teeth on app builder/interface builder about 10 years ago, back in college, and I have never learned to love the GUI approach to building UI (nor do I care for the XML/XAML approach of android/xamarin - just code, thank you).
Since then I learned python, ruby, and don't feel any desire to go back to strongly typed languages. Anyway, I hope more and more people get fed up with Swift and join us in the RubyMotion camp. It's a ton 'o' fun. ;-)
If you already have a comfortable work flow, I would not encourage you to migrate just for the sake of it, but having the option to write a native app in Ruby is very compelling to a lot of people who might otherwise not be interested in writing a native mobile app.
RubyMotion supports xib files, storyboards, xcdatamodel files, and Android XML files (and localization files, etc), so if you ARE interested in switching, you don't have to stop using those if you're already used to them.
Even the venerable libraries like useQuery introduce as many surprises as they do benefits. The complexity cost of understanding what is going on under those 20 LOC is quite high – you need to understand "stable values" (which is only relevant to React components), re-renders and how they're triggered, maybe need to understand how graphql fragments are collated into one query document... maybe need to know when useRef is the right way to memoize over useMemo.
I agree with the author, that it feels insane. I would even add to the insanity the lack of quality when searching for help, and the weird rabbit holes that GPT can send you down if you don't already know what "good" looks like.